narragansett

thanks for the catch :)

Pls see reply above.

You actually bring up a good point. v6 genuinely helps here. It gives every device a routable address, so no nat, but it doesn't open a hole through the firewall, which still defaults to blocking inbound, and it doesn't address authentication. You'd still need something to introduce the peers and verify identity. What v6 changes is that hole punching gets easier and more connections go direct. v6 does kill CGNAT specifically, which is the worst case for hole punching. I would really like to see CGNAT go away, which would happen in a 100% ipv6 world. Weirdly, v6 still isn't close to 100%... v6 good for BitBang and doesn't replace, which I assume was the point you were making.

Yes, I started using AI for coding (Claude Code) after much consternation -- it's been really good at boosting my productivity. This is a passion project I tackle in my spare time, I like coding, but I don't like much of the coding. Much of it is drudgery-- AI is great for that. But there is no substitute for code review.

Yes, that should work. "serve" prints the URL and the 6-digit pairing code to stdout, so your ssh session sees them, and shutting it down is just killing the process.

One suggestion for the untrusted-PC part: bitbang serve -ephemeral. That uses a throwaway identity that dies with the process, so the URL is dead the moment you kill it -- rather than persisting and still working later from whatever browser history it's sitting in. --pin adds a second factor if you want one.

The pairing code is possibly handy too. If you'd rather not type a long URL on an unfamiliar machine, go to bitba.ng, enter the 6-digit code, and confirm the number it shows you back on the Pi.

Remote access lacks a certain amount of sex appeal -- thanks for reading the through the techno-babble and not giving up :)

And yes -- open source and self-hostable is a big part it. The other half is that the connecting side can be a browser, so there's no client to install on whatever you happen to be sitting at. Tailscale is a network you join, this is closer to a link you hand someone.

Also taking "read a whole bunch of text first" as a hint. That comparison probably belongs higher up the README.

here's hoping! :)

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.

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.

Thank you -- and if you're the Sean who wrote Pion, this is built on your work, so that means a lot. :)

The friends case is exactly the gap I kept running into. A mesh VPN is fine for my own devices and hopeless the moment someone else needs in, because now they're installing a client and making an account to look at one thing. Here they get a link.

Baking it into self-hosting flows is the right instinct and I'd love help figuring out where it fits. There's already an OctoPrint plugin; Jellyfin seems like the obvious next one.

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.