BitBang

“BitBang turns any machine into a URL.” Rich LeGrand’s MIT-licensed stack for reaching a device behind a home router from a browser, with no account, no port forwarding, and nothing installed on the connecting side. Run bitbang serve, get a URL, open it: a terminal, a file browser, and a proxy to that machine’s network. 27★ and 27 commits on the entry repo as of 2026-08-03 — a young project, and the star count is not evidence of anything.

Despite the name it has nothing to do with bit-banging a protocol on GPIO pins, and nothing to do with ../bit-manipulation-wiki. The subject is device connectivity (device-reachability).

What it actually does

A browser normally reaches a server over a TCP socket. BitBang replaces that with a WebRTC data channel, the same transport Zoom and Meet use for media, carrying proxied HTTP and WebSockets instead. The bitba.ng signaling server does four things — serves the browser runtime, authenticates the device by RSA challenge, holds a WebSocket to active devices, and brokers the ICE/SDP exchange — and then drops out. After the handshake it is not in the data path.

The pitch is that WebRTC is “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.”

Four repos: bitbang-cli (shell, files, HTTP proxy), bitbang-python (pip install bitbang, wraps any WSGI/ASGI app — Flask, FastAPI, Quart — with live video), bitbang-server (self-hostable signaling), and Octoprint-BitBang, which puts the full OctoPrint UI and hardware-encoded H.264 camera video from a 3D printer behind one URL.

The trust model

Every remote-access system needs a broker, because both ends sit behind NAT and something with a public IP must introduce them. The project’s trustless-signaling.md sorts the field by what the broker does after the introduction: cloud platforms are the data path; tunnelling services decrypt at their edge and re-encrypt; mesh VPNs negotiate every connection through coordination servers. Its argument is that encryption doesn’t settle this, because “a broker that quietly substitutes its own key for either endpoint’s becomes an undetected man-in-the-middle. The encryption stays intact, it just terminates at the broker.” It cites Tailscale’s Tailnet Lock as an opt-in mitigation for exactly that gap.

BitBang’s answer: the device generates a keypair, and the hash of its public key is its 128-bit ID, carried in the URL. A 64-bit access code rides in the URL fragment, which browsers never send to a server — so the signaling server can route a connection but cannot start one. The browser checks the device’s key against the URL itself, encrypts a challenge to it, and verifies the response. Authentication never touches the server.

The paper is honest about where this stops. It splits attacks into wire attacks (MITM, SDP tampering — covert, defeated by the protocol) and JS tampering (overt, defeated only by the served code being inspectable). That second one is a real dependency on the operator of the signaling server, and the document says so: trust “shifts from an opaque policy question to an inspectable code question,” which is weaker than removing it. Users of the installed CLI or Python client avoid the served-code question entirely.

Its own comparison

From the bitbang-cli README, reproduced as the project’s claim rather than as a verified result:

Nobody independent has checked any row of this.

Origin, and why it belongs on this spoke

LeGrand traces it to a 2010 Google Tech Talk with Illah Nourbakhsh (Carnegie Mellon) on TeRK, a Google- and Intel-funded educational telepresence robot kit. The conclusion he reports had nothing 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 just open-sourced libjingle, the P2P engine behind Google Talk, but it was C++ and tied to XMPP.

His account of what happened next:

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.

That is a claim about why the IoT platform layer looks the way it does — timing and inertia rather than necessity — and it is the first source here to make one. BitBang was built for Goby, a sub-$100 telepresence robot that ran a Kickstarter in 2025; the stack was open-sourced as promised.

T3. A self-described README plus two design documents by the author, MIT-licensed and readable, with no independent audit, no third-party benchmark, and no measurement of the P2P success rate (which in practice depends on NAT types and on TURN fallback the entry README doesn’t discuss). Star counts and the comparison table are 2026-08-03 snapshots.

Related

device-reachability · iot-protocols · the-open-book-ereader · embedded-systems · synthesis