[HN Gopher] Overlay networks based on WebRTC
___________________________________________________________________
Overlay networks based on WebRTC
Author : keepamovin
Score : 168 points
Date : 2024-03-29 17:00 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| EGreg wrote:
| Good work! I just want to point out that WebRTC requires servers
| for STUN and TURN.
|
| If I may, we also developed an open source solution for WebRTC
| videoconferencing, livestreaming and even peer-to-peer
| broadcasting to unlimited numbers of people! Feel free to use it:
|
| https://community.qbix.com/t/teleconferencing-and-live-broad...
| megous wrote:
| It does not require either of those.
| ongy wrote:
| NAT traversal is the first point on the feature list of the
| linked repo. So in context, it's important to point out.
|
| While in theory it doesn't it reduces the possible
| connections quite a bit. Though STUN servers are plenty on
| the internet and free to use. There's even a service
| providing TURN (US geo though), but I have no idea who runs
| it and what their business model is, so I wouldn't rely on
| it.
| eyegor wrote:
| Having used webrtc in offline environments (host device
| broadcast a local wifi), I can say it's a royal pain to use
| without ice/stun/turn servers. I had to manually mangle the
| sdp packets to make it work because browsers would randomly
| decide they needed ip privacy (from the device they connected
| to by ip...) where they'd translate ips to some_hash.local
| and try to find a turn server. I tried hosting a coturn
| server too, but browsers would sometimes ignore it since it
| was a local address. Mangling the sdp handshake is reliable
| but feels pretty jank.
| xori wrote:
| Hyperswarm has been my go-to for stuff like this, but you bring
| up a good point that I don't think it's encrypted.
|
| https://github.com/holepunchto/hyperswarm
| apitman wrote:
| Can hyperswarm be used to set up a generic IP network?
| Uptrenda wrote:
| Quite a solid project and approach. Both founders seem smart
| and to know the problem well. I can see their new framework
| (Pear runtime) getting huge in the future.
| apitman wrote:
| Onto the list[0] it goes.
|
| I always have the feeling that WebRTC had so much more potential
| than has been realized. I wonder how things might have turned out
| differently if it had better server and browser support ~5 years
| ago. I remember trying to use it for a game at the time and had
| trouble finding a good server implementation, and had all sorts
| of issues with Safari.
|
| In the near future I'm not sure there will be much reason to use
| it over WebTransport, unless you're doing p2p. I actually prefer
| WebRTC's data channel API, since you can get separate datagram
| streams, whereas with WebTransport you have to multiplex them
| yourself[1].
|
| [0]: https://github.com/anderspitman/awesome-tunneling
|
| [1]: https://datatracker.ietf.org/doc/html/rfc9221#name-
| multiplex...
| billywhizz wrote:
| i've long felt the same. i came to conclusion the browser
| vendors decided it was kind of a mistake. it enables all sorts
| of local first and p2p things that cut out the service
| providers.
|
| hopefully it will get some attention again. i have done a bunch
| of really interesting experiments with data channels. being
| able to choose the reliability is nice for sure.
| treyd wrote:
| > it enables all sorts of local first and p2p things that cut
| out the service providers.
|
| And this is another reason why the web will always be a shaky
| foundation for local first and p2p software.
| Sean-Der wrote:
| WebRTC will live on. I think it will continue to grow from
| grassroots efforts.
|
| WebRTC has P2P and it also doesn't require the user to have any
| knowledge of Video/Networking. The alternatives to it are more
| geared at 'video developers'. I don't know which way the future
| will go.
| andai wrote:
| > had all sorts of issues with Safari
|
| Tangential rant, but this appears to be intentional. As far as
| I can tell, Apple is intentionally lagging behind supporting
| various web technologies, to make the web as unattractive as
| possible (within their ecosystem), and by extension, to make
| native app development as attractive as possible, so they can
| take a cut of the profits.
|
| If their reasoning is correct, then they would actually lose
| money by _not_ investing into their own browser engine, which
| is somewhat amusing, because the worse of a job they do, the
| more money they make.
|
| (I find this idea particularly painful in the context of "we at
| Apple love web technology so much, we're going to use our love
| of web as our main excuse for killing Flash"...)
| keepamovin wrote:
| Not a great strategy. Can't compare apples and oranges. Long
| term weakening their web offering will only strengthen their
| competition and likely have compounding effects against their
| app store. Maybe it's a short term thing for them. Seems a
| better way would be to embrace web and create the synergies
| with their existing offerings that boost both...but, I think
| this highlights the issue
|
| It's not so much about a binary choice between app store vs
| web. I think it's more just, the web is not very "Apple".
| It's too open, wild. If they go "all in" on the web, they'd
| be afraid to risk "losing themselves" or fucking something up
| and creating a backlash.
| simfree wrote:
| This strategy of trying to snuff out web apps by locking
| all iOS users into a decade out of date fork of Chrome that
| only gets a trickle of new features, and those features
| consistently have added UX friction that exists in no other
| modern borders is working in North America.
| keepamovin wrote:
| True, it works some. But think of what could be done if
| they could get beyond their, albeit understandable, web
| aversion.
|
| Tho I disagree that Safari is so defunkt as you make out.
| They have a bunch of new features. Check out:
| https://webkit.org/blog/15243/release-notes-for-safari-
| techn...
| matthewmacleod wrote:
| Just seems trivially obviously not the case to me, but seems
| like a popular meme regardless.
| andai wrote:
| https://old.reddit.com/r/webdev/comments/1brp9jn/i_made_a_s
| i...
|
| https://ios404.com/
| halfmatthalfcat wrote:
| To be fair to them though, they're the only browser where you
| can transfer RTCDataChannels to workers and get that off the
| main thread. All others are still lagging behind there.
| samtheprogram wrote:
| Around 5 years ago, peer negotiation got massively simplified
| with new additions to the spec (see Perfect Negotiation). If
| you're on a browser released since then, your life will be far
| easier.
| keepamovin wrote:
| Regarding issues with Safari, they recently made a change where
| in order to get WebRTC data channels, you no longer had to
| request get user media permissions. This was the case before.
| It's still the case on Safari Mobile right now. But you can
| just say, request mic access, establish the connection, and
| once it's established, you just drop the mic access. In my
| case, typically about one to two seconds. So there are indeed
| quirks on Safari.
| rmdes wrote:
| Felicitas is one of those devs, every repository on her profile
| is a gem to learn from, and well documented!
| tptacek wrote:
| I can't tell for sure without actually checking the repo out but
| this looks to be GCM with random nonces using a command line flag
| string as the fixed key for the network.
|
| If you're trying to build a modern encrypted multipoint overlay
| network, MLS is a good place to start.
| orion138 wrote:
| Did you mean MPLS? Or could you link to MLS?
| akerl_ wrote:
| https://en.wikipedia.org/wiki/Messaging_Layer_Security
| k__ wrote:
| Is this like web-onion?
| egberts1 wrote:
| That's the first thing I disable in all enterprise/office PCs'
| browser: WebRTC.
|
| Disclosure: I am an cybersecurity architect of IDS/NDS/XNS.
| egberts1 wrote:
| Meh, WebRTC ... it's not for everyone.
| bjconlan wrote:
| I'm curious as to why? Introduce difficulty to promote some ICE
| holepunching access to the device?
| nottorp wrote:
| I don't know why the OP disables it, but chrome used to block
| my desktop from sleeping because 'WebRTC has active peer
| connections'.
|
| I don't appreciate web pages or applications or whatever
| blocking my system from sleeping so i just turn off WebRTC
| since then.
|
| Edit: I was not doing anything related to video, audio, p2p
| or anything else implying long running connections
| explicitly. Some "experts" were doing it behind my back on
| their pages. Don't know and don't care why.
| mrkramer wrote:
| WebTorrent[0] is also good WebRTC P2P project.
|
| [0] https://en.wikipedia.org/wiki/WebTorrent
| evbogue wrote:
| I recently started using Trystero to send messages and video
| around via WebRTC.
|
| https://oxism.com/trystero/
| pappapisshu wrote:
| ADGT.js [0] was another P2P overlay network based on WebRTC.
|
| [0] https://doi.org/10.1002/cpe.4254
| lostmsu wrote:
| I am actually working on something like this in
| https://borg.games ( also see
| https://github.com/BorgGames/borggames.github.io )
|
| Basically the idea is that the only endpoint available through
| regular HTTPS is the signaling server, and the other services are
| accessible via WebRTC by requesting peers from the signaling
| server with service's public key.
|
| There are multiple things I am planning to layer over p2p
| connections: CDN, virtual LANs to play games "locally",
| gameserver hosting, etc
| dboreham wrote:
| WebRTC is widely misunderstood. It is not a p2p-enabling
| technology. It requires a mechanism for passing messages between
| nodes prior to establishing a session (this is called "signaling"
| in the literature). So it's another turtle layer: it's a scheme
| for communicating between nodes provided they can already
| communicate.
|
| So why does it exist? Answer: to reduce the cost to provide a
| service where bulk data flows are p2p. It does this by trying to
| get said flows over UDP with NAT traversal directly between the
| host networks for communicating nodes. The canonical example is
| internet telephony. But it does this on the assumption that there
| will be a long tail of node pairs for which a hairpin route
| through a server will be needed. It doesn't remove the need for
| servers, only the resources needed for those servers.
|
| Everyone who says they have built a true p2p system with WebRTC
| is confused[1].
|
| [1] You can build such a thing with WebRTC, but only if the nodes
| are not browser hosted and have public IPs. If you think that's
| useful then you're also confused.
| Sean-Der wrote:
| What protocols/networks do you consider P2P? Every P2P
| technology I have used requires some bootstrapping.
|
| I have done WebRTC with zero signaling, but browser only one
| side[0]. I wish the w3c/ietf would care, but that's the issue
| with corporate/profit driven standards!
|
| [0] https://github.com/pion/offline-browser-communication
| Uptrenda wrote:
| Bootstrapping is an interesting problem. If there's a large
| P2P network (think like Gnutella) there's papers that have
| proposed using port scanning of residential IP ranges to find
| peers that belong to the network. It's an interesting
| approach because there's no centralized bootstrapping
| servers. But, port scanning is inefficient and such an
| approach may only be viable if a network is large (I may be
| wrong here.) Still, I think it's cool how little work has
| been done on these problems. I am still really into p2p
| networks.
|
| For my own project I observed that all of the main networks
| in some way still depend on trusted introduction points. Just
| many of them and combined. So I think using infrastructure
| that's federated and open is a good design (in my case:
| public MQTT servers is what my own software is based on.)
| convolvatron wrote:
| I think it's worth remembering that the original intent of
| the internet was entirely p2p and this bootstrapping issue
| wasn't a problem. In fact, there was a whole set of protocols
| developed around global multicast that allowed for discovery
| to build exactly these structures.
|
| So you can't blame the ietf for not thinking of this problem
| - you can blame them for not being able to respond well when
| the market went and mucked up their architecture by putting
| nat everywhere.
| halfmatthalfcat wrote:
| You can do offline signaling. Quoting MDN:
|
| > It's any sort of channel of communication to exchange
| information before setting up a connection, whether by email,
| postcard, or a carrier pigeon. It's up to you.
|
| All you need are SDPs and ICE Candidates. People _choose_ a
| centralized signaling server because it 's the easiest but
| WebRTC does not _dictate_ it be that way.
|
| Echoing the other commenter, there really is no other way to
| establish a connection without some knowledge of the other
| peer, be it gained online or offline.
| keepamovin wrote:
| I experimented with implementing this manual signaling where
| the delay between back and forth could be dozens of seconds
| or even minutes.
|
| I found that you need to call restartIce, which is not
| typically called in SimplePeer and is not normally exposed.
|
| So as it currently stands, SimplePeer regular version that
| you can get from the package manager will not support
| signaling over dozens of minutes. It just won't work.
|
| But it can be made to work if you just call restart ICE,
| which keeps everything alive.
|
| I discovered this through my own research and experiments.
|
| And you can see the code below. And also, you can fork this
| repo and read the instructions to get a working version as
| well.
|
| I think the original idea was basically you can, like, be in
| your shell and you can run this repo and then you can be
| chatting with people who come to your GitHub repository. And,
| the signaling is done over comments and there's sort of like
| a comment robot that facilitates that to make it easy.
|
| https://github.com/o0101/janus/
|
| RestartIce: https://github.com/o0101/janus/blob/9b092218b7623
| ca198c3caef...
| ravenstine wrote:
| Exactly. This is trivial to carry out and can be done "by
| hand" between two browsers. I don't know what the OP is
| talking about. They are speaking as if the commonly chosen
| mode of bootstrapping a connection is fundamental to the
| entire communication cycle. It's flat out not true. When the
| connection has been established, peers are connected
| directly, but by their definition, this doesn't matter
| because a trusted peer was used to form the initial
| connection. Ridiculous. By that logic, it wouldn't be a P2P
| connection if IPs were initially exchanged by snail mail or
| carrier pigeon, or if DNS were used.
| halfmatthalfcat wrote:
| And once you do connect with a peer, peers can maintain
| DHTs of other peers and you can have a true mesh network
| where you signal over WebRTC itself.
| javajosh wrote:
| It's okay to make a distinction between _transient_ and
| _steady-state_ communications. If the steady-state is p2p then
| that 's good enough for me. BTW I've never built one but I've
| read that WebRTC can connect browsers on a local LAN if they
| can see each other's IP address. (This is actually an
| experiment I'd one day like to do.)
| fulafel wrote:
| Communicating between a group of computers on a LAN using IP
| doesn't have any limitations vs doing the same on the
| internet, so there's no reason it wouldn't work. (But yes
| I've tried it and it worked)
| derefr wrote:
| Yes, nodes behind NAT must be able to already communicate
| through some kind of intermediary -- at least initially (for
| STUN), but maybe the whole time (for TURN.)
|
| But this intermediary has very low requirements. It doesn't
| need to be mutually trusted by both parties, and it doesn't
| need any compute of its own for handling encryption/etc, just
| the ability to re-wrap opaque IP-packet payloads back and forth
| between ports. Any random low-power network switch could
| implement full-speed TURN. And anyone could _also_ run a STUN
| or TURN server on a $2 /mo VPS.
|
| And, beyond that, STUN/TURN servers also don't need to be
| protocol-specific; you can reuse a STUN/TURN server someone put
| up to help some _other_ protocol. They 're a global resource --
| even STUN/TURN servers established for _non-WebRTC_ routing,
| can be reused for WebRTC routing, and vice-versa.
|
| This means that in-browser WebRTC protocols that rely on ICE,
| are both:
|
| * _affordable_ to "enable" connectivity on (because any
| network or protocol likely has some backing foundation, which
| can easily afford enough ultra-cheap STUN/TURN nodes to ensure
| the network's operation; but even if they _don 't_, the network
| can be designed to use existing STUN/TURN nodes established by
| p2p advocates like the EFF, acting as a free rider on those
| nodes; and even if you don't do _that_ , either party, with at
| least $2 of motivation to communicate, can get a VPS [in a non-
| CGNATed country] and run their _own_ STUN /TURN nodes on it.)
|
| * _uncensorable_ in the weak sense (in that there 's no central
| entity _within_ the p2p network which can choose to _deny you
| access_ to connectivity on the network.)
|
| (Mind you, your ISP might drop all your STUN/TURN -looking
| traffic; or you might not be able to acquire a non-CGNATed VPS
| IP address anywhere in your whole country... but this is not a
| problem for "p2p protocols" to solve; as, at that point, you're
| not _on_ "the Internet" per se, but on a weird LAN that is
| willing to route IP packets to some whitelisted subset of the
| Internet. Solving for network-level censorship isn't the domain
| of "p2p protocols", but rather the domain of anti-censorship
| technologies, like Tor's hidden bridge nodes.)
|
| ---
|
| But I assume you don't really care about the practicality here,
| and are speaking more in the context of being an IPv6 public-
| routability maximalist. (Which, hey, I'm one of those too. Non-
| globally-routable addresses are silly.) Thus this:
|
| > You can build such a thing with WebRTC, but only if the nodes
| are not browser hosted and have public IPs. If you think that's
| useful then you're also confused.
|
| I do get why you say this -- the naive counterargument is that
| phones on cellular networks are non-browser-hosted and have
| public IPs, and that therefore native mobile apps can act as
| both WebRTC and STUN/TURN servers.
|
| But of course, the cellular networks that aren't CGNATed, are
| all IPv6 networks. So this is no help to anyone whose ISP has
| only assigned them an IPv4 address behind a NAT.
|
| But there's an (IMHO much better) rebuttal, in the form of an
| emerging technology-trend, which you may not have considered:
| Desktop-as-a-Service (DaaS) nodes.
|
| If you run a browser _on a cloud VM_ , then you get a browser
| _with_ a public-routable IPv4 address, where that browser can
| then participate in a WebRTC network as a "supernode."
|
| Sure, if you're doing this _with the goal of_ enabling STUN
| /TURN, then this is silly: you may as well just get the $2 VPS
| and run just the STUN/TURN servers on it.
|
| But my point is that many corporate employees just connect to
| some DaaS using thin-client hardware _by default_ , and do
| everything on that DaaS (incl. using a browser); and so, as
| long as your protocol is likely to be _used_ by any corporate
| workers, then your protocol _does_ get its necessary supernodes
| -- in the form of the browsers running on these workers ' VMs
| -- "for free."
| saurik wrote:
| So, I _mostly_ agree with you--and I certainly think WebRTC
| is "peer to peer" as I am unsure what the definition of
| "peer to peer" even would have to be if it weren't--there is
| a big caveat that I think undermines the beauty here: a
| browser can't act as a supernode as it can't listen for HTTP
| connections.
|
| To me, what WebRTC is missing is the ability to just connect
| to another peer who DOES have a public IP. And frankly, the
| tech stack seems _so close_ to being able to pull this off...
| Sean even has that demo repository he linked on this thread
| somewhere of just hardcoding the SDP, but it isn 't clear to
| me -- and it didn't seem clear to him either (based on a
| comment in his README) -- that this would actually be secure
| enough as a bootstrap. It certainly _could be_ with only a
| minor modification, as I should only have to know the pinned
| certificate of the DTLS server, but I think the browser API
| of WebRTC requires the server to know the client 's
| certificate as well, which then implies the client's private
| key has to be hardcoded and shared, and it feels non-obvious
| if the security model of DTLS still works in that case (I
| should really sit down and try to pencil this out).
|
| Without this, your supernodes can't be browsers: they have to
| be native programs with full socket access. Again: I think it
| is still OK to call the technology peer-to-peer, and yet it
| is also yet still missing something that feels really core to
| the idea of it being usable as a platform technology for P2P
| deployment, and likely it will never get the rest of the way
| as people are now wasting their time on the definitely-not-
| even-trying-to-be-peer-to-peer WebTransport :/.
| derefr wrote:
| > I think the browser API of WebRTC requires the server to
| know the client's certificate as well
|
| Yes, as it stands, the browser WebRTC API is designed
| around the idea that a p2p connection is being bootstrapped
| by connecting two of the leaves of a star topology to each-
| other. _For this use-case_ , it's a pure optimization: the
| server starts off intermediating between peers; then at
| some point, the peers each figure out that the other one
| can do WebRTC, so the server introduces the peers to one-
| another (gives each peer the other peer's authoritative
| DTLS certificate hash), and the peers stop talking to the
| server and start talking to one-another instead.
|
| I don't think this is any kind of equilibrium state,
| though. This is the way things are because because WebRTC
| evolved purely _as_ an optimization for companies like
| Google and Facebook to avoid needing to deal with massive
| streaming-media traffic fan-in. In their cases, they
| already _had_ multimedia chat platforms that used
| authoritative central backend servers intermediating media
| streams; and they just wanted to introduce a way for a
| browser to "upgrade" from talking to the backend, to
| talking to another browser. Like upgrading an HTTP flow
| into a Websocket flow.
|
| But a lot of the work since then, on Data Channels, DTLS
| and so forth, has been at the behest of other companies
| (e.g. Ericsson) whose motivation _isn 't_ to decrease load
| on their massive video-chat backends, but rather to do
| other things, like enabling browsers to talk directly to
| e.g softphones or IP cameras, with both sides throwing
| packets directly at one-another without some kind of
| gateway in the way.
|
| I fully expect that while you might not get browser
| STUN/TURN nodes in the near future, we _will_ at least see
| something like browsers offering the option of mutual
| authentication of DTLS certificates through a specified
| X.509 CA set (where both peers have been issued client
| certificates signed by one of the CAs trusted in the set;
| and where the CA could very well be a self-signed private
| one unique to the service.)
| saurik wrote:
| Do we even need "mutual authentication of DTLS
| certificates", though? I would think it should be
| sufficient for either the server's certificate to be CA-
| signed or -- even easier and even better as far as I am
| concerned (as to me the CA system is itself bowing to an
| authoritative system I would rather avoid) -- for the
| client to just already know the certificate hash of the
| server (as part of its address).
|
| The _only_ problem I am seeing is that I want to be able
| to leave the peer certificate hash null and just
| authenticate with anyone on the other side. Like, I
| actively don 't want "mutual authentication of DTLS
| certificates" for when a user first connects. For later
| re-connections it might be useful for the client to leave
| the network a certificate hash, but for that initial
| connection I want one side to not have a certificate,
| same as using TLS to connect to any known HTTPS server.
| amadeuspagel wrote:
| > So why does it exist? Answer: to reduce the cost to provide a
| service where bulk data flows are p2p.
|
| Also to lower latency.
| gfodor wrote:
| Sounds like you understand WebRTC yet take issue with
| describing it as a p2p-enabling technology. It is literally
| technology which enabled peer to peer connectivity in the
| browser. Without it, browsers would not be able to directly
| connect to one another over the Internet. These kinds of
| definition-focused posts on HN are always so tiresome.
| Uptrenda wrote:
| [...] using STUN.
|
| I'm convinced no one actually knows what STUN is. I always see
| these references to STUN in P2P contexts. STUN is just a shitty
| protocol that shows what your external IP and port is. That's
| literally it. You can't use it by itself to do any kind of NAT
| traversal. There is an RFC that lists how to use STUN lookups to
| enumerate a NAT (but its far from definitive) and anything useful
| requires looking at other papers about NATs to apply the results.
| This is what you would need to do before you did hole punching.
|
| [...] webrtc.
|
| See, the thing about webrtc is: its a vague, low-quality spec. It
| uses over-simplified descriptions of peers, NATs, and hole
| punching algorithms, over a design that would provide better
| reachability. But the approach that webrtc takes is to just
| fallback to TURN for edge-cases (TURN is a proxy protocol.) The
| problem with that is it's likely that TURN will be used
| significantly for things like mobile devices due to symmetric
| NATs. This means maintaining infrastructure for your 'p2p' system
| when you don't have to.
|
| Overall, I am a fan of the fact that webrtc is in the browser and
| its 'standardized' but I think that the actual implementation of
| what its trying to achieve doesn't work well for the real
| Internet.
___________________________________________________________________
(page generated 2024-03-30 23:02 UTC)