Proposal: centralized internal event layer for future integrations #38

New Issue

MrUnknownDE · 2026-04-05T16:15:48+02:00

MrUnknownDE commented

2026-04-05 16:15:48 +02:00

Originally created by @Sakura1618 on 3/7/2026

Hi, and thanks again for the review and feedback on my webhook export PR. https://github.com/vrcx-team/VRCX/pull/1678

After reading your comments, I agree that the current PR is too large, too intrusive, and was submitted too early without first discussing the design and scope. The implementation I proposed is closer to a working prototype than to a maintainable upstream change.

I would like to restart the discussion at a smaller and more architectural level.

Problem

VRCX already has many meaningful state changes and user-facing actions that could potentially be useful for future integrations or tooling, such as:

notification events
friend state/location changes
self/world/instance changes
app / VRChat lifecycle updates

My previous approach tried to export those directly by inserting webhook emission calls into multiple stores and methods. As you pointed out, that creates a lot of coupling between domain logic and integration behavior, and makes the solution fragile and difficult to maintain.

Proposal

Instead of discussing webhook delivery directly, I would like to propose a more limited first step:

Introduce a centralized internal event layer that can be used by future integrations, debugging tools, or optional exporters.

The goal of this layer would be:

provide a single internal mechanism for emitting app/domain events
reduce the need to scatter integration hooks across multiple stores
keep event production separate from delivery/export concerns
allow future consumers (logging, debugging, webhook export, etc.) to subscribe in one place

Non-goals for this discussion

I do not want this issue to propose or require the full webhook feature yet.

Specifically, this issue is not about:

webhook UI/settings
delivery guarantees
retries / queues / batching
rate limiting / throttling policy
public API stability guarantees
committing to a finalized external event contract right away

Those should only be discussed later if an internal event mechanism is considered a good fit for the project.

Possible shape

At a high level, I am thinking about something closer to:

a small internal event bus / dispatcher
event definitions documented in one place
a limited number of initial producers connected to it
no external delivery by default

This would make it easier to discuss event naming, schema shape, and subscription points before exposing anything externally.

Why I am opening this issue

I want to check whether this direction is aligned with how you would prefer such functionality to evolve in VRCX.

If the idea itself does not fit the project, that is useful to know early.

If the idea is acceptable, I can prepare a much smaller follow-up PR focused only on the internal event layer, without webhook delivery or UI.

Thanks again for the feedback.

*Originally created by @Sakura1618 on 3/7/2026* Hi, and thanks again for the review and feedback on my webhook export PR. [https://github.com/vrcx-team/VRCX/pull/1678](url) After reading your comments, I agree that the current PR is too large, too intrusive, and was submitted too early without first discussing the design and scope. The implementation I proposed is closer to a working prototype than to a maintainable upstream change. I would like to restart the discussion at a smaller and more architectural level. ## Problem VRCX already has many meaningful state changes and user-facing actions that could potentially be useful for future integrations or tooling, such as: - notification events - friend state/location changes - self/world/instance changes - app / VRChat lifecycle updates My previous approach tried to export those directly by inserting webhook emission calls into multiple stores and methods. As you pointed out, that creates a lot of coupling between domain logic and integration behavior, and makes the solution fragile and difficult to maintain. ## Proposal Instead of discussing webhook delivery directly, I would like to propose a more limited first step: **Introduce a centralized internal event layer** that can be used by future integrations, debugging tools, or optional exporters. The goal of this layer would be: - provide a single internal mechanism for emitting app/domain events - reduce the need to scatter integration hooks across multiple stores - keep event production separate from delivery/export concerns - allow future consumers (logging, debugging, webhook export, etc.) to subscribe in one place ## Non-goals for this discussion I do **not** want this issue to propose or require the full webhook feature yet. Specifically, this issue is **not** about: - webhook UI/settings - delivery guarantees - retries / queues / batching - rate limiting / throttling policy - public API stability guarantees - committing to a finalized external event contract right away Those should only be discussed later if an internal event mechanism is considered a good fit for the project. ## Possible shape At a high level, I am thinking about something closer to: - a small internal event bus / dispatcher - event definitions documented in one place - a limited number of initial producers connected to it - no external delivery by default This would make it easier to discuss event naming, schema shape, and subscription points before exposing anything externally. ## Why I am opening this issue I want to check whether this direction is aligned with how you would prefer such functionality to evolve in VRCX. If the idea itself does not fit the project, that is useful to know early. If the idea is acceptable, I can prepare a much smaller follow-up PR focused only on the internal event layer, without webhook delivery or UI. Thanks again for the feedback.

MrUnknownDE closed this issue

2026-04-05 16:15:48 +02:00

Sign in to join this conversation.

No Label

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/VRCX#38