The features we refused, and why.

What everyone else does, and why we cannot copy it

Every shipping design makes the same trade in one of two directions:

• Route the call through the company's own server. This hides your IP address from the person you are calling, and hands the company a record that the call happened and how long it lasted. SimpleX documents exactly this, in those words: its relay "can also observe the duration of your calls."
• Connect the two phones directly. Then there is no server record — and your IP address is now known to whoever you called. Signal's default, with a setting to switch to the first option.

Both are reasonable products. Neither is available to us, because Avano's whole promise is that no such record exists anywhere, and we are not willing to hand your address to a contact either. Briar — the closest thing to us architecturally, also routed over Tor with no central servers — ships no calls at all, for the same reasons.

So: Avano does not do voice or video calls, and it is not going to. If you need to talk, use Avano to agree where and when.

This is the single thing about Avano most likely to surprise you, so it should be the first thing you know. Avano posts no notifications, there is no push integration on either platform, and messages do not arrive in the background. Your messages are waiting at the relay; you collect them when you open the app.

That follows from something we consider non-negotiable. Avano locks itself when it leaves the foreground, and after a short idle. A locked Avano's keys are sealed, which means a locked Avano cannot poll, cannot subscribe, and cannot learn that mail exists. That is the defence that makes a seized phone worth so little, and it is the reason the app behaves this way.

Why not just add push?

Because of what it would cost, and what it would actually buy.

• 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. It is also subpoenable, from a company that is not us.
• 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. Even if a push arrived, a locked Avano could not act on it — 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”. That is what we would be paying a permanent metadata leak for.

If notifications ever exist here, they will be designed to that constraint rather than around it. Until then this page, and the app itself, say plainly that there are none.

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 would have to be padded like everything else — and what it buys is a thumbnail.

So we do not build previews. What we build instead is 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. It is strictly better for you than a picture.

We want to be blunt rather than gentle here, because people discover this at the worst 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 that would be 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. That is the whole design.

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:

• 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 — which is exactly the linkage the current design spends its effort preventing.
• Keeping two devices in step is itself a new signal. Sync traffic is bidirectional and follows your activity by construction.
• Keys multiply. 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.