Privacy, Encryption, And Erasure
Chatto is designed so operators can run and repair a server without automatically gaining access to member conversations. The system separates operational metadata from message content, encrypts sensitive durable data at rest, and supports account deletion through crypto-shredding.
Operator Privacy Boundary
Section titled “Operator Privacy Boundary”Admins and owners can operate the server. They cannot use the admin UI to read arbitrary conversation content.
| Operators can see | Operators cannot see through admin tools |
|---|---|
| Members, roles, room names, room counts | Message bodies |
| Verified email status and account metadata, when permissioned | Direct-message contents |
| Storage, stream, projection, and system diagnostics | File contents |
| Event-log diagnostics and safe request metadata | Passwords, raw tokens, raw auth codes, or raw reset links |
This is an intentional boundary. A future content moderation feature would need its own explicit permission and audit model.
Encrypted Durable Data
Section titled “Encrypted Durable Data”Chatto encrypts message bodies and durable user PII before writing them to durable storage. Message bodies use purpose-scoped per-user data-encryption key epochs and authenticated encryption. Durable user events encrypt login, display name, and verified email fields separately from message bodies.
The built-in KMS stores key-encryption-key records in the ENCRYPTION_KEYS bucket. App-owned wrapped data-encryption-key records live in RUNTIME_STATE.
Operationally, this means:
- copying only the JetStream data files is not enough to decrypt message bodies
- key material must be backed up intentionally
- key loss can make otherwise intact data unreadable
- account deletion can make remaining ciphertext permanently unreadable
Account Deletion And Crypto-Shredding
Section titled “Account Deletion And Crypto-Shredding”When a user deletes their account, or an operator deletes it through an authorized workflow, Chatto removes user-facing account state and shreds the user’s content-key references. Remaining encrypted message bodies and durable PII for that user become unreadable.
Deletion also removes related runtime state such as active credentials and push subscriptions. The visible timeline can keep durable public facts, but deleted-user content is no longer readable.
Backups And Key Material
Section titled “Backups And Key Material”Backups are the place where privacy and disaster recovery meet. Decide up front whether your backup archive should include encryption keys.
| Backup shape | Use when |
|---|---|
Encrypted backup with --include-keys | You run a small self-hosted server and want the simplest reliable restore. |
| Data backup plus separate key export | You want to store data and key material separately for stronger blast-radius control. |
| Data backup without keys | You intentionally want an archive that cannot decrypt message bodies or durable PII by itself. |
Old backups can reintroduce data that was deleted after the backup was taken if the old backup also includes the keys needed to decrypt it. Set retention on local backup files, remote object-store backups, and storage-provider snapshots.
Operational Rules
Section titled “Operational Rules”- Protect
chatto.toml,[core].secret_key, cookie secrets, and encryption-key exports. - Use encrypted backups for off-server storage.
- Test restores before you rely on a backup policy.
- Keep key export and data backup retention aligned with your deletion policy.
- Do not expose the operator socket to untrusted containers or users.
- Avoid logging raw login names, emails, identifiers, tokens, or full URLs in external automation.