ES | EN | |

How messages work

The full process, step by step: how messages are generated, encrypted, stored and picked up. At no point do the servers see the content: zero-knowledge model.

CENTRAL · Directory who is on which node and their public key The central only keeps sealed envelopes: it can't open them only checks: which node hosts B Device A writes and ENCRYPTS on their phone NODE · Mailbox run by the users the message lives here, encrypted Device B fetches and DECRYPTS on their phone deposits fetches The message travels A → NODE → B . The node is run by the users, not the central server.

1. Keys

Each user has an ECDH key pair on the P-256 curve. The public key is published in the central directory so others can encrypt messages to them. The private key NEVER leaves the device.

2. Composition

The user writes the message on their device. At that moment the plaintext only exists there, on the sender phone.

3. Encryption (ECIES = ECDH + HKDF + AES-GCM with AAD)

The device encrypts the message with the recipient PUBLIC key, producing a sealed "envelope". The AES key is derived via HKDF-SHA256 from the ECDH agreement and the ephemeral key is bound to the ciphertext (AAD). It also generates an encrypted copy for the sender themselves, so they can re-read what they sent. Only the sender and the recipient can open the envelope; no one else.

4. Sending and storage

Via central: the encrypted envelope is stored on the central server (ciphertext only) and delivered to the recipient.
Via federation (new): the device deposits the envelope directly in the mailbox of the recipient home node, without going through the central server, which is only queried as a directory.
Files always go to a node; only an encrypted link to the file travels with the message.

5. Reception

The recipient device picks up the envelope (from the central server and/or from its node), decrypts it LOCALLY with its private key and stores the plaintext ONLY on the device.

6. Retention

Messages can self-destruct (ephemeral per conversation) or be purged according to the chosen policy. The server only stores encrypted data, so a purge removes only unreadable blobs.

Zero-knowledge

At no point along the way do the servers see the content of messages or files. Central and nodes only handle end-to-end encrypted blobs; the keys to open them live exclusively on the devices.

Architecture Features