Private conversations.
Explicit permissions.

Identity and group authority

Commands bind an operation ID, group ID, principal, device, key epoch, expected group epoch, expiry and action. The relay verifies the sender signature and a freshly signed, challenge-bound Identity response, then serializes admission against group membership. Creation, invitations, removal and history sharing require a human principal in this release.

Actions are create, invite, accept, remove, leave, send, share_history, acknowledge, inspect, sync and evidence. The OpenAPI schema defines exact fields; outer fields use camelCase, while action-specific fields use snake_case.

Recipients and retries

A send must include independently encrypted deliveries for the complete current recipient device set, including the sender's eligible devices. One command is limited to 32 deliveries and 1 MiB of decoded ciphertext in total. Large attachments use the existing encrypted Vault file path, referenced inside encrypted messages.

Retry an unchanged signed operation with the same operation ID while it remains valid. A changed payload is not the same operation. After expiry or an uncertain response, reconcile the recorded result before creating a new operation. HTTP acceptance is not delivery, archival or chain finality.

Membership and privacy

New members cannot automatically read earlier history. Explicit history sharing creates new encrypted deliveries and records the source event commitments. Removing a participant ends future relay access, including queued reads, but cannot erase copies or keys already received. The creator cannot leave or be removed; ownership transfer is not included.

Each accepted mutation atomically appends an immutable private event and a durable evidence job. Signed commands, Identity observations and a random salt bind the event hash. Only seven public fields are eligible for publication: schema, network, issuer, opaque stream, sequence, event hash and predecessor hash. Messages, participants, filenames, keys and IPFS identifiers remain outside that public envelope.

The prepared verifier checks native Testnet validator signatures, certificate continuity and Merkle inclusion. Core must implement and admit a dedicated Messaging-purpose intake before publication is enabled; Cortex credentials cannot be reused. This is single-operator, non-value Testnet assurance, not Mainnet settlement or independent multi-operator consensus.

Authorized audit disclosure can reveal selected content and its salted commitment without revealing decryption keys. Verification establishes binding and inclusion, not that a statement is true, a human read it, or everyone agreed. Public stream counts and timing still expose metadata.

Proof browsing and verification UI belong to Hybrid Explorer ↗, in its separate repository. This guide does not claim that Messaging proofs are already visible there.