The status page we'd want to read.

A real user of the pre-release Android build gets these now. iOS gets none of them yet.

• Identity with no accountA key derived on the device from a recovery phrase. No phone number, no email, no name, no accounts table anywhere.
• Pairing by one-time linkA single-use invitation, spent on use. There is no QR scanning — no camera permission is requested and no scanner exists.
• Post-quantum message encryptionUnmodified libsignal, with a quantum-resistant key exchange at setup and continuous quantum-resistant material mixed into every message thereafter.
• Messaging over embedded TorReal messages ride an in-process Tor client to an onion-only relay, so the relay never learns your address. Verified by running it, against a relay a plain socket cannot resolve.
• Sealed transport channelA hybrid classical-plus-quantum-resistant channel inside the circuit seals the queue codes and routing details, not only the message body — because Tor's own circuit encryption is classical.
• Blind queues, fixed-size blocksEvery envelope is one 4096-byte sealed block under a random code, with no sender field in the protocol. One size class only, deliberately.
• Sealed at rest, with a passphrase lockEach stored item is encrypted; identifying fields are blind-indexed; the app can be locked behind a memory-hard passphrase bound to a hardware-held key, and locks itself on leaving the foreground.
• Cover traffic, on by defaultA constant-rate lane so an observer cannot read how much you send. Free for everyone at the same rate. Costs about 750 MB per month; switchable off.
• Files and photos in one-to-one chatsChosen from your library — there is no in-app camera. Split into identical padded pieces under random names; location and camera tags stripped before sending.
• Small private groupsText only. Sealed separately per member, with the group identifier inside the envelope rather than on the wire.
• Disappearing messagesSwept from both ends. Off unless you turn it on, and one setting for every conversation — a per-chat timer does not exist, so a timer set from inside a chat applies everywhere.
• Spread inbound collectionYour addresses are collected over eight separate connections, each on its own randomised schedule, so a relay cannot read your whole contact set off one socket.
• Link cleaningTracking parameters stripped, lookalike addresses and unencrypted links flagged. No preview is ever fetched.
• Erase everythingDestroys the identity, the messages, the contacts and the platform key they are bound to. Read the honest limits on what deletion does and does not reach.
• One live relayReachable only as an onion service, holding sealed blocks in memory, writing nothing to a disk. Verified over Tor.

The code exists and is tested. Nothing calls it, or nothing is deployed for it to work against. Listed separately because a defence nobody invokes protects nobody, and calling these "features" would be the exact mistake this project keeps catching in itself.

• The two-relay direction splitWritten and wired so that no single relay sees both ends of a conversation. A second relay is deployed, run by a different company on a different network in a different country — and the app does not yet dial it, so today both directions land on the same host. Separate connections and separate circuits, same operator.
• Rotating per-contact addressesEach address is designed to rotate on a schedule so no single code stays correlatable. Implemented and tested in the engine; no app code calls it, so in practice your addresses are stable.
• Censorship bridgesobfs4 and Snowflake transports are built from pinned source, bundled, and proven to thread all the way into the Tor client. What has never happened is a connection through a live bridge on a real censored network. Until it has, we will not tell anyone in Iran or China that this works.
• The transparency logAn append-only log with inclusion proofs and signed checkpoints, implemented and tested. Zero releases have ever been appended and no log is published. This is the single most important switched-off item on this page.
• Release build signingThe build now refuses to produce a release without a signing key, instead of silently emitting an unsigned one. There is still no key, so nothing has been signed with one. A gate with nothing behind it stops the hole widening; it does not close it.
• Split backup across relaysA design that would spread a backup across several independent relays so no single one holds anything useful. Not finished, not exposed in the app, and gated on relay diversity we do not have.
• Duress passphrase and wipe-after-NBoth exist and both are weaker than they should be — each depends on a side file that can be deleted to disable it, and the decoy is distinguishable by its timestamps. We describe these as unfinished rather than as protections.

Active work, with an outcome we can describe but not date.

• A real release signing keyThe single widest hole in the product and the cheapest to close. Key custody belongs to the founder; no tool here generates, stores or commits one, deliberately.
• Publishing a signed manifest and a log entry for one releaseThe cryptography is done. What is missing is the act, and a static published file is enough to make it real.
• The iOS appThe engine is cross-platform and the native app is being built. It has compiled and run; it does not yet carry the messaging flow. We do not describe iOS behaviour as working until it is.
• Turning on the second relayMaking the deployed second relay the one the app actually splits across. This is what converts the entire diversity design from zero to a property.
• Message searchAs a linear decrypt-and-match that keeps nothing, never as a plaintext index. Why →
• Anonymous billing primitivesSo that if a paid tier ever exists, a payment cannot be linked to a user. Never on the message path; messaging works whether or not any of it exists.

Directions we intend. Not capabilities, and not dated.

• Publishing the sourceLicensed AGPL-3.0-or-later already. Publishing it turns several rows of what you can check yourself from no into yes.
• An independent external auditOf our own additions, which is where every distinctive claim lives. We have never had one. Open source and a published threat model do not replace it and we will not imply they do.
• A reproducible build of the whole applicationOne component reproduces bit-for-bit on one machine. The full application has not been attempted and nobody outside this project has reproduced anything.
• A verifier that runs outside the appAn app cannot honestly attest to itself — a malicious build prints the honest answer. The deliverable is a separate tool we cannot influence.
• Independent witnesses on the logOther parties countersigning our checkpoints. Without them, a log is a database with extra steps.
• A signed relay directorySo that a substituted relay at our address is detectable rather than invisible.
• Stronger network anonymityA mixnet backend for the adversary who can watch the whole network. Researched and prototyped against; not shipped, and cover traffic does not substitute for it.
• Group fan-out defencesSpreading and delaying a group send so that membership does not accumulate at a relay over time. Only part of this exists.
• Closing the at-rest gapsThe three places a seized device still yields your contact list. Named here →
• A linked reader, not a second phoneIf multi-device lands, it lands in the form that does not defeat the lock.
• Off-grid bearersCarrying Avano over local mesh, and later satellite, for when the network is cut. A direction, not a plan.