Device reachability

A device on a home or office network can open connections outward and cannot accept them inward. bitbang states it as two rules: machines with public addresses are reachable by anything; machines on your local network are reachable only from your local network. NAT and the firewall enforce the asymmetry, and it applies to “files, cameras, sensors, compute, or the web app you’re currently developing.”

This is the constraint that shapes the layer above iot-protocols, and it belongs in the same family as the ones embedded-systems is built on. Power, memory and board area explain why a sensor runs bare-metal firmware; reachability explains why it phones home.

The cloud is a workaround for it

If a device cannot be dialled, it must dial out and hold the connection, which means something with a public address has to sit at the other end and stay there. That server is then positioned to become the product. The result is the pattern bitbang names: “Your device talks to a cloud, your browser talks to the same cloud, and they meet in the middle.”

Read this way, several things that look like independent design decisions are the same decision. MQTT’s broker exists because publisher and subscriber can’t reach each other. The IoT Platform-as-a-Service exists because someone has to run that broker. Accounts, subscriptions and telemetry-in-someone-else’s-datacentre follow from owning the middle. The technical constraint is real; the business model on top of it is not implied by it, and that gap is the whole of bitbang‘s argument.

Four things a broker can be

Any two NATed endpoints need an introduction. What differs is what the introducer does afterwards — this is bitbang‘s taxonomy, and it is a useful map regardless of whether its own solution works:

• Cloud platform — the broker is the data path. Every message goes through it.
• Tunnelling service (ngrok, Cloudflare Tunnel) — traffic terminates at their edge, is decrypted there, and is re-encrypted onward.
• Mesh VPN (Tailscale) — the data path is peer-to-peer, but coordination servers negotiate every connection and hold the key distribution.
• Introduction only — the broker exchanges connection metadata and then drops out, which is what WebRTC signaling does and what bitbang is built on.

The first three all leave the broker able to substitute a key and terminate the encryption at itself without either endpoint noticing. That’s the argument; no source here has tested it.

Refusing the middle, twice

The spoke now holds two devices that decline to depend on someone else’s server, at different layers. the-open-book-ereader has no radio at all — it solves reachability by not being reachable, and its argument is about who controls what you read. bitbang keeps the network and removes the cloud from the data path.

These are the two available answers to the same discomfort, and they cost different things. The Open Book gives up remote access entirely; BitBang keeps it and takes on NAT traversal, a signaling dependency, and a browser as the client runtime. Neither is the default the field actually shipped.

Related

bitbang · iot-protocols · the-open-book-ereader · embedded-systems · synthesis