feat:added rooms protocol

[vinaysingh8866]

Add Rooms 1.0 Protocol

Summary

This PR introduces the Rooms 1.0 protocol for end-to-end encrypted group messaging over DIDComm v2. It combines MLS (RFC 9420) for cryptographic group keying, a Host (MLS Delivery Service) for handshake ordering and fan-out, optional Routers for mesh relay, and Signing 1.0 artifacts for admin governance, replay-proof join tokens, and router attestations. MLS provides forward secrecy and post-compromise security; DIDComm provides addressing, routing, threading, and offline-first delivery via Message Pickup.

What's Added

• New Protocol: https://didcomm.org/rooms/1.0
• Protocol Location: site/content/protocols/rooms/1.0/readme.md
• Status: Demonstrated
• License: MIT

Key Features

Cryptographic Group Keying — MLS (RFC 9420)

• Tree-based MLS for forward secrecy and post-compromise security
• Configurable ciphersuites (default: MLS_128_DHKEMX25519_AES128GCM_SHA256_Ed25519)
• Multi-device support — users join with multiple MLS leaves
• Epoch-based ratcheting; one Commit wins per epoch (DS-ordered)

Roles

• owner — creates the room, controls the Room DID
• admin — authorized to change membership and policy via Signing 1.0
• member — MLS leaf participant
• host — Delivery Service: orders MLS commits, fans out messages, stores for pickup
• router — non-authoritative relay forwarding envelopes; never decrypts MLS

Room Identity

• Room DID with DIDCommMessaging service endpoint pointing to the Host
• controller field supports multiple admin DIDs for multi-admin governance
• Pluggable AS (Authentication Service) policy for binding MLS credentials to DIDs

Membership & Governance

• Replay-proof join tokens — Signing 1.0 ticket with device binding, monotonic counter, and expiry
• HPKE envelope for sealed welcome secrets, AAD bound to token digest
• Admin authorization — every invite, moderate, and policy update carries a Signing 1.0 artifact (single signature or threshold like FROST/MuSig2)
• Moderation actions: add, remove, ban, unban, promote, demote, transfer-ownership

Delivery Semantics

• At-least-once delivery with idempotent processing
• Two-ID model: DIDComm id (network-level) + mls_msg_id in MLS AAD (content-level)
• Receipts 1.0 for delivery acks; Host is the authoritative ack log
• Loop prevention via bounded hop_count and optional via trace

Offline & Mesh Support

• Message Pickup for offline mobile delivery
• Optional Routers for mesh relay with signed router attestations
• Routers cache acks to avoid duplicate sends; consult Host's authoritative ack log

Protocol Messages

Lifecycle

• create, created — room creation and acknowledgment

Membership

• invite — admin invites a DID with Signing 1.0 authz artifact
• join — invitee joins with MLS KeyPackage and join token
• welcome — Host delivers MLS Welcome to new member
• commit — MLS Commit fan-out to existing members
• leave — member self-removal

Roster

• roster-request, roster — fetch current members and MLS epoch

Application Data

• msg — carries MLS application ciphertext (opaque to Host and Routers)

Moderation

• moderate — admin actions on membership (requires Signing 1.0 authz)

Mesh Relay

• route-advertise, route-ack — Router registers reach set with signed attestation

State Machines

Room Lifecycle:

[Created] -> [Active] -> [Suspended] -> [Active]
                |                          |
                +-> [Archived] -> [Deleted]

Member Lifecycle:

[Pending] -> [Active] -> [Removed]
                |
                +-> [Banned]

Security Highlights

Measure	Detail
MLS E2EE	Forward secrecy + post-compromise security; Host/Routers see opaque ciphertext
Replay-proof joins	Monotonic counter + expiry + HPKE AAD binding to token digest
Admin authorization	Signing 1.0 artifacts (single or threshold) verified before MLS sequencing
Sender auth	DIDComm authcrypt provides sender authentication
AS/DS split	Recommended non-colluding Authentication Service and Delivery Service
Metadata reduction	Host fan-out preferred over multi-recipient headers; padding/batching supported
No plaintext leakage	Error reports MUST NOT include MLS plaintext

Error Codes (Report-Problem 2.0)

• authz.denied — invalid or missing admin authorization
• mls.conflict — competing commit; retry later
• mls.epoch-stale — sender behind current epoch; resync required
• join.token-expired — join token past expiry
• join.replay — token counter already seen
• router.attestation-invalid — bad or expired router attestation

Composition with Other Protocols

Protocol	Usage
Signing 1.0	Admin authz artifacts, replay-proof join tokens, router attestations
Receipts 1.0	Delivery acknowledgments (member -> Host)
Report Problem 2.0	Error reporting
Message Pickup 2.0	Offline-first message delivery
Routing 2.0	DIDComm forward for encrypted routing

Use Cases

• Private group chat with strong cryptographic guarantees (forward secrecy, PCS)
• Multi-admin team rooms with threshold-signed governance
• Offline-first mobile messaging via Message Pickup
• Mesh-relayed group chat with attested routers (BLE, LoRa)
• Federated communities spanning multiple DID methods and transports
• Compliance-grade messaging with cryptographic audit trail of admin actions

References

• RFC 9420 (MLS Protocol), MLS Architecture
• RFC 9180 (HPKE)
• DID Core (W3C), DIDComm v2
• Signing 1.0, Receipts 1.0, Message Pickup 2.0, Routing 2.0