Knowledge base Privacy
Encryption
Your questions and its answers are end-to-end encrypted, with a post-quantum layer over the classical one. This page is about what that actually protects.
End-to-end by default
There is no setting to turn on. Every message in every conversation is encrypted on your device before it goes anywhere, and decrypted on the other end. The relays that carry it cannot read it, and neither can anything in between.
"The other end" here is the Nymbot service, which has to read your question in order to answer it. End-to-end means nobody else can — it does not and cannot mean the assistant answers something it never saw. Anonymous mode is the answer to the different question of whether it should know who asked.
Gift wraps
Messages travel as Nostr gift wraps. Each one is three layers:
- a rumor — the message itself, unsigned, so it can never be proved to a third party;
- a seal, signed by you and encrypted to the recipient, which is how the recipient knows who sent it;
- a wrap, encrypted and signed by a single-use throwaway key, which is all a relay ever sees.
So a relay holding your traffic sees an event from a key that exists only for that message, with a random timestamp — it can tell a message is for Nymbot, not who sent it. Metadata analysis over the wraps gets very little.
A copy of each message is also wrapped to your own key, which is how your history restores on a new device from the relays rather than from any server-side transcript.
Post-quantum hybrid
The classical layer is elliptic-curve. A large enough quantum computer breaks that retroactively — traffic captured today, decrypted years later. So the encryption is hybrid: an ML-KEM key encapsulation is combined with the classical exchange, and an attacker has to break both to read anything.
ML-KEM is the NIST-standardized lattice KEM. Combining rather than replacing is deliberate: if the lattice assumption turns out to be wrong, you still have the elliptic curve, and the other way round.
Nymbot publishes a signed capability announcement carrying its KEM key, so your app can seal to it without a lookup race that would quietly leave a message classical-only. Your app publishes one too, which is how replies come back hybrid.
What the server sees
Being precise about this matters more than being reassuring about it.
| Thing | Normally | In anonymous mode |
|---|---|---|
| Your message text | Read, to answer it | Read, to answer it |
| Which key asked | Your nym's public key | A throwaway key |
| Which key is charged | Your nym | The throwaway key |
| A usage record of each reply | Time, model, token counts and cost, never the text, kept for 90 days under your nym | Same, under the throwaway key |
| Your conversation title | Only encrypted to your own key, for sync | Same |
| Your private key | Never leaves the device | Never leaves the device |
| Your repository and connector tokens | Passed with the requests that use them, never stored readable; stored sealed with a server key only while a background run that uses them is working (at most 6 hours); synced only inside your sealed settings | Passed with each request, never stored. A forge token names your forge account, so using a repository in an anonymous chat lets the server tie that chat to it |
| Pictures you attach | Uploaded to a public media host, signed by a throwaway key made for that picture | Same |
| Code you run on a server | The code and any files you chose, run in a container destroyed afterward | Same, paid by the throwaway key |
| Background runs (opt-in) | Only if you turn them on: the saved state of a paused task and the settings its next step needs, including repository and connector tokens, sealed with a key only the server holds while the task carries on without your app, and deleted when it ends and always within 6 hours. The server publishes each step's reply to relays, encrypted to you, and keeps it for 24 hours after the task's 6-hour window so your devices can collect it | Not available; the app never asks for one |
| Scheduled prompts (opt-in) | Only for a schedule you set to run on the server: its prompt, title, repeat, target chat, model, credit limits and where to send the notification, sealed with a key only the server holds, which can read the prompt when it runs it. Deleted when you delete the schedule, turn the option off, clear your history or wipe the app, and at the latest when its permission ends after 90 days. “Notify me instead of running” keeps only the due time and where to send the notification | Not available: a schedule that answers in an anonymous chat runs only on your device, and a server schedule never runs in an anonymous chat's thread |
| A push registration for reply notifications (opt-in) | Your device's push token or your browser's push subscription, with an opaque chat id, kept until that reply is finished | None: anonymous chats never register for push, so you are notified only while the app is open |
| Memory | The entries relevant to a message travel inside it | Never sent, and nothing is proposed from the chat |
| Your IP address | Seen by the worker; relays see the worker, not you, whenever it can be reached | Same — use Tor or a VPN if that matters |
Conversation titles are generated on your device, never by the model, and only cross the wire encrypted to your own key, so your other devices can show them.