[HN Gopher] Peer Calls: WebRTC peer to peer calls for everyone
___________________________________________________________________
Peer Calls: WebRTC peer to peer calls for everyone
Author : yamrzou
Score : 76 points
Date : 2024-09-30 16:51 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| koolala wrote:
| Any web browser could do a p2p call with just a bookmarklet and a
| chat room / comment section for trading ICE information.
| remram wrote:
| Isn't that true of anything a web browser can do?
| Sean-Der wrote:
| You should build that!
| mettamage wrote:
| Could you elaborate?
| koolala wrote:
| 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 normal thing where we freely tap into our
| browser's capabilities.
| fidotron wrote:
| Yes, I feel I am missing something here. Is this just a
| signalling server with optional SFU or is there more to it?
| Sean-Der wrote:
| I think people are excited because it's easy to run yourself
| and well documented.
|
| I find the code base easy to understand since it's built by
| one developer. It's a consistent read and not
| sprawling/pointless duplication
| ranger_danger wrote:
| They could but they're not, that's the difference.
|
| If you think that method can become popular, then by all
| means... be the change.
| ranger_danger wrote:
| 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.
| Sean-Der wrote:
| I don't think Chrome or FireFox support passive ICE-TCP
| Candidates.
|
| The assumption is that two clients are in the same LAN they
| would use UDP anyway. If are in two differents NATs doing
| traversal with TCP isn't support. I have read that it is
| possible, not something I have tried myself though.
| 1oooqooq wrote:
| every time i have to deal with ice and webrtc, i wonder if it is
| easier to ship a mirai style bot which would hack the modems from
| the lan side which is even easier than from the wan side, and and
| just add the portforwards.
| Sean-Der wrote:
| 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 that I need to exchange a
| Offer/Answer using a remote server to start a session with a IP
| Camera in my LAN.
| marcodiego wrote:
| You can user Tor and expose a service running on your lan to
| the whole world.
| noident wrote:
| I can count to 30 before the onion service running my
| personal wiki loads. Tor is awesome but onion services are
| really, really slow!
| SahAssar wrote:
| > My other wishlist item is to allow mDNS for signaling.
|
| If you load a webpage with from a mDNS address of the camera
| what other steps are needed? Your browser and the camera
| should be able to exchange SDP and connect without any third
| party.
| IgorPartola wrote:
| 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 as
| the weird new protocol.
|
| I guess engineer activism is all there is really left to do.
| Enable dual stack, write your code to be IPv6-first (it can
| automatically do IPv4 connectivity if enabled so really you
| only need to support one stack and the OS will translate for
| you; this doesn't mean you can avoid having IPv4 addresses if
| you want to have your service IPv4 accessible, just that your
| code can pretend like every address is an IPv6 address). Test
| your code without IPv4 connectivity. If you reference
| localhost, don't use 127.0.0.1 preferring _localhost_
| instead. Don't be the reason the next engineer has to say
| "well this codebase isn't IPv6 compliant so we can't enable
| it".
| Muromec wrote:
| Another reason to use ipv6 and just memorize your address to also
| not depend on dns
___________________________________________________________________
(page generated 2024-09-30 23:00 UTC)