[Feature Request]: Increase reliability of Direct Messaging [DISCUSSION THREAD]

[benkyd]

Platform

NRF52, ESP32, RP2040, Linux Native, Cross-Platform

Description

This issue intends to consolidate efforts to allow the saving and re-transmitting of messages to nodes as they join and leave the mesh. I have seen proposals on the "Store and Forward Module" However, as well as that I personally believe that individual nodes can contribute to this by just keeping a small buffer of "heard but not ACK'd" messages in RAM.

It could essentially be a re-transmit rule if certain conditions are met

• If message is not ACK'd
• If it has been a while since dest node was last heard
• If it is clear that next-hop-routing failed somehow (sender heard the hop without the next byte)
  Then...
• Sender node notifies application of non-delivered
• Sender node caches message for a set period of time (say 24 hours)
• If during this time, the sender node hears the dest node again on the mesh (maybe a clientinfo or a traceroute, anything to indicate that they might now be reachable).. sender node rebroadcasts to the mesh the original message.
• It does this once and only once as not to congest the network

A use case of this might be

• user A wants to message user B. They are both aware of nodeIDs and have pre-negotiated a PSK.
• user A only drives past user Bs cluster once a day

A prerequisite to this feature would be #5875 as knowing when a node leaves and when it was last around is essential.

The idea of "is a node attended" being a flag is an interesting one too? Although i am not sure how it would integrate meshtastic/protobufs#667

I will include @GUVWAF and @RCGV1 as i think their direction is good

I am a relatively new contributor to this project. But i would love for meshtastic to allow for far more robust messaging without any specially configured nodes on a mesh nor any special settings in the p2p "2 node mesh". This thread is for thoughts and i'd love to get writing code!

[mikecarper]

Better path finding of the message to address the "picket fence" issue where a node in client mode is the only one that can reach another location but router and router_late doesn't make sense for the node. Being able to counteract temp links created by a node in a plane at 10k+ feet is also needed.

[mepholic]

I support this proposal from @benkyd