What 1-z-2 keeps
Your address and routes stay. What you send does not.
1-z-2 is a post office, not a filing cabinet. Its long-term job is remembering your address, your contacts, examples of what your apps can exchange, and the routes built between different app formats. Those last as long as your account does—they are what let you throw an app away and connect a new one.
The useful things you send are not part of that long-term job. An item exists to be delivered; 1-z-2 holds it while it is on its way, and starts a deletion countdown the moment it arrives. This page lists exactly what is kept and what is deleted. It describes what the software actually does, and it changes only when the software does.
keptKept while your account exists
- Your handle and public key. Your secret key is created on your device and never leaves it — the relay only ever has the public half.
- Your contacts, and the status of each connection.
- Your apps' data shapes — the examples your apps publish of what they send and receive.
- The translations built between your shapes and your contacts'.
- Message status records — sent, delivered, failed — so your history still makes sense after the contents are gone.
- The waitlist, if you joined it: exactly what you typed in the one field, and when — nothing else. Kept until your invite goes out, or until you ask to come off it.
- Your plan, if you subscribe: which plan, its status, and Stripe's reference numbers for your subscription — that's all. Your card never touches the relay; Stripe holds it. Deleted with your account (Stripe keeps the invoices the law makes a business keep).
deletedDeleted automatically
- Message contents. Held while waiting to be delivered, permanently deleted 10 days after delivery — or failure.
- Originals of translated messages. You can compare what was sent with what arrived, but only inside that same 10-day window.
- Public message pages (
/m/…) expire on the same clock as the message they show. - Error text that could quote a message is cleared on the same schedule.
Deletion is code, not a policy document
An automatic cleanup runs every hour, and once at startup so a restart catches
up. It is not a script someone remembers to run, and not a promise waiting on a
support ticket. The database is set to overwrite deleted data
(secure_delete), so deleted messages don't linger invisibly inside
the database file either.
The 10-day window exists for one reason: it gives your app time to go back and check the original version of a translated message if something looks off. After that, the words are gone.
One honest footnote: the relay keeps encrypted off-site backups so your identity and contacts survive a disaster, and a message inside its 10-day window is in those backups too. Backup copies are kept for 7 days, so deletion reaches the backups within a week of reaching the database.
Undelivered mail is on the same clock: like a post office holding a parcel, the relay keeps a message for ten days waiting for its recipient, and then deletes the contents rather than keep them around indefinitely. So "never store" here means: never store longer than ten days, delivered or not.
Routes are built from examples, not private messages
Working out how to adapt between two app formats starts with the example data apps deliberately publish, never real private messages passing through.
Building a route only needs to see how your data is organised, not the substance. If you'd rather not publish examples that resemble real data, publish made-up ones—the route follows the format, not the private contents.
What the relay can see today
Plainly: there is no end-to-end encryption yet. Messages travel over an encrypted connection, but while a message is inside its 10-day window, the relay software can read it — a postcard inside the post office, not a sealed envelope. Until that changes, the guarantee is time, not blindness: nothing readable outlives its window. Send accordingly.
End-to-end encryption is on the roadmap. When it ships, messages will be sealed before they reach the relay — at that point it cannot read even the messages passing through.
The gate and the bounds
Nothing arrives without an accepted contact request — a stranger cannot put a message in your inbox.
Messages are structured data only (JSON), with a size limit: no files, no images, no attachments. If it can't be a shape, it can't be a message.
If we ever keep more
A long-term history archive may exist someday — as an opt-in, off-by-default, paid feature: you can pay us to also keep your words. Retention defaults will not silently flip. A change to this page is a change to the software.
1-z-2 is early and invite-only. A formal privacy policy and terms of service are in progress; until they exist, this page is the authoritative description of data handling, kept in lockstep with the code that enforces it. Questions? You were invited by someone — the chain from them to the operator is short. For the claims this page rests on — and how to check each one against the running system — see Trust, verified.