Hacker News Reader

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

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.)

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.

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.

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/9b092218b7623ca198c3caef...

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.

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.

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.)

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)

> So why does it exist? Answer: to reduce the cost to provide a service where bulk data flows are p2p.

Also to lower latency.

FWIW, lower latency is not guaranteed when going direct vs through a relay. There are way too many variables in routing. You've got to try it all ways and see.

Ideally, you should try to measure the one way delay on each path and choose the 'best' path in each direction, but WebRTC tries to converge on the 'same' path for both directions (either relay both ways or direct both ways).

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.

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."

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 :/.

> 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.)

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.

> 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

I mean, we're talking about something where the core use-case is for equal peers to be connecting to one-another, where who is dialing whom is entirely arbitrary. While your app on top of WebRTC might have nodes that do server-like things and other nodes that don't, on the WebRTC level, there is no "server"; for any given WebRTC session, either one of the peers might end up doing the dialing or the listening, perhaps with this even changing for the same pair of peers on a connection-by-connection basis.

In such a context, mutual auth is the only kind of auth that makes sense to me. Both sides establish a stable identity (beyond their relatively-unstable current IP address), so that each side's User Agent has at least one piece of reliable information it can use to whitelist or blacklist other nodes' connection attempts by.

Consider: we're struggling right now to get the phone network to adopt protocols that allow each side of a phone call to non-repudiatably identify the entity on the other end of the call (i.e. for it to be impossible for each side to fake its phone number.)

So why would we want to introduce a new protocol in the year 2024, supposedly for p2p connectivity, where at least one side of the connection is allowed to be the equivalent of the phone network's "Unknown Caller"?

Or, to put that another way: do you really want to enable your browser to be DDoSed? By other browsers, who've landed on some malicious webpage that runs in a background tab, opening never-ending WebRTC connections to target hosts according to the websocket-delivered instructions of some booter service?

Mutual auth at least ensures that connection attempts like those will be dropped at DTLS establishment time. To talk to a WebRTC session established by a page from origin X running in your browser, those tabs in those other people's browsers will need access to DTLS certs that are signed by a party trusted by the code in your browser (i.e. the code written by origin X.) And those DTLS certs would in turn presumably only be made available to... pages from origin X. (Or its logistical data partners.)

But, I don't want "origin X", I want "peer-to-peer". I don't want some server somewhere providing the authorization to enter the network by gating the CA: I want a mutually interoperating set of web applications written by different developers all able to run code (maybe in a library) that bootstrap themselves into a permissionless peer-to-peer network. As for your concern about having to deal with a ton of incoming connections, such is the life of a supernode: if you aren't up for that, don't sign up to be a supernode. But like, without this, why do we care about "supernodes" anyway? If you have some centralized server you have to talk to to get certificates, just have it do signaling as well! :(