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
[x] Are you reporting a bug? Use github issues for bug reports and feature requests. For general questions, please use https://discuss.yjs.dev/
[x] 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, it requires reinitializing the provider whenever a signaling server needs to be added or removed. Since y-webrtc is a peer-to-peer module, it would make sense to allow signaling servers to be dynamically managed without disrupting existing connections.
In many peer-to-peer communication applications, a central server is not necessary. Each peer could potentially host its own signaling server. Enabling dynamic signaling server management would improve flexibility, especially when peers join and leave, allowing new servers to be added or removed as needed.
Describe the solution you'd like
I would like the y-webrtc provider to support dynamically managing signaling servers. This would allow signaling servers to be added or removed on-the-fly, keeping the provider and existing connections intact, and adapting to peer changes in a decentralized setup without needing a full provider reinitialization.
API suggestion:
// Initialize the provider with an initial list of signaling serversconstprovider=newWebrtcProvider('my-room-name',yDoc,{signaling: ['wss://signaling-server-1.com','wss://signaling-server-2.com'],});// Add a new signaling server dynamically without reinitializing the providerprovider.addSignalingServer('wss://new-signaling-server.com');//=> ['wss://signaling-server-1.com', 'wss://signaling-server-2.com', 'wss://new-signaling-server.com']// Remove an existing signaling server by URLprovider.removeSignalingServer('wss://signaling-server-1.com');//=> ['wss://signaling-server-2.com', 'wss://new-signaling-server.com']// Optionally, provide a list of signaling servers to reset or replace the current listprovider.setSignalingServers(['wss://another-server.com','wss://yet-another-server.com']);//=> ['wss://another-server.com', 'wss://yet-another-server.com']
Describe alternatives you've considered
One alternative is to continue reinitializing the provider each time a signaling server needs updating. However, this disrupts all active connections, requiring reconnections and causing delays and potential data inconsistencies during the reinitialization process.
Additional context
Supporting dynamic signaling server management would make real-time, decentralized collaborative applications more robust, particularly in scenarios where signaling servers are peer-hosted and can change frequently. Allowing servers to be added or removed as peers join or leave would enhance resilience and scalability, reducing reliance on a central server.
I'm a sponsor 💖
This feature is critical for my project.
The text was updated successfully, but these errors were encountered:
Checklist
[x] Are you reporting a bug? Use github issues for bug reports and feature requests. For general questions, please use https://discuss.yjs.dev/
[x] 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, it requires reinitializing the provider whenever a signaling server needs to be added or removed. Since
y-webrtc
is a peer-to-peer module, it would make sense to allow signaling servers to be dynamically managed without disrupting existing connections.In many peer-to-peer communication applications, a central server is not necessary. Each peer could potentially host its own signaling server. Enabling dynamic signaling server management would improve flexibility, especially when peers join and leave, allowing new servers to be added or removed as needed.
Describe the solution you'd like
I would like the
y-webrtc
provider to support dynamically managing signaling servers. This would allow signaling servers to be added or removed on-the-fly, keeping the provider and existing connections intact, and adapting to peer changes in a decentralized setup without needing a full provider reinitialization.API suggestion:
Describe alternatives you've considered
One alternative is to continue reinitializing the provider each time a signaling server needs updating. However, this disrupts all active connections, requiring reconnections and causing delays and potential data inconsistencies during the reinitialization process.
Additional context
Supporting dynamic signaling server management would make real-time, decentralized collaborative applications more robust, particularly in scenarios where signaling servers are peer-hosted and can change frequently. Allowing servers to be added or removed as peers join or leave would enhance resilience and scalability, reducing reliance on a central server.
The text was updated successfully, but these errors were encountered: