Every messaging app you use depends on infrastructure you never think about: cell towers, an internet backbone, and central servers. That dependency is invisible right up until the moment it isn't — an earthquake, a flood, a blackout — and then all of it fails at once. The question I wanted to work through was simple to ask and hard to answer: can two phones hold a secure conversation using nothing but their own radios?
Modern phones already carry the radio for it — direct device-to-device links like WiFi Direct don't need a tower or a router. The hard part isn't the link. It's everything you have to rebuild on top of a link once you remove the servers. Working through it, the difficulty breaks into five distinct problems.
1. You can't even register without the internet
Mainstream messengers run through central servers, and most of them verify identity with a phone number — which itself needs a working network. So in the exact conditions where you need it, you can't even create a new account. An off-grid system has to establish identity entirely on the device, with no server and no phone number, and still have that identity be stable and verifiable to the people you're talking to.
2. The existing off-grid options can't carry what matters
Most infrastructure-free solutions today are built on Bluetooth Low Energy. BLE's bandwidth is so limited that in practice it carries short text and location pings — and little else. But in a disaster the content that matters most is often a photo of an injury, a voice message, a picture of a street. Carrying media means using the higher bandwidth of a direct WiFi link — and the handful of solutions that do tend to lack verified end-to-end encryption and confirmed delivery.
3. Relaying to a group quietly breaks encryption
Without a server, one device usually acts as a hub, relaying messages to everyone else. The naive ways to do this all have the same flaw: send the same ciphertext to all recipients, share one common group key, or relay in the clear. Each means that compromising a single device — or a single key — can unlock everyone's traffic. Preserving real per-person confidentiality through a relay, especially for broadcast messages, is far less obvious than it sounds.
4. "Did it actually arrive?" has no easy answer
Off-grid links are unstable by nature. Delivery receipts get lost on relay paths, or worse, can be forged. And because packets arrive out of order on a shaky network, message status can move backwards — a message that showed "delivered" reverting to "sent." To a user, that inconsistency reads as the system being broken. Reliable, tamper-resistant delivery status is its own problem, separate from moving the message itself.
5. Connections drop constantly, and cleanup is hard
Phones sleep. Apps go to the background. People walk out of range and back into it. Each of those events can leave a session in an inconsistent state, and recovering cleanly is surprisingly fiddly. Retry forever and you drain the radio and the battery; give up too soon and you miss reconnections that were seconds away. Getting that balance right is the difference between a system that survives real-world use and one that looks good only in a demo.
The approach
Each of these has an answer, and fitting them together was the interesting part: identity that lives entirely on the device, a separate encrypted session per connection, a relay design that preserves per-connection encryption even when one device forwards to many, authenticated delivery receipts that can't move backwards, and a reconnection strategy bounded to protect the battery.
The method itself is the subject of a utility-model application (TR 2026/009023, filed with an early-publication request), so I'm keeping the mechanics out of this note for now. Once it publishes, I'll write a follow-up that walks through how each of the five problems above actually got solved.