You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Are you reporting a bug? Use github issues for bug reports and feature requests. For general questions, please use https://discuss.yjs.dev/
Try to report your issue in the correct repository. Yjs consists of many modules. When in doubt, report it to https://github.com/yjs/yjs/issues/
Is your feature request related to a problem? Please describe.
Currently y-webrtcuses a custom server for signaling. I think this is not ideal because it's a comparatively niche thing. Sometimes public servers go down (#43), creating a big headache for app developers that now have to set up a new server (that might go down as well). Having a custom server also adds maintenance costs.
I'm not 100% sure this is a good idea, and I didn't look into details of how the current signaling server works, or how Centrifugo works. It's just a high-level idea that I think it makes sense to strive for.
The text was updated successfully, but these errors were encountered:
I had the same concerns and went ahead by creating a Rust-based signaling server here. You can host it for free on fly.io.
I'm currently using it for my app and I expect to maintain it in the future.
Posting it here in case anyone is interested :)
WofWca
changed the title
Use existing signaling server implementation
Use existing (3rd party) signaling server implementation
Nov 13, 2023
But it's probably even easier than this now since Deno 2 supports more of the Node APIs and you can probably just use the node version.
NOTE: Deno Deploy is a serverless runtime so peer discovery will depend on which regional server you are connected to (afaik there is no way to connect to specific server) so in this case you might want to deploy the server to Fly.io (single instance) instead (both Node.js and Deno are supported).
Checklist
Is your feature request related to a problem? Please describe.
Currently
y-webrtc
uses a custom server for signaling. I think this is not ideal because it's a comparatively niche thing. Sometimes public servers go down (#43), creating a big headache for app developers that now have to set up a new server (that might go down as well). Having a custom server also adds maintenance costs.Describe the solution you'd like
Rely on another existing server that can be used for signaling. For example, https://github.com/peers/peerjs-server. Or, I heard, you can use https://github.com/centrifugal/centrifugo for signaling (there is a concept of rooms (channels) as well).
Describe alternatives you've considered
None
Additional context
I'm not 100% sure this is a good idea, and I didn't look into details of how the current signaling server works, or how Centrifugo works. It's just a high-level idea that I think it makes sense to strive for.
The text was updated successfully, but these errors were encountered: