Eight hard lines, and the arguments behind them.

For a long time this section said we would never add calls, on three arguments. The design answered all three, and one-to-one voice calling is now built and reachable in the app. What is refused is narrower than "no calls", and the cost we accepted is stated in full — including inside the app, before every call.

Why this trade, and not one of the others

Every shipping design makes the same choice in one of two directions. Route the call through a relay — this hides your address from the person you are calling, and hands one relay a record that the call happened and how long it lasted. SimpleX documents exactly this: its relay "can also observe the duration of your calls." Or connect the two phones directly — then there is no relay record, and your address is known to whoever you called. That is Signal's default, with a setting to switch to the first.

We took the first, deliberately: your contact never learns your address, and the residual is one relay that sees IPs and timing but never content. We refused to pretend that residual away — the alternative was to keep claiming "no calls" while the code shipped them, which is the one thing this page exists not to do.

Avano posts an arrival notification on both Android and iOS, the moment mail lands, and there is no push service anywhere in the product — no Firebase, no FCM, no APNs registration, no UnifiedPush, no push token. Arrival is detected over your own relay, on your own circuit, so no third party learns that you received anything or when. The notification carries nothing but the app's own name: no sender, no preview, no count, no badge. A posted notification lands in a system store outside the app, which we do not encrypt and cannot erase, so anything richer would be a leak we could not take back.

Avano still locks itself when it leaves the foreground and after a short idle, and a locked Avano's keys are sealed, so it cannot poll and cannot open a new subscription. It can still learn that mail exists — a subscription armed before the lock keeps firing, because its reader loop reads no credential — and that survival is deliberate, since tearing it down and re-arming on every unlock would hand the relay a timestamped record of every phone pickup.

The limits differ by platform and we are not smoothing them together. Android will not notify you while the device is locked, because the credential that detects arrival is held in the Android keystore and the OS will not release it to a locked device; the app re-checks the lock at the moment it posts. iOS will not notify you once iOS has terminated the app, because a terminated app runs no code and raising a notification for one requires APNs.

Why not just add push?

The cost. A push notification requires telling a third party — Apple or Google — that a message arrived for a particular device. That hands over a device-linked identifier and a timing record for every message you receive: precisely the metadata this entire product exists to avoid creating, held by a company that is not us and can be subpoenaed separately.

The alternative cost. The only way to avoid the third party is to keep the credentials that drain your queues cached outside the sealed store, so a locked app can keep polling. We refused that in writing, and the argument is one sentence: anything that keeps polling while locked has not locked.

What it would buy. Here is the part that settles it. A locked Avano cannot act on a push — it does not have the message, the sender, or the count. The most a notification could ever say is "open Avano and type your passphrase", and that is exactly what we already deliver, on both platforms, with nobody in the path. What push would add is one case: an alert on iOS after iOS has terminated the app. The price is a device-linked identifier and a permanent timing record for every message you receive, held by a company that is not us.

Fetching a preview means somebody has to load the page. There are only three candidates, and the obvious one is the most dangerous feature we could possibly ship.

Your phone fetches it when you receive the message. This is what most apps do. Think about who chooses the address: the sender does. So the sender chooses which server learns your IP address and the exact second you read your messages. An adversary would not need to attack Avano at all — they send you a link to a machine they control, and the fetch reports your address, your rough location, your operating system and when you were reading. It converts a metadata-private messenger into a beacon that reports on you, on the attacker's schedule, with one message.

A company server fetches it. Then that server holds a log of every link every user has ever sent. We do not have such a server and are not going to build one.

The sender's phone fetches it before sending and puts the result inside the encrypted message. This is the only defensible version and it is what Signal does, through a proxy that hides the sender's address from the site. It would cost us weeks — the fetch would have to go out over Tor, the image would have to be stripped of its metadata on the way in, and the result padded like everything else — and what it buys is a thumbnail.

What we build instead

The half of this feature that protects rather than exposes. When you receive a link, Avano strips the tracking parameters that were added to follow you, and warns you when an address is trying to look like a different one — lookalike characters, a hidden real destination, or a plain unencrypted connection. You see a cleaned, flagged link and you decide whether to open it.

We would rather be blunt than gentle here, because people discover this at the worst possible moment. Avano keeps your conversations only on your phone. There is no cloud copy, no export, and no account on our side to restore from. If the phone is lost, destroyed or wiped, the messages are gone. Your recovery phrase restores your identity; it does not bring back a single message.

The reason is that any provider-hosted backup is a second copy of your entire history, sitting outside the sealed store, held by somebody who can be ordered to produce it. Everything else in this product is an argument against creating exactly that.

There is a design in our codebase for a backup split into pieces across several independent relays, so that no single one holds anything useful. It is not finished and is not exposed in the app, and the simpler version that does exist is marked in our own source as unsuitable for real use, because the single relay holding it could read the lot. We would rather ship no backup than that one.

Practically: if a conversation matters to you long-term, get it off the phone yourself before you need it.

Broadcast channels, discoverable communities, public groups — the features that made Telegram what it is. They are the opposite of this product.

A channel anyone can join is a list of everyone who joined, held somewhere, and it is a list an adversary can subscribe to as easily as anyone else. Membership of a channel is precisely the kind of association Avano exists to make unavailable, and there is no way to serve the feature without serving the list.

Avano's groups are small, private, and created by invitation from someone already in them. There is no directory, nothing to search, and no way to find a group you were not asked into.

Searching message content is the most-missed feature Avano does not have yet, and it is coming — but not in the form most apps use.

Fast search in a messenger normally means a full-text index: a separate, searchable, plaintext copy of every message you have ever sent, sitting on the disk next to the encrypted ones. That single file discards the entire at-rest design in one step, and it is the first thing a forensic tool would read.

What we will build instead is the slow, boring version: open the messages for one conversation, decrypt them in memory, match, and keep nothing. On a phone-sized history that is fast enough and it leaves no artefact. It is the right trade and it is why the feature has not appeared yet.

Multi-device sounds like a convenience feature. In this design it is four separate problems, and only the first is obvious. (Moving your account to a new phone is a different thing, and it is supported: your recovery phrase restores your identity on the new device. What this section refuses is a second device running at the same time.)

Two devices poll the same addresses. A relay that sees one address collected from two different connections on two different schedules has learned those connections belong to one person — exactly the linkage the current design spends its effort preventing. Keeping two devices in step is itself a new signal, because sync traffic is bidirectional and follows your activity by construction. Keys multiply, so a second device is a second seizure target holding the same material.

And it breaks the lock. The point of multi-device is that the desktop keeps receiving while the phone is away. But "keeps receiving" is exactly what a locked Avano must not do. Multi-device as people expect it is a request to defeat the lock.

When this lands, we expect it to land as a linked reader rather than a second phone: something that can display history handed to it and send, while the phone remains the only thing that ever talks to a relay. That keeps the first and last problems closed, at the honest cost that the desktop does not work when the phone is off.

There is no vendor administrator mode in Avano — no way for us to add a party to a conversation, read one, or hand anyone a master key. (Groups do have an authoriser: the person who created the group can add or remove its members. That is a user holding their own group, not us holding a backdoor.) No message-retention or compliance copy. And no account recovery on our side, because there is no account on our side to recover — your recovery phrase restores your identity from your own device, and we are never in that loop.

This is not a promise about our intentions. Intentions do not survive an acquisition, a court order, or a change of ownership. A capability that exists only for the vendor to use "when required" will be used by whoever acquires or compels the vendor. ANOM's hidden extra recipient was built by the vendor. EncroChat's update channel was the vendor's own.

It also decides a market we will not enter. Organisations in regulated industries need communications that are retained, held by a third party, tamper-evident and outside the user's control — the exact properties this design exists to deny. We are not the right supplier for that and we would rather say so than build a switch and promise never to flip it. "We do not have the mechanism" is a defence. "We have the mechanism but we promise to show you when it is on" is a negotiating position, in a court that has already decided.

There is a further argument from evidence: the archival copy is repeatedly the thing that gets breached, because it is a second, weaker system holding the plaintext of the first. In 2025 a modified Signal client used to archive messages for government users was breached through an exposed debugging endpoint, and the archived logs — usernames, passwords, chat contents, keys — were not encrypted between the client and the storage at all.