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