Proposal: Optional Private Channel Delivery ACKs

[greatgrumbledook]

Hi everyone,

I came across the discussion about avoiding ACKs for broadcast packets (e.g. issue #8924), and I completely understand the reasoning. On the public Primary Channel (Channel 0), minimizing airtime is critical, and broadcast acknowledgements would not scale well.

However, I think there is a different use case that might deserve discussion.

Private team channels

Many people use Meshtastic on small private channels for applications such as:

Search & Rescue
Volunteer organizations
Farms
Industrial sites
Event coordination
Family groups
Outdoor expeditions

In these situations, it is often important to know whether a critical broadcast actually reached the intended team members.

For example:

"Meeting point changed."
"Please return to base."
"Safety alert."
"Trail closed."

Today, the sender knows that the message entered the mesh, but not which team members actually received it.

Proposal:
What about an optional delivery confirmation feature that is available only for private channels?

Some possible constraints:
Disabled by default.
Never used on the public Primary Channel (Channel 0).
Enabled only on private channels if the channel owner chooses.
One delivery confirmation per receiving node.
Randomized backoff before sending confirmations to reduce collisions.
Sender collects confirmations for a configurable time window.
The app could display either:
"4 of 7 channel members confirmed delivery", or
A list of nodes that confirmed reception.
Delivery confirmation, not read receipts

This is not intended as a read receipt.

It would simply confirm that the destination node successfully received the packet, similar to a direct message ACK, without implying that the user has read the message.

Why this could work:
Private channels usually contain relatively few nodes compared to the public mesh.

Keeping the feature optional and disabled by default should minimize additional airtime while providing useful feedback for teams that depend on reliable group communication.

I'm interested in hearing whether something like this could fit within Meshtastic's long-term design goals, or whether there are technical limitations that would make it impractical.

Thanks for your thoughts!
Greetings
GreatGrumbledook