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. :)
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.
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.
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.
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.
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.
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 -- 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.
Fantastic work on this. This idea has so much promise, I hope this is the project that makes it take off.
Self-hosting is pretty these days with docker. Exposing it to the internet is the annoying part. I do Jellyfin via netbird, but that means I don't really share it with my friends. I hope something like this getting baked into self-hosting flows is killer.
My other pet peeve is that people use 'Cloud Services' for File transfer. Sometimes when they are in the same LAN!
Nice work again and I hope it catches on/people understand how great this really is :)
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.
This seems simple and utile! Reading though the white paper on GitHub, there is a malformed Markdown table in the “Why WebRTC?” section [1] that probably just needs one more | somewhere.
So i can see my use case like this: I ssh from my phone to my home raspberry pi through tailscale. i type an alias that causes the RPi to run bitbang serve and prints the connection number through stdout so i see it on my phone ssh session.
Now on an untrusted PC i can bingbang into my home network, do stuff with a real keyboard, and then run another command to shutdown bitbang.
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.
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.
UPnP is the standard way to get CPE firewalls to allow a port.
Other than that, discussing IPv6 on HN is… draining at best. It's all been argued a million times at this point. People hate it. People love it. People love to hate it. People hate to love it. I'm done :-)
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. :)
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.
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.
> 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
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.
Ah good point, no udp. I was looking at webtorrent but it does share the same limitation, unless you’re on the nodejs (non-browser) version.
Looking forward to trying bitbang! Seems super neat
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.
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.
I'm thrown off because you use so many em dashes, but the text surrounding them generally seems human.
Not judging or brigading, just personally don't want to add a new tool to my toolbelt knowing it's made with ai right now. Is bitbang made with ai?
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.
There are several Coauthored by Claude commits. So at least partially LLM generated.
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?)
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.
> 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.
Cloudflare's is $0.05 per GB if your traffic exceeds the 1,000 GB free threshold.
Sounds like all I need to do is get this onto a machine and find a way to open the url click exploit or something and I get a RAT
Fantastic work on this. This idea has so much promise, I hope this is the project that makes it take off.
Self-hosting is pretty these days with docker. Exposing it to the internet is the annoying part. I do Jellyfin via netbird, but that means I don't really share it with my friends. I hope something like this getting baked into self-hosting flows is killer.
My other pet peeve is that people use 'Cloud Services' for File transfer. Sometimes when they are in the same LAN!
Nice work again and I hope it catches on/people understand how great this really is :)
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.
I'm so ready for this and jellyfin, just need you to fix the cli args so i can run the server on Cloudflare TURN.
This is a really useful feature and on the top of my todo list https://github.com/richlegrand/bitbang-cli/issues/9
Would love to have this on https://github.com/anderspitman/awesome-tunneling as soon as it hits 100 stars.
here's hoping! :)
Will shamelessly promote my thing: https://ssh-j.com
No applications except regular ssh client. Needs an SSH connection on the client as well though.
Hey there, neat offering.
I see you posted it before. https://news.ycombinator.com/item?id=26500128
If you want this to have more traction engage with those of us who have/had questions. Please consider an example section once connected to ssh-j.com
Thanks.
It has an example on both the website and in SSH.
This seems simple and utile! Reading though the white paper on GitHub, there is a malformed Markdown table in the “Why WebRTC?” section [1] that probably just needs one more | somewhere.
[1] https://github.com/richlegrand/bitbang/blob/main/whitepaper....
thanks for the catch :)
So i can see my use case like this: I ssh from my phone to my home raspberry pi through tailscale. i type an alias that causes the RPi to run bitbang serve and prints the connection number through stdout so i see it on my phone ssh session.
Now on an untrusted PC i can bingbang into my home network, do stuff with a real keyboard, and then run another command to shutdown bitbang.
Does that sound feasible?
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.
Looks like https://www.iroh.computer, can you explain how this approach is similar/different?
I like the idea but product seems to be unfinished or at least still not usable considering the problem it is solving
So I read a whole bunch of text trying to figure out what this thing is...
Then I see the following line in the 'How it compares' section:
"Self-hostable server (open source)": ngrok->No, Cloudflare Tunnel->No, Tailscale->No, Bitbang->Yes
...and I'm like, "It's Open Source Tailscale!"
And now I "get it"! (you know, epiphany, profound enlightenment and all that!) :-)
(Well, it's an open source alternative to Tailscale, to be more precise, and an excellent one at that!)
Great work, Rich LeGrand!
(Another step forward for open source!)
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.
IPv6.
(Let's skip the discussion, I don't feel like watching groundhog day today.)
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.
UPnP is the standard way to get CPE firewalls to allow a port.
Other than that, discussing IPv6 on HN is… draining at best. It's all been argued a million times at this point. People hate it. People love it. People love to hate it. People hate to love it. I'm done :-)
how's this different from iroh?
Pls see reply above.