Store and Forward

Store and forward is a messaging pattern in which a well-resourced relay node holds onto traffic destined for peers that are currently unreachable, then delivers it later when those peers reappear. In an intermittently connected mesh — where nodes sleep to save battery, move out of range, or lose power — this decouples sending from receiving, so a message written now can still arrive hours later. It is one of the oldest ideas in networking: email, packet radio BBSs, and delay-tolerant networking for space probes all rest on the same principle. A mesh without it is a walkie-talkie conversation; a mesh with it starts to behave like a postal service.

Why real meshes need it

A radio mesh is honest about physics: a broadcast reaches whoever is listening at that moment, and nobody else, ever. But real networks breathe. Battery nodes duty-cycle their radios, hikers walk behind ridgelines, solar nodes brown out overnight, and a village's worth of handhelds simply get switched off at bedtime. Without a store-and-forward layer, every one of those gaps is permanent message loss; with one, a single always-on node quietly converts a flaky real-time channel into reliable asynchronous messaging. The relay does not need to be exotic — it needs power, uptime, memory, and a decent antenna position. The pattern also changes how people use the network: knowing a message will eventually arrive makes the mesh useful for coordination and logistics, not just live chatter between nodes that happen to be awake at the same moment.

How Meshtastic implements it

Meshtastic ships a Store & Forward module intended to run on an always-on, mains- or solar-powered node with onboard PSRAM (such as a T-Beam or T3S3). The module quietly records the messages it overhears on the mesh. When a node returns to coverage, its user requests the missed history — on Android by direct-messaging the server node the text "SF", on Apple platforms through a retrieve-messages option — and the server replays the stored packets back over the LoRa channel. By default the module dedicates about two-thirds of available PSRAM to this cache, holding on the order of ten thousand records, with configurable history depth. Replay consumes airtime like any other traffic, so a sensible history window matters on a busy channel — the same airtime discipline that governs every LoRa deployment applies to catching up on history.

Deployment realities

The feature is restricted to private channels rather than the public mesh, which suits the closed, trusted networks sovereign groups tend to build — a neighbourhood watch, a farm crew, an off-grid family. Placement follows relay logic: the store-and-forward node wants the same high, central, always-powered position a good router occupies, and one dedicated server per mesh is the intended pattern. Pair it with a solar panel and a battery sized for your worst week of weather, and the mailbox stays open through the very outages it exists to bridge — the moments when centralized alternatives are down are exactly when it earns its keep.

Why it strengthens sovereignty

Store and forward turns a fragile, range-limited mesh into something closer to dependable infrastructure without ever touching the internet, a cellular carrier, or anyone's server farm. A single hilltop relay becomes the community's mailbox: messages survive nightfall, power cuts, and patrol rotations, and the only party holding your traffic is a box your own community owns. That is the decentralisation thesis in miniature — replace a dependency you rent with a capability you control. Store and forward complements managed-flood mesh routing by serving the nodes that were offline during a broadcast, extending the practical reach of the network across time as well as distance.