3 ms·
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
by koolala 2y ago
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.
- throwing_away 2y agoMy 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?
- kothar 2y agoI’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!