Group Hosting Protocol

Client–relay protocol

Group hosting is an optional client–relay module. Users create groups and select a fixed hosting relay; clients connect directly to it, without account route DHT or relay RPC. Relays offering this capability MUST implement the entire module and declare group.host.v1 in a valid RelayDescriptor.

Purpose and Trust Boundaries

The host verifies devices, membership, and roles, maintains current group state, orders events and key epochs, and distributes relay secrets to authorized devices. Current members share a client group secret. Group message keys MUST derive from both client and relay secrets, so the relay alone cannot decrypt messages.

Clients verify members and public keys through the permanently retained administration chain. They reconstruct membership locally and MUST complete administration verification before wrapping secrets.

Collusion between the relay and a party holding the client secret may decrypt corresponding messages. This protocol claims neither forward secrecy nor post-compromise security. See Security boundaries for collusion, disclosure, and rotation limits.

Protocol Contents

Concepts and Core Objects

Methods and Notifications

Method Index

All methods below use device sessions.

HTTP/WSS mapping and errors follow Common group method conventions.

Notification Index

• group.timeline.changed
• group.application.changed
• group.member.recovery.changed

Envelopes follow Client–relay notification conventions.

Conformance Requirements

Conforming implementations MUST follow Conformance testing boundaries and Common client method conventions, covering:

• Requests and commits: verify complete requests, device signatures and account binding, independent approver verification, field/resource boundaries, HTTP/WSS error mapping and disclosure boundaries under Common group conventions. Concurrency and failure MUST NOT leave partial state, events, keys, access intervals, or invitation counts.
• Administration state: verify creation, property/role updates, transfers, leaving, removal, banning/unbanning, capacity limits, and member projections under the Administration chain and Membership and access control, including same-value updates, old-head replay, unknown administration types, and suspension after failed verification.
• Invitations and approval: verify sharing, viewing, usage permissions, application retries/replacement, key resets, expiry, and dependent deletion under Admission and Member key reset. List pagination must cover cursors, empty pages, list/permission changes, complete traversal of unchanged lists, and list results not substituting for current-state checks at submission.
• Secrets and rotation: verify separate secrets, commitments, both box types and derivation, two-phase client rotation and relay rotation under Key model and Key methods, including batches/replacement, late retries, non-refreshing deadlines, member changes, complete coverage, owner key changes, and activating candidate material only after verification.
• Key and private-state recovery: verify staging independently arriving material, private-key selection and revision confirmation from verified history, historical/current box recovery, and cross-page/adjacent box omission under Account-internal synchronization and group.key.sync. Missing historical keys do not block administration verification or current-epoch recovery.
• Events and access: verify new-device entry, boundaries and multiple intervals, differing management/message visibility, nonconsecutive sequences and epochs, message authentication, and chain reconstruction under Device access intervals and group.sync. Snapshots, notifications, and private material cannot advance verified state or cursors.
• Messages and nicknames: verify complete envelopes, random nonces, AAD, current permissions, result retention, bodies/attachments, replies, and local nickname ordering, clearing, and rejoin boundaries under Group messaging and encryption and Idempotent retries. Handle business plaintext errors separately from administration-event errors.
• Subscriptions and notifications: verify replacement, clearing, reduced limits, failure details, and preservation of device access intervals under Subscriptions and Notifications, including event-hint coalescing, unversioned list refresh, and notifications after request expiry/deletion.
• Retention and closure: verify message/old-key pruning, current-key recovery, permanent retention of administration events and verification certificates, and irreversible closure under Retention and access and group.close. After closure, reads and message/key retention are not guaranteed.