MMP Extension: Mesh Group

Abstract

This extension defines a generic application-layer convention for a mesh group — a small set of MMP nodes that have explicitly joined a shared, named group within the broader mesh — and the canonical CMB conventions members use to broadcast state to the group.

The convention does not change MMP wire format. CMBs remain MMP v0.2.2 CMBs. This convention specifies how members agree on group identity, how they discover each other, how they tag CMBs as group-scoped, and how they bound group lifetime.

The convention is the protocol primitive that real-world co-located group experiences are built on. The first use case (§9) is MeloTune’s “Mood Room” feature; the convention is intentionally generic so that other applications — group meditation, collaborative work sessions, multiplayer co-located experiences — can adopt it and interoperate at the protocol layer.

Introduction

MMP v0.2.2 §5.8 (Mesh Groups) names mesh groups as a structural concept but does not specify how a group is identified, discovered, or membership-managed. Implementers have adopted ad-hoc conventions, which has prevented cross-application interoperability.

This extension formalises the conventions that §5.8 leaves underspecified: a canonical group_id carried in CMB metadata; a Bonjour service type for LAN discovery and a relay channel pattern for WAN; a focus-prefix convention so multiple applications can share group infrastructure without colliding on state semantics; a receiver-side filtering rule for group-scoped CMBs; and a membership lifecycle (join, heartbeat, leave, expire).

Nothing in this extension changes MMP wire format. Implementers conforming to MMP v0.2.2 already have everything they need at the transport layer; this document specifies the application-layer agreement that lets two MMP implementations form an interoperable group.

1. Motivation

1.1 The §5.8 Gap

MMP v0.2.2 §5.8 introduces “mesh groups” but treats them as an opaque concept. Two implementers reading §5.8 cannot independently produce code that joins each other’s groups. The §5.8 text describes the semantic intent without specifying the wire format of the group identifier, the discovery mechanism for finding co-members, the CMB tagging that lets receivers filter group-scoped traffic, or the lifecycle events that mark joins, leaves, and expiration.

This extension fills the gap by formalising the conventions that §5.8 leaves to implementers.

1.2 Real-World Co-located Group Use Cases

Group experiences happen at human scale: a small number of people, briefly co-located, sharing some state. MeloTune’s Mood Room is one example: 2–6 listeners in the same physical space, each running MeloTune on their own device, each broadcasting their music-agent state into the shared room.

Other use cases follow the same pattern: a group meditation app where N practitioners share breathing-cycle state; a collaborative work app where N team members share focus-context; a multiplayer co-located experience where N participants share game-state. All of these need the same protocol primitive: a transient, named, peer-discovered subgroup of the broader mesh.

2. Mesh Group Model

A mesh group is an explicit, transient grouping of MMP nodes. Membership is voluntary on both sides: a node joins by advertising its membership; the group exists from the moment its first member joins until either the last member leaves or an optional expires_at timestamp passes.

The mesh group is not a long-lived addressable entity. It does not have a persistent state on any node beyond the transient list of currently-known members.

This document uses RFC 2119 keywords (MUST, SHOULD, MAY) as written in capital letters.

3. Group Identity

A mesh group MUST have a group_id (string, UUIDv4 RECOMMENDED).

A mesh group MAY have:

• A group_label (human-readable string, ≤64 UTF-8 bytes).
• An expires_at (RFC 3339 timestamp).
• A group_token (opaque bearer string).

The group_token is REQUIRED for WAN relay-mediated discovery (§4.2) and is OPTIONAL for Bonjour-LAN-mediated discovery (§4.1).

The convention does not specify how these values are agreed among members. Implementations typically distribute them out-of-band: one node generates them, and other nodes receive them via QR code, NFC tap, push notification, share-sheet link, or any other application-layer channel.

4. Discovery

4.1 LAN Discovery via Bonjour

Members MUST advertise the group via Bonjour service type _mmp-mesh-group._tcp with the following TXT record:

group_id        = <UUIDv4>
group_label     = <optional, ≤64 bytes>
mmp_version     = 0.2.2
member_identity = <Ed25519 public-key fingerprint, first 16 hex chars>

A node joining the group browses for _mmp-mesh-group._tcp, filters by matching group_id in TXT records, and connects to the discovered peers using standard MMP Layer 1 (TCP) transport.

Concrete TXT record example:

group_id        = 550e8400-e29b-41d4-a716-446655440000
group_label     = Living Room Sunday
mmp_version     = 0.2.2
member_identity = a1b2c3d4e5f6a7b8

Bonjour TXT records are key=value pairs of UTF-8 bytes; total record size MUST stay under the mDNS ~400-byte practical limit. group_label SHOULD be omitted if it would push the record over budget.

4.2 WAN Discovery via Relay (OPTIONAL)

Groups MAY operate LAN-only via Bonjour alone. Implementations without relay support interoperate with relay-aware implementations on the Bonjour path.

When a relay is used, members register membership with the SYM relay by:

1. Opening a WebSocket connection to the relay endpoint.
2. Presenting group_token as a bearer credential in the connection handshake (Authorization: Bearer <group_token> header).
3. Subscribing to the per-group channel named by group_id.

The relay enforces token-based authorisation and forwards group-scoped CMBs (those whose meta.group_id matches the channel) only among members holding a valid token for that group_id.

Members SHOULD reconnect on disconnection with exponential backoff (default: 1 s initial, 60 s maximum).

5. CMB Tagging Conventions

5.1 Group-Scoped CMBs

A member’s CMB is “group-scoped” when its meta.group_id field equals the group’s group_id.

Members MAY emit:

• Group-scoped CMBs — meta.group_id set, intended for delivery to other group members.
• Un-scoped CMBs — no meta.group_id, intended for the broader mesh per existing MMP rules.

A member MAY filter inbound CMBs by meta.group_id to restrict processing to group-scoped traffic. Receivers are NOT REQUIRED to filter; this convention only specifies the tagging semantics.

5.2 Application Focus-Prefix Convention

For inter-application interoperability, group members MAY use a CMB focus field prefix to indicate the kind of group state being broadcast. The prefix format is <app>:<state-type>. Examples:

• MeloTune Mood Room: focus: "melotune-room:state", "melotune-room:peer"
• (hypothetical) Group meditation: focus: "meditation:phase"
• (hypothetical) Collaborative work: focus: "cowork:status"

This is a RECOMMENDED convention, not a requirement. Applications MAY use any focus content. Inter-application namespace registration is deferred to a future version of this extension (§11).

6. Membership Lifecycle

7. Receiver Behaviour

A node receiving a group-scoped CMB SHOULD verify:

1. The sender’s identity is currently a known member of the group (via the Bonjour browse list AND/OR relay registration).
2. The CMB is received before expires_at (if set).

A node MAY accept group-scoped CMBs from unknown senders if the application context warrants it (for example, a listener entering a Mood Room mid-session may not yet have observed the original joiner’s announcement).

8. Failure Modes

9. First Use Case — MeloTune Mood Room

MeloTune’s “Mood Room” is the first use case of this extension. The MeloTune product:

1. Generates a group_id UUID per Mood Room.
2. Sets group_label to the room’s user-facing name (e.g., “Living Room Sunday”).
3. Sets expires_at to 24 hours after creation (configurable).
4. Distributes group_token via the in-app share sheet.
5. Each MeloTune instance joins the group, advertises via Bonjour _mmp-mesh-group._tcp and registers with the relay, and emits group-scoped CMBs with focus: "melotune-room:state" carrying the listener’s current music-agent state.
6. Each MeloTune instance receives the other listeners’ melotune-room:state CMBs and feeds them into MeloTune’s Personal Arousal Function for music curation.

The MeloTune-product naming, UX, and music semantics are MeloTune-specific and are NOT part of this extension. Other applications adopting this extension would use their own focus prefixes and their own state semantics.

10. Promotion Criteria

This document is a Draft Candidate Extension. Promotion to Published status in the MMP §16 Extensions registry requires:

1. A second independent implementer adopts. At least one application outside MeloTune ships a working implementation. “Implementer” means a distinct codebase, not a MeloTune-derived fork.
2. Two implementations interoperate. Demonstrated via documented interop test vectors, not anecdotal co-presence.
3. No accumulated breaking changes. If the convention has been revised to v0.2.0 or later during the wait, promote the stable v0.x.0 that both implementers ran against.

Until promotion, this document does NOT establish a formal MMP extension. The SYMBit whitepaper §4.1 commitment (“SYMBit does not require changes to the MMP protocol specification”) remains strictly true.

11. Future Work

• Cryptographic group membership. Replace shared bearer token with per-member capability tokens signed by a designated group authority.
• Group key agreement. TLS-style session key derivation between members for end-to-end encryption of group-scoped CMBs.
• Group state persistence. Currently transient; v0.2.0+ MAY add optional persistent group state (rejoinable, history-replayable).
• Multi-app group interop. Once 2+ applications adopt the convention, formalise focus-prefix registration so applications do not collide on the <app>:<state-type> namespace.
• IANA service-type registration. A formal RFC track would require Bonjour service type _mmp-mesh-group._tcp registration with IANA per RFC 6335.
• Rate limiting and DoS considerations. v0.2.0+ defines per-member rate-limit guidance and receiver-side back-pressure semantics.
• Versioning strategy. Co-existence rules for v0.1 and v0.2+ implementations in the same group.
• Bonjour and relay membership reconciliation. Canonical merge rule when Bonjour browse and relay subscription return conflicting membership lists.

12. Security Considerations

• Group token distribution is out-of-band. Compromise of the token allows a third party to join the group and observe or inject CMBs. v0.1.0 does not protect against this; v0.2.0+ adds capability tokens.
• Bonjour discovery is unauthenticated. Any node on the local network can browse _mmp-mesh-group._tcp and learn group_id values. Confidential group identity requires the WAN-relay path with group_token.
• CMB content is not encrypted at this layer. Existing MMP transport-layer encryption (per MMP v0.2.2 §3.4) applies between adjacent peers; end-to-end encryption among group members requires the group key agreement deferred to v0.2.0+.
• No per-member access control. All members see all group-scoped CMBs in v0.1.0. Per-member ACLs are out of scope.

These limitations are documented openly because this is a Draft Candidate Extension. They will be addressed in subsequent versions before this extension is recommended for safety-critical or high-confidentiality deployments.

13. Conformance

A conforming implementation MUST:

1. Support group_id as a UUIDv4 string carried in CMB meta.
2. Advertise group membership via Bonjour service type _mmp-mesh-group._tcp with the TXT record format in §4.1.
3. Filter group-scoped CMBs by matching meta.group_id if filtering is performed at all.
4. Honour expires_at if set: cease emitting group-scoped CMBs after the timestamp; discard inbound group-scoped CMBs received after the timestamp.

A conforming implementation SHOULD:

1. Emit mesh-group:join and mesh-group:leave CMBs at lifecycle boundaries.
2. Re-advertise Bonjour at the default mDNS cadence.
3. Implement the receiver-side membership verification rules in §7.
4. Surface failure modes from §8 to the application layer rather than absorbing them silently.

A conforming implementation MAY:

1. Support WAN relay-mediated discovery per §4.2.
2. Accept group-scoped CMBs from unknown senders if the application context warrants it.
3. Use the application focus-prefix convention from §5.2.

14. Change Log

• v0.1.0 (15 April 2026) — Initial Draft Candidate Extension. First use case: MeloTune Mood Room.

15. References

1. MMP v0.2.2 — Mesh Memory Protocol Specification. Particularly §3 (Identity), §4 (Transport), §5.8 (Mesh Groups), §16 (Extensions).
2. RFC 2119 — Key words for use in RFCs to Indicate Requirement Levels.
3. RFC 6335 — IANA Procedures for Service Name and Transport Protocol Port Number Registry.
4. Xu, H. (2026). Symbolic-Vector Attention Fusion for Collective Intelligence. arXiv:2604.03955 [cs.MA, cs.AI].