upvote

points

by narragansett6 hours ago |
comments
upvoteby owaiswiz2 hours ago|
next
[-]
In case a direct p2p connection is not possible and it goes through the relay, is that for all traffic (even if encrypted )?

And who bears the cost for that (or does it have some FUP) (bandwidth cant be free/unlimited?)

reply
upvoteby narragansett2 hours ago|
parent|
[-]
Yes -- if direct P2P fails, everything rides the TURN relay that gets inserted automatically -- it's DTLS end-to-end so the relay only sees ciphertext, never plaintext or the access code.

On cost: I pay for it on bitba.ng and it's capped right now at 10 minutes per connection (mostly to prevent people from connecting and walking away). But you're not stuck with mine -- the signaling server is open source, so you can self-host and point it at your own TURN. The Python library supports "bring your own TURN" by specifying (--turn-url, --turn-user, --turn-credential); adding the same flags to the CLI is a small gap I need to close. There are TURN providers that have reasonably generous free tiers.

reply
upvoteby ranger_danger53 minutes ago|
parent|
[-]
> There are TURN providers that have reasonably generous free tiers.

Could you provide a list of ones you know? Last I looked I wasn't able to find anything fast or reliable.

reply
upvoteby gtoubassi4 hours ago|
prev|
[-]
Its really clever and minimal approach to getting (for my use case at least) the moral equivalent of a cloudflare tunnel without actually depending on CF. Super cool.
reply
upvoteby tadasv3 hours ago|
parent|
[-]
It is minimal and somewhat neat. It claims to be P2P, but it still needs to bootstrap the connection via central server. I think that always might be a limitation of P2P.

I had a similar idea but for wireguard only, where you would allow people to join a vpn through a "shared" jumpbox. To get started with wg is very simple, the problem is the same you need public IP address to scaffold everything.

Out of the two options I probably would prefer going wg route, just because it generalizes better. But this is a pretty cool demo of webrtc.

reply
upvoteby nighthawk4542 hours ago|
parent|
next
[-]
> it still needs to bootstrap the connection via central server. I think that always might be a limitation of P2P

I think Iroh has a way of doing it using either DNS or BitTorrent DHT. Not perfect but fairly decentralized

reply
upvoteby narragansett1 hours ago|
parent|
[-]
Iroh's discovery is genuinely neat, and node-IDs-as-public-keys is similar to bitbang.

A browser can't join a DHT though because of no UDP sockets, so the connecting side would need a native client, which is the thing bitbang avoids. And DHT lets you locate the peer, but you still need somewhere to trade SDP and ICE candidates, so the rendezvous stays either way I think.

What I can do is keep the broker small enough that self-hosting is realistic, which is where it is now -- no accounts, no registry, nothing that grants access, only a simple broker.

reply
upvoteby spl7572 hours ago|
parent|
prev|
next
[-]
If you are running this stuff on a cheap VPS with limited bandwidth, you will not want all of your traffic being routed as ingress and egress as that could easily eat your monthly bandwidth limit depending on the size of files and frequency.
reply
upvoteby narragansett3 hours ago|
parent|
prev|
[-]
Right, bootstrapping needs a rendezvous point -- that's true of any P2P system, including the wg version. The difference is what the rendezvous knows and costs. Here it holds no accounts, no registry, and nothing that grants access, so it's a phonebook rather than a keyring, and it's out of the data path so it's cheap to run and you can self-host it.

On generalizing: wg wins for "put these machines on one network." WebRTC wins on reach, because the connecting side can be a browser -- a phone, a borrowed laptop, a machine you don't administer -- with nothing installed. A wg jumpbox still needs a client on both ends and a public IP for the box. Different tradeoff rather than a strictly better one.

reply