This is a companion issue for features proposal to yrs-webscoket (y-websocket compatible Rust library).
Support for passing messages of any size: right now WebRTC has a limitation over the max message size. This limit can be easier reached with bigger documents - esp. 16KiB limit for Firefox ↔ Chrome. While this should be solved at a transport level, in practice the issue stays and somebody has to fix it. We could add message chunking/assembling at y-sync protocol level ie. by using y-sync protocol extensions capabilities. Also add configuration option to message chunk size (make it 16 KiB by default for seamless support between all browsers).
Support multiplexing single connection over multiple documents: right now the limitation of y-webrtc WebRTCProvider is that it requires a unique connection per document. If users have multiple active documents, they need multiple active connections. WebRTC support having multiple non-blocking data channels over a single connection and we should support this as well. Having extra data channels doesn't cost anything. The only limitation of the WebRTC protocol itself is that AFAIK all data channels must be defined up-front and they cannot be added/removed while connection is active.
Support alternatives for signalling server: currently to exchange signalling info we need a hosted WebSocket server. It would be great if we could abstract that part to allow alternative options like ie. Apple's Bonjour discovery protocol. EDIT: after checking for available options, it seems that currently browsers don't support bonjour/zeroconf, the only option would be to run signalling server over ie. bluetooth, which doesn't seem to be very useful atm. for the scope of this library.
Since y-webrtc is build on top of simple-peer, some of these changes should be probably implemented over there. We might potentially contribute to that project, fork it if necessary or thing about alternatives.
This is a companion issue for features proposal to yrs-webscoket (y-websocket compatible Rust library).
WebRTCProvideris that it requires a unique connection per document. If users have multiple active documents, they need multiple active connections. WebRTC support having multiple non-blocking data channels over a single connection and we should support this as well. Having extra data channels doesn't cost anything. The only limitation of the WebRTC protocol itself is that AFAIK all data channels must be defined up-front and they cannot be added/removed while connection is active.Support alternatives for signalling server: currently to exchange signalling info we need a hosted WebSocket server. It would be great if we could abstract that part to allow alternative options like ie. Apple's Bonjour discovery protocol.EDIT: after checking for available options, it seems that currently browsers don't support bonjour/zeroconf, the only option would be to run signalling server over ie. bluetooth, which doesn't seem to be very useful atm. for the scope of this library.Since y-webrtc is build on top of simple-peer, some of these changes should be probably implemented over there. We might potentially contribute to that project, fork it if necessary or thing about alternatives.