bitbang README

The project's README from github.com/richlegrand/bitbang. As one markdown file: README.md.

BitBang

BitBang turns any machine into a URL.

Run BitBang, get a URL, and open it in any browser -- you're connected to the machine, peer-to-peer and end-to-end encrypted. There's no account, no port forwarding, and nothing to install on the connecting side.

This repository is the entry point to the BitBang project. The code lives in the repos below.

Try it (30 seconds)

On the machine you want to reach (Linux; other platforms are coming):

curl -sSfL bitba.ng/install | sh
bitbang serve

serve prints a URL. Open it in any browser for a terminal, a file browser, and a proxy to that machine's network. Full documentation, pairing, and the CLI client: bitbang-cli.

The repositories

bitbang-cli -- start here. Turns any machine into a URL: remote shell, file access, and web-app proxying, from a browser or another terminal. For you if you want remote access to a machine, now.

Octoprint-BitBang -- turns your 3D printer into a URL: the full OctoPrint UI, including hardware-encoded H.264 video from the printer's camera. For you if you have a 3D printer.

bitbang-python -- turns any Python program into a URL (pip install bitbang): wraps any WSGI or ASGI app (Flask, FastAPI, Quart), with live video streaming. For you if you're building something.

bitbang-server -- the machinery behind the URLs: the signaling server and browser runtime. It powers bitba.ng, and you can self-host it -- the whole stack, under your control. For you if you trust no one, which around here is considered a feature.

Read more

Why BitBang is needed

The Internet is often thought of as a fully connected network -- every machine accessible from every other machine. But there are rules governing accessibility...

Rules of Internet Accessibility

  1. Machines on the Internet are accessible by other machines on the Internet -- and by machines on your local network.
  2. Machines on your local network are only accessible by other machines on your local network.

Because of rule 2, machines on your local network aren't reachable from outside -- nor are the resources they hold: files, cameras, sensors, compute, or the web app you're currently developing. Cloud services exist to fill this gap: Dropbox for files, AWS IoT for sensors, Tailscale for compute, ngrok for web apps. These services apply rule 1, but each comes with the friction of account creation, fees, and your data living on someone else's server.

BitBang takes a different path: devices connect directly to browsers, peer-to-peer, with the server reduced to a brief introduction it can neither read nor tamper with. For a feature-by-feature comparison with ngrok, Cloudflare Tunnel, and Tailscale, see the bitbang-cli README.

How it works

Browsers normally connect to web servers over a TCP socket. BitBang replaces this with a WebRTC data channel.

BitBang block diagram

The signaling server (bitba.ng) brokers the WebRTC handshake, then has no further involvement and never sees application data.

WebRTC?

WebRTC is the technology behind Zoom and Google Meet. It was designed for real-time media -- sub-second latency, high bandwidth -- and it's mature, well-tested, and built into every major browser. Alongside media it carries raw data over "data channels," which is what BitBang uses to proxy HTTP and WebSockets. WebRTC is also notoriously unpleasant to use directly: signaling, SDP, ICE, DTLS fingerprints, TURN. Burying that is most of what BitBang does. You get an address, not a protocol project.

Signaling server

The signaling server (source) does four things:

  1. Serves the BitBang browser runtime
  2. Authenticates connecting devices via RSA challenge
  3. Maintains WebSocket connections to active devices
  4. Brokers ICE candidate and SDP exchange between browsers and devices

After the P2P connection is established, the signaling server is not involved. We provide one at https://bitba.ng; it mostly brokers connections, so its resource needs are small -- and you can run your own.

Security

WebRTC mandates encryption:

Each BitBang device generates an RSA keypair. The public key hash becomes its unique 128-bit ID, used in its BitBang URL. A 64-bit access code rides in the URL fragment (after #), which browsers never send to a server -- so the signaling server can route connections but cannot initiate them. How the two ends authenticate each other without trusting the server, and exactly where that guarantee's boundary lies, is covered in Trustless Signaling.

Origin

In 2010, I gave a Google Tech Talk with Illah Nourbakhsh of Carnegie Mellon on TeRK (Telepresence Robot Kit), a Google- and Intel-funded project to make educational robotics accessible. Our conclusion had little to do with robots: the internet is broken for devices. NATs and firewalls make every device behind a home router invisible from the outside. Google had recently open-sourced libjingle -- the P2P engine behind Google Talk -- and we wanted to use it for zero-config device connectivity. But it was a C++ library tied to XMPP, and we felt strongly the technology should be browser-friendly. That was too big a problem for our resources.

In the years that followed, connected devices became "IoT" and converged on a single pattern: Platform-as-a-Service. Your device talks to a cloud, your browser talks to the same cloud, and they meet in the middle -- accounts, subscriptions, and your data on someone else's server. Meanwhile WebRTC, libjingle's direct descendant, quietly shipped in every major browser. But it was built for video calls, and by the time it arrived, IoT had already settled into its cloud pattern -- peer-to-peer never entered the picture. BitBang is what happens when it does: devices talk directly to browsers, with no cloud in the data path and no account required. BitBang was built for Goby, a tiny telepresence robot that launched on Kickstarter in 2025 -- the spiritual descendant of TeRK, realized with the technology we had wished for fifteen years earlier. We promised to open-source the networking stack that made it possible. BitBang is that stack.

License

MIT, across all repositories.

Contributing

Issues and PRs are welcome.

bitbang (richlegrand/bitbang)

Searching Database…

这是什么?BitBang 能把任何一台机器变成一个 URL:在设备上运行它,在任意浏览器里打开这个 URL,你就通过端到端加密的点对点方式连上了那台机器 —— 不需要注册账号,不需要端口转发,连接的一端也不用装任何东西。
这是需要注册使用的托管服务,还是我自己运行的软件?它是你自己运行的开源软件(MIT 许可证),不是基于账号的服务。这个仓库是一整套子仓库的入口;bitba.ng 上有一个公共的信令服务器,但整个系统也可以完全自托管,由你自己掌控。
我怎么连接到我的一台机器?在你想访问的机器上(目前是 Linux),安装 bitbang-cli 并运行 serve —— 它会打印出一个 BitBang URL。在浏览器里打开它,你就能得到一个终端、一个文件浏览器,以及通往那台机器网络的代理。
我用什么设备来连接?只需要一个现代浏览器 —— WebRTC 内置于所有主流浏览器中,所以连接的一端什么都不用安装。
目前有哪些限制需要了解?设备端目前只支持 Linux;README 里说其他平台正在开发中。“不信任服务器”保证的确切边界在 Trustless Signaling 论文中有单独说明。
它能在哪些平台上运行?设备端目前是 Linux;连接的一端可以是任何操作系统上的任何主流浏览器,因为连接方什么都不用安装。
我能自己运行服务器端吗?可以 —— 信令服务器支持自托管,而且主要只是撮合连接,资源需求很小。你可以运行整套系统,而不依赖 bitba.ng。
我的流量会经过你们的服务器吗?不会 —— 信令服务器只负责撮合 WebRTC 握手,之后就不再参与,永远看不到应用数据。数据通道使用 DTLS 1.2+,媒体流使用 SRTP,访问码放在 URL 的片段部分(# 之后),浏览器绝不会把这部分发送给服务器。
它和 ngrok 或 Tailscale 有什么不同?那些云服务能打通 NAT,但需要注册账号、付费,而且你的数据存在别人的服务器上。BitBang 让设备直接与你的浏览器点对点连接;服务器只负责牵线,既读不到也篡改不了流量。与 ngrok、Cloudflare Tunnel 和 Tailscale 的逐项功能对比可以在 bitbang-cli 的 README 里找到。
别人拿到我的 URL 就能连接我的机器吗?不能。每台设备会生成一对 RSA 密钥,其公钥哈希就是它的 128 位 ID;另有一个 64 位访问码放在 URL 中 # 之后的片段部分 —— 浏览器绝不会把这部分发送给服务器。所以信令服务器能转发连接请求,却无法主动发起连接;Trustless Signaling 文档详细说明了这个保证的边界在哪里。
作者为什么要做这个项目?它源自 TeRK —— 一个 2010 年的教育机器人项目,该项目得出的结论是:对处于 NAT 后面的设备来说,互联网是坏掉的。WebRTC 后来进入了每一款浏览器,但它是为视频通话设计的,所以点对点技术从未进入物联网领域。BitBang 是 Goby 背后开源出来的网络协议栈,Goby 是一款 2025 年在 Kickstarter 上发布的小型远程临场机器人。
Size
0.5 MB
Stars
183
Updated
CommitOct 02
Age
5mo
Commits · 90 Days