Feat message queue

[Stephen-S-H]

This feature adds an optional message queue that stores messages until a node is reachable and then retries sending.

https://github.com/meshtastic/Meshtastic-Android/issues/1979#issuecomment-2934666279

Enable the message queue

Send a message to a node that is not reachable

When Max Retransmission Attempts are reached, the message enters the queue:

Tap the clock icon for more info, to manually retry, or to delete the message from the queue (deletes message entirely)

When the node comes online and the app receives a packet from the node, it retries the send.

This seems to work on my devices nicely, but I'm new to both Meshtastic and Kotlin so please take a careful look over this PR to make sure I'm not doing anything unwise here.

[CLAassistant]

All committers have signed the CLA.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[jamesarich]

I shared your PR with the other contributors on discord and it's generated a lot of excitement, and also some implementation feedback:

• Instead of a global on/off toggle from the main menu - let's utilize the current retry dialog to allow the user add to the queue.
• Adjust the inital Retry backoff time - 1 minute seemed like it could be a touch fast depending on the user's LoRa settings and mesh congestion.

[Stephen-S-H]

Thanks for the feedback. I'll clean this up per your suggestions. I originally made this so you needed to hit 'Retry' in the dialog to enter the queue, but it felt like an unnecessary extra step given I know that I always want the queue behaviour. Are you suggesting that the queue is always enabled, and a message enters the queue when you click 'Retry' in the retry dialog? Should I remove the setting from the main menu?

About backoff times. What do you suggest for backoff times? I pulled those out of the air. Presumably if this feature is being utilized the user is not in a congested mesh, but we understandably can't expect everyone to use the feature with consideration of wider impacts. (15m 1h 3h 6h 12h)?

[jamesarich]

Yes, the suggested flow would be the queue is always available, and messages to be added to the queue as an additional option from the retry dialog. (Also removing the main menu setting since it's always "on").

Manual per-message opt-in allows us to mitigate initial impact until we better understand it.

As for the timing, let's roll with it the way it currently is. We can tune it in later iterations.

[Xaositek]

There is equally inherent 3-attempt logic at the radio level while trying to find a recipient for either direct delivery or relayed DM. I would also ensure we persist this as a DM only feature, not something we have available for channel messages.

[jamesarich]

hi @Stephen-S-H - any plans to continue work on this?

[Stephen-S-H]

Yes, I'm time poor though. I'll update my PR in the next week I think.

On Wed, 18 Jun 2025 at 22:18, James Rich @.***> wrote:

jamesarich left a comment (meshtastic/Meshtastic-Android#2056) https://github.com/meshtastic/Meshtastic-Android/pull/2056#issuecomment-2983968382

hi @Stephen-S-H https://github.com/Stephen-S-H - any plans to continue work on this?

— Reply to this email directly, view it on GitHub https://github.com/meshtastic/Meshtastic-Android/pull/2056#issuecomment-2983968382, or unsubscribe https://github.com/notifications/unsubscribe-auth/A3KPXZET6QAUBB5UTCHR4O33EFKIJAVCNFSM6AAAAAB62Z2JXCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSOBTHE3DQMZYGI . You are receiving this because you were mentioned.Message ID: @.***>

[jamesarich]

Sounds good, thanks!