Device binding

The account's contact identity encrypts a room-specific proof of its device identity. The peer checks the room, sender, recipient and public device keys before pinning them.

Session setup

The device signs its one-time prekeys. The relay claims a key atomically and does not restore it when publication is retried. Setup waits when no key is available.

The engine is pinned to vodozemac 0.11.1. Olm uses AES-256 and HMAC with an eight-byte transmitted authentication tag.

Message delivery

Each other participant receives a separate pairwise envelope. A group can contain up to eight people. The encrypted payload repeats and authenticates the routing header.

Room, sender, recipient, device IDs, session and message ID must match before the client commits received state. This excerpt lists the envelope fields:

{
  "room": "conversation ID",
  "sender": "account ID",
  "recipient": "peer account ID",
  "sender_device": "device ID",
  "recipient_device": "peer device ID",
  "session": "session ID",
  "message": "message ID",
  "ciphertext": "encrypted content"
}

State and retries

Before sending, the browser commits the advanced ratchet, outbox and local sent copy. If the network response is lost, it retries that original ciphertext.

The relay commits all recipient queues atomically. A retry digest lasts until the original expiry, so an acknowledged or burned envelope cannot be recreated by a late retry.

Recipients save state and encrypted history before acknowledging delivery. Shredding changes the room generation, invalidating stale queued sends.

Verification

Checks cover bidirectional and simultaneous sessions, context and replay rejection, groups, attachments, retries, local reload, timers and device changes. These checks exercise implementation behaviour; they are not a security proof.

Run the local encryption demonstration or read the pinned engine documentation.