Store, carry, forward: delivery when the path blinks in and out

The internet’s core assumption is that a path exists from end to end at the moment you send. Routing protocols spend their effort finding the best such path, but they take for granted that one is there. At the edge, that assumption is often false. The next hop is asleep, out of range, or out of battery, and it will come back in thirty seconds or thirty minutes. A network built on end-to-end paths calls that a failure. A network built to carry data through it calls it Tuesday.

A different contract: custody, not connection

Offline Protocol’s delivery model is store, carry, and forward. A device that accepts a message takes custody of it. It holds the message in a local buffer, carries it while there is nowhere to send it, and forwards it the instant a suitable next hop appears. Delivery is not a single synchronous act across a live path; it is a relay of custody transfers, each one a short, local, opportunistic handoff between two devices that happen to be in contact.

This is the classical delay-tolerant networking idea, and it inverts the usual failure mode. Instead of “no path right now, therefore error,” the device’s stance is “no path right now, therefore hold.” The message is not lost when connectivity is absent. It is simply not done moving yet.

Every message carries what it needs to be handled

For custody transfer to work without a coordinator, each message has to be self-describing. In Offline Protocol every message carries a unique ID and a TTL, and relays act on those two fields. The ID lets any device recognize a message it has already seen; the TTL, together with a hop limit of up to eight, bounds how far and how long it travels before it is allowed to expire. A relay does not need to consult anyone to decide what to do with a message. Everything it needs to make the decision is in the message.

That self-description is what makes the buffer safe to flood from and safe to drain. When a device meets a peer, it can offer what it is holding, the peer can accept what it has not already seen, and neither side needs a shared view of the network to do it correctly.

Deduplication is the load-bearing wall

Opportunistic forwarding creates copies. The same message can reach a device by two paths, or come back around a loop, and without a defense that redundancy would multiply until it drowned the mesh. Deduplication by ID is the defense. Relays remember the IDs they have handled and drop repeats, so a message that arrives twice is forwarded onward and delivered to the application exactly once. Receivers acknowledge, senders retry on timeout, and the dedup layer absorbs the duplicates all of that retrying naturally produces.

The effect is a system that is aggressive about redundancy where redundancy buys reach, and strict about idempotence where duplication would cost stability. You get the delivery odds of flooding without paying flooding’s usual price.

The buffer is a budget, and so is the battery

Holding messages costs memory, and forwarding them costs energy, so store-and-forward is really an exercise in spending two budgets well. TTLs cap how long a message can occupy a buffer, so storage reclaims itself as messages age out rather than accumulating forever. Forwarding duty follows charge level: well-charged devices take on more relay work and devices below an energy threshold shed it, the same energy-aware routing that keeps multi-hop paths viable on phones. A buffer that never forgot and a fleet that forwarded blindly would both collapse; bounding each is what keeps the mesh alive over hours, not seconds.

Bulk data rides the same discipline with an added mechanism. File transfer up to 100MB is chunked with per-chunk acknowledgment and resume, so a large payload interrupted by a link dropping picks up from the last confirmed chunk instead of restarting. Store-and-forward at the message level and resume at the chunk level are the same principle applied at two scales: never redo work the network already accepted custody of.

Reconcile when the link returns

The visible payoff is what happens at reconnection. Because devices kept working and kept custody of what they produced while the backhaul was gone, coming back online is a reconciliation rather than a recovery. Buffered messages drain toward their destinations, acknowledgments settle, and duplicates are quietly discarded by the same dedup that protected the mesh during the outage. Nothing had to be regenerated, because nothing was thrown away when the path first blinked out.

Why it matters

Store, carry, and forward is the reason an outage on Offline Protocol is a delay instead of a loss. It runs in production across 350,000+ devices in 80+ countries, underneath the failover that chooses transports and the sessions that keep everything encrypted end to end. If your data has to arrive eventually even when there is no path right now, the machinery that holds it, deduplicates it, and moves it on the next contact is the part that makes “eventually” a guarantee rather than a hope.

Read more on how the mesh works, or talk to us about moving data through paths that come and go.