Courier/Postoffice feature

[tronba]

What if we could have two special node types that allow for long-range communication, similar to a post office and courier service between mashes? A PostOffice node gathers and stores messages intended for other locations. In contrast, Courier nodes move between areas, synchronizing with PostOffices they meet and delivering messages when conditions are right.

Messages sent to a Postoffice node could, for instance be:

• For public broadcast in another zone, rebroadcast whenever a Courier is inside that area.
• For a private message within a zone, broadcast in the same way but meant for a specific receiver if they happen to be there.
• For a private message to a specific device, delivered only if a PostOffice or Courier "sees" that device on air.

Each of these message would include a few extra fields:

• A time-based TTL, (for example, seven days before PostOffice and Courier drops them).
• A limit on how many PostOffice hops are allowed (to hinder too much rebroadcast).
• The receiver zone, (for example, defined using a 10 km UTM grid).

The function
A user sends a message to a local PostOffice node, providing either a receiver, a zone, or both. The PostOffice stores the message with a timestamp and applies the TTL. When a Courier announces itself, the PostOffice and Courier exchange any stored messages they do not both already have. The courier may then pass messages to other PostOffices it encounters, or deliver them when it enters the receiver’s zone or sees the target device.

Needed change

• Implementing this would require dedicated firmware for PostOffice and Courier roles (these would need devices with more storage than usual).
• Ordinary nodes only need minor updates to recognize the new message fields and maintain a longer-term deduplication buffer so duplicate deliveries are ignored.
• The companion app would need a simple map view or zone selector to define the receiver area when composing a message.

This would be perfect for a place like Norway, where we have a bunch of Mesh networks, but they can't be connected together directly via radio. It's just too far between. I know this would be a big change, but it's a neat idea to consider. I know MQTT would do much the same thing, but that requires internet and is not as cool as a courier.

[Ryu945]

https://meshtastic.org/zh-TW/docs/configuration/module/store-and-forward-module/

[tronba]

@Ryu945 Store and Forward has its uses for sure, but seems to be too narrow in scope to work well for this type of situation (multi mesh coms).

[korbinianbauer]

I think @tronba is talking about Courier Nodes physically moving between disconnected meshes.

Sounds fun, but it's also inherently going to generate a dealbreaking tsunami of traffic whenever the Courier dumps its messages onto the Post-Office if that's done via the general mesh.

I could imagine introducing the Post-Office functionality for local meshes first.

Once that is there, there could be Couriers talking to PostOffices to switch over to their separate, 0-hop, high datarate channel for sync.

That's probably all in the distant future though.

[tronba]

Yes, load on the meshes would be a challenge, especially for the large ones.
One way this might be mediated is to have an initial communication between PostOffice and Courier, where they send a list of the message IDs they have in buffer. And that they only sync messages that one of the nodes is missing. A slow message rate if the network is congested might also be wise, to spread out the load.

This feature would be an undertaking, and is not core to Meshtastic, it's also something a fair few governments might object to. So I have little expectation that it will be implemented. But I liked the concept.