Hacker News new | ask | show | jobs
by waynenilsen 2196 days ago
How can we further decentralize this such that the entire app runs "without any servers"? Sadly it is so close but the realities of ipv4 and local subnets definitely makes this more difficult. I always thought that this is part of what webrtc was trying to solve
2 comments

Bootstrapping a distributed swarm is always a tricky proposition. Bittorrent clients use a few endpoints to bootstrap their dht, and then upgrade to p2p after that. I think that's a good compromise, especially if you can have a number of highly-available options to cycle through.

With Squawk[1] we do the initial signaling through our own servers via websocket, and a key registry for authing peers to each other, but after that, all the fun stuff happens p2p. The protocol level data (who's speaking, which group they're speaking to, whether they are muted, etc) flows entirely p2p over data channels, and since we're audio only we made the decision not to use SFUs but rather do a full mesh architecture (massive PITA but it does scale well to 20-30 peers) with geo-optimized TURN servers when people need to punch through NAT (but TURN does not terminate ssl).

[1] https://www.squawk.to

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
> you'll need some other channel to exchange the peers connection data

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!