Well technically it is possible to avoid the signaling server, but you'll need some other channel to exchange the peers connection data. This is pretty inconvenient though. But a signal server is a rather light thing and easy to install on a location you trust: https://github.com/holtwick/briefing/tree/master/signal
Comments
Well technically it is possible to avoid the signaling server, but you'll need some other channel to exchange the peers connection data. This is pretty inconvenient though. But a signal server is a rather light thing and easy to install on a location you trust: https://github.com/holtwick/briefing/tree/master/signal
Perhaps using IPFS to pin the data temporarily and share that hash between the peers?
That's a good idea. I don't know the internals of IPFS, but the related https://libp2p.io/ looks promising. Follow up https://github.com/holtwick/briefing/issues/52
I did a POC of this over a year ago [0]. Now, with better libp2p-js library, it is surely much easier/better nowadays.
0 - https://github.com/cretz/webrtc-ipfs-signaling
If you can figure out how to share that hash, you may as well just share the offer.
Yes, serialization is the issue. URL length is technically unlimited but in practice very long urls don't work out so well
Thank you for making both the client and server sides of this video chat application open source.
The only missing piece it seems is the STUN/TURN server. Would you have a plan to also release it?
I use coturn. Find installation details here https://github.com/holtwick/briefing/blob/master/app/INSTALL...
Oh, I didn't see that. Thanks so much for sharing!