How an always-on node can replay missed text messages when users return to radio range.
Store and Forward helps a client recover recent text messages after it has been outside radio range. A special always-on server listens to messages, keeps history in memory and later replays eligible records when requested. It is useful for intermittent users, but it is not guaranteed delivery, offline direct messaging or an internet-style mailbox.
How it works
The server stores text traffic it receives. When a client returns, it can request messages within a configured time window, up to a configured maximum. The server does not know exactly which messages that client missed, so duplicates are possible. Since firmware 2.4, connecting an app directly to the server retrieves its larger local history automatically.
According to the current Store and Forward documentation, only ESP32 devices with onboard PSRAM, such as suitable T-Beam and T3S3 variants, can operate as servers. A server should be continuously powered and well positioned; missed reception produces an incomplete archive.
Two retrieval cases
| Case | Transport | Important limit |
|---|---|---|
| Client requests history through the mesh | Stored messages are retransmitted over LoRa | Not available on the default public channel; can create a traffic burst |
| User connects an app to the server itself | App retrieves the server’s local history | User must reach and connect to that server |
Server planning
Choose mains-powered or generously powered ESP32/PSRAM hardware. Label the node clearly and assign a steward. A server can be configured with store_forward.is_server without making it a Router; this avoids changing the node role merely to enable history service. The history record default uses a large portion of available PSRAM and may hold roughly 11,000 records on typical supported hardware, but replay limits should remain much smaller.
The heartbeat announces that a server is available. It can be disabled to reduce periodic traffic when clients already know the server or when history is only accessed by connecting locally. The documentation describes a fifteen-minute heartbeat, so several servers can add needless background traffic.
Protect the shared channel
A client history request can cause many messages to be retransmitted. Configure a modest history-return maximum and a realistic time window. Schedule experiments away from busy periods. Do not repeatedly request the same history when duplicates are expected, and do not treat Store and Forward as an excuse to raise hop limits or flood a whole regional mesh.
For a public network, a dedicated coordinated channel may be more appropriate than the default public channel. Remember that anyone with the channel key can read the stored channel messages. The server is a data-retention point, so its physical security, administration and retention policy matter.
Failure modes
- The server was offline or could not hear the original message.
- The client asks outside the retained time window.
- The maximum response count truncates the history.
- Replay packets are lost or congest the channel.
- The user receives duplicates and mistakes them for new messages.
- A firmware change or power failure clears or changes available history.
Deployment checklist
- Test with three nodes on an isolated channel: sender, server and returning client.
- Confirm the board has ESP32, PSRAM and reliable power.
- Set a conservative return maximum and time window.
- Decide whether heartbeat traffic is actually needed.
- Measure replay impact across the intended hop count.
- Publish simple client instructions and explain duplicates.
- Monitor uptime and name a maintainer.
Store and Forward improves convenience for occasional users, but urgent communication still requires acknowledgement and an alternative plan. It should be described as recent-message recovery, not a guaranteed emergency store. For airtime planning, see Meshtastic network capacity and congestion.