Messages that reach who you sent them to, on infrastructure you run.

End-to-end encrypted chat and groups for an organisation, delivered by a relay the organisation operates itself. No provider, no account, no server of ours in the path.

What your relay can see

  • The address each device connects from
  • Which identity signed in, and when
  • Timing and volume of messages
  • Message size, to within a factor of four
  • Roughly how many contacts an identity has
We publish this list because you will be asked for it, and because a product that claims to hide everything is not telling you the truth.

What it cannot see

  • What any message says
  • Who sent a private message
  • Who it was sent to
  • Who talks to whom
  • That any set of messages forms a group
These hold against the relay operator, against a future quantum computer reading recorded traffic, and against anyone who takes the relay's disk.

The relay is a store, not a participant.

Every person is a keypair. Every message is a signed, sealed event. A relay holds those events and hands them to whoever proves they may receive them — and understands nothing else about them. The sender's identity is inside the encryption. The recipient is addressed by an opaque tag that changes every week. The relay matches the tag and moves on.

You run the relay. A Windows application, on a machine you own, under a jurisdiction you chose. It needs nothing from us to work, and if we disappeared tomorrow it would keep working.

To reach someone at another organisation, your device connects to their relay and drops the sealed message there. No account is needed, and the two relays never speak to each other. There is no federation to trust and no central server to depend on.

The relay console is a Windows application today. Other operating systems will follow; the relay itself is the same on all of them.

What it does

One-to-one chat

Sealed sender, hybrid post-quantum key agreement, and a verification step that grants a badge only when two people compare codes in person.

Groups

A message is encrypted once and delivered to each member separately, so the relay cannot tell the messages are related. Removing someone rotates the key.

Attachments to 256 MB

Chunked, encrypted, streamed one chunk at a time, and held on the sender's relay. A relay holding every piece of a file holds nothing it can read.

What it does not do, and we say so

Removing someone from a group does not take back what they already have. They keep every message they received. Rotating the key stops them reading what comes next, and that is all any messenger can offer. The app says this at the moment you remove someone, because you will assume otherwise.

A seized phone is readable with the PIN, and not without. The disk is always encrypted, the app locks, and a second PIN wipes it. But a phone imaged before any PIN is entered has everything; the wipe is visible; and there is no ratchet yet. The setup screen says all of that before you choose.

There is no account recovery. An identity is a key. Lose the key without a backup and it is gone, and there is nobody — including us — who can bring it back. The app makes you choose to skip the backup rather than letting you forget.

A relay knows its members are online. A mailbox has to know its owner. What it does not know is who they are talking to.

Removing someone is not blocking them. They lose the connection and are told exactly that. A new request from them still lands in your tray, because a block is a different act and we have not built one.

Where it stands

September 2026
Two people, two phones, two cities, one relay on a Windows machine behind a tunnel. Messages both ways. The first thing the product did outside a test rig.
v0.12.23
The protocol specification, with fourteen normative test vectors that the implementation reproduces byte for byte.
562 tests
Plus a scenario runner that drives the real binaries through a twenty-eight-step exchange and then searches the relay's log to prove no identity leaked into it.
80 findings
Places where implementing the specification found it wrong, across twenty-nine gates, each recorded with the reasoning that fixed it. We think a protocol whose defects are on the record is safer than one whose defects are not.
256 MB
Rehearsed through the relay in both directions before the second field day, at under 150 MB of memory on the phone. The first pass needed 720 — so it was streamed, and the rehearsal is the reason.

See it on two phones.

A demonstration is the relay on a laptop, the app on two handsets, and twenty minutes. You will see what the relay's console shows — and what it doesn't.

Write to info@nsango.com