Skip to content

Nex — Node Encrypted eXchange

Messages that no server ever holds.

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.

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.

  • 731 automated tests: 440 across the Rust core, daemon, mailbox and relay; 191 on the Apple clients; 100 on the web client.
  • Two daemons complete a real handshake and exchange a real encrypted message — and the plaintext is provably absent from the receiving daemon’s database files.
  • 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