Skip to content

The encryption model

Every team brain is protected by a per-vault encryption key that's created on your device and wrapped separately for each member — so only invited people can read your notes.

Read this first: a team vault encrypts note contents, not note names. Paths in the encrypted store are identical to the plaintext ones, so anyone who can read the shared sync folder still learns every filename, every folder name, the shape of the whole vault, and who is on the roster. What they cannot read is what any note says.

The two keys that matter

  • A per-vault data encryption key. Each team vault has one symmetric key that encrypts note contents. Notes are sealed with XChaCha20-Poly1305, an authenticated cipher with a 24-byte nonce, so anything tampered with in transit or at rest fails to open rather than opening silently.
  • A personal key pair per member. Every member has an X25519 key pair. The vault key is wrapped (encrypted) separately for each member using their public key, so each person unwraps it with their own private key — and no one else's.

Members never share a password, and there is no single shared secret held by a third party. Adding a member re-wraps the same vault key for them, so existing ciphertext stays valid. Removing a member is stronger: the vault key is rotated and the whole store re-encrypted under the new one.

What is protected, and what is not

  • Note contents — every byte of every note body.
  • Attachment contents.
  • The per-member wrapped copies of the vault key.

All of this is sealed on your device before anything is written to the shared folder.

The roster is not merely present — it is signed by the Owner's Ed25519 key, carries a monotonic version number with an anti-rollback floor, and is authenticated with a MAC keyed by the vault key. A member cannot quietly promote themselves, strip the signature, or replay an older roster in which someone revoked was still a member. The first roster a device sees for a vault is pinned locally (trust on first use) outside the vault, so a synced-in keyring can never arrive with a matching anchor of its own.

End-to-end, by construction

"End-to-end encrypted" means encryption and decryption happen on members' devices, and no key that can open your notes is ever handed to anything in between. When a teammate opens the team brain:

1

They unwrap the vault key

Their X25519 private key unwraps their personal copy of the per-vault key — locally, on their device.

2

They decrypt what they need

That key decrypts note contents as they browse — the plaintext exists only in the app on their machine, plus the working copy on their own disk.

3

They re-seal any changes

Edits are encrypted again before they are written into the shared folder, so only ciphertext travels.

Why per-member wrapping matters

Because every member holds their own wrapped key, access is something you can grant and take away cryptographically rather than by trusting a permission flag. Revoking a member rotates the vault key and re-encrypts the store, so their old copy of the key opens nothing that is written afterwards.

Revocation cuts off future access. It cannot un-see what a member already synced or read while they had the key — no encryption scheme can. Plan revocation as a boundary in time, not as an eraser.

Next

See how granting and removing that access works in practice → Invite & revoke members.