Skip to main content
Pitch In Subscribe

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.

Important caveat: Store and Forward is best-effort, not a delivery guarantee. The server only buffers traffic it personally received over RF; clients only get the history they explicitly request while in range of the server; and the buffer is volatile (held in RAM and lost on reboot or power loss). Do not rely on it to guarantee delivery of critical messages.

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 flashthe memory.device's PSRAM (volatile RAM, not flash). The buffer is lost on reboot or power loss.
  2. WhenThe aserver client node that was offline reconnects, itperiodically sends a heartbeat advertising itself to indicatethe it is online.mesh.
  3. TheA client canthat thenwas requestoffline requests history from the Store and Forward server.server (on Android, by sending the text command SF to the server; on the Apple/connected app this happens automatically).
  4. The server replays stored messages to the requesting client.

Enabling on a Server Node (Repeater)

Configure the node that will store messages:messages. Note that only PSRAM-equipped ESP32 boards (for example T-Beam v1.0+, T3S3) can act as a server — nRF52840 devices cannot:

meshtastic --set store_and_forward.store_forward.enabled true
meshtastic --set store_and_forward.store_forward.is_server true
meshtastic --set store_and_forward.store_forward.records 1000
meshtastic --set store_forward.history_return_max 25

records sets the maximum number of messages to store (circular buffer; oldest messages are overwritten). DefaultThe 100;default increaseis up0, which auto-allocates roughly two-thirds of the device's PSRAM (about 11,000 records); set a specific number to cap it. Capacity scales with the device's PSRAM, not its flash capacity— ofonly yourESP32 deviceboards with onboard PSRAM (ESP32e.g. hasT-Beam, moreT3S3) flashcan thanrun an S&F server, and nRF52840 forboards this purpose).cannot.

Enabling on a Client Node

ClientA nodesclient thatgenerally wantdoes not need any special Store and Forward configuration beyond being on the same channel as the server. The is_server flag already defaults to receive history need the module enabled:false:

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

TheWhen an app connects to the server, history can be retrieved automatically. Over LoRa, an Android client will automatically requestrequests history whenby itsending comesthe onlinetext andcommand canSF seeto 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 channeltext messages are stored,stored and replayed. Position reports and telemetry are not position reports or telemetry (configurable).stored.
  • FlashBuffer wear.is volatile. FrequentMessages writesare held in PSRAM, not flash, so the entire history is lost on reboot or power loss. There is no flash-wear concern because nothing is written to flash for messagethis 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.purpose.
  • Message delivery is best-effort. If the client is out of radio range of the server, history request packets cannot reach the server. History retrieval over LoRa is also unavailable on the default public channel.

Best Deployment Practice

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

Back to top