You may have heard pdxlocs and myself talking about testing Store and Forward ++ on the MeshOregon network. But what is it? And how do you use it?
Store and Forward ++ is a new feature still in development from meshtastic developer Jonathan Bennett. It is currently only compatible with linux native nodes – but luckily, you don’t have to be running a Linux node to benefit from it.
In short, participating nodes keep a local database of messages they’ve seen. At the time of writing this, that consists only of text messages sent on the main public channel (though in the future they hope to expand this to DMs and other message types). These participating nodes periodically communicate in the background over the mesh to compare their database hashes. If a participating node finds that it is missing any messages that another one heard, they will communicate over the mesh to “re-sync” those messages, then the node that previously missed the message will re-broadcast the message out to its local mesh area.
For a practical application of this scenario, let’s assume the Portland to Salem link is being flaky one day, and someone sends a message in Salem that does not make it to Portland. The SF++ node in Salem will receive and log the message – then, next time the Salem SF++ and Portland SF++ nodes communicate, they will note the discrepancy in their message tables, and the Salem SF++ node will send the Portland SF++ node the message and its associated metadata. The Portland SF++ node will then re-transmit the previously “missing” message to its local area (with a reduced hop limit), meaning allowing the message to propagate out to the area it previously missed, with only a short delay. The resync happens every few minutes.
Your node doesn’t need to opt in or do anything in order to receive these rebroadcasts. From your perspective, the mesh simply becomes even more reliable.
SF++ nodes, as far as we can tell and in their current state, are best suited to run on a single Linux infrastructure node in each area, which is usually capable of receiving as close to 100% of the messages on the infrastructure network as possible. As SF++ does use a fair amount of traffic in the background during resyncs, we are avoiding excess SF++ deployments and saving them for major “regions” which have the potential to become semi-isolated over LoRa. For example, when we expand South towards Eugene, we may end up putting a SF++ node in that area as well.
That’s about it for now! We look forward to continuing to test this exciting new software as development continues.