Store and Forward

What Is Store and Forward?

Store and Forward (S&F) is a Meshtastic server module that buffers text messages for nodes that are temporarily offline. When a client node comes back within range, the S&F server can replay text messages the client missed while it was away.

Important - the buffer is volatile and S&F is not a delivery guarantee. Stored messages live only in the server node's PSRAM. Any reboot, brownout, or power loss on the server node erases ALL stored messages with no recovery. Replay is best-effort, request-driven, and limited by count and time window; it covers text messages only (not telemetry, position, or other packet types). Never treat the buffer as durable storage, and never rely on it for life-safety message assurance - for incident use, assume the buffer can vanish at any moment.

How It Works

1. A node with S&F enabled in server mode listens to text messages on its primary channel (channel 0) and stores them in a ring buffer in PSRAM. Note: history retrieval over LoRa is not available on the default public channel, so the server must be configured with a non-default primary channel for S&F history to work.
2. When a client node requests history (see Client Configuration below), it sends a replay request.
3. The server transmits buffered messages up to the configured History Return Max count and within the History Return Window time range.

Hardware Requirements

The S&F server requires an ESP32 device with PSRAM - nRF52-based boards cannot run the Store-and-Forward server module at all:

• Recommended (ESP32-with-PSRAM only): T-Beam (v1.0 and later), LilyGo T3S3, or other ESP32-S3 devices that include PSRAM.
• Not supported as an S&F server: nRF52840-based devices (RAK4631, Nordic development kits) and any board without PSRAM. These cannot act as a Store-and-Forward server.

Server Configuration

1. Navigate to Config → Module Config → Store and Forward.
2. Set Enabled → true.
3. Set Is Server → true.
4. Set History Return Max - the maximum number of messages to replay per request (default: 25 messages, which is the value used when this is left at 0).
5. Set History Return Window - the time window in minutes from which to replay messages (default 0 = 240 minutes / 4 hours).
6. Save and reboot the node.

Client Configuration

A client node does not need the Store and Forward module enabled to request history. To retrieve missed messages:

1. Set role to CLIENT (or CLIENT_MUTE, labelled "Client Mute" in the app menu, if the device should not rebroadcast).
2. Request history manually: on Android, send a direct message containing SF to the server node; on Apple, use the Client History option.

History retrieval over LoRa is manually requested as above. Automatic retrieval happens only when an app connects directly to the server node (firmware 2.4+) - it does not happen automatically over the mesh just by coming into range.

Ideal Use Cases

• Hikers or cyclists who move in and out of mesh coverage.
• Vehicles that periodically leave and re-enter a covered area.
• Remote monitoring stations that reconnect on a schedule.
• Community nets that want a convenience replay of recent text traffic - but note S&F is best-effort only and must never be relied on as guaranteed delivery for emergency or life-safety messages.

Limitations

• S&F history retrieval over LoRa is not available on the default public channel; you must configure a non-default primary channel to use it. S&F operates only on the primary channel (channel 0) - if your net runs on a private or secondary channel, store-and-forward will not buffer or replay that traffic. Verify replay actually works on YOUR channel before depending on it.
• Text messages only - telemetry, position, and other packet types are not buffered or replayed.
• Large message volumes will cause the ring buffer to overwrite older messages quickly.
• The buffer lives in PSRAM only. The server node must be continuously powered and on-mesh; any reboot, brownout, or power loss erases ALL stored messages with no recovery.
• S&F adds overhead to the server node; monitor channel utilisation on high-traffic networks.