What the server in the middle actually holds.
Almost every claim Avano makes comes down to one question: what does the machine your messages pass through know? Here is the answer, in as much detail as we can give without asking you to read code.
Not a server that knows you. A shelf with numbered slots.
In an ordinary messenger the server is the centre of everything. It knows your account, your contacts, which groups you are in, and it decides what to deliver where. If you want to know what a subpoena would produce, you look at that server's database, and the answer is: your life.
An Avano relay is deliberately much stupider. Think of a wall of numbered pigeonholes in a room nobody is allowed to identify themselves in. Someone walks in, drops an identical sealed envelope into slot 7QF3·MXK2, and leaves. Later somebody else walks in, opens slot 7QF3·MXK2 with a key only they have, takes the envelope, and leaves.
The room has no visitor book. The envelopes are all exactly the same size and weight. The slot numbers are random and mean nothing. And the room is only reachable through a door that does not record who came through it.
That is not a metaphor for something more complicated underneath. It is a fairly literal description, and the rest of this page is the detail.
Follow one message to the relay and stop there.
- Your phone seals the message for one person Using libsignal — the same cryptography Signal uses, unmodified — including its post-quantum ratchet. This part is not our invention and we do not want it to be. Only the person you are writing to can open it.
- It is padded to a fixed size The result goes into a single 4096-byte block, and every block on the wire is exactly that size. Not roughly. Exactly. A two-word reply and a long paragraph produce identical traffic, so length tells an observer nothing. There is only ever one size class, on purpose — two would let a relay tell "a new conversation is starting" from "an ongoing one" by size alone, which is the leak the whole design exists to close.
- It leaves through Tor Through a Tor client built into the app, not a separate program you have to install and not an optional setting. The relay is published only as an onion address, so a connection to it arrives from inside the Tor network. Your IP address does not reach us and is not discarded by us — it never gets here.
- Inside that circuit, it is sealed again Tor protects the connection, but Tor's own encryption is classical — meaning a recording made today could be decrypted by a future quantum computer. Because the thing inside that connection is exactly the metadata this product exists to protect, we do not rely on Tor alone: a second, post-quantum-hybrid channel wraps every frame, so the slot number and the routing details are sealed too, not just the message. Worth being precise about what that does not fix: it is worth nothing against the relay itself, which has to read the slot number to know where to put the envelope. And it reaches nothing already recorded before it shipped. No change ever does.
- It lands in a slot The relay accepts a deposit that carries no sender identity of any kind. Not an anonymised sender, not a hashed one — the field does not exist in the protocol. There is nothing to authenticate, nothing to log and nothing to hand over.
What it can see, and what it cannot.
- That some slot received something at some time. A random-looking code and a timestamp.
- How often each slot is used. A rate per slot, over time.
- Which slots are being emptied from the same connection. Your phone spreads its slots across eight separate connections, so this partitions your addresses into roughly eight groups rather than revealing all of them at once — but each group is a stable pattern that follows your device.
- When you opened and closed the app. All of your connections start within seconds of unlocking and stop together when it locks. That start-and-stop is the clearest signal we hand a relay, and closing it would mean polling while locked, which we refuse.
- That somebody, somewhere, connected to the relay. Not who. This is a property of Tor and of how many people are using the service — which today is very few.
- Who sent anything. There is no sender field. Not hidden — absent.
- What any message says. The relay never holds a key that opens one, and the sealing happens on your phone before it leaves.
- Your IP address, or where you are. The connection arrives from the Tor network.
- Your contacts, your groups, or your name. None of these exist on the relay. There is no accounts table, no contacts table, no membership list — not emptied, never created.
- How big a message or a file is, or what type it is. Blocks are one fixed size; files are split into identical padded pieces under unrelated random names, so a 2 MB photo and a 2 MB document are the same shape.
- Which slots belong to the same person — across the eight groups. That linkage is what the split into separate connections exists to break, and it is broken imperfectly, not perfectly. See the leak below.
A relay that watches long enough learns which addresses belong to one group, because sending to a group posts one block to each member within a moment of each other. It does not need to open anything to do this — it is arithmetic on arrival times. This is a published weakness of this entire family of designs, it applies to Signal's sealed sender too, and the number of observations needed grows only slowly as a service gets bigger. Growth does not dilute it. The defence is temporal — spreading and delaying that fan-out — and only part of it is built. Do not read anything on this page as saying group membership is hidden over time. It is not.
What a seizure of the relay would produce.
What is written to the disk: nothing
The relay holds its queues in memory. There is no database, no state directory, no message spool on the drive. Undelivered mail waits in RAM and — so that a crash does not destroy it — is checkpointed to a memory-backed filesystem, which is still memory: those pages are never written to the block device, and the machine has no swap. The relay refuses to start against a spool directory that is not memory-backed, rather than merely warning about it.
So: a warrant for the disk, a request to the hosting company for a snapshot, or a subpoena for backups produces nothing. That is a real and complete defeat of the most common form of the attack, and it is worth having.
What that does not defeat, and we will not let it be over-read
The relay runs on a rented virtual machine. The company that owns the physical machine can be compelled — silently, without our knowledge, and without needing anything from us — to take a copy of that machine's memory from the layer beneath it.
Such a copy would contain the live slot numbers, the keys that open them, any undelivered blocks, and the relay's own onion identity key. Nothing in an in-memory design prevents this. We keep saying it in the same paragraph as the good news because the good news is easy to over-read as an answer to it.
The distinction the whole design rests on is this: a memory image captures the present; a disk image captures the past. Copying memory requires the machine to be running and requires it to happen then. A disk artefact can be read afterwards, off a decommissioned volume, a provider snapshot, or a backup, long after the fact. We have accepted a real cost — a reboot loses undelivered mail — to keep it that way.
What a copied identity key would allow
The relay's onion address is its identity. Somebody holding a copy of that key could run a relay that is indistinguishable from ours, at our address. There is no separate identity key today and nothing in the app would detect the substitution. That is a real gap and it is the thing a signed directory of relays is for; see the roadmap.
What we can be ordered to build
The relay is our code, so an order could in principle require us to run a modified one that records what the current one does not. There is no cryptography that prevents that, and any company telling you otherwise about their own servers is telling you something they cannot back.
What limits it is structural and it is the reason relay diversity is on our roadmap ahead of almost everything else: an order reaches one operator in one country. A conversation split across two relays run by two unrelated companies under two legal systems requires two orders, and each of them yields one direction. Today we have a second relay in a different country, with a different company, on a different network — and the app does not yet use it. Until it does, the honest statement is one operator, one jurisdiction, and an order to that one is enough.
Why your phone sends things it doesn't need to send.
Fixed-size blocks hide how long your messages are. They do not hide how many you send — anybody watching your internet connection can count. A burst of traffic at two in the morning followed by silence is information, and it does not require reading a single byte.
So Avano sends at a steady rate whether or not you are saying anything. When you write something, it takes the next slot in that steady stream. When you do not, a decoy goes instead — a genuine sealed block, deposited into a slot you own and empty yourself, byte-for-byte indistinguishable from a real message because it is one. There is no special "this is a dummy" message type; that would be a tag an observer could filter on, and a smaller packet they could count.
What it buys, precisely
- Against whoever watches your internet connection — your internet provider, a national tap, anyone on your network — they see one fixed-size block per slot, forever, whether you are mid-argument or the app has been idle a week. They know your name, and they learn nothing about your volume. This is the adversary it exists for.
- Against the relay — a rate per slot, and no way to tell a decoy from a message even in principle.
What it does not buy
- It does not hide that you are online. Constant traffic is still traffic. It cannot conceal the moment you go offline, and we will not describe it as anonymity.
- There is a residual: your phone sends a decoy only when there is nothing real waiting, so a relay hosting both your decoy slot and a contact's slot can add the two rates together, see a constant, and read your real volume off the difference. Relay diversity is what fixes that.
What it costs you
One design decision worth explaining, because we reversed our own earlier position on it. Cover traffic was going to be a paid feature. It is not, and the argument is not generosity — a privacy lane you have to buy marks the people who bought it. If only subscribers carry constant traffic, a relay does not need to break anything to find them; it reads the constant rate straight off the queue. And people who pay for anonymity are, on average, people with more to hide. A premium-only cover lane is not a privacy feature at all. It is a high-value-target flag, maintained by us, at the subscriber's expense. Anonymity is a property of a crowd, and a crowd you have to buy your way into is not one.
The claims, and how far you can take them.
Everything on this page is a design claim. The page that tells you which of them you can actually verify is the next one.