Lattice Lattice

WP-05 — What Lattice Doesn't Do.

Roughly 8 minutes to read.

An explicit list of limits. Every claim Lattice makes is bounded by something. We'd rather you read these limits before installing than discover them at the wrong moment.

Authors: Lattice project · Version: 1.0 · License: CC-BY-4.0 · Status: draft, will be signed and frozen at v1.0 launch.

Why this paper exists.

Most messaging projects publish marketing material describing what they do. Lattice publishes this paper describing what it doesn't. It is the most important document for anyone deciding whether to trust the app with anything that matters.

If a critic ever says "but Lattice doesn't do X" — yes, we know. It's documented here. We chose the trade-off deliberately, and the reasoning for the choice is in the section below.

1. Lattice doesn't work everywhere.

It is density-dependent and range-limited.

If you are the only Lattice user for ten kilometres, the mesh has nothing to mesh with. Bluetooth Low Energy — the most reliable transport — has a real-world range of about 30 metres line-of-sight, sometimes more in open air, less inside buildings. Wi-Fi Aware, where the hardware supports it, does roughly 200 metres in good conditions. The mesh extends those short hops by stringing them together, so the more nearby Lattice users, the further your message can travel. A city block with two or three users gives you that block. A festival with thousands of users gives you the whole festival.

   Bluetooth LE 5 (typical):
   ──────────────────────────
                    ┌── 30 m ──┐
        📱 ───────── │  range  │ ───────── ✗ out of range
                    └─────────┘

   Wi-Fi Aware (NAN):
   ──────────────────
                    ┌─── 200 m ───┐
        📱 ───────── │   range    │ ───────── ✗ out of range
                    └────────────┘

   Mesh hop chain (Lattice):
   ─────────────────────────
        📱 ── 25 m ── 📱 ── 25 m ── 📱 ── 25 m ── 📱
                                                   = 100 m through hops
                                                   IF nodes exist between

Some neighbourhoods will have density. Some won't. There is no software-engineering trick that fixes the absence of nearby phones — nothing for the mesh to use. The defence is adoption.

2. Lattice doesn't reach across cities without help.

Two phones in different cities cannot reach each other through Lattice's mesh alone. The chain of intermediate phones doesn't exist. Three real options:

Beyond that, the situation is bound by physics. A small radio cannot reach a thousand kilometres without infrastructure. We are honest about this on the website, in the app, and here.

3. Lattice doesn't deliver background notifications reliably on iOS.

This is Apple's platform constraint, not ours.

iOS limits what a background app can do. A messenger like WhatsApp gets push notifications via Apple's APNs (Apple Push Notification service) — Apple's servers wake the phone, deliver the notification, and the app can run briefly. Lattice has no server, so it has nothing to push. It must scan for nearby Lattice users itself. iOS will allow some background scanning (BLE state preservation, "background app refresh") but throttles it aggressively to save battery.

Realistic reliability bands, measured against a scripted scenario of one message every 5 minutes for 8 hours:

   Foreground (user has app open):                  ~100% reliability
   Recently backgrounded (last 30 min):             ~80–90% reliability
   Long-locked (overnight, 8h+):                    ~40–60% reliability
   Force-quit by user:                              ~0% reliability

   Android equivalent (foreground service):
   ─────────────────────────────────────────────────────────────
   Foreground:                                       ~100%
   Backgrounded with foreground service:             ~98%
   Force-quit + battery optimisation aggressive:     ~30–60%
                                                     (Samsung / Xiaomi)

We document this in the FAQ and in the onboarding. We do not pretend Lattice on iOS will reliably ping you overnight. If reliable background notification is essential, Android is currently more capable.

4. Lattice doesn't protect against a rooted or jailbroken device.

If the operating system is compromised, the operating system can read whatever the user can read. Decryption keys are in the OS keystore; messages are decrypted in app memory; the screen renders plaintext. Any of those points yields the conversation to a sufficiently-privileged attacker on the device.

Lattice's defences end at the application boundary. The Secure Enclave / StrongBox keep the seed key safe even from a rooted OS, but that only protects future sessions if the keys can be re-derived; it does not protect present sessions whose plaintext is in app memory.

This is a fundamental limit of every messenger. Signal, WhatsApp, iMessage, Telegram all share it. We document it because pretending otherwise damages trust.

5. Lattice doesn't protect against a global passive observer doing traffic confirmation.

An adversary with sufficient observation points — for example, a national-level traffic-tap programme — can correlate "Alice transmitted on the radio at 21:04, Bob's phone received something at 21:04" and infer the relationship even without reading content.

Cover traffic and onion wrapping make this harder; they don't make it impossible. Tor faces the same problem and acknowledges it openly. The defence is not running in a small anonymity set, which is exactly what Lattice is in the early days. As the network grows, the anonymity set grows with it.

If you face this threat model — meaning a state-level adversary with widespread radio observation infrastructure — Lattice raises the bar but does not eliminate the risk. Honest answer: in such a scenario, prefer a meet-in-person conversation.

6. Lattice doesn't help if you lose your seed phrase.

By design.

The Lattice identity is a wallet-style key derivation: a 12-word BIP-39 phrase generated on your phone the first time you open the app. The phrase is the seed; the Bullet ID and all your derived keys come from it deterministically. If you write the phrase down and keep it safe, you can restore your identity on a new phone after losing your phone. If you don't, you can't.

There is intentionally no recovery path that doesn't go through your seed phrase. A recovery path is a thing an attacker can attack — phish you, social-engineer the recovery operator, breach a recovery server. We chose the wallet model precisely so there is no such surface to attack.

The trade-off is real. Lose your phone and the phrase, and your Lattice identity is gone. Your contacts will have to re-add a fresh you. We are honest about this in the onboarding flow itself.

7. Lattice doesn't make you invisible.

Your presence on the mesh is detectable. The radios advertise themselves; that's what makes them work as radios. An adversary in BLE range can see that some Lattice user is nearby, and with active probing, can sometimes correlate that to a specific phone.

Your contents are not visible — the cryptography handles that. Your recipients are not visible to relays — sealed-sender tags handle that. But "this person is running a privacy-focused mesh messenger" is, by physical necessity, knowable to anyone in your radio range.

If running Lattice itself is dangerous in your context, our honest advice is not to run it.

8. Lattice doesn't have voice or video calls.

Out of scope. The mesh has a fraction of the bandwidth and latency consistency of a cellular voice link. Doing voice/video over the mesh would require constant high-rate transmission, which would crater the battery model and the multi-user delivery story. We send text. Text is enough for the situations Lattice is designed for.

9. Lattice doesn't moderate content.

There is no moderation. There is no reporting button that sends your conversation to a Lattice trust-and-safety team because there is no Lattice trust-and-safety team. The mesh routes any encrypted packet that meets the protocol rules without inspecting contents. End-to-end encryption and zero-server architecture make moderation infeasible by design.

If a user is harassing you, the only remedy is the same as any other peer-to-peer system: stop sharing your contact details with them, and remove them from groups you control.

10. Lattice doesn't promise eventual delivery.

Best-effort. The store-and-forward outbox holds undelivered messages for 7 days by default; if no path opens to the recipient in that window, the message expires. There is no eventually-consistent global queue; there is no central retry service. Messages are delivered when phones come into range.

For most use cases this works fine — the people you care about most are usually within radio range or reachable via mesh hops in your urban area. But if your recipient lives in a place with low Lattice density and no LoRa bridge, your message may simply never deliver.

Why we publish this paper.

Two reasons.

First, trust. A project that says "we do everything" is asking to be caught lying. A project that documents its limits in detail before the user installs is doing the inverse — it is offering you the data you need to make an informed decision. We want users who installed Lattice with their eyes open.

Second, focus. Every limit on this list is the consequence of a deliberate trade-off. Voice calls are out because they wreck the battery model. The recovery path is out because it would be an attack surface. The internet bridge is opt-in because requiring it would defeat the whole point. Documenting the trade-offs publicly forces us to defend each one — and forces us to revisit any that no longer serve the project.

If you want a messenger that promises everything, there are options. Lattice is the one that gives you a complete list of what it does not do, in writing, before you ever open it.

References.

This paper is open to comment. Comments welcome in our Matrix room.