[Feature Request]: Message Delivered. Change behavior or change documentation

[roberthadow]

Prerequisites

• I have searched existing issues to ensure this feature hasn't already been requested
• I have checked the documentation to verify this feature doesn't already exist

Problem Statement

(1) Send a DM to a node for which you know there is a key mismatch.
(2) Get a Message Delivered response (circle with ellipsis changes to circle with check)
(3) Node list does not update time last seen. (This is entirely logical.)

"Message delivered" is not descriptive. It seems to mean that the message was delivered to another node in the mesh. As the CLI would say, "delivery is not guaranteed."

Proposed Solution

If the architecture supports it, make two distinct messages, "Message on its way," and then, "Message delivered."

In the alternative, change the existing message to, "Message on its way." As an added bonus, scan the message for the string "--ack". If it's there, append a request for acknowledgment to the message.

Or, update the documentation that explains that "Message delivered" means message delivered to the mesh, not necessarily to the named destination.

Current Alternatives

If ones uses the Meshtastic CLI, this is possible.

Importance

Important

Additional Context

If there are no changes to code, at least document what "Message delivered" means.

[roberthadow]

I found the description: https://meshtastic.org/docs/software/android/usage/

• UNKNOWN: Not known for this message.
• RECEIVED: Message delivered and acknowledged by the intended node.
• QUEUED: Message waiting to be sent to the mesh as soon as the device connects.
• ENROUTE: Message delivered to the radio, but no ACK or NAK received yet.
• DELIVERED: Message successfully delivered and acknowledged to the mesh (ACK received).
• ERROR: Message not delivered (NAK received or other error).

Perhaps we could be more specific about the operations here.

Am I to understand that RECEIVED refers to a DM? The intended recipient has acknowledged receipt. Is that why the icon has a single human form signifying a particular node to this the message was delivered?

DELIVERED iindicates that any one of many nodes to which channel traffic is directed has acknowledged receipt. Do I understand that of many recipients, at least one has acknowledged?

I understand what device(s) should respond to an --ack request. What device generates the NAK resonse? Or is it one's own device not receiving an acknowledgement after some perod of time?

If I get an ERROR icon immediatley after pressing Send, what conclusion should I draw or action to take?