Knowledge base / Privacy

Anonymous mode

Encryption was never the gap. Attribution was. Anonymous mode makes the server able to charge a message without being able to learn whose credits it is charging.

The gap it closes

The chat is end-to-end encrypted, but the service still knows which public key is talking to it. The seal inside each gift wrap is signed by your identity key; your credit row, your conversation thread and the turn de-duplication all hang off that key; and the archived copy of each reply is addressed to it.

So anyone holding the bot's private key could enumerate who used the paid chat, and anyone with the database could do it without the key. Nothing there is a decryption failure. It is simply that your name is on the bill.

The throwaway key

The Anon chip, or ?anon, generates a keypair on your device and moves the whole conversation onto it. From then on the rumor, the seal and the request signature are all that key — your identity key signs nothing in this conversation at all.

A conversation stays under the key it started with. In the web app, the chip shows whether the chat on screen is anonymous; turning it on in an empty chat makes that chat anonymous, and turning it on in a chat that already has messages opens a new anonymous chat instead.

Replies stay hybrid post-quantum: the throwaway key carries its own KEM key, derived from a root generated independently of the signing key, so publishing one does not weaken the other.

While it is on, read receipts, typing indicators, reactions and edits to Nymbot are held back. Each of those would otherwise carry your real signature into the same conversation and undo the whole thing. If your app cannot honor that — a locked vault, state not yet restored — it refuses to send rather than quietly falling back to your identity key.

The throwaway key is stored under identity encryption and syncs to your other devices, so the conversation and its balance follow you. Rotating it keeps the previous keys around for a while so their history stays readable and their balance stays sweepable.

Blind credit vouchers

Simply transferring credits to the throwaway key would hand the server the link the mode exists to break. So credits move as blind vouchers, in the Chaumian style a Cashu mint uses.

1. Your app picks a random secret and blinds it with a random factor.
2. Authenticated as your nym, it asks the server to sign the blinded value. The server debits your balance and signs something it cannot read.
3. Each signature comes with a proof that the published signing key was the one used. Your app verifies it, and refuses the whole move if it does not check out — an unprovable signature is a tagging vector, not a cosmetic problem.
4. Your app unblinds. The result is a valid token that looks like nothing the server has seen.
5. Later, authenticated as the throwaway key, it presents the token. The server verifies it, checks it has not been spent, and credits the key — with nothing to match it against.

The tables record that a voucher was issued and that a voucher was spent. Neither records who. That link is what the blinding destroys, and storing it would put it straight back.

The keyset is published, and your app pins it and warns you if it changes — a per-user keyset is exactly how a mint would tag its users. You can also skip the move entirely and buy credits straight onto the throwaway key with ?buy.

What it does not hide

Being honest about the edges is the only way the rest of it is worth anything.

• One connection publishes both identities' events. The app reaches relays through the worker, so the relays see the worker's address rather than yours — but the worker sees the connection, and if it cannot be reached the app connects to the relays itself. If that is in your threat model, use Tor or a VPN.
• Rotating the key and carrying the balance over shows the server one anonymous key paying another.
• A conversation is a conversation. Every message under one throwaway key is linked to the others by construction — the assistant needs the thread as context.
• What you write can identify you. No amount of key hygiene helps if the question names your employer.
• ?gift and ?transfer stay on your real nym: a gift is made from its balance and a redeemed gift lands on it, never on the throwaway key.
• A repository token names its account. A repository you use in an anonymous chat sends its access token with each request, as in any chat, and it is never stored — but the forge, and Nymbot while it holds the request, can tell which account that token belongs to.

Some features would otherwise tie the throwaway key back to your nym, so an anonymous chat goes without them:

• Push notifications for anonymous chats are off. You are notified while the app is open; nothing registers a push token or subscription for the chat.
• Server schedules and background runs are not available. A scheduled prompt that answers in an anonymous chat runs only on your device.
• Saved memories are not sent, and nothing is proposed for memory from an anonymous chat.
• Your Settings defaults stay home. The request carries only the chat's own permissions, and a request limit only when you choose Start anyway for that message.
• Each key asks for itself. Checks for replies, Nymbot branch cleanup and the list of running requests go one key per request, spaced by a random wait, and an anonymous chat's runs are only asked about while that chat is open.