Meshtastic proposes optional delivery confirmations for private team channels

Meshtastic user greatgrumbledook opened a GitHub discussion on June 30, 2026 proposing optional delivery confirmations for private team channels, with the feature disabled by default and excluded from Channel 0. The feature is aimed at groups that care less about whether a message was read than whether a broadcast actually reached every node that needed it.

Meshtastic already treats the Primary channel differently. Channel 0 is the Primary channel, active channels are indexed from 0 to 7, and periodic broadcasts like position and telemetry go out on the Primary channel by default. Private channels use a shared channel name and encryption key to define the group, while direct messages are separate point-to-point encrypted communications.

Each receiving node would send only one confirmation, confirmations would use randomized backoff to cut down on collisions, and the sender would collect acknowledgements for a configurable window. In the app, it would show 4 of 7 channel members confirmed delivery, or list which nodes actually received the packet. Greatgrumbledook drew a sharp line between delivery confirmation and a read receipt: this would prove the destination node got the message, not that a person opened it.

Search and rescue teams, volunteer groups, farms, industrial sites, event crews, family groups, and outdoor expeditions often need a fast answer to one question: did the important message make it through? A meeting-point change, return-to-base call, safety alert, or trail closure does not need social-style read receipts. It needs a reliable signal that the mesh carried the packet to the right private channel members without flooding the air.

Meshtastic already shows direct-message states such as Queued, En route, Delivered, Received, Store & Forward Confirmed, and Error. The Python API includes a wantAck option that sends text reliably with retries and ACK/NAK feedback. Since version 2.6, Meshtastic has used different approaches for broadcasts and direct messages, and its mesh algorithm docs describe broadcast traffic as unreliable zero-hop messaging. Store & Forward can resend text after a client has been temporarily out of LoRa range, and since firmware 2.4, connecting to a Store & Forward server can automatically provide a larger history than the default device cache.