SPORE Bridge Reference

The emoji in each protocol's title tells you how far it is:

Throughout, U is the underlay address type (how a medium names a peer) and Form is the driver form (dgram / stream / store, see below).

Bulk budget. Since files became manifest trees they can be arbitrarily large, so any link can be conscripted into hauling one. Each interface may therefore register a bulk budget — bytes per second of other people's file chunks it is willing to relay (Hub::register_limited) — as a leaky bucket that accrues a few seconds of burst.

Only chunks count as bulk. Messages, announces, receipts and manifests always pass, so a paced link stays a full member of the mesh: it still carries the conversation, and still tells everyone what exists. It declines only to be the pipe, and because chunks are named by content the fetch simply asks again and another path answers. The default for each medium is a constant in that bridge's module, so the number and its reasoning stay together; override at runtime with Hub::set_bulk_budget. Media fast enough not to care (UDP, TCP, WebRTC, the web overlays) set no budget at all and are unchanged.

Nothing. A bridge moves bytes; it is never trusted for authenticity, secrecy or honesty. Envelopes are signed and sealed end to end (§2, §7), ids are content hashes, and path learning binds only from signed frames. A hostile link can drop, delay, replay or reorder — all of which the router already survives — but it cannot forge, read a sealed payload, or make a node believe a false address.

That last one is load-bearing and was, until recently, not actually enforced. Bridges learn SPORE address → underlay address by snooping, and both learning paths — Neighbors::snoop and the node's own path table — accepted the SIGNED flag as proof. A flag is one bit chosen by whoever wrote the frame. Copy a victim's public key into src, set the bit, attach 64 zero bytes, and the victim's address bound to your underlay address: every directed send for them unicast to you instead. Sealed payloads stayed unreadable, so this stole no content — it redirected delivery, which is the same guarantee by a different door. Both paths now verify the signature, and Src::Short (8 bytes of address, no key, nothing to verify against) teaches nothing at all. A bridge that declines to learn falls back to broadcast, which always reaches the peer; a bridge that learns a forged binding does not.

What a bridge can do wrong is spend our resources. Every bridge parses input from something it does not control, and the failure mode is not a forged message but an out-of-memory. So the rule for every bridge in this repo is:

Every read from a peer is bounded, and every length that comes off the wire is checked before it is believed.

The limits, and where they live:

Two of these bounds are on a read, not on a size the sender declared, and the distinction is the point:

• spool stats the file and then caps the read anyway. The size check is a fast reject; it is not the bound. Between the stat and the read the mover can replace or extend the file, so a plain fs::read would buffer whatever is there at the later moment. The cap lives on the read itself; an over-cap file is left for the next sweep, whose stat now sees the real size and clears it.
• reticulum::run_udp accepts datagrams only from the companion. It is the one datagram bridge that carries framing state across datagrams, so a frame may be half-assembled when the next arrives. Where udp::run_group can ignore a stranger's datagram as one bad envelope, here a stranger's bytes would interleave into a frame the companion is midway through — corrupting a good frame rather than merely adding a bad one. Single-sourcing the framer is what removes it.

congestion::STAMP_QUOTA_BYPASS_BITS is 16. Mail stamped to at least that class skips the per-source quota (§10d) and a busy peer's backpressure (§10c); below it, mail still flows but is charged to its source's budget like anything else, and stamp still orders eviction and TX priority (§10.3).

This was stamp > 0, which bounded nothing. A stamp is the leading zero bits of the envelope id, and the id is a hash, so class 1 costs about two tries and half of all envelopes have it by accident — measured, 12 of 20 arbitrary junk envelopes were exempt from the quota by luck alone. SPEC is explicit that "priority is bought, not claimed" (§2) and that a stamp is "proof of work" (§10); the exemption has to cost something for either sentence to be true.

Consequences a deployer should know:

• A node running this is stricter than an older one. It throttles low-class stamped traffic that older relays pass. That is a local policy difference, not a wire incompatibility — nothing about the envelope changed, and the two interoperate.
• 16 bits is ~65k tries: milliseconds on a laptop, seconds on a microcontroller. Affordable once for a genuinely urgent message, ruinous for a flooder paying it per envelope. Raise it on fast networks; lower it (or set it to 1) to restore the old permissive behaviour if you need bit-identical admission against a 1.0 relay fleet.
• sos still outranks policy by convention — that is a routing preference, not a quota exemption, and is unaffected.

A bridge cannot forge and cannot read a sealed payload. It can always see that traffic happened, how big it was, and when — and on some media it can see rather more than that. This section is per-bridge because the honest answer differs a lot, and "SPORE is encrypted" is not a useful thing to tell an operator choosing between a folder in someone's cloud account and a serial cable.

The part people get wrong first: a public flood is not encrypted. Sealing is something a sender does. An envelope to ZERO_DEST or to a plaintext topic carries its payload in the clear, by design — and the reason is that there is no key to encrypt it to. A public topic's whole job is to be readable by a node that joined afterwards, that you have never met, receiving it third-hand; anything needing a prior key exchange is not that. (It is not that relays must read the payload to route: forwarding runs entirely on the header, and sealed unicast floods perfectly well with an opaque body.) Signed does not mean secret.

If a message must stay private on a medium anyone can watch, seal it to a recipient prekey, or use an encrypted topic (§7) — which is a real private group, with topic::rotate for forward secrecy and topic::rekey_seal to evict a member. Otherwise assume it is a postcard, because it is one.

Three consequences worth stating outright:

• A gateway links identities across media. A node bridging Wi-Fi and LoRa tells anyone watching either side that those two populations are connected, and relays timing between them. That is the job — but it means running a gateway is not a neutral act, and mix mode exists for when it must not be inferable.
• "Works offline" is not "works privately". The media that need no infrastructure — broadcast, radio, sound — are the ones where observation is cheapest. A blackout does not remove eavesdroppers.
• Mix mode is not Tor. It nests sealed envelopes and pads to three size classes (mix::SIZE_CLASSES), which frustrates casual correlation. Nobody has analysed it against a global observer, and it has had no external review. Do not stake anything on it that Tor would be the right tool for.

Several media on this page speak only TLS: Matrix, XMPP, e-mail, wss:// Nostr relays, most public HTTP shares. SPORE links no TLS stack, and that is a decision rather than an omission.

SPORE does not need TLS for security. Envelopes are signed and sealed end-to-end (§2, §7); a link is assumed hostile whatever it is made of. TLS here buys exactly one thing — permission to talk to a server that insists on it. Paying for that with a TLS implementation and its certificate machinery, in a project whose premise is that one person can audit and rebuild the whole thing from a printed spec, is a bad trade.

So TLS is terminated outside the process, the same way sound cards, serial line settings and Reticulum already are:

# HTTPS share -> plaintext on localhost, then point a bridge at the tunnel
socat TCP-LISTEN:8080,fork,reuseaddr OPENSSL:files.example.org:443
spore copyparty:http://127.0.0.1:8080/bag/

# or with stunnel, which verifies certificates properly
stunnel -c -d 127.0.0.1:8080 -r files.example.org:443

Three consequences worth being explicit about:

• Certificate verification is the tunnel's job. socat OPENSSL: verifies by default; openssl s_client does not unless told to. Configure it as carefully as you would any TLS client, because SPORE cannot check it for you.
• The plaintext hop is real. Bind the tunnel to loopback. On a shared machine that hop is visible to other users — though it carries signed, sealed envelopes, so what leaks is traffic analysis, not content.
• TLS alone does not deliver Matrix or XMPP. Those also need their protocol (Matrix's client-server API and JSON, XMPP's XML streams). The tunnel removes the transport blocker; the protocol work is still unwritten. What it does unlock today is every HTTP-shaped store: copyparty, WebDAV, an HTTPS bag.

If a single-binary story ever matters more than the dependency budget, the clean way in is an optional cargo feature that swaps the tunnel for a pure-Rust TLS client — not a default dependency, and not something hand-rolled. Nobody should write their own TLS.

Because the router is medium-independent, every bridge reduces to the same three things, and all the shared logic already lives in src/bridge/:

1. An address type U — how that medium names a peer (a MAC, an IP:port, a Meshtastic node number, or () for broadcast-only media). Learned and resolved by bridge::Neighbors<U> (SPORE's ARP), which is generic over U: it snoops the source of inbound frames to bind spore_addr → U, resolves a SPORE dest to a U for directed sends, and ages bindings out (expire) or drops them on disconnect (forget).
2. A payload budget (MTU) — the bridge clamps the shared node's mtu, and SPORE's fountain fragmentation (Node::send) auto-splits to fit. There is no per-medium chunking code to write.
3. recv / send — the only platform-specific part. A datagram medium implements bridge::driver::DatagramTransport (just recv, send, optional mtu) and gets neighbour learning, resolution, relay, and MTU clamping for free from driver::run_datagram.

So adding a medium is: pick U, set the MTU, write recv/send. Everything else is in the lib.

Protocol wire format (RFC 768). The SPORE envelope is the UDP payload verbatim — one envelope per datagram, no extra framing.

 0               15 16              31
+-----------------+-----------------+
|   Source Port   | Destination Port|
+-----------------+-----------------+
|     Length      |    Checksum     |
+-----------------+-----------------+
|         data  =  SPORE envelope   |
+-----------------------------------+

SPORE bridge mapping. send(None, env) sends env to the broadcast address; send(Some(sa), env) unicasts to a learned SocketAddr. recv reads one datagram and reports the sender's SocketAddr as U, which Neighbors<SocketAddr> snoops to bind spore_addr → ip:port. Broadcast is native: 255.255.255.255 (limited) or the primary interface's directed broadcast (192.168.x.255), which run_primary derives from the interface netmask for zero-config LAN. MTU is clamped to 1400 so the fountain fragmenter splits larger objects into datagram-sized chunks. No connection lifecycle — a neighbour ages out when its heartbeats stop.

Security. UDP itself has no authentication or encryption (its checksum is integrity-only and optional on IPv4). SPORE does not rely on the medium: every envelope carries its own Ed25519 signature and an optional sealed-box payload, so a forged or replayed datagram is rejected by the router (hops=0 content-ID dedup + signature check), not by UDP. On open Wi-Fi, treat the segment as public.

References. RFC 768 (UDP); RFC 919 / RFC 922 (broadcasting datagrams).

Protocol wire format (IEEE 802.3). dest MAC(6) · src MAC(6) · EtherType(2) · payload(46–1500) · FCS(4). The bridge picks an unregistered EtherType (e.g. 0x88B5/0x88B6, reserved for experimental use) and places the SPORE envelope in the payload; frames shorter than 46 bytes are zero-padded (SPORE ignores the pad — the envelope carries its own length).

SPORE bridge mapping. U = [u8;6]; recv yields the source MAC, Neighbors<[u8;6]> snoops it, and broadcast is ff:ff:ff:ff:ff:ff. Needs CAP_NET_RAW (Linux) or a BPF device (macOS/BSD); belongs in a platform crate, not the portable core.

Security. None at L2; rely on the envelope signature. VLAN/segment isolation is the only medium-level boundary.

References. IEEE 802.3; EtherType registry (IEEE RA).

Protocol. 802.11 MAC frames carry up to four address fields and a payload; a bridge would use a data or vendor-specific action frame with the envelope as the frame body. In practice most deployments run IP over Wi-Fi and reuse the UDP bridge — raw injection is only worth it for AP-less operation and needs a card/driver that supports monitor mode + injection.

SPORE bridge mapping. U = [u8;6] (the source MAC), dgram form, one envelope per frame body. The receive side is the part that differs from every other bridge: monitor mode delivers every frame in the air, not just ours, so the callback must reject foreign traffic before doing any work on it. Envelope::probe exists for exactly this — it walks the v1 header and returns the envelope's length, or None to discard, without allocating. Only what survives it is worth handing to Envelope::decode and then hub.on_rx. A probe hit is a structural match and nothing more; the signature check still decides whether a frame is real.

Frame format (normative — both implementations must match). The board and the Linux daemon are two implementations of one wire format, so it is specified here rather than left to whichever gets written first. Board-to-board interop happens by accident when both ends run our code; board-to-laptop only happens if this is written down.

SPORE rides a vendor-specific Action frame — management type, subtype Action, category 127. That is the same mechanism ESP-NOW is built on, which is the reason to choose it: it is the one frame shape an ESP32 is known to inject and receive without association, and it needs no LLC/SNAP header or registered EtherType.

802.11 MAC header (24 bytes)
  0   Frame Control  2   0xD0 0x00  — type=Management(0), subtype=Action(13)
  2   Duration       2   0x0000     — set by hardware
  4   Address 1      6   FF:FF:FF:FF:FF:FF  (destination; always broadcast)
  10  Address 2      6   transmitter MAC    (learned as `U`)
  16  Address 3      6   02:53:50:4F:52:45  (BSSID, fixed — see below)
  22  Seq Control    2   0x0000     — set by hardware
Action body
  24  Category       1   0x7F       — Vendor Specific
  25  OUI            3   02:53:50   — locally administered, see below
  28  Magic          1   0x53       — 'S'
  29  Version        1   0x01       — this format
  30  Payload        n   one SPORE envelope, verbatim
FCS                  4              — appended and checked by hardware

• Broadcast only. Address 1 is always the broadcast MAC. SPORE floods and dedups by content id; unicast at this layer would duplicate routing the core already does.
• The BSSID is a constant, not an access point. 02:53:50:4F:52:45 is 02 + "SPORE" in ASCII, with the locally-administered bit set. Nothing joins it and no beacons are sent — it exists so a capture filter can select SPORE traffic cheaply, and so two boards from the same box share it with no configuration.
• The OUI is locally administered, not IEEE-registered. 02:53:50 sets the local bit for the same reason. Collision with another vendor using the same value is possible and harmless: the magic byte, the version, and then Envelope::probe reject anything that is not ours before it costs a decode.
• Channel 1 by default, because the locked "flash it and it works" rule means two boards must find each other with no configuration. Both ends must be on the same channel; scanning is not part of this bridge.
• No FEC of our own, deliberately. 802.11's PHY already does forward error correction, and the FCS means a corrupted frame never reaches us — losses arrive as whole missing frames, not flipped bits. That is exactly the shape SPORE's fountain erasure coding already handles at the object layer (Spec §3), so adding bit-level coding here would pay overhead to solve a problem the medium has solved.
• MTU is unvalidated. The 2304-byte MSDU is the standard's ceiling, not what a given driver will inject; ESP-IDF and mac80211 both impose their own lower limits. Treat the table's figure as the theoretical maximum and fix a conservative real one during E2 — 🧪 until a device run establishes it.

Security. WPA2/WPA3 secure the link when associated; raw/ad-hoc frames are open. SPORE's signature is the trust anchor either way.

Regulatory. Injecting frames outside normal association is regulated differently across jurisdictions, and some bands carry rules this bridge does not try to satisfy on your behalf — amateur bands prohibiting encrypted content being the most common. SPORE documents what the bridge does and does not weaken or strip encryption to comply with a band's rules for you; whether a given deployment is permitted is the operator's call, and theirs to answer. This is the same disclosure posture as a mix mode's stated limits, not an endorsement or a warning against use.

References. IEEE 802.11.

SPORE bridge mapping. Bring up the P2P group with the platform API (wpa_supplicant p2p_connect, Android WifiP2pManager), then run the UDP broadcast bridge on the group interface's directed broadcast. No SPORE-specific code is needed beyond selecting the interface.

References. Wi-Fi Alliance — Wi-Fi Direct (specification is member-gated); relies on IEEE 802.11 P2P.

Protocol. A vendor action frame carries up to 250 bytes of payload to a unicast peer MAC or the broadcast MAC. The SPORE envelope is that payload; larger objects fountain-fragment to ≤250 bytes.

SPORE bridge mapping. U = [u8;6]; register a receive callback that feeds hub.on_rx and snoops the source MAC; send(None, …) uses the broadcast peer. Runs on the ESP32 core build (esp-idf), not the desktop daemon.

References. ESP-NOW User Guide (Espressif).

Protocol. GATT writes/notifications carry opaque bytes capped at the negotiated ATT MTU. There is no framing, so a stream framer is required: SPORE uses KISS (bridge::kiss_stream), matching the serial bridge, and chunks each frame to the characteristic size. The de-facto profile is the Nordic UART Service (NUS, 6e400001-…) with RX …0002 and TX …0003.

SPORE bridge mapping. U is the connected device; on disconnect call Neighbors::forget. Discovery is the platform scan/pair flow. See web/transports/webbluetooth.mjs and kiss.mjs for a complete, byte-compatible reference.

Security. BLE pairing (LE Secure Connections) encrypts the link; SPORE's signature holds regardless of pairing mode.

References. Bluetooth Core Specification (GATT/ATT, Vol 3); Nordic UART Service (Nordic Semiconductor docs).

Protocol. SPORE would ride a vendor model message; the stack handles segmentation/reassembly and relay. U = u16; group address = broadcast.

Security. BLE Mesh has its own network/app keys; SPORE's signature is independent.

References. Bluetooth Mesh Protocol Specification.

Protocol. An NDEF message wraps the envelope in a MIME record (application/x-spore). encodeNdef emits the short-record form whenever the payload fits in a byte — the common case for a fragment — and the 4-byte length field beyond that. Larger objects span multiple taps as fountain fragments, and any ~K of N suffice, so a mistimed tap costs a repeat rather than a restart.

Why the browser and not the daemon. A Rust NFC bridge needs libnfc or PC/SC — a C library. That is the one thing the bridge selection rule excludes, and it is the same rule that kept TLS out (see the TLS section). Web NFC needs no dependency at all, and the realistic gesture — two phones touching — is a phone scenario anyway. There is therefore no Rust twin and nothing for web/codec-test.mjs to check parity against; it tests the codec on its own.

Verification, honestly. The codec is pure and covered by twelve checks in web/codec-test.mjs: short and long records round-trip, and a URL tag, a foreign MIME type, a length that runs past the buffer, and every truncation of a valid message are all refused. The NDEFReader plumbing is not tested — Web NFC is Chrome on Android over HTTPS with a user gesture, and there is no headless way to present a tag. Same split as the ICMP bridge: the framing is tested, the hardware loop is the operator's.

Bounded like every other bridge. A tag is written by whoever held it last, so the decoder checks every declared length against what actually arrived rather than believing it. Outbound envelopes queue until a tag enters the field, and that queue is capped (MAX_QUEUED, oldest dropped) — a phone in a pocket must not accumulate a backlog because nothing has been tapped for an hour.

Security. Proximity is the channel; the envelope signature authenticates. The range is the honest guarantee here — a few centimetres is a real access-control property in a way no radio bridge can claim.

References. ISO/IEC 14443; NFC Forum NDEF; W3C Web NFC.

SPORE bridge mapping. Conceptually identical to the audio modem: modulate the envelope to a symbol stream, demodulate on the far side; U = () (broadcast, directional). A software approach can reuse the FSK framing over an LED driver and a camera/photodiode.

References. IEEE 802.15.7.

SPORE bridge mapping. Treat IrCOMM as a byte stream: KISS-frame envelopes as on Web Serial. U = the discovered device address.

References. IrDA specifications (archived); IrLAP/IrLMP/IrCOMM.

Protocol. 802.15.4 MAC (127-byte PHY) → NWK → APS. SPORE rides a manufacturer- specific cluster; APS fragmentation carries envelopes over the tiny MTU (the fountain fragmenter also helps). U = u64; broadcast = 0xFFFF network address.

References. IEEE 802.15.4; Zigbee/Matter specs (CSA).

SPORE bridge mapping. Talk to the controller over serial; send/receive raw application payloads. The ~54-byte MTU makes fountain fragmentation essential. U = u8 node id; broadcast node = 0xFF.

References. Z-Wave specifications (Silicon Labs / Z-Wave Alliance); ITU-T G.9959 (PHY/MAC).

Protocol. Envelopes ride the application payload of confirmed/unconfirmed uplinks/downlinks. Because a network server sits in the path, the bridge is really a store/queue client of that server (e.g. The Things Network MQTT). Respect the region's duty cycle; keep envelopes tiny and rare.

References. LoRaWAN L2 1.0.4 / 1.1 (LoRa Alliance).

SPORE bridge mapping. U = (): every modem in range hears every frame, so resolve is trivial and the envelope dest filters. Set MTU from the modem's configured SF/BW/CR. Instead of driving the SX127x directly, the practical path is an RNode in host mode — already implemented as web/transports/reticulum.mjs.

Security. Raw LoRa is unencrypted broadcast; the envelope signature is the trust anchor.

References. Semtech SX1276 datasheet; LoRa PHY is proprietary to Semtech.

Protocol wire format. SPORE rides an AX.25 UI (unnumbered information) frame, and the host↔TNC link uses KISS:

AX.25 UI frame:
  Flag(0x7E) · Dest addr(7) · Src addr(7) [· digipeaters…] · Control(0x03=UI) ·
  PID(0xF0=no L3) · Info(= SPORE envelope) · FCS(2) · Flag(0x7E)

KISS host↔TNC frame (bytes on the serial line):
  FEND(0xC0) · cmd(0x00=data, port 0) · …payload, 0xC0/0xDB escaped… · FEND(0xC0)

bridge::kiss_stream::KissStream and web/transports/kiss.mjs implement the KISS layer byte-for-byte (src/kiss.rs is the source of truth).

SPORE bridge mapping. The TNC does the AX.25 framing/FCS; the bridge speaks KISS to the TNC over serial/TCP. U = () for a broadcast beacon channel, or the sender's call-ssid string if you parse the AX.25 header. UI frames are stateless — fit SPORE's flood directly. Keep paclen ≤256; fountain-fragment above it.

Security. FCC/most regulators forbid encryption on amateur bands — so send signed but unencrypted envelopes here (SPORE's SIGNED flag without ENCRYPTED). The signature still authenticates; no message secrecy on-air by law.

References. AX.25 v2.2 (TAPR); KISS TNC protocol.

Protocol. An APRS message is :ADDRESSEE :text{msgNo. Base-91/base-64 the envelope into the text (tiny — expect heavy fragmentation), or attach as a chunked payload. Rides the AX.25 KISS path on RF, or a TCP socket to APRS-IS.

Security. Same amateur-band no-encryption rule as AX.25 — sign, don't encrypt.

References. APRS Protocol Reference 1.0.1.

Protocol. DMR carries data in confirmed/unconfirmed short-data or packet-data services; a hotspot (MMDVM) exposes it. U = u32 DMR ID. Bandwidth is small — keep envelopes minimal.

Security. Amateur DMR: no encryption (sign only). Commercial DMR may encrypt at the radio layer.

References. ETSI TS 102 361 (DMR Air Interface, parts 1–4).

Protocol. Proprietary — no public on-air wire format. The practical bridge is through the vendor SDK on a paired phone: send/receive app payloads carrying the envelope. U = u32 GID; group messages = broadcast.

References. goTenna developer SDK (vendor documentation; the radio protocol itself is closed).

Wire format (SPORE-defined). A 16-tone FSK modem, 4 bits/symbol, 48 kHz, 1024 samples/symbol:

per frame:  SYNC(6 symbols) · LEN(2 bytes) · PAYLOAD(LEN bytes) · CRC(4 bytes)
  SYNC   = [15,0,15,0,12,3]           (fixed sync word)
  bytes  = high nibble then low nibble, one 4-bit tone each
  tone f = (32 + 4·symbol) · 48000/1024  Hz   (1500 … 4312.5 Hz)
  CRC    = SHA-256(LEN‖PAYLOAD)[0..4]

The Rust and JS implementations are byte-identical: the browser twin's SHA-256 CRC and tone plan were verified against the native modem, and frames roundtrip under noise. So a browser tab and a native spore-audio pipe exchange real envelopes over the air.

Throughput and what it means for files. 16 tones × 4 bits at ~47 symbols/s is about 23 bytes per second, so a single 1336-byte file chunk would occupy the channel for a minute. Hence a bulk budget of zero: a sound link relays messages, announces and manifests at full speed — telling the mesh you exist and what you have, which is what an audio link is for — and declines to haul chunks. Because chunks are content-addressed, whoever wants them asks again and a faster path answers; nothing fails, it just routes around.

SPORE bridge mapping. U = (), broadcast-only; the streaming demodulator scans for the sync word at sub-symbol resolution to tolerate lead-in silence and timing offset. Native I/O is deliberately sound-card-agnostic: bridge::audio::run_pipe reads/writes f32 PCM on stdin/stdout so any backend (sox, ffmpeg, pw-cat) supplies the samples. The browser uses a ScriptProcessor on the mic and an AudioBufferSource to the speakers.

Security. The channel is public (anyone in earshot). Confidentiality, if needed, comes from an encrypted envelope payload; authenticity always from the signature.

References. SPORE-native; see src/bridge/audio.rs and the ggwave project for prior art in data-over-sound.

bridge::icmp is the worked example of a broader idea: any protocol with a field that holds arbitrary bytes is a carrier. SPORE only needs to move bytes, and it assumes every link is hostile, so smuggling those bytes through a protocol never meant for data costs nothing in security — the envelope is still signed and sealed.

The module is split so the honest part is verifiable: the codec (encode_echo / decode_echo, checksum and all) is pure and unit-tested, including the odd-length and rejected-ordinary-ping cases; the runner needs a raw socket, which needs CAP_NET_RAW and Linux, and cannot be exercised in CI — so it is a template whose framing is tested and whose socket call is not. Grant it without root: sudo setcap cap_net_raw+ep ./spore.

One detail the template gets right because it is easy to get wrong: a raw IPPROTO_ICMP socket hands back the IP header, and that header is 20 bytes only when it carries no options. ipv4_payload_offset reads the IHL field instead of assuming 20 — otherwise every packet carrying record-route or timestamp options (exactly what a "diagnostics only" network is prone to adding, which is the kind of network this bridge exists for) would decode from four bytes off and fail the checksum, invisibly. IHL is also a number chosen by whoever sent the packet, so it is range-checked against the datagram rather than trusted as an index.

The same pattern extends to the rest of the family, each differing only in which field carries the bytes, and each a raw-socket (often L2, often root) runner over a tested codec:

• DHCP — a vendor/private option (e.g. 224–254) on the broadcast that every LAN already floods; no association needed.
• ARP — the sparest carrier: a broadcast that crosses no router, with only the frame's minimum-length padding to hide in (~18 bytes), so a fountain fragment at a time.
• DNS — a query name (base32 label) to a resolver you don't control, the classic egress from a filtered network.

These share one caution beyond the usual: they are conspicuous. A covert channel is a transport, not a cloak — traffic analysis sees a host that pings a lot. Use them to get out of somewhere restrictive, not to hide that you are communicating; §9 mix mode is the tool for the latter.

SPORE bridge mapping. Like the audio modem but through a water-coupled transducer at JANUS symbol rates. The ~32-byte MTU means only the smallest envelopes (or fountain fragments of them) fit.

References. NATO STANAG 4748 / JANUS; ANEP-87.

Wire format. armor::wrap renders the envelope to checksummed base32 text (SMS/paper-safe), which is then encoded into one or more QR symbols; a long envelope becomes an animated sequence of fountain fragments the camera reassembles. armor::unwrap validates the checksum and recovers the bytes.

SPORE bridge mapping. U = (), one-way broadcast (screen → camera). No addressing: the reader takes whatever it can decode and hands it to the router, which dedups by content-ID. Pair with the Seed Sheet for the printed, fountain-coded variant.

References. ISO/IEC 18004 (QR Code); SPORE armor module for the text layer.

Protocol. A mobile-originated SBD message carries up to 340 bytes; the envelope (or a fountain fragment) is the payload, delivered through the Iridium gateway to an email/HTTP endpoint — so the far side is effectively a store carrier. Costly per message; use sparingly.

References. Iridium SBD Developers Guide (vendor); modem AT command set per manufacturer.

Protocol wire format (mesh.proto, hand-rolled protobuf). The envelope rides a Data sub-message on portnum 256 (PRIVATE_APP) inside a MeshPacket:

MeshPacket {                       Data (field 4, "decoded") {
  1: from      (varint, u32)         1: portnum  = 256   (varint)
  2: to        (varint, u32)         2: payload  = SPORE envelope (bytes)
  4: decoded   (Data, bytes)       }
  6: id        (fixed32)
  9: hop_limit (varint)
}
Serial pipe adds a stream frame:  0x94 0xC3 <len:u16 BE> <ToRadio|FromRadio proto>
  host→device:  ToRadio  { 1: packet = MeshPacket }
  device→host:  FromRadio{ 2: packet = MeshPacket }
BLE pipe: write ToRadio to the ToRadio characteristic; read FromRadio on a
  FromNum notification. Service 6ba1b218-…; ToRadio f75c76d2-…; FromRadio 2c55e69e-….

The MeshPacket encode/decode is a JS port of bridge::meshtastic, verified byte-identical (a roundtrip in Node reproduces the exact Rust field layout: 0x08 from-varint, 0x22 decoded-len, 0x08 0x80 0x02 portnum=256, then the payload).

SPORE bridge mapping. U = u32; broadcast is node 0xFFFFFFFF. On Wi-Fi-UDP the packet is a bare MeshPacket in a multicast datagram (224.0.0.69:4403), so it uses the datagram driver directly; on serial/BLE it is wrapped in ToRadio/FromRadio and framed as above. The node number is derived from the first four bytes of the SPORE address. MTU 237 forces fountain fragmentation for anything larger. On serial/ BLE the connection is stateful — drop the neighbour on disconnect.

Security. This bridge handles only the unencrypted decoded variant; an encrypted Meshtastic channel puts ciphertext in field 5 (AES-CTR with the channel key), which the bridge would need that key to open — use an unencrypted channel, and rely on SPORE's own signature/encryption inside the payload. Field numbers follow mesh.proto; confirm against the firmware you target.

References. Meshtastic mesh.proto; Meshtastic developer docs; serial stream API.

Two models.

• RNS payload (implemented, via companion). SPORE rides Reticulum as data on a shared PLAIN destination spore.mesh — a broadcast bus every SPORE-over-RNS node listens on (a PLAIN destination's hash derives only from its name+aspects, so everyone computes the same one and hears every packet). RNS provides transport, path-finding, and every interface it is configured with (LoRa, TCP, I2P, packet radio). Because Reticulum's canonical implementation is the Python rns library and its packet/crypto format is defined by that code, the bridge is split: the portable half (bridge::reticulum::run_pipe) exchanges KISS-framed envelopes on stdin/stdout exactly like the audio modem, and a small companion (tools/reticulum_companion.py) does the real RNS work with the library — so nothing security-critical is re-implemented. The node's MTU is clamped to a single RNS packet (383 B); larger objects fountain- fragment. U is effectively () (the bus is broadcast; the envelope dest filters). Verified off-network at the framing layer (the companion's KISS matches src/kiss.rs byte-for-byte); the live RNS path needs a Reticulum network to exercise, hence 🧪.

• RNode host mode (implemented). An RNode is a LoRa modem speaking a KISS host protocol. Configure the radio, then every SPORE envelope is a KISS DATA frame:

  KISS host frame:  0xC0 <cmd> …payload (0xC0/0xDB escaped)… 0xC0
    cmd 0x00 = DATA         payload = SPORE envelope
    cmd 0x01 = FREQUENCY    (u32 BE, Hz)     cmd 0x04 = SPREADING FACTOR (u8)
    cmd 0x02 = BANDWIDTH    (u32 BE, Hz)     cmd 0x05 = CODING RATE      (u8)
    cmd 0x03 = TX POWER     (u8, dBm)        cmd 0x06 = RADIO STATE      (u8, 1=on)
  

  A dedicated de-framer keeps the command byte and surfaces only DATA (0x00) frames as inbound envelopes; status frames are ignored. Over BLE the same frames ride the Nordic UART Service.

SPORE bridge mapping. For RNode, U = () (broadcast — every modem in range hears the DATA frame; the envelope dest filters). The radio must be brought up first (configure() sends FREQUENCY/BANDWIDTH/SF/CR/TXPOWER then RADIO_STATE=1) — so the bridge exposes those as parameters; match your region and the other radios. The connection is stateful (serial/BLE); drop the neighbour on disconnect. MTU tracks the LoRa PHY (SF/BW dependent).

Security. RNS provides its own strong end-to-end encryption on the payload path; the RNode host path is a raw radio pipe with no medium encryption, so SPORE's signature (and optional encrypted payload) is the trust anchor. Either way the envelope is self-authenticating.

References. Reticulum Manual & protocol spec; RNS reference implementation; RNode firmware (host/KISS command set).

SPORE bridge mapping. BATMAN-adv presents a normal L2 interface, so directed or limited broadcast over UDP floods the whole mesh. No SPORE-specific code — select the bat0 interface. U is the batman node MAC as seen by UDP.

References. batman-adv (Open Mesh); BATMAN V protocol.

SPORE bridge mapping. Send UDP to peers' overlay IPv6 addresses (multicast/ link-local for discovery). The crypto-address means U is already key-bound at the overlay layer, but SPORE still authenticates with its own signature. Keep to the 1280-byte IPv6 minimum MTU.

References. Yggdrasil; cjdns / Hyperboria.

SPORE bridge mapping. UDP to Thread mesh-local or link-local addresses; the border router bridges to wider IP if present. 802.15.4's tiny frames mean heavy 6LoWPAN fragmentation beneath — keep envelopes small.

References. Thread Specification (Thread Group) (membership-gated); OpenThread.

SPORE bridge mapping. Treat it as a byte stream: run the WebSocket or a TCP bridge, but dial through Tor's SOCKS5 port and publish an onion service for inbound. U = the peer's .onion. Framing is KISS or length-prefix as for any stream.

Security. Tor provides transport anonymity and encryption; SPORE's signature is still required for authenticity.

References. Tor Rendezvous Spec v3; Tor SOCKS extensions.

SPORE bridge mapping. Open a SAM v3 DATAGRAM session; send/recv map directly to I2P repliable datagrams, and the sender's b32 destination is U. Fountain-fragment above ~1200 bytes.

References. I2P SAM v3; I2P datagrams.

SPORE bridge mapping. An iroh Endpoint is bound once; the dialer opens a bi stream to the peer's id, the listener accepts one, and the same stream_link KISS framing and best-effort store-and-forward semantics apply as on TCP. iroh is async (tokio); the seam is a private multi-thread runtime whose stream halves are wrapped as blocking Read/Write, so the shared pump drives them without knowing they are async. A dropped link reconnects with backoff; the outbound queue drains when it returns.

Trust — read before pointing this at the internet.

• EndpointId is not a SPORE address. iroh authenticates the transport peer; SPORE's own seal/sign authenticates the message. Keep the layers separate — do not derive one identity from the other.
• Relays are a phone-home. In the default (non–direct-only) mode the endpoint uses the n0 relay + discovery infrastructure to hole-punch and to fall back to relaying. A relay sees ciphertext only (envelopes are already sealed) but still sees your IP, your peer's, and traffic timing. If that metadata matters, use Tor/I2P instead, run your own relay, or use the direct-only id@addr form on a trusted LAN.
• Not a substitute for the mesh. iroh is for when both ends can reach the network. Offline peers still use store-and-forward; iroh just injects envelopes into the same hub once a path exists.

References. iroh; iroh discovery & relays.

SPORE bridge mapping. Use Veilid private routes for send/recv; the route or node id is U. Veilid encrypts and anonymises the path; SPORE authenticates.

References. Veilid documentation; Veilid source.

SPORE bridge mapping. Map a SPORE topic to a gossipsub topic and publish envelopes as messages; inbound messages feed the router. libp2p handles peer discovery (mDNS/DHT), transport (TCP/QUIC/WebRTC), and multiplexing. U = PeerId. Because gossipsub already dedups and floods, this is one of the cleaner overlay fits.

References. libp2p specs; gossipsub v1.1; rust-libp2p.

Protocol wire format (RFC 6455). After the HTTP Upgrade handshake, each message is a framed record: FIN+opcode(1) · MASK+len(1) · [ext len 2/8] · [mask key 4] · payload. SPORE uses one binary message (opcode 0x2) per envelope — no additional framing, since WebSocket messages are already delimited.

SPORE bridge mapping. U is the socket; outbound queues until open, inbound messages feed hub._rx. A relay is just a server that rebroadcasts each message to the other sockets; a direct peer is a single socket. On close, forget the neighbour. Tested end-to-end in web/test.mjs (loopback) and web/ws-test.mjs (a real ws relay, A→relay→B).

Security. wss:// gives TLS transport security; SPORE's signature authenticates the sender independent of the relay, so a malicious relay can drop or reorder but not forge.

References. RFC 6455 (WebSocket); WHATWG WebSocket API.

SPORE bridge mapping. Use the datagram API for a true datagram bridge (envelope per datagram) or a bidirectional stream with KISS framing. Needs an HTTP/3 server endpoint. U is the session.

Note on references. WebTransport is not a numbered RFC yet — it is a W3C Working Draft plus IETF drafts, transported over HTTP/3. (Do not confuse it with RFC 9297, Proxying UDP in HTTP, which is a different mechanism.)

References. W3C WebTransport; draft-ietf-webtrans-http3; RFC 9000 (QUIC).

Protocol wire format (RFC 8831). A data channel is SCTP over DTLS over ICE/ UDP. SPORE sends one binary message per envelope on an unordered, unreliable channel ({ordered:false}) — matching flood semantics — capped at a safe SCTP message size (~16 K; fountain-fragment above it). Signaling uses SDP offer/answer (JSEP), which SPORE packs into a base64 blob for manual exchange; ICE is gathered non-trickle so a single blob carries every candidate.

SPORE bridge mapping. U is the peer/channel; queue sends until open, feed inbound to the hub, forget on close/failure. STUN (stun.l.google.com:19302) is used for NAT traversal; no signaling server is required. The standalone node also drives a WebTorrent swarm which negotiates WebRTC channels automatically via trackers.

Security. DTLS-SRTP encrypts the channel; the DTLS fingerprint is exchanged in the SDP. SPORE's signature authenticates the application payload regardless.

Browser only, deliberately — there is no daemon WebRTC bridge. This is the most-asked-for missing bridge, so the answer is recorded here rather than rediscovered. A native Rust WebRTC stack means ICE, DTLS and SCTP; none of those are small, and the lightest credible option (a sans-IO crate such as str0m) is still the largest dependency this project would have taken. That is the same budget that keeps TLS out of the tree and put NFC in the browser, and it is the rule that selected every bridge on this page. Spending it here was considered and declined.

What you lose is NAT traversal between two daemons with no reachable address. What you have instead: Tor and I2P both traverse NAT and do it with better metadata properties, and either is a torrc/SAM config away.

The path to a native half is QUIC, not WebRTC. The one place a native WebRTC bridge would matter is browser ↔ native node — a browser has WebRTC but a daemon does not, so the two cannot speak directly today. That gap is better closed with WebTransport (QUIC datagrams in the browser) on the browser side and the iroh QUIC path already merged in the core (src/direct/iroh.rs, bridge-iroh) on the native side: the browser's QUIC becomes one more Direct medium rather than a special case that pulls in an ICE/DTLS/SCTP stack. Native WebRTC is therefore declined outright; a native WebTransport/QUIC adapter is the planned answer to the browser↔native conformance gap (see Roadmap M2). Until that adapter exists, the SPEC page-2 "native nodes run ice-lite" line reads as more than the tree does, and says so.

The browser and the Android WebView keep WebRTC because there it costs nothing — the platform ships the stack. Note that the Android app does not currently load this transport (its WebView is given websocket, nostr and webtorrent), though WebRTC demonstrably works there, since webtorrent negotiates data channels itself. What is missing on Android is not the runtime but signaling: this transport takes an already-open RTCDataChannel, and there is no human present to paste an offer into a headless WebView.

References. RFC 8831 (data channels); RFC 8832 (DCEP); RFC 8829 (JSEP); W3C WebRTC.

Protocol. The bittorrent-tracker WebSocket protocol: announce with a batch of WebRTC offers under a 20-byte infohash + peer id; the tracker relays a remote peer's offer/answer between browsers; on data-channel open the peers exchange SPORE envelopes over WebRTC directly. The infohash is SHA-256(name)[..20] so any two nodes naming the same swarm meet; it will not collide with real torrents.

SPORE bridge mapping. Each open data channel is one neighbour; send broadcasts an envelope to all channels, inbound feeds the hub. Peer discovery touches the trackers, but traffic is peer-to-peer, so the swarm survives a tracker going down. Default trackers: tracker.openwebtorrent.com, tracker.webtorrent.dev.

Security. WebRTC (DTLS) encrypts each link; the tracker only introduces peers. SPORE's signature authenticates.

References. WebTorrent; bittorrent-tracker (ws protocol); BEP 3 (BitTorrent); RFC 8831.

Wire format. KISS (0xC0 0x00 …escaped… 0xC0), byte-for-byte with src/kiss.rs, so a browser tab and a physical board interoperate. See AX.25 / KISS for the frame detail. (Meshtastic and RNode use their own serial framings — see Meshtastic and Reticulum.)

SPORE bridge mapping. A stateful stream: a KissDeframer reassembles frames across reads; U is the open port; closing the port forgets the neighbour. The user gesture (navigator.serial.requestPort()) is required to open, so it cannot auto-reconnect silently.

References. W3C Web Serial API; KISS.

Wire format. KISS over the Nordic UART Service (6e400001-…, RX …0002 write, TX …0003 notify); frames are chunked to ≤20 bytes and reassembled by the KissDeframer. See BLE GATT for the GATT detail.

SPORE bridge mapping. U is the connected device; notifications deliver inbound frames, writes carry outbound (serialised, chunked). Requires a user gesture to pair; disconnect forgets the neighbour.

References. W3C Web Bluetooth; Bluetooth GATT.

Wire format. One envelope per file, named by its content-ID (<id>.spore); the file body is the raw envelope bytes. No framing — the filesystem delimits.

SPORE bridge mapping. Poll the directory for new files → feed the router; write outbound forwards as new files. There is no U and no MTU: a whole envelope is one file. Deduplication is free (content-ID = filename), so re-syncing the same folder never reprocesses. Syncthing/rsync/Dropbox/a USB stick are all just "the directory replicator".

Security. Filesystem permissions bound access; the envelope signature authenticates. An encrypted payload keeps contents private on a shared drive.

References. SPORE-native (bridge::store); Syncthing as one replicator.

Protocol. Plain HTTP: GET the bag to list/fetch envelopes, POST/PUT to deposit. Each envelope is an opaque blob keyed by content-ID, so a static file server (one file per id) or a tiny dynamic endpoint both work. Pull-based: a node fetches ids it lacks (mirroring SPORE's INV/WANT sync).

SPORE bridge mapping. store form — poll the bag, diff against the local store, fetch missing, deposit new. No addressing beyond the URL. Combine with the content-ID dedup so repeated pulls are cheap.

Security. https:// for transport; the signature authenticates each envelope. A public bag is a public channel — encrypt payloads that need privacy.

References. RFC 9110 (HTTP semantics); SPORE-native (bridge::bag).

SPORE bridge mapping. Identical to the HTTP bag, using copyparty's upload/list endpoints (or WebDAV). Envelopes are files in the share.

References. copyparty.

Wire format. armor::wrap emits the envelope as base32 with a short checksum and human-readable delimiters; armor::unwrap validates and recovers the bytes. Long envelopes split into numbered fountain fragments so several SMS / lines / cards reassemble. Chosen to be case- and whitespace-tolerant for voice/paper transcription.

SPORE bridge mapping. No addressing; the reader hands whatever it decodes to the router (content-ID dedups). This is the store pattern degenerated to a single text blob.

Security. The channel is whatever carried the text (often public); the checksum guards transcription errors, the signature guards authenticity.

References. SPORE-native (armor module); base32 RFC 4648.

Protocol (NIP-01). A SPORE envelope is base64'd into the content of a kind-30078 (parameterised replaceable app-data) event tagged d: spore-v1; ["REQ", …, {kinds:[30078], "#d":["spore-v1"]}] subscribes, ["EVENT", …] publishes. Any relay that accepts kind-30078 works.

SPORE bridge mapping. store form over a WebSocket to the relay. Inbound needs no key (just subscribe and unwrap the base64); outbound requires a Nostr signer (NIP-07 window.nostr, or a local key) to sign the wrapping event — the envelope's own SPORE signature is separate and inside. U is the relay.

Security. The wrapping Nostr event is signed by the poster's Nostr key; the SPORE envelope inside is signed by the SPORE identity. A public relay is a public channel.

References. NIP-01; NIP-78 (app data, kind 30078); NIP-07 (signer).

Protocol. Each envelope becomes a message with spore-v1 typed content appended to the local feed; SSB's gossip replicates the log to peers, who extract the envelope. U is the feed id.

SPORE bridge mapping. store form: append outbound envelopes to the log, scan inbound messages of type spore-v1 for envelopes to feed the router. The folder-log runner reads/writes an on-disk log so it works without a full SSB stack.

Security. SSB messages are signed and hash-chained by the feed identity; the SPORE envelope carries its own signature independently.

References. SSB Protocol Guide; SSB specs.

SPORE bridge mapping. Send a custom event type (e.g. m.spore) with the base64 envelope as content via PUT /rooms/{id}/send/...; sync to receive. U is the room id. The homeserver stores and federates.

References. Matrix Client-Server API; Matrix specification.

SPORE bridge mapping. Base64 the envelope into a <message> body or a custom child element, or publish to a PubSub node for one-to-many. U is the JID. The XMPP server stores-and-forwards to offline contacts (MAM/offline storage).

References. RFC 6120 (XMPP Core); RFC 6121 (IM); XEP-0060 PubSub.

SPORE bridge mapping. Attach the envelope (or base64 it in the body) to a mail with a marker header/subject; poll IMAP for incoming, send via SMTP. U is the address. Mail servers provide global store-and-forward and offline delivery.

References. DeltaChat; Autocrypt; RFC 5321 SMTP / RFC 3501 IMAP.

SPORE bridge mapping. Store envelopes to a recipient's swarm via the storage server API; poll to receive. U is the session id (a public key). Onion routing anonymises; SPORE authenticates.

References. Session protocol / whitepaper; Oxen docs.

SPORE bridge mapping. Ride Briar's contact sync as a client (or a custom transport plugin), moving envelopes between mutually-added contacts over whichever link (Tor/Wi-Fi/BLE) is available. U is the contact.

References. Briar; Bramble protocols.

SPORE bridge mapping. Send envelopes as custom lossless packets to connected friends; U is the ToxID. The DHT handles discovery and NAT traversal.

References. toxcore; Tox spec (archived).

Protocol. A bundle carries a primary block (source/destination EID, lifetime, timestamps) plus payload and extension blocks (CBOR-encoded). SPORE puts the envelope in the payload block; the DTN agent handles custody transfer and forwarding across intermittent links. U is the destination EID.

SPORE bridge mapping. store form over a bundle agent's API: submit envelopes as bundle payloads, register to receive. SPORE's own expiry maps onto bundle lifetime; its content-ID dedups replays. This is arguably the most natural fit in the whole matrix — two store-carry-forward systems stacked.

References. RFC 9171 (Bundle Protocol v7); RFC 9172 (BPSec); RFC 4838 (DTN architecture).

SPORE writes outbound envelopes into a tx/ directory and consumes inbound ones from rx/ (bridge::spool); NNCP is what carries tx to the peer and fills rx. That split is exactly NNCP's own model, so the wiring is NNCP config, not code:

# outbound: package the tx directory to a node, on a schedule or when it fills
nncp-file ./spool/tx/ node:spore-in
# inbound: nncp-toss unpacks received packets into the peer's rx directory
spore "spool: ./spool/tx -> ./spool/rx"

nncp-xfer (USB), nncp-daemon/nncp-caller (online) or nncp-file over any medium then move the packets. NNCP adds its own strong crypto on top of SPORE's, and the spool bridge validates every inbound file against its content id, so a tampered packet is dropped rather than trusted.

References. NNCP.

The same bridge::spool as NNCP, moved by UUCP instead: uucp the tx/ files to the peer's rx/, over serial, TCP or sneakernet.

# outbound: copy tx to the peer (a cron, or uucico on a schedule)
uucp ./spool/tx/* peer!~/spore-in/
spore "spool: ./spool/tx -> ./spool/rx"

U is the UUCP host name. The spool bridge is medium-blind — it never learns whether UUCP moved the files over a modem or a fibre, which is the point.

References. Taylor UUCP.

SPORE bridge mapping. Publish envelopes as Rhizome bundles (manifest + payload); the mesh carries them device-to-device. U is the SID. Content-addressing lines up with SPORE's own.

References. Serval Project — Rhizome.

SPORE bridge mapping. Append each envelope as a Hypercore block; replicate over Hyperswarm to subscribers who read the log. U is the core's public key. The log's integrity is built-in; SPORE adds sender authenticity.

References. Hypercore (Holepunch); Hyperswarm.

SPORE bridge mapping. Write envelopes as documents in a share; peers reconcile the share on contact and extract them. U is the share/namespace. Willow's range- based set reconciliation is efficient for large stores.

References. Willow Protocol; Earthstar.

Building a new bridge? Work down this list:

1. Pick the form. Frames → dgram; byte stream → stream; shared container → store. (See Driver form comparison.)
2. Pick U. How does the medium name a peer? Use () if it is broadcast-only.
3. Set the MTU. The per-frame payload budget; the fountain fragmenter handles the rest. (See MTU reference.)
4. Write recv/send — the only platform-specific code. dgram: implement driver::DatagramTransport and hand it to driver::run_datagram. stream: add framing (reuse kiss_stream). store: poll + write items.
5. Handle state. Stateful media call Neighbors::forget on disconnect; stateless media rely on expire.
6. Never re-implement routing, dedup, fragmentation, signing, or encryption — they live in the shared node and run identically on every medium.
7. Respect medium law. On amateur bands, send signed-but-unencrypted envelopes.
8. Document it here. Add an index row and a deep-dive section to this file, with the correct status emoji and a real specification reference — the docs-sync guard (scripts/check_docs_sync.py) checks that every implemented bridge appears here and that every file/module this doc cites exists.

Status: 🟢 implemented (browser side)

WebTransport is a browser API for sending and receiving data over HTTP/3. SPORE uses it to connect browsers to native nodes via a proxy that terminates TLS and forwards UDP.

Bridge mapping

• Form: Datagram (dgram)
• Underlay address (U): Url (the WebTransport URL)
• MTU: 1400 bytes (same as UDP)

Implementation

The browser-side implementation is in web/transports/webtransport.mjs. It:

1. Opens a WebTransport session to the proxy URL
2. Uses the datagram API for bidirectional communication
3. Bridges datagrams to the SPORE hub interface

The native side requires a proxy that:

• Terminates TLS (Caddy/Nginx)
• Forwards WebTransport datagrams to UDP port 7439
• Runs on port 443 (browser requirement)

Browser  --WebTransport (HTTPS)-->  Proxy  --plaintext UDP-->  SPORE Daemon
Browser  <--WebTransport datagrams--  Proxy  <--UDP responses--  SPORE Daemon

See Proxy setup for sample configurations.