The Hard Part of Multi-Device Messaging

Separate leaves, shared identity

MIP-06 gives each device its own MLS key material and its own leaf in the ratchet tree. Every leaf carries the same Nostr pubkey in the credential identity field. The devices share an identity but share no cryptographic state, which means compromising one device does not hand the attacker the keys to the other.

The group must opt in

A group cannot silently acquire multi-device behavior. The multi-device extension must be enabled at the group level and marked as required, with every member advertising support before the feature activates. Existing groups must roll this out in stages to avoid state forks. If even one client does not recognize the extension, it will treat a legitimate second-device join as an unauthorized intrusion, and the group state will fork.

MIP-03 normally restricts structural commits to admins. MIP-06 carves out a narrow exception for a specific second-device join path, active only when the group has already signaled support for the multi-device extension. Every client must recognize the exception before any device can use it.

Four proofs in one commit

The new device joins through an MLS External Commit, which eliminates the need for an online admin to issue an Add on its behalf. An already-enrolled device pairs the newcomer by handing over current group material through an authenticated channel, and the newcomer then publishes its own External Commit to the relays. That commit must satisfy four independent checks.

First, the joining leaf must claim a credential identity that already exists in the group. Second, the commit must include exactly one resumption proof tied to the current group and current epoch, proving the newcomer holds secrets from the active key schedule. Third, a Nostr identity proof must travel inside the commit's authenticated data. Marmot constructs this proof as an unpublished kind 450 event with a zero timestamp, whose content is the SHA-256 challenge over the joining leaf and the relevant group state. The signer signs this as an ordinary Nostr event, and the signature binds the proof to the specific commit seeking admission. Fourth, standard MLS validation applies to the commit as a whole.

Pairing requires physical trust

The new device generates a fresh X25519 ephemeral keypair and presents its public key through QR, NFC, Bluetooth, or another bootstrap channel. The spec requires that this exchange be authenticated by the user. BLE broadcast alone is not sufficient, because encrypting the pairing payload to the wrong public key would hand an attacker the group information and epoch secrets for every group being paired.

The payload encryption uses X25519 key agreement fed into HKDF-SHA256 and ChaCha20-Poly1305 with fresh ephemeral material. Every value in that payload is epoch-specific. If the group advances an epoch while pairing is in progress, the transferred material becomes stale and the join will fail. The existing device must then send refreshed material from the new epoch.

As ratchet trees grow, so does the pairing payload. A small group fits in a QR code, but larger groups push the transport requirement toward BBQr or Bluetooth.

What you do not get

A newly paired device cannot decrypt messages from before it joined. That boundary comes from MLS forward secrecy and MIP-06 does not attempt to cross it. Accessing older messages would require a separate data availability mechanism outside this spec's scope.

Admin status is identity-based, so a new device for an admin pubkey inherits admin power on arrival. A compromised admin phone can therefore bootstrap a second admin leaf, and the spec requires clients to surface device additions and flag unusual bursts of same-identity joins so that group members can react.

Leaving is leaf-scoped, meaning that leaving on one device removes only that leaf while your other devices remain in the group. Marmot does not yet define a cross-group device identifier, which means there is no protocol-level mechanism to revoke a stolen device from all groups at once. That capability requires further specification work, and until it exists every additional device also leaks information. Members can infer device counts from same-identity join patterns. Relay observers gain timing data. A malicious participant can force rapid epoch advancement by repeatedly adding devices through valid external commits, imposing computational cost on every other member. White Noise will need client-side rate limiting and clear device management UI to contain these costs.