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

21–30 of 41 posts

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

#21

Post by m463 »

I think a lot of the nonsense on the internet happens because companies become a necessary intermediary for communication.

I believe this would be solved except...

"It is difficult to get a man to understand something, when his salary depends on his not understanding it."

So companies NEED to be intermediaries "for security", "for discovery", because we need TURN, (...and for subscriptions, for ad serving, for revenue idea of the week, etc)

If more folks were able to use peer to peer communications (think families, not phishing/trolling/etc) a lot of this nonsense would go away.

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

#22

Post by idiotsecant »

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…

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.

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

#23

Post by ranger_danger »

toast0 wrote: post #20
ranger_danger wrote: post #3

I applaud the real support for TURN (and TCP ICE) and the emphasis on explaining the (IMO very common) issue properly unlike so many other WebRTC projects that think the majority of people will never need it. I know Firefox now supports outgoing TCP ICE, but what about incoming TCP connections? I wasn't able to find an answer easily from googling.

I've setup TCP and TCP+TLS for an SFU, and at least for my client base, it's barely used, but it is used. Almost everyone can do UDP. For 1:1 calling, I suspect the number of peers that can do peer to peer TCP, but not UDP is so small that it's not worth bothering. But that doesn't answer your question, sorry. I know the application I work on doesn't listen for incoming tcp on clients, but I think there is support fo…

Many public wifi spots like stores, hotels, airplanes etc. often block UDP (other than local DHCP).

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

#24

Post by type0 »

m463 wrote: post #21

I think a lot of the nonsense on the internet happens because companies become a necessary intermediary for communication. I believe this would be solved except... "It is difficult to get a man to understand something, when his salary depends on his not understanding it." So companies NEED to be intermediaries "for security", "for discovery", because we need TURN, (...and for subscriptions, for ad serving, for revenu…

Sadly people are indoctrinated on how they should use computers/smartphones

most users won't leave the mindset of "there's an app for that"

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

#25

Post by toast0 »

ranger_danger wrote: post #23
toast0 wrote: post #20

Earlier quoted context omitted.

I've setup TCP and TCP+TLS for an SFU, and at least for my client base, it's barely used, but it is used. Almost everyone can do UDP. For 1:1 calling, I suspect the number of peers that can do peer to peer TCP, but not UDP is so small that it's not worth bothering. But that doesn't answer your question, sorry. I know the application I work on doesn't listen for incoming tcp on clients, but I think there is support fo…

Many public wifi spots like stores, hotels, airplanes etc. often block UDP (other than local DHCP).

Yeah, so your SFU or your TURN server needs to support TCP.

But if you're on public wifi, chances are you can't get inbound tcp to work. And the majority of the peers you might connect to probably can't either. It's not worth the effort to eek a tiny % more peer to peer when you have to build the relay server fallback anyway.

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

#26

Post by EGreg »

IgorPartola wrote: post #18
Sean-Der wrote: post #9

Earlier quoted context omitted.

My dream would be if WebRTC Agents would experiment with Port Control Protocol. I don't know if it is the answer, but a world without dependence on STUN servers sounds pretty amazing. I can see why it would feel like kludge, but how could would it be to remove that dependency. My other wishlist item is to allow mDNS for signaling. Something like https://github.com/pion/offline-browser-communication . It is so silly t…

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?

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

#27

Post by kelnos »

IgorPartola wrote: post #18
Sean-Der wrote: post #9

Earlier quoted context omitted.

My dream would be if WebRTC Agents would experiment with Port Control Protocol. I don't know if it is the answer, but a world without dependence on STUN servers sounds pretty amazing. I can see why it would feel like kludge, but how could would it be to remove that dependency. My other wishlist item is to allow mDNS for signaling. Something like https://github.com/pion/offline-browser-communication . It is so silly t…

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 firewall know that the request was coming from a user on the network, and not malware (or a user being duped by malware)?

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

#28

Post by dboreham »

IgorPartola wrote: post #18
Sean-Der wrote: post #9

Earlier quoted context omitted.

My dream would be if WebRTC Agents would experiment with Port Control Protocol. I don't know if it is the answer, but a world without dependence on STUN servers sounds pretty amazing. I can see why it would feel like kludge, but how could would it be to remove that dependency. My other wishlist item is to allow mDNS for signaling. Something like https://github.com/pion/offline-browser-communication . It is so silly t…

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…

It would still block inbound connections.
Post reply on HN