Meshtastic has really picked up speed in recent years. More and more people swear by the small LoRa devices to chat with each other even without cell reception or Wi-Fi. One truly exciting feature here is Store & Forward (S&F). But how does it actually work, and why does this feature quickly run into trouble in larger networks?
What can Store & Forward do?
Normally with Meshtastic, if the receiver is out of range, the message is lost. Store & Forward elegantly solves this. A special device in the network, the so-called S&F server, temporarily stores messages and holds them ready. As soon as a device comes back online after a radio silence, it can issue a “History Request” to the server. The server then resends the stored messages—like a little mailbox within the mesh network. Handy, right?
What does it require?
Sounds great, but there are a few prerequisites:
- Hardware: Only ESP32 devices with PSRAM (e.g. T-Beam or T3S3) can run as S&F servers.
- Continuous operation: The server should always be on; otherwise, messages are lost.
- Storage space: Messages end up in PSRAM. By default, thousands of entries fit there, but when the memory is full, older messages are overwritten.
- Private channels: S&F isn’t intended for the public channel to avoid flooding the network with data junk.
Where are the bottlenecks?
As cool as Store & Forward is, it has clear limits, especially in larger meshes:
- LoRa is slow: LoRa may have impressive range, but the bandwidth is tiny. When many old messages are resent, the channel quickly gets clogged.
- Duty cycle: Especially in Europe (868 MHz), there are legal limits on transmission time. An overloaded S&F buffer can cause messages to hang forever or never arrive.
- Duplicates: The server doesn’t know exactly what a device missed. So it often sends more messages than necessary—including some the receiver already has.
- Hop limit: Meshtastic messages usually get forwarded only three times (hops). If the server is too far away, stored messages don’t arrive.
- Network load: With many devices, resending becomes a problem. Every fetch triggers a flood of messages that all other devices in the network hear.
What does the documentation say?
According to the official Meshtastic documentation, there are two important parameters for Store & Forward:
- History Return Max: Sets how many messages are returned at most when a device requests history. Default at “0”: 25 messages.
- History Return Window: A time window in minutes—messages outside this window aren’t sent. Default at “0”: 240 minutes (4 hours, not 2!).
- Records: Determines how many messages are stored in total. At the default “0”, the server uses about two-thirds of the PSRAM—enough for approximately 11,000 messages.
Sometimes you hear about configurations with 100 messages and 2 hours (7,200 seconds) storage time, e.g. in a Chicagoland Mesh example. This is possible if you set History Return Max to 100 and History Return Window to 120 minutes. But that’s not standard—the default, as mentioned, is 25 messages and 4 hours.
Conclusion
Store & Forward is a truly clever feature to avoid message loss in small Meshtastic networks. For hiking groups, festivals, or emergency scenarios, it can be a game-changer. But in large networks, it quickly hits limits: slow data rates, memory issues, and network congestion make it impractical. Meshtastic is not a WhatsApp replacement but a low-bandwidth system with compromises. Store & Forward helps—but only when the scale remains manageable.