Acknowledged Group Messaging — per-member delivery confirmation for group conversations

[junomaluca]

Problem

Meshtastic's current messaging model has two modes: Direct Messages (1:1, with ACK) and Channels (broadcast, no ACK). This leaves a critical gap — there's no way to message a group of people and know that everyone received it.

In real-world deployments (search & rescue, events, off-grid groups, field teams), the most common pattern is: "I need to tell 5–10 people something important, and I need to know they all got it." Today, the only options are:

• Channel: fire-and-forget. You have no idea if anyone received it. In a sparse mesh with intermittent connectivity, messages frequently get lost silently.
• Multiple DMs: send the same message 5–10 times individually. Tedious, doesn't scale, and still no group awareness.

This is arguably the #1 reliability complaint in the Meshtastic community. Channels are fine for casual chatter, but when the message matters, there's no mechanism to ensure delivery.

Proposed Solution: Acknowledged Group Messaging

A new messaging primitive that combines the broadcast reach of channels with the delivery accountability of DMs.

How It Works

Group Creation & Membership

• A group is identified by a shared encryption key (same UX as adding a channel — paste a key or scan a QR code).
• Any node that adds the group key becomes a member.
• When a node joins, it broadcasts a JOIN announcement (encrypted with the group key). All existing members update their local member roster.
• Members can see the full group roster in the companion app.
• A LEAVE announcement is broadcast when a member departs.
• Member list is eventually consistent — propagates through the mesh as nodes relay.

Per-Member Delivery Confirmation

• When a member sends a message, it includes a recipient manifest (all known member node IDs).
• Each recipient sends back an individual ACK to the sender.
• Tapping a sent message in the app reveals delivery status per member:
  • ✓ Acknowledged
  • ⏳ Pending
  • ✗ Not delivered (after timeout)

Swarm Rebroadcast (Cooperative Delivery)

• Every group member who receives a message becomes a relay for that message.
• Relaying members continue rebroadcasting on a decaying schedule until:
  • A maximum time elapses (default: 24 hours), OR
  • The sender broadcasts an ALL_ACKED signal.
• This creates a "swarm delivery" effect — the more members are online, the harder the mesh works to reach offline members.
• Schedule: every 30s for the first 10 min → every 2 min for the next hour → every 10 min for 6 hours → every 30 min until timeout.

MQTT Support

• Group messages can optionally relay via MQTT, extending reach beyond local RF — same as current channel MQTT behavior.

Configuration Parameters

Parameter	Default	Range
group.max_relay_duration_hours	24	1–72
group.enable_mqtt_bridge	true	true/false
group.max_members	32	2–64
group.ack_aggregation_delay_ms	5000	1000–30000

Backward Compatibility

This is fully backward compatible with existing Meshtastic deployments:

• New protobuf message types — stock firmware simply ignores packet types it doesn't recognize (standard protobuf behavior).
• A stock-firmware node that adds a group key would still receive messages (same encryption), but wouldn't send ACKs or appear in the member roster. It functions as a passive/read-only participant.
• No changes to existing DM or Channel behavior.
• The modified companion app is required to use group features, but the standard app continues working for basic messaging.

Implementation Considerations

• Memory: Tracking ACKs for 32 members × N messages on ESP32 (~320KB RAM) requires a bounded message window with eviction. Likely limit to last 50–100 messages with active ACK tracking.
• Broadcast storms: The rebroadcast schedule uses aggressive decay and deduplication to prevent mesh overload. A bridge_ttl limits relay hops.
• Protobuf schema: New message types would be added to the meshtastic/protobufs repo — GroupMessage, GroupAck, GroupMembership (JOIN/LEAVE/ROSTER).
• Companion app: Major UI addition — group creation/management, member roster view, per-message ACK status overlay.

Why This Matters

No other mesh radio platform (goTenna, ATAK plugin, Briar) offers per-member delivery confirmation for group messages. This would be a genuine first in the off-grid mesh networking space, and it directly addresses the most common reliability complaint from Meshtastic users.

I'm willing to contribute code for this. Happy to discuss the protocol design further and iterate based on community and maintainer feedback.

[junomaluca]

Happy to contribute a working implementation for this — firmware (protobuf schema + protocol logic) and companion app changes. Would love to hear from maintainers on preferred protobuf patterns and any concerns about the approach before starting a PR.