Zero-knowledge security — how it really works.

1

You create your account.

When you register, your password never leaves your browser in plaintext. Instead:

• We use the OPAQUE PAKE protocol so our servers never see your plaintext password
• After successful registration or login, OPAQUE gives your browser a secret export key we never receive
• A random 32-byte “data key” is generated on your device
• This data key is encrypted locally with a wrapping key derived from that OPAQUE export key
• The encrypted data key is stored on our servers — but we can’t decrypt it without the client-side unlock material
• You can download a one-time backup key. It wraps the same data key in your browser, and we store only an encrypted recovery wrapper

Key point: the unlock key and data key are handled in your browser. We store only encrypted wrappers, never plaintext passwords or workspace keys.

2

You create a project or task.

Readable workspace content is encrypted on your device; operational metadata remains server-visible:

• Project titles and descriptions
• Task titles, bodies, checklists, and comments
• Recurring-task template content is encrypted; cron schedule, timezone, active state, iteration, and materialization timestamps remain server-visible
• Everything is encrypted using ChaCha20-Poly1305 AEAD (a modern, audited cipher)
• Each project has its own unique encryption key derived from your data key

The server stores encrypted workspace payloads plus the disclosed operational metadata; it cannot read the encrypted plaintext without client-held keys.

3

You invite team members.

When sharing projects with teammates:

• Each member gets their own encrypted copy of the project key
• Keys are exchanged using HPKE (Hybrid Public Key Encryption)
• Invitation public keys are recorded in a Merkle transparency log. A retained trusted checkpoint can surface a mismatch during verification, but the current client does not remain fail-closed or preserve that detection: it may discard the checkpoint and retry from genesis
• Removing a collaborator revokes their server-authorized access to the project. Using access review to remove them from every manageable project applies that same server-side revocation to each project. On the server that commits the change, active real-time streams are signaled after the commit; changes committed on another server and bulk or otherwise unsignaled changes are rechecked within the current authorization lease, at most 30 seconds. Bytes already delivered or buffered by the transport cannot be recalled. The current release does not automatically rotate any affected project key or re-encrypt projects for remaining members, and removal cannot erase content or key material obtained while the collaborator was authorized. If future sensitive work needs a fresh cryptographic boundary, create a new project and share it only with current members.

4

The server checks HMAC consistency without decrypting the payload.

Database session and active membership state authorize access. Separately, the browser derives a list-scoped payload-binding key from the list key with HKDF and a fixed protocol constant; the same binding key is copied into each membership and stored by the server.

The server uses that key to verify an HMAC over the ciphertext. This proves only that the supplied HMAC matches those ciphertext bytes, without decrypting them.

• Your browser derives the list-scoped binding key from the list key with HKDF; it is not a workspace-content decryption key
• The server checks the authenticated session and active membership before authorizing the request
• The server stores the copied binding key and can verify or compute matching HMACs over ciphertext
• The HMAC does not establish freshness, prevent replay, bind an entity or member, or authenticate the payload against the server