Store and Forward Module

The Store and Forward module lets a designated node buffer messages for clients that were offline when a message was sent. When the offline client reconnects to the mesh, it can request the message history and receive messages it missed.

How Store and Forward Works

1. A node configured as a Store and Forward server (typically a fixed repeater with reliable power) listens to all channel traffic and stores messages in flash memory.
2. When a client node that was offline reconnects, it sends a heartbeat to indicate it is online.
3. The client can then request history from the Store and Forward server.
4. The server replays stored messages to the requesting client.

Enabling on a Server Node (Repeater)

Configure the node that will store messages:

meshtastic --set store_and_forward.enabled true
meshtastic --set store_and_forward.is_server true
meshtastic --set store_and_forward.records 100

records sets the maximum number of messages to store (circular buffer; oldest messages are overwritten). Default 100; increase up to the flash capacity of your device (ESP32 has more flash than nRF52840 for this purpose).

Enabling on a Client Node

Client nodes that want to receive history need the module enabled:

meshtastic --set store_and_forward.enabled true
meshtastic --set store_and_forward.is_server false

The client will automatically request history when it comes online and can see the server node.

Limitations and Considerations

• Only one Store and Forward server per channel is recommended. Multiple servers on the same channel will each replay messages independently, causing duplicate deliveries.
• Server node must be always-on. A server that goes offline defeats the purpose. Use a mains or solar-powered repeater with reliable uptime.
• Does not store all traffic by default. Only channel messages are stored, not position reports or telemetry (configurable).
• Flash wear. Frequent writes to flash for message storage will wear the flash memory over years of operation. This is generally acceptable for typical community mesh usage but worth noting for very high-traffic channels.
• Message delivery is best-effort. If the client is out of radio range of the server, history request packets cannot reach the server.

Best Deployment Practice

Deploy Store and Forward on your highest-uptime fixed node — typically the primary community repeater with mains or solar power. This is the node most likely to have been online and collecting messages during the period a user was offline.