CONTRA

🤖 This project — code and documentation — was written by an LLM (Claude), on the ideas, instruction, and editing of humans, per factor X.

A password manager where the server knows nothing about you.

Not "we promise not to look." Not "we encrypt at rest." The server that holds your vault cannot open it, cannot tell you apart from anyone else, and does not know your email address. If it is stolen tomorrow, the thief gets a pile of ciphertext and the times of day you connected.

CONTRA is a CARLOS app, built to the strictest class the family publishes — A1, host-blind: keys live on your devices, the instance never holds one that opens your content, and nothing derived from your content is stored in the clear. Item names, URLs, usernames, folder structure and vault names are sealed exactly like the passwords are, because a name is a secret too.

Honest trade-offs — read before trusting it

This is the part most password managers put in a support article. It goes here instead.

• Lose your kit and your passphrase and your data is gone. That is the product, not a gap in it. There is no reset link, no support override, no "verify your identity and we'll restore it," because a server that could give your vault back is a server that could give it to someone else. Every password manager that can email you a way back in has, by definition, a way in. We don't, and we are not going to apologise for the consequence.
• The clearest way to think about it: the kit is your vault. The passphrase is just the convenient way in. On a device you already use, the passphrase is all you need. But a brand-new device asks for your Account Key — so if you lost the kit and every device you had, remembering the passphrase will not be enough. Same rule, and it surprises people, which is why we are saying it here rather than in a support article.
• So do two things, and we will keep asking until you have. Keep the kit somewhere real, and set up a second device. Either one alone rescues the other. If you lose the kit while a device is still signed in, reprint it that day — it works right up until your last device is gone.
• Why we ask you to keep paper at all. We could have let a passphrase alone open your vault from anywhere. Then the encrypted copy of your data would only ever be as strong as the phrase you chose, and most chosen phrases fall to a patient machine. The Account Key means that whatever you pick, the stored copy cannot be broken into. We would rather ask you to keep a piece of paper than quietly cap how safe your vault can be.
• Removing someone from a shared vault does not un-give what they already have. Their access dies immediately and the vault's key rotates forward, so they see nothing new. What they already downloaded is already theirs. Nobody's design changes that; ours says so.
• The server still learns transport shape — that someone connected, roughly when, and roughly how big the reply was. That is the residue A1 permits, and we are not going to pretend it is zero.
• Passkeys stored in 1Password cannot be exported. Not by us, not by any tool — 1Password does not let them out. Everything else in your vault comes across; those need to be re-created by hand, and we will show you which ones.
• A web browser trusts the server to send it honest code. This one is subtle and most of our competitors do not say it. When you use the web console, the server hands your browser the JavaScript that handles your passphrase — so a server that has been actively taken over could send code that steals it as you type. Our at-rest promise ("steal the database and get nothing") holds absolutely. The stronger promise — "compromise the running server and still get nothing" — is only fully true for the signed native apps, where the code is not fetched from us each time. We serve the console from a separate, static, signed origin to narrow this as far as a browser allows, and we would rather tell you than let you assume.
• The server can see who shares a vault with whom. Not what is in it, not its name, not a single value — but the wrapped keys that let your colleague open a shared vault are visible as a shape, so the server learns that two accounts share something. Personal vaults reveal nothing. We could hide this and have chosen not to spend the complexity yet; it is listed here rather than left for someone to discover.
• It is early. What is built and what is not is in PLAN.md, with triggers for each deferral rather than vague intentions.

Leaving 1Password

CONTRA imports 1Password's .1pux export — items, types, TOTP seeds, attachments and vault structure. The file never reaches our server: it is opened, parsed and sealed in your browser, and only ciphertext is uploaded. Bitwarden and Apple Passwords importers are wanted and not built yet.

How you get in

• A passphrase signs you in to the web console.
• An Emergency Kit — printed once at signup, generated in your browser and never sent to us. It is two documents, on purpose: - an Account Key card — a new device asks for this once. Store it somewhere safe: a drawer, a wallet, the folder your documents live in. Somewhere you can find it and nobody else goes. On its own it opens nothing, because without your passphrase it is useless. - a Recovery sheet — the way back if you forget your passphrase. Store this one securely, and it is the stricter of the two: keep it where you'd keep a passport or a will, and never photograph it. This sheet alone can open your vault, and nobody can reissue it.
• On a device you have already set up, the passphrase alone is enough. Setting up a new one takes the Account Key — scan it from the kit, or let a device you already use hand it over.
• A passkey on a device you trust is a fast unlock on top — a convenience, never the only door. The passphrase is offered beside it on every screen, because passkey ceremonies fail in ways that are not the user's fault.

Your email address is stored only as a blind index — a keyed hash. There is no address column in the database. It proves you are you, and it can never decrypt anything.

Agents

CONTRA can be driven by an AI agent, deliberately and narrowly. An agent can list what is in a vault (names, sites, usernames), use a secret without ever receiving it — the local daemon does the authenticated thing on the agent's behalf — and add new secrets, which needs no unlock at all. An agent cannot read a value into its own context. There is no setting that turns that on.

Status

Pre-alpha. Nothing to sign up for yet.

Licence

Mozilla Public License 2.0 — see LICENSE.

MPL's file-level copyleft is the right fit for a security product: anyone who ships a modified CONTRA has to publish the modified files, so the thing you are running can always be checked against the thing we published. That is the same argument as the rest of this README — you should not have to take our word for it. Factor VI, and it is not deferred.