Privacy Policy

mosskeys is a managed, post-quantum key directory built on append-only transparency logs. This policy explains what data we collect, how it is protected, who processes it on our behalf, and the controls you have over it. It applies to the mosskeys website, developer APIs, and account tools.

Two facts shape everything below, and they pull in different directions, so we state both plainly:

• Your secrets stay with you. Private key material is generated and encrypted client side in your browser (WebAssembly). Our servers never receive your private keys or any sealed body.
• Your published entries are public. A transparency log is append-only and public by design. The labels and committed leaf bytes you publish become permanent, tamper-evident artifacts that anyone can read and verify.

mosskeys is built so that secrets never leave your infrastructure. If the work can happen on your device, it does: keys are generated and encrypted client side, and only already-public material or data you signed locally first crosses the wire.

• We never see your private keys. They are sealed in the browser before anything is stored, and the sealed blobs are opaque to us.
• We never sign on your behalf. Checkpoint signing is Bring-Your-Own-Key and happens entirely on your side; our server only verifies a signed note and that it commits to the log's current head.
• Your exports keep the same guarantee. Settings offers two downloads: an encrypted backup of public fields and opaque, client-sealed blobs, and a readable archive that is decrypted and assembled in your browser, never on our servers.

This is the most important expectation to set. When you publish to a namespace, you are writing to a public, append-only transparency log.

• Labels are public. The label you choose for an entry (for example an email address, a user id, or an agent name) is resolvable through the public read API by anyone who knows or guesses it. Do not use a label you need to keep private.
• Committed leaf bytes are public. The public key material you publish, the tree size and root, and the checkpoint notes are all served publicly so anyone can verify them.
• Entries are permanent. An append-only log cannot rewrite or delete history without breaking the very guarantee it exists to provide. Published entries stay in the log (see Data retention below).

• Account email. Stored encrypted at rest (AES-256-GCM), with a keyed blind index so we can find your account at sign-in without keeping a readable list of addresses. This is not zero-knowledge: our servers can read your email, which is how we send you sign-in links, confirmations, and security notices, and contact you about your account.
• Authentication data. We support passwordless magic-link sign-in, passkeys (WebAuthn), and optional TOTP two-factor. We store the data needed to verify these, not your underlying secrets.
• Billing metadata. Paid plans run through Stripe. We store subscription and entitlement metadata and a Stripe customer id so we can resolve your tier. We do not store card numbers; card data is handled by Stripe.
• Namespaces and log data. The namespaces you create and the entries and checkpoints you publish. Public fields are public; private key halves are stored only as opaque, client-sealed blobs.
• Operational logs. Standard request and error logs for security, abuse prevention, and capacity monitoring. These are not used to profile you.

We use a small set of trusted providers to run the service. Each processes only the data it needs for its function.

• Fly.io: application hosting.
• Fly Managed Postgres: the primary database.
• Stripe: billing and payments.
• Mailgun: transactional email delivery.

You can access and remove your account data directly from your account settings.

• Export and portability. Request a downloadable archive from Settings. Pick an encrypted backup of opaque, client-sealed blobs, or a readable archive that is decrypted and assembled in your browser, on your device only.
• Account deletion. Request deletion from your settings. Deletion runs on a grace window and lets you choose a disposition for each namespace you own (seal, delete, or transfer to a steward).

Note that because transparency logs are public and append-only, entries already published cannot be retracted from the log's history. Deletion and disposition control the namespace and your account, not the immutable fact of past public entries.

• Append-only log entries and checkpoints are permanent by design for as long as the namespace exists.
• Generated export archives are retained for 7 days, then pruned.
• Ephemeral operational tables (for example rate-limit counters and expired sessions) are pruned on a regular schedule.

Everything that can happen on your device does happen there: key generation, sealing, recovery, checkpoint signing, and readable exports all run in your browser, and our servers only ever store opaque ciphertext for them. Two things fall outside that, by design: published log entries are public and permanent, and your account email is encrypted at rest but readable by our servers so we can send you mail. Checkpoints are signed by you, on your device (BYOK); our servers never sign. On paid tiers, mosskeys can relay each checkpoint to independent C2SP witnesses and merge their cosignatures, and checkpoint notes are dual-signed (hybrid post-quantum plus classical Ed25519) so stock witness software can cosign them. This deployment has no witnesses configured yet, so no checkpoint carries a cosignature today. We will update this policy if that changes.

We may update this policy as mosskeys evolves. Material changes will be reflected in the effective date at the top of this page, and where appropriate we will notify account holders by email.