What the server refuses to do

From the API contract, verbatim. The server must refuse to:

• Accept or return any plaintext secret, master password, or derived key.
• Decrypt, search, or index payload contents.
• Hand a user another user’s wrapped key or private key blob.
• Log bodies containing any ciphertext field.
• Accept key material on invite-accept for an email that already has an account.

Why these are structural

The first two are not enforced by a check somewhere in a request handler. The server does not contain the code that would perform them. It depends on the wire-format crate only, never on the crypto crate where every decryption path lives, and a continuous-integration rule fails the build if that dependency edge is added — including transitively.

So “the server cannot decrypt your secrets” is a statement about what is linked into the binary, not about what its authors intend. Adding server-side decryption is not a small change someone could slip in under deadline pressure; it requires adding a dependency that CI is specifically watching for.

The server validates shape, never content. Every secret-bearing field is opaque base64: it can check that a field is well-formed base64 of a plausible length, and that is the end of its understanding.

What it does do

Authentication, syncing ciphertext, membership and grant state, invitations, the audit log, and rate limiting. It is a dumb pipe and a store, deliberately.

It also cannot verify the one thing you might most want it to. When a member grants another member access, what gets stored is a key wrapped to the recipient’s public key — and the server has no way to check that the blob really wraps the right key to the right person, because checking would require reading it.

That gap is not an oversight; it is the direct consequence of invariant 1. It is exactly why the fingerprint ceremony exists and is mandatory, and why it has to be done by two humans over a channel the server does not control.

What it necessarily sees

Refusing to read your values does not make the server blind. It sees account emails, project and environment names and their ordering, payload sizes, version counts, and access timing.

Content is opaque. Existence and activity are not. See telemetry and privacy for the full list, and the threat model for why encrypting names was considered and rejected for now.