Skip to content
NNex

How it works

Direct first. A sealed mailbox only when it has to be.

Most encrypted messengers send everything through a server and encrypt it so the server cannot read it. Nex tries not to involve a server at all, and when it must, the server’s job is to hold an opaque blob for as short a time as possible.

How a Nex message reaches the other device When both devices are online the message goes straight from one device to the other with no server in the path. When the other device is offline, the sealed ciphertext is left in a mailbox, fetched when that device comes back, and deleted from the mailbox the moment delivery is acknowledged — at most fourteen days. Your deviceTheir deviceMailboxholds your keysholds their keysholds sealed ciphertext only 1 · Direct, when both are online end-to-end encrypted, no server in the path 2 · They are offline sealed ciphertext waits 3 · They come back their device fetches it 4 · Their device acknowledges — the mailbox deletes it. Unacknowledged mail expires after 14 days.

The three states of a message

  1. Step 1

    Direct, when both of you are online

    Your device finds theirs and opens an encrypted connection straight to it. Nothing is stored anywhere in between, because there is no in-between. If the two devices cannot reach each other directly — most home networks make that hard — the packets are bounced through a relay that carries them without being able to open them, and the interface says "relayed" rather than pretending it was direct.

  2. Step 2

    A sealed mailbox, when they are not

    Phones sleep and laptops close. When the other device is unreachable, your device encrypts the message for them and leaves it in a mailbox. The mailbox receives bytes it cannot read, padded so their length says as little as possible. It has no key, and no key ever passes through it.

  3. Step 3

    Deleted on acknowledgement, not on read

    When their device collects the message it sends back an acknowledgement, and the mailbox deletes it. Deletion is triggered by that acknowledgement rather than by the fetch, so a client that crashes half way through a download does not lose the message. Anything nobody ever collects is swept after fourteen days.

What the mailbox operator can see

This is the part that deserves precision rather than reassurance. A mailbox that holds your sealed messages is not nothing — it is simply much less than a server that holds your conversations.

Applies to whoever runs the mailbox, including Stuart Technologies when you use the default one.
The operator can see The operator cannot see
That a particular queue received something, how large it was, and roughly when.The content of any message. It arrives already sealed and is never opened.
That the queue was emptied, and when.Who sent it. Each item is sealed to the recipient device under a one-time key, so the sender is not named anywhere the server can read.
The network address that deposited or collected mail, at the moment it connected.Which conversation it belongs to. The conversation identifier is inside the sealed layer.
How much traffic the service handles in total.Anything after delivery. The item is deleted on acknowledgement, so there is no archive to hand over.
Message boundaries in any useful detail — payloads are padded to fixed sizes, and acknowledgements are now the same size as messages.

Why the phone behaves differently

A phone cannot hold a peer-to-peer connection open in the background — the operating system will not allow it.

So the mobile client is a mailbox client by design: it is woken by a push notification, it collects what is waiting, and it decrypts on the device. The push service learns that something arrived, never what. That is the same trade every encrypted messenger on iOS makes; it is stated here rather than left for you to discover.

Next: the approval gate in front of agents