What works today

Counted from the tree, not written from memory. A hand-maintained status page ages in the flattering direction — something gets marked working when its tests pass and nothing ever moves it back — so every number here is read out of a document that is maintained for another reason.

The short version

• 7 of 58 bridges are implemented and tested.
• 18 are implemented but have never been run against the real hardware they are for. Their codecs are tested; the last hop is not.
• 3 are partly built — some of the path exists and some does not.
• 3 carry more than one status at once, because they are several paths under one name and those paths are not equally proved.
• 27 are planned and not written.
• 0 of 22 hardware verification procedures have a recorded run.
• 0 of 12 components have had an independent security review.

No hardware procedure has a recorded run, and that is the most important line on this page. Everything marked 🧪 below is code that compiles, passes its codec tests, and has never met an antenna — a template to confirm against your own hardware, not a claim that it works.

Nor has anything had an independent review. Every fault on record was found by the same people who wrote the thing, which is a real method with a known blind spot: it finds what its authors thought to look for.

What you can actually do right now

• Run a node in a browser tab, offline, from a single HTML file with no external requests — and have two tabs talk over a loopback or WebSocket link.
• Run a node on Linux, macOS or Windows, and on Android. Both are built on every pull request.
• Move messages over anything that carries bytes: a socket, a folder, a USB stick, a serial cable. These are the paths CI exercises end to end.
• Rebuild the whole protocol from the documentation, with decoders in C, Python and shell that depend on nothing. See Rebuild.

Bridges, by what has actually been proved

✅ Implemented and tested

• UDP / IPv4 broadcast — implemented & tested
• Audio modem — implemented & tested
• TCP (KISS) — implemented & tested
• WebSocket — implemented & tested (JS; native shim TODO)
• Folder / USB / Syncthing — implemented & tested
• HTTP bag — implemented & tested
• Text armor (SMS / paper / voice) — implemented & tested

🧪 Implemented, never run on the hardware it is for

The codec is tested off-device; the radio, the tap, the live peer is not. Treat each as a template to confirm against your own hardware — the repeatable procedure is in Hardware verification.

• Wi-Fi Direct — implemented — udp::run_group pinned to the P2P interface's address
• NFC (ISO/IEC 14443) — NDEF codec implemented + tested; the tap itself needs a phone
• Ham AX.25 / KISS — implemented — run_tcp / run_serial, not hardware-verified here
• ICMP echo (ping) — codec tested; raw-socket runner is a Linux CAP_NET_RAW template
• BATMAN-adv — implemented — udp::run_group bound to bat0's address
• Yggdrasil / cjdns — implemented — udp::run_group binds the tun and floods ff02::7373
• Thread — implemented — udp::run_group on the mesh interface (IPv6 multicast)
• Tor (onion service) — implemented — dial-out via SOCKS5 (reconnecting); inbound is a torrc onion service in front of bridge::tcp
• I2P — implemented — STREAM CONNECT out, STREAM ACCEPT in, reconnecting
• iroh (QUIC) — implemented — two-endpoint localhost round-trip in CI (iroh workflow); real NAT paths not yet exercised
• WebRTC DataChannel — implemented, not automated-tested (needs a live peer)
• WebTorrent swarm — implemented, not automated-tested (needs trackers + peers)
• Web Serial / USB — implemented, not hardware-tested
• Web Bluetooth — implemented, not hardware-tested
• Copyparty — implemented — http:// shares; put TLS in a tunnel (see below)
• Nostr — implemented (JS), not live-tested against relays
• NNCP — via bridge::spool — the SPORE side is tested; the NNCP wiring is config
• UUCP — via bridge::spool — the SPORE side is tested; the UUCP wiring is config

Several paths, unequally proved

One name, more than one route, and not all of them tested. The full status line is reproduced rather than reduced to its best marker.

• BLE GATT — ⚪ planned (native); 🧪 in the browser
• Meshtastic — one codec, four pipes — ✅ WiFi-UDP (bridge::meshtastic::run) · 🧪 USB serial (run_serial / run_pipe) · 🧪 Web Serial & BLE
• Reticulum (RNS) — RNode host mode — 🧪 RNS payload (bridge::reticulum + companion, via stdio/TCP/UDP) · 🧪 Web Serial & BLE (RNode host mode) · ⚪ native RNode serial

🟡 Partly built

Some of the path exists and some does not. Each row says which half.

• QR stream — partial — armor present, animated runner TODO
• WebTransport — partial — browser shim written, not wired in; no native endpoint
• SSB (Secure Scuttlebutt) — partial — bridge::ssb codec + folder-log runner

⚪ Planned, not written

• Ethernet 802.3
• Wi-Fi 802.11
• ESP-NOW
• BLE Mesh
• LiFi (IEEE 802.15.7)
• IrDA
• Zigbee
• Z-Wave
• LoRaWAN
• LoRa P2P
• APRS
• DMR
• goTenna
• JANUS (underwater sonar)
• Iridium SBD
• Veilid
• libp2p (gossipsub)
• Matrix
• XMPP / Jabber
• DeltaChat (email)
• Session (Oxen)
• Briar
• Tox
• DTN / Bundle Protocol v7
• Serval Rhizome
• Hypercore / Hyperswarm
• Earthstar / Willow

Testing, per component

Of 12 components: 8 fuzzed, 4 property-tested, 3 exercised by a hardware procedure, 0 independently reviewed. The per-component table, including what an attacker controls in each case, is the security maturity matrix.

Where the numbers come from

• Bridge rows: the Status line of each section in Bridges.
• Hardware: rows in the checklist, and how many carry a date. The file asks each runner to note the date and result; a row without one has not been run, or the run was not written down, and those are the same thing from here.
• Components: the security maturity matrix, which is itself generated from the fuzz targets and test modules in the tree.