Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Peer Calls: WebRTC peer to peer calls for everyone

github.com

Post reply on HN
Print view View original

31–40 of 41 posts

Re: Peer Calls: WebRTC peer to peer calls for everyone

#31

Post by throwing_away »

koolala wrote: post #16
mettamage wrote: post #8

Earlier quoted context omitted.

Could you elaborate?

Want to p2p video call? Here run this script. We don't really use our Browsers like terminals to dynamically run user code. It would be like a different timeline where a programming console is not a 'dev' feature and anyone is equal at using code. If our computers become smart like AI then all friction for programming could be erased. It's hard to elaborate on a world where bookmarklets and user scripting becomes a n…

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

Re: Peer Calls: WebRTC peer to peer calls for everyone

#32

Post by njtransit »

dboreham wrote: post #29

Quick note that this isn't peer to peer (WebRTC never is) but is a project that allows you to host your own server to facilitate WebRTC channels between browsers you want to provide service for.

WebRTC can absolutely be peer to peer. You just need some out-of-band method of exchanging ICE candidates. The connections in WebRTC are literally called "peer connections."

Re: Peer Calls: WebRTC peer to peer calls for everyone

#33

Post by LegionMammal978 »

kelnos wrote: post #27
IgorPartola wrote: post #18

Earlier quoted context omitted.

You know what’s easier than all this happy crappy? Goddamn IPv6. How many engineer-hours have been spent trying to work around NAT and IPv4 which could have been spent implementing IPv6? Every browser tab could have its own publicly routable address if we wanted to. And the more work arounds we create the less pressure there is to get over the hump and treat IPv4 as the weird legacy protocol instead of treating IPv6…

My network's firewall doesn't let random incoming IPv6 connections come in, and I wouldn't change that even if I didn't need NAT for IPv4. Is there a safe protocol to allow applications inside a network to automatically ask edge firewalls for temporary port forwards (or port unblockings, which would be all that would be needed with routable IPv6)? I still can't see how that could be made safe, though: how would the f…

As I understand it, that is basically the purpose of UPnP IGD [0], as well as the newer PCP [1]. But hardly anyone implements these protocols due to the usual concerns around incoming connections.

[0] https://en.wikipedia.org/wiki/Internet_Gateway_Device_Protoc...

[1] https://en.wikipedia.org/wiki/Port_Control_Protocol

Re: Peer Calls: WebRTC peer to peer calls for everyone

#34

Post by Sean-Der »

dboreham wrote: post #29

Quick note that this isn't peer to peer (WebRTC never is) but is a project that allows you to host your own server to facilitate WebRTC channels between browsers you want to provide service for.

Peer calls can run in P2P mode or as a SFU.

Different topologies are better for different use cases. 1:1 vs group calls in this case!

Re: Peer Calls: WebRTC peer to peer calls for everyone

#35

Post by koolala »

idiotsecant wrote: post #22
koolala wrote: post #16

Earlier quoted context omitted.

Want to p2p video call? Here run this script. We don't really use our Browsers like terminals to dynamically run user code. It would be like a different timeline where a programming console is not a 'dev' feature and anyone is equal at using code. If our computers become smart like AI then all friction for programming could be erased. It's hard to elaborate on a world where bookmarklets and user scripting becomes a n…

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)

Re: Peer Calls: WebRTC peer to peer calls for everyone

#36

Post by koolala »

throwing_away wrote: post #31
koolala wrote: post #16

Earlier quoted context omitted.

Want to p2p video call? Here run this script. We don't really use our Browsers like terminals to dynamically run user code. It would be like a different timeline where a programming console is not a 'dev' feature and anyone is equal at using code. If our computers become smart like AI then all friction for programming could be erased. It's hard to elaborate on a world where bookmarklets and user scripting becomes a n…

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 solu…

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.

Re: Peer Calls: WebRTC peer to peer calls for everyone

#37

Post by throwing_away »

koolala wrote: post #36
throwing_away wrote: post #31

Earlier quoted context omitted.

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 solu…

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 i…

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?

Re: Peer Calls: WebRTC peer to peer calls for everyone

#38

Post by kothar »

throwing_away wrote: post #37
koolala wrote: post #36

Earlier quoted context omitted.

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 i…

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 restri…

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!

Re: Peer Calls: WebRTC peer to peer calls for everyone

#39

Post by IgorPartola »

kelnos wrote: post #27
IgorPartola wrote: post #18

Earlier quoted context omitted.

You know what’s easier than all this happy crappy? Goddamn IPv6. How many engineer-hours have been spent trying to work around NAT and IPv4 which could have been spent implementing IPv6? Every browser tab could have its own publicly routable address if we wanted to. And the more work arounds we create the less pressure there is to get over the hump and treat IPv4 as the weird legacy protocol instead of treating IPv6…

My network's firewall doesn't let random incoming IPv6 connections come in, and I wouldn't change that even if I didn't need NAT for IPv4. Is there a safe protocol to allow applications inside a network to automatically ask edge firewalls for temporary port forwards (or port unblockings, which would be all that would be needed with routable IPv6)? I still can't see how that could be made safe, though: how would the f…

Realistically STUN and TURN are still just ways to get around your firewall rules, are they not? Your firewall is already being bypassed. IPv6 wouldn’t change that fact.

Instead we could implement a better version of UPnP or just open a set of ports specifically used for P2P connections and allow the browsers to open those ports when they expect an incoming connection.

Firewalls serve a purpose but make no mistake they don’t prevent you from bypassing them. Clearly P2P connections are still made all the time.

Your specific question of “how do I know it’s not malware?” doesn’t make much sense. First most default firewalls allow outbound connections which is what malware would do. If you have malicious code running on your machine, the game is already lost.

The job of the firewall is two-fold. First it protects against unwanted flood of traffic to devices whose local resources are too limited to do the filtering themselves. The second is to keep ports closed to hosts outside of your LAN that they shouldn’t have access to. Say you misconfigured your NAS network file system and allow connections from anywhere. Oops. Your firewall protects against that.

But unless you effectively disconnect your laptop from the internet, the firewall won’t stop it from connecting to a remote host. At that point if you open a TCP port that is how you signal that you are requesting an incoming connection. Which is exactly what the current WebRTC system does except it also has to jump through a lot of hoops to establish the connection (steps that any malware would be able to take as well.)

Re: Peer Calls: WebRTC peer to peer calls for everyone

#40

Post by IgorPartola »

EGreg wrote: post #26
IgorPartola wrote: post #18

Earlier quoted context omitted.

You know what’s easier than all this happy crappy? Goddamn IPv6. How many engineer-hours have been spent trying to work around NAT and IPv4 which could have been spent implementing IPv6? Every browser tab could have its own publicly routable address if we wanted to. And the more work arounds we create the less pressure there is to get over the hump and treat IPv4 as the weird legacy protocol instead of treating IPv6…

Get around hole punching NATs with this one weird trick “they” they don’t want you to know about?

NAT should have never been a thing. That should have been the moment of “oh yeah we need a different IP protocol.”
Post reply on HN