🧵I’ve been pretty quiet on the #p2p stuff lately. We’ve been heads down. Here’s why.

Buffering packets into the network is great for data that can be eventually consistent.

But with things like video, audio, actually any kind of real-time, you want to stream directly to the other peer. But that doesn’t always work because there is a pretty common case where two peers have incompatible NAT types and they can’t connect directly!

We solved this with peer-proxies.

When peers join, a peer that is introducing them can see that they have incompatible nat types and can elect a peer (NOT A SERVER, A PEER) to be a proxy. Peers have a streaming bandwidth limiter similar to the packet limiter.

@heapwolf It's cool how all the p2p protocols are coming to similar feature sets. Hyperswarm and libp2p (and I think there was a BitTorrent spec at one point?) do pretty much the same thing. Also dates back to ICE stuff that got developed for VoIP systems back in the day.

Might be cool to think about using TURN as the protocol for relaying instead of inventing another one. :x

@mauve this comment has thirsty troll vibes. I know how these protocols work — or rather, don’t work — if they did work, we’d be using one of them instead of solving this problem ourselves. Hyper and libp2p both use servers for relay.

@heapwolf That's fair. I actually haven't read the TURN spec. I had assumed it'd be something simple but I guess my assumption was wrong.

Defs wouldn't suggest implementing hyper or libp2p over your own thing. :)

Excited for the spec for your thing once it's out!