The messenger is the first product. This is what it runs on.
An app that keeps no account needs infrastructure that keeps as little: relays that hold numbered slots and nothing else, a directory that is signed rather than trusted, discovery that never sees a list, and a way for a second operator, or a company, to run a relay of its own. Every piece below is marked live (serving today), built (in the source, tested, not yet deployed or not yet switched on) or designed (written down, argued, not built). The limits page holds the same discipline for the app.
Two machines serve today. Neither writes a message to a disk.
A message relay holds queues named by sixteen random bytes, each a shelf of sealed blocks, in memory only. It is reached as a Tor onion service, so it never sees where a phone is. It learns that a block of a fixed size arrived in a slot and that a block left, and the time of each; it cannot open a block, and it does not know which two slots belong to one conversation. The architecture page explains why a RAM image captures the present and a disk image captures the past.
A second, separate machine carries calls. It is the only Avano host that sees a real network address, because a voice call cannot survive Tor's latency, and the features page says so beside the call button rather than leaving it in a footnote.
What the message relay runs today is an older build than the source. The newer verbs on this page, where they are marked built, are in the source and tested against a relay built from the same tree on a rented machine; they reach the live relay when it is redeployed, which is one person's decision and one morning's work with a rollback drilled.
One, in a German data centre, onion-only, memory-only. Serves every conversation today.
One, in Finland. Sees both callers' addresses for the length of a call, and the site says so.
Metering, the clear-network listener and the newer verbs below reach the live relay with it.
The list of relays is signed by three keys, and the phone accepts two.
Which relays exist is not something the app should take from a server's word. The relay directory is a signed record: three keys, held by three parties, and a phone accepts a change only when two of them signed it. One of those keys is ours. One will be a second operator's. A change we make alone does not reach any phone.
The directory is what makes two legs possible: your inbox on one relay, your contact's on another, so that no single machine sees both directions of a conversation. The client's half of this is built: it chooses a relay for each new contact's inbox, opens a connection to it on its own circuit, and follows that placement for every poll and acknowledgement. It is dormant until a signed directory verifies on the phone, and until then every conversation rides the one relay, as it always has. The banner you see when you pair says which it is, honestly, every time.
The format, the signing tool, the verifier in the app. The founder's keys exist; no record has been published yet.
Chooses, opens and follows a second relay per contact. Dormant until a directory verifies.
Says one relay or two. Today it always says one.
An email, a phone number or a username can find you. We still keep no list.
Avano has no accounts, and the people who want to be found by an email address or a number should not have to give that up. So discovery is a separate service with two halves. A verifier confirms that a handle is yours by sending a code to it and keeping nothing but a short-lived proof; a directory answers lookups that are blinded on the phone, so it learns neither who asked nor what for. Someone who holds your email can find your address; someone who holds the directory cannot read the list, because there is none to read.
The same service carries a backup card: an encrypted copy of your contact list, filed under a handle and a passphrase, so that "log in with email" means a recoverable address book, not a password on a server. Registration, lookup and the card are built and tested against a daemon built from the same source; the daemon has not been deployed, and the three deployments it needs (a host, an outbound mail route for the code, a clear listener on the relay) are listed on the limits page as what waits.
Email, phone and username handles; blinded lookups; the backup card. In the source, tested end to end in process; on 21 October it ran as a process on a rented box against two headless clients, which registered an email, found and asked, answered by name, and wrote each other; the same day against two Android phones on that box, driven from their screens, which did the same and found the phone drawing a lookup packet's queue as a conversation, fixed on both platforms. That evening the backup card ran on the same two phones: one backed up by email, a fresh install on the other took the lock passphrase, the code and the backup passphrase on its own screens and came back with the same address, contact list and message history, and the contact consented to the new device; reading the road first found that a fresh phone had no store for it to ask, fixed on both platforms before the run.
Not yet. Until it is, the app's Simple posture behaves as its Strict one.
Your contacts are blinded on the phone and matched privately; the page receives the matches and nothing of the rest.
A channel has readers, and the relay does not know who they are.
A channel is a feed one person posts to and many read. On the relay it is a queue like any other: posts arrive as sealed blocks, readers fetch them, and the relay holds no roster, because a channel's readers are not a list on any machine. The link to a channel is shared like a pairing link; following one costs the reader nothing and tells the relay nothing about them. Posting is paid in the same anonymous tokens as any deposit, so a relay cannot be flooded by a channel and cannot tell a channel's posts from anyone else's.
Communities are channels with rooms: the same machinery as groups, the same rule that the roster lives in members' phones. Both are built and were driven end to end with two headless clients against a metered relay, and channels on 21 October with two Android phones on a rented box against a metered relay, where the author's app was killed between her posts: the run found the phone presenting tokens it had already spent, and then a post's tokens being spent by the phone's own cover traffic while they aged; both fixed the same day. The community followed the same evening on the same box: a username taken on a phone, rules and rooms posted and pinned on the reader's screen, the reader asking a room's runner privately and joining the room, which is a group; and a capture of what the relay sees of two readers behind one address, the same frames on two connections. A relay's memory under readers was measured on 22 October with ten thousand of them asking for a post that does not exist every thirty seconds, the shape of a quiet channel: about three and a half kilobytes each, and a relay that serves four thousand and ninety-six connections at once and refuses the rest, which a reader holding its connection between polls would fill; so the reader lets go of it after each poll, and a quiet channel's readers cost a relay nothing between polls. They reach the live relay with the redeploy above.
Create, link, follow, post, read, delete a post, delete the channel. Both phones, and the headless client. A picture or a video in a post, stripped of its metadata and sealed as ordinary file pieces the post points at, paid with the post and deleted with it; fetchable for two weeks, the caption for the post's ninety days. A document cannot be posted, because nothing can strip what it says about who made it. Posted by the headless client and read on a phone on the rented box on 22 October: the bytes on the screen the stripped ones, the picture said gone after the author's delete.
Not until the redeploy: the relay serving today refuses the channel verbs.
The second relay should not be ours. The kit to run one is written.
Two legs on one company's machines divide nothing. The operator kit is how a second organisation, in a different jurisdiction, runs a relay from the source we publish, on machines only it can reach: the deploy recipe, the memory-only posture, what the relay must and must not log, the undertakings each side makes, and an outline of the agreement for counsel. It names what an operator sees, which is the same sentence as the first section of this page, and what it cannot be made to produce, because it does not hold it.
No second operator has signed. The kit exists so that when one does, the only new thing is their key in the directory.
Deploy recipe, posture, undertakings, the memorandum outline, the third key's custody rules.
A written specification of every construction, and since 20 October a set of known-answer vectors computed by the code that ships: the same words to the same keys and address, the same directory bytes, the same block opening, the same proof verifying. A second implementation checks itself against them before it talks to anything.
Every address and root of trust a build reaches for, in one file: the home relay, the directory's keys, the call relay, the discovery pair. The shells, the engine and the page read generated copies of it, and a guard refuses a value pinned anywhere else. A sovereign deployment, with its own relays and keys on its own hardware, is a second file and the same build.
None yet.
A company can run its own relay for its own people. It still cannot read them.
Teams is the operator kit sold to a company: a relay the company runs (or has run for it) that creates inboxes only for its own people, and a directory that registers work handles only for them. Who counts as its people is decided by a seat: a blind signature under the company's monthly key. The phone shows the seat to the relay once a month to mint a batch of anonymous tokens and spends one token per inbox, so the relay learns that a seat holder minted a batch and never which inbox is whose. The company's console mints one-time codes for its people and never sees a seat; the relay issues the seat from the code over its own channel, signing blind, and sees no serial either.
What this does not do is stated in the contract rather than discovered later: the company's relay sees its people's traffic timing, as any relay does; a seat that lapses stops new inboxes and new handles at the month's end and takes nothing that already exists; and nothing in Teams reads a message, names a room's members, or tells the company who writes to whom. The whole flow (console, gated relay, a refused stranger, two seat holders pairing, a code redeemed, a key rotation) runs as a scripted smoke on a rented machine with the headless client, and the Shield screen of the app has the seat sheet.
Inbox creation and work-handle registration reserved for seat holders; everything else untouched. Run end to end on two phones against a relay built from the source, over a plain connection rather than Tor.
Blind monthly credentials; a one-time code redeemed over the relay's channel; the console and the contract outline. On the same two phones: a code redeemed, a used code refused, a pasted seat, both inboxes bought after the token age clock, a message delivered.
Not yet: the price, the entity that invoices and the first customer are decisions, not code.
A relay with no accounts still has to say no to a flood.
Without accounts there is nobody to rate-limit. So the relay issues anonymous tokens: a phone solves a small proof of work, receives a blind signature it unblinds on its own, and spends one token per block deposited: a token buys exactly one block, so padding a deposit buys nothing. The relay can verify a token and refuse a replay; it cannot link a token to the phone that minted it or to any other token. A phone's stock of tokens survives a relaunch, so the clock a token must age is paid once per relay, not once per launch, which was measured on the headless client before it was fixed.
The live relay does not meter yet. The code that meters is what the channels, the backup card and Teams are priced on, and it is also the relay's defence against a flood, which it has run without.
Mint, age, spend, refuse a replay; the wallet kept sealed across launches.
A monthly credential of a level, shown once per batch, buys blind tokens on the same issuer a solved one comes from, bounded per credential per hour; the signed directory names the keys a relay honours. Every level is zero until the prices are decided, so a credential buys nothing today.
Off until the redeploy.
The relay keeps room for people to drain their inboxes when a flood fills its budget, sheds files and links before mail, and answers a line of counters on the box for the operator's monitor, and counts on it the connections it refused when full. A watcher script that alerts on that line exists; where it runs is a decision, not code.
A contact can be a program. The same engine runs without a screen.
The engine the two phones share can be driven from a command line with no page and no window: open an account, invite, accept, send, receive, follow a channel, take a seat. A bot is a contact whose other end is that program, and pairing already makes that possible without any directory. It is also how the infrastructure on this page is tested without a phone: two clients against a relay built from the same source, every verb over the real wire.
Over Tor or to a local relay; an echo bot and an external-command bot; a read of its own token wallet, one line per relay, so a refused post can be explained from the outside.
Prove your account to a site or an app: your phone signs a statement for that party alone, with the keys your words make, carrying the party's own challenge. The party checks it from the bytes with a small library and asks nobody. Nothing is sent by the phone and nothing is issued by us: there is no account to look up.
A program can send a card: a title, lines, fields and up to eight buttons. The app draws it from the text with its own code; no code of the sender's runs on the phone. A tap sends one ordinary message back, from you, or opens the same sheets a pasted link opens, which do nothing until you act. Mini-apps that run their own code are a separate decision, not built.
The account a store reviewer pairs with: a program on the same engine that answers every message with a fixed sentence. Ran on one phone against a relay built from the source over a plain connection: the phone paired by its link, wrote, and read the answer.
A window over the same engine exists in the source; whether to ship one is an open decision.
Every push is signed and recorded. The nightly builds what the record attests.
The source lives on a machine we rent, mirrored from the laptop it is written on. Every push carries a signed record in a chain, so a rewrite of history, or a push nobody signed, is visible to the verifier that walks the chain. A nightly on the same machine formats, lints, tests about two thousand four hundred tests, audits dependencies and builds the Android engine. Enforcement of the signed record by that nightly is one install away; until then the record is kept and checked by hand. Reproducible builds and the transparency log are on the proof page, which is the page that invites you to check.
Every push since 23 September carries a signed record; the verifier walks the chain.
Two nightlies, and what each proves. The one that compiles and tests moved on 23 October to the build box, a rented machine with the memory for it, after the relay box's run of 22 October thrashed for two hours in a check it could not hold (one core, two gigabytes, no swap, and swap on a relay is against the threat model); it tests the exact tree every signed push sends, and its first clean run passed every stage, 556 test suites. The relay box's own nightly, the one that refuses an unsigned tip, still awaits one install; its timer is off until then, with the reason written beside its status. On 21 October it had run again and was red on four stages (a test the hook never compiled, and seven dependency advisories from the dark fortnight), all fixed that morning. On 24 October it was red on two, for three advisories published the day before: two dependencies moved, the third found to be in the lock file and compiled by nothing, with the measurement written beside its exception. The same morning showed that the other lock files, those of the parts built outside the main workspace, had fallen behind with nothing to say so (the desktop client's carried five fixed TLS flaws), so the nightly now audits the three that are built; the fourth, a dormant helper nothing builds, is named with its reason in the nightly's script. It had aborted on a full disk for thirteen nights in October before anyone read it, and the aborts are written here because a nightly nobody reads is the same blindness as none.
The published recipe (a pinned image, the engine, both transports and the unsigned app) ran for the first time on 20 and 21 October, on a rented build box, through fifteen stops it records one by one. Two container builds of one commit gave an app that was byte-identical but for the signature block. Same machine both times; a second machine and a published app to compare against are still owed.
A page, check a download, runs the command-line verifier on an app, its signed manifest and the published key, in your browser: the same checks, the same words, compiled to a module that imports nothing, so nothing you give it can leave the page. The module is rebuilt every night and compared byte for byte with the one the site serves. It has nothing to check until the first release is signed.
If a row says built, ask when. If it says live, ask where.
The limits page lists what runs today on each phone; the refusals page lists what we decided not to build and why; the company page says who holds the keys. Nothing on this page is softer than what the source can honour, and the wiring guards that read this site fail if a withdrawn sentence comes back.