Lattice Lattice

Bearers — every radio, in parallel.

Roughly 6 minutes.

Lattice doesn't pick one radio and hope. It races every viable radio at once and lets the receiver throw away the duplicates. This page covers how that works, what the five bearers are, and a useful thing that falls out for free when one user happens to own two kinds of LoRa hardware.

1. The five bearers.

A bearer is one way to put a Lattice packet on the wire. Each one is a thin driver that says either "I accepted this packet" or "I can't reach that peer right now." The bearer has no idea what's in the packet. That's already encrypted by the time it gets here.

BearerRangeNeeds internet?Status
Bluetooth Low Energy~30 m line of sightNoProven core, both platforms
Wi-Fi Aware~200 mNoBuilt in where the OS supports it
Meshtastic LoRa (BLE-tethered)~5 km, much further with relaysNoBuilt in, both platforms; hardware hardening ongoing
USB LoRa dongle~5 km, more line-of-sightNoDriver built in on Android; bring-up ongoing. iPhone goes via a BLE-tethered Meshtastic device instead
Tor (.onion)Anywhere with internetYesWorks end-to-end today

Bluetooth is the workhorse. It's in every phone, the OS lets us use it without tricks, and most messages only travel a few metres or a few hundred. Wi-Fi Aware is for the festival case: tens of metres turning into hundreds, with far more bandwidth. The two LoRa bearers reach kilometres. And Tor is for when two phones sit in different cities and the cell network is working. Lattice ducks into the internet through a hidden service, comes out the far end, and looks like any other Lattice traffic to the receiver.

2. The race.

When you send a message to Bob, the router asks every bearer "can you reach Bob?" and fires the message down every bearer that says yes, all at the same time. There's no fall-back chain and no priority order. Every viable bearer gets its copy at once.

              Alice's phone
                    │
       ┌────────┬───┴───┬────────┐
       ▼        ▼       ▼        ▼
      BLE   Wi-Fi   LoRa       Tor
       │     Aware    │         │
       └────────┴───┬─┴─────────┘
                    ▼
              Bob's phone
              (dedupe by bundle id, show once)

Bob's phone might receive the same message four times: once over BLE, once over LoRa, once over Tor, and a hop later from a relay that picked it up off Wi-Fi Aware. He sees it once. The thing that makes that work is the bundle id, a deterministic SHA-256 of (peer, direction, sent_at, body) that comes out identical on both sides. The vault has a UNIQUE column on it, so the second, third and fourth copies hit INSERT OR IGNORE and quietly drop.

That sounds wasteful, and it would be if any of the bearers cost real money or real airtime. Mostly they don't. BLE and Wi-Fi Aware are local-only. LoRa airtime is regulated (1% duty cycle in the EU, unlimited LBT in the US), but Lattice accounts for it on the dongle side. Tor is a few hundred milliseconds of mobile data per message. Sending duplicates and dropping them costs far less than picking the wrong bearer and waiting.

3. Sync vs. async bearers.

Two of the bearers can answer "did you accept this packet?" within about 100 ms: BLE and the LoRa pair. Tor can't, because a fresh circuit takes seconds to build. The router treats the two cases differently.

It's the difference between "I posted the letter" and "they got the letter." For BLE and LoRa the post and the receipt land close enough together that we collapse them into one. For Tor we wait for the real receipt.

4. Delivery blooms.

Every Lattice node periodically broadcasts a small Bloom filter: "here are the bundle ids I've decrypted lately." 320 bytes of bits, sized for 256 messages at under 1% false positive rate, fits in a single BLE fragment. This rides through the gossip layer the same way messages do.

When Alice sees one of Bob's bloom broadcasts and it carries the bundle id of a message she sent him, she retires the outbox row. That's what makes Tor delivery confirmable. A Tor-delivered message produces no point-to-point ACK back to Alice, but Bob's bloom rolls past her eventually anyway, the bundle id is in it, and her tick turns green.

5. Custody chain.

Every relay that forwards a packet appends its 12-character short id to the packet's custody chain. The chain travels in plaintext on the wire. Relays' identities are already broadcast over BLE to anyone in range, so encrypting it would buy no privacy. Three things use it.

6. Carol bridges Meshtastic and Meshcore for free.

There's a side-effect of multi-bearer routing worth pulling out on its own. Two LoRa mesh ecosystems, Meshtastic and Meshcore, are radio-incompatible at the firmware layer. Different airtime conventions, different framing, different headers. There's no protocol-level handshake that makes a Meshtastic radio talk to a Meshcore radio directly.

Lattice doesn't try to bridge them at the radio. That's not possible, and pretending it were would be a lie. Here's what it does instead.

   Alice (Meshtastic only)              Bob (Meshcore only)
        │                                       ▲
        │                                       │
       LoRa-Meshtastic                  LoRa-Meshcore
        │                                       │
        ▼                                       │
   ┌─────────────────────────────────────────────┐
   │ Carol's phone                               │
   │ ┌───────────────────┐   ┌─────────────────┐ │
   │ │ Meshtastic dongle │   │ Meshcore dongle │ │
   │ └────────┬──────────┘   └────────┬────────┘ │
   │          └────────┬──────────────┘          │
   │                   ▼                         │
   │           Lattice routing                   │
   │  (same packet rides both bearers)           │
   └─────────────────────────────────────────────┘

Carol has both kinds of LoRa hardware paired to her phone. She didn't set out to bridge the two meshes. She just happens to own both pieces of hardware. When a Lattice packet for Bob arrives over the Meshtastic LoRa bearer, the router sees that Bob is reachable over the Meshcore bearer too and forwards there. The packet rides as Lattice payload on top of either firmware. The two LoRa firmwares never talk to each other. Carol's phone is the bridge, and the bridging is free.

It's the same reason a single Lattice user with one LoRa dongle and a Bluetooth radio extends the BLE mesh by kilometres with no "bridge mode" setting anywhere. Multi-bearer routing turns every dual-bearer device into a bridge by accident.

7. What this is not.

Going deeper.