Provide a websocket interface for OSC events

[bdunderscore]

What's the idea?* Please provide a way to have VRChat connect out to a websocket URL, and send/receive OSC events and avatar configuration data down that websocket. This would allow for building server-side OSC-ish applications without needing to run an application on the user's machine.

Is there another way? Running an application on the user's PC, with full access to their computer.

Additional context One of the challenges of OSC apps today is that you need to run an application on your computer, with full OS level access, in order to do anything with vrchat. For some use cases, it may be sufficient to run an application server-side, however. Providing a way to attach VRChat to a websocket URL would allow VRChat to interact with ordinary webapps without needing to grant any special access to the user's PC, and would be a much safer experience than running sketchy code from the internet.

[yewnyx]

Slightly different take on WebSocket. As it would need to be merged into this one anyways to merge the discussion, I'm appending my suggestion here as a comment rather than splitting it.

Problem

OSC over UDP makes sense for high-frequency short-lived events, which suits sensory/physical inputs, but some use cases require reliable delivery rather than high-update-rate disposable events.

I have additionally heard (unsourced) that UDP on Windows can be somewhat error-prone, something which anecdotally matches my experience, albeit without an thorough root-cause investigation.

Suggested Solution

Use a library such as websocket-sharp (MIT licensed) to listen on a websocket in a similar fashion to the current OSC method as an alternate endpoint for an app to connect to and send/receive avatar parameter updates. It also allows for a hybrid HTTP+WebSocket setup.

As a bonus it might be easier to define an API by which one could query the full set of current avatar parameter values.

Additionally, it could also be possible to write a reusable proxy to fit the use case that the OP suggests; delegating event delivery to a remote server.

Alternatives Considered

• While OSC over TCP could technically provide reliable transport, the quality of OSC libraries is fairly inconsistent. WebSocket by contrast has many well-tested and battle-hardened clients in virtually every language and is even included in standard libraries (such as C#'s).
• MQTT is a protocol whose addressing scheme is substantially similar to OSC's, and additionally provides delivery guarantees (at least/exactly/at most once), and is used for delivering mission-critical payloads at scale.
  • MQTT has reasonably mature clients and servers and is used in production by many companies albeit as backend infrastructure.
  • It's a possible fit but tends to suit a spoke-hub topology more so than point-to-point like OSC or WebSocket.