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.

This is a really useful feature and on the top of my todo list https://github.com/richlegrand/bitbang-cli/issues/9

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.

It's a single Go binary, shaped like ssh. The main difference is the transport -- WebRTC instead of TCP -- so it doesn't need the machine to be reachable in the first place. Run "bitbang serve" and it prints a URL. Open it in a browser and you get a terminal, a file browser, and a proxy to web apps on that machine's network -- or connect from another terminal. There's nothing to install on the connecting side, no account, no port forwarding.

The trick to having no accounts: a device's identity is the hash of its public key, so browser and device verify each other directly. The server keeps no registry, authorizes nothing, and isn't in the data path -- it brokers the introduction and steps aside. About 75% of connections go direct P2P. The rest fall back to a TURN relay that only sees ciphertext. The server is open source and self-hostable -- and since it's out of the data path, cheap to run.

BitBang started on an ESP32, as the networking for a tiny telepresence robot. Embedded development is difficult and slow, so this CLI is where I've beaten the security model into shape. The embedded version is next. :)

It's completely useless, but I still want one.

Agreed. IoT is a shitshow of ways to grab your data and PaaS monthly fees. Maker-friendly IoT like this is welcome. Remember Blynk? It started well enough, but became just another platform to coral its customers to the paywall.