I'm interested in building in this area, but the problem as I understand it, is that NAT traversal is kind of unreliable, even if you can break the sandbox via console/bookmarklet or tell the user to paste code to a system terminal.

For some people (behind CG-NAT), it may just not be possible to get an inbound port at all, so there may be two nodes that cannot directly communicate in the network.

The traditional solution is some kind of relay (see: TURN, skype's supernodes).

As far as I know, and maybe somebody can point me in the right direction, there is no technology available for a webrtc overlay mesh network where some nodes can relay for other nodes. I know webtorrent exists, so it should be possible.

You can see evidence of this problem in this project's README:

> When a direct connection cannot be established, it might be help to use a TURN server. The peercalls.com instance is configured to use a TURN server and it can be used for testing. However, the server bandwidth there is not unlimited.

What's needed, IMO, and please HN tell me why I'm wrong -- is a browser-to-browser mesh overlay system.

I would love to see an array of nodes (across varying levels of NAT) saturate their connections by all relaying to each other as a decentralized stress test that reports real-world p2p bandwidth between providers.

--

Btw, Tailscale has an excellent post on this topic: https://tailscale.com/blog/how-nat-traversal-works

To comment on the "tell me im wrong" part, not to tell you your wrong or this is right, but I haven't found obvious examples where WebRTC STUN fails where you'd convince network admins to a new kind of mesh network protocol in their corporate firewall. The obvious examples where a p2p internet connection doesn't work are obvious and acceptable failures. Like a p2p video call won't work in a military base? I have no idea honestly. Corporate and Government networks are not not my networks and I'm just happy p2p works on the open web at all.

My thesis is that your p2p node could contact some other p2p node that's willing to act as a relay and create a mesh network from entirely within a browser.

If your side of NAT sucks and STUN fails, you'll probably only be able to connect to someone that has a NAT-traversal friendly configuration. But since you're able to reach them, they could act as a relay to the rest of the overlay network from behind your restrictive NAT.

Imagine I'm running one node that's willing to relay on a publicly accessible IP. If I'm the only node willing to relay on a public IP, then we've pretty much got TURN without the daemon.

If multiple nodes are willing to relay, then we have a general purpose mesh network within the browser sandbox that works on mobile?

I’ve played around with this a bit in the past, and I think the biggest obstacle is going to be managing connections. Browser tabs are relatively short lived ‘peers’, each can only maintain about 100 simultaneous peer connections, and you can’t use WebRTC in workers.

Haven’t given up on the idea though!

And uncle Jimbo accidentally uploads his password cache running a script that was supposed to show him his favorite celebrity naked.

The Internet is a common public square now. Unfortunately the public is, statistically, an idiot.

On most computers your files are like one big bowl of soup. I'm really excited for the future direction the browser file system is going in. I disagree with statistical fear and judgement. With OPFS it's hard to imagine someone doing that (especially in a native container OS)