Phone-to-phone mesh messaging with no internet and no mobile network is genuinely possible, and the demonstrations look impressive. What the demonstration usually omits is the boundary: how far, how many hops, at what battery cost, and what happens when two halves of a group have been out of contact for an hour. Those limits come mostly from radio physics and operating system policy, not from how good the software is. Knowing them before you commit is the difference between a product that works in the field and one that works in a car park.
The two radios, and what each is good for
Bluetooth Low Energy is the discovery and control layer. It is cheap in power, can advertise and scan more or less continuously, and works reasonably well with phones in pockets. Throughput is modest — fine for text and presence, painful for anything with an image attached. Practical range between handsets is tens of metres in open space and considerably less through walls and bodies.
WiFi Direct, and its equivalents on each platform, is the bulk transport. Throughput is far higher and range is better, but it is expensive in power, slower to negotiate, and on some platforms involves user-visible prompts or interferes with the device’s ordinary WiFi association. Keeping it up continuously across a group is not viable on battery.
So the sensible architecture uses both: BLE as the constant nervous system — who is nearby, what do they have that I lack — and WiFi Direct brought up on demand for a specific transfer between a specific pair, then torn down. Either radio alone gives you a system that can only send short text, or one that flattens the battery.
Hops are not free, and the number is small
Mesh diagrams show neat lattices of nodes relaying happily across a city. Every hop adds latency, a battery cost on the relaying device, and a chance of failure — and the intermediate node is a phone in someone’s pocket, which may move, sleep or run flat mid-relay. Delivery probability degrades multiplicatively. Somewhere in the low single digits of hops, the chain becomes too unreliable to design around.
The stronger model is store-and-forward rather than live routing. Do not hold an end-to-end path open across several devices. Instead, each node carries messages it has received, including messages addressed to others, and hands them over whenever it meets a node that lacks them. Delivery happens because people move, not because a route exists. That is far more robust to nodes disappearing and matches how a crowd behaves.
The trade-off is that the interface must be honest. “Sent” and “delivered” are different states, and in a mesh the gap can be long. A message queued on a device that has not met a suitable relay should look queued. Borrowing the instant-messaging tick that implies delivery, when you cannot know, is the fastest way to lose a user’s trust in an emergency.
Discovery, and the battery bill
Peer discovery is where offline messaging quietly drains a phone. Scanning aggressively finds peers within a second or two and costs a great deal of power. Scanning conservatively costs little and may take a minute to notice someone walking past. Neither is right all the time.
What works is an adaptive duty cycle driven by context. Scan hard when the situation warrants it — the user has just opened the app, has unsent messages queued, the device is moving, or a peer was seen recently. Back off when nothing has been seen for a while and the device is stationary, further below a battery threshold, with a user override. Where the mesh matters most, a phone that lasts twelve hours at reduced responsiveness beats one that finds peers instantly and dies at hour four.
Operating system policy is the other constraint, and you cannot engineer around it. Background execution, background BLE scanning and background radio access are restricted differently on each platform, and the restrictions tighten with most major releases. Any design assuming a mesh app runs freely in the background indefinitely will be undermined by an OS update. Plan for degraded background behaviour as the normal case, and treat foreground operation as the high-performance mode.
What happens when nodes meet again
A mesh partitions constantly. Two people walk out of range, both keep sending into the same group conversation, and an hour later they meet again. Both sides now hold messages the other has never seen, interleaved in a way neither can reconstruct from wall-clock timestamps — device clocks are not synchronised, and offline there is no time server to fix that.
Do not order by device clock. Use logical clocks — a vector or per-device counter carried in each message — recording what a sender had already seen when it composed the message. That gives a genuine causal order: replies always appear after the message they answer, whatever the handsets thought the time was. Messages with no causal relationship are concurrent; order those with a stable tie-break so every device independently reaches the same sequence.
For chat, the underlying data structure is append-only. Messages are immutable facts; the merge on reunion is a set union plus a deterministic sort, which converges without negotiation. Genuine conflicts appear only in mutable state — a group name, a membership list, a read marker — best handled with last-writer-wins on a logical clock, or a representation where concurrent edits merge rather than fight. Deletions need care: a plain removal cannot propagate, because a node that never learnt of it will re-share the item at the next encounter. Deletion has to be an explicit tombstone that spreads like any other message. Storage is finite too, so sync should exchange a compact summary of what each side holds before transferring anything, and the local store needs an eviction policy.
Encryption with no server to hand out keys
Store-and-forward means your messages sit on strangers’ devices. End-to-end encryption is therefore not a feature to add later; it is the precondition for the architecture being acceptable at all. Every relayed message must be opaque to the relay, and the routing metadata attached should be the minimum that makes forwarding possible.
The hard part is not the cipher. It is that no server vouches for who owns which key. Each device generates its own long-term identity key pair and derives per-conversation session keys through a key agreement carried in the messages themselves, so a session can be established between two devices that never had internet access at the same moment. That part is well-trodden.
Trust establishment is the open problem, and it should be solved out of band, in person, while people are together. Scanning a QR code or comparing a short verification string face to face binds a human to a key with no infrastructure involved. Groups bootstrap the same way, with membership propagating afterwards. State this limitation to users rather than hiding it — verifying someone you have never met, over a mesh, with no trusted third party, is not something you can do safely, and a product implying otherwise is misleading people about their own security.
Forward secrecy is achievable by ratcheting keys forward, but note the tension with store-and-forward: a message may arrive days late, after the receiving device has rotated past the key it was encrypted under. Retaining old keys long enough to decrypt late arrivals weakens the guarantee. Pick the retention window deliberately.
Where this is actually worth building
Offline mesh is a poor general-purpose messenger and an excellent specific one. It earns its place where infrastructure is absent, saturated or untrusted:
- Disaster response, where the network is down and responders are clustered — exactly the density mesh needs.
- Large events, where cells are up but congested to uselessness and thousands of handsets stand within metres of each other.
- Remote work sites, expeditions and maritime settings, where a small known group needs coordination beyond coverage and can verify keys before departing.
- Industrial and underground environments where coverage is structurally impossible.
The common factor is density plus absence of infrastructure. Sparse users spread across a wide area will not form a mesh however well the software is written — with no one in range, there is nothing to relay through. So before committing, work out the realistic spatial distribution of your users at the moment they need it. Within tens of metres of each other, mesh is the right tool. Kilometres apart, you need a satellite or long-range radio bearer, and mesh will only ever be the last hop.