Skip to content

Nex — Node Encrypted eXchange

Messages no server — or anyone else — ever reads.

Two things here are genuinely different from every other messenger. Neither of them is a slogan about encryption — both are things you can check.

One

No server holds your messages.

When both devices are online, a message goes straight from yours to theirs. There is no server in the middle to store it, because there is no server in the middle at all.

When the other person is offline, the sealed message waits in a mailbox — and only there. It is deleted the moment their device confirms it arrived, and it expires after fourteen days if nobody ever collects it.

Whoever runs that mailbox can see that a delivery happened. They can never see what was said, or read it later, because they never had it in a readable form in the first place.

One exception on the server side: a mailbox can be configured to offer an opt-in directory, so that people who do not yet hold each other’s contact card can find one another. If you put yourself on it, the operator holds the label you typed until it expires. It is off unless it is switched on, twice — once by the operator and once by you.

And one thing that leaves your device without touching a server at all: with local discovery switched on, Nex announces itself on the network you are joined to, so two devices in the same building can find each other. The announcement carries no name, no account and no key, and the value in it changes every fifteen minutes — but it does carry your device’s address, so anyone listening on that network can tell a Nex device is present. It is off until you turn it on.

Exactly what the operator can and cannot see

Two

An AI agent needs your signature before it can touch anything.

Give an assistant access to your messages and you have usually given it everything, for as long as it likes. Nex does not have a setting for that.

An agent, a script or a CLI has to ask for specific permissions — read this, send that — with an expiry attached. A human then signs for it, and can hand back less than was asked for. The token lives in that process’s memory and is never written to disk, so closing it ends the access.

Change your mind and the next call the agent makes fails. Not the next session — the next call.

Real transcripts: asked, narrowed, refused, revoked

What is real today

This is an unfinished project, and the honest way to describe it is to separate what runs from what is planned. These three all run.

  • Automated Rust, Swift and web suites cover direct and offline chat, pairing, attachments, recovery, device linking and the agent approval boundary.
  • The iOS, macOS, local-web and hosted-web source builds exchange real end-to-end encrypted traffic; multi-process tests put the mailbox and restart paths in the loop.
  • An agent is refused before approval, refused again the moment the human narrows the grant, and refused again the instant the token is revoked.
The delivered plaintext is not in the receiving daemon’s storage.demo harness
grep -r '<the message text>' /tmp/nex-poc/b/(no match — the plaintext is in none of these files)    nex.db            94208 bytesgrep -c '<the message text>' sess1.txt   # control: grep does find it in a plaintext file2PASS  the delivered plaintext is absent from every file in B’s data directoryPASS  control: the same grep finds the string in a file that really contains it

Where to go next