Security architecture
The server is a mailbox, not a memory reader.
Docmancer encrypts canonical memory revisions on the client and gives the service only enough information to authenticate, order, deliver, retain, and bill for ciphertext. We describe the metadata that remains visible instead of claiming the service knows nothing.
01
Client-side cryptography
- XChaCha20-Poly1305 IETF authenticated encryption
- Ed25519 device signatures
- X25519 sealed boxes for per-device workspace-key wrapping
- HKDF-SHA256 and workspace-scoped HMAC opaque references
02
What leaves your machine
| Data | Server view |
|---|---|
| Memory text, tags, graph data, project identity | Encrypted ciphertext only |
| Local record and revision IDs | Workspace-scoped opaque references |
| Local paths and private keys | Never sent |
| Account, device, timing, size, cursor, membership, billing | Visible operational metadata |
03
Account access is not decryption
Supabase account sessions authorize workspace and device operations. A connected device or the offline recovery kit is still required to unwrap memory. A new machine normally uses a four-word code approved by a connected machine, while recovery is the fallback when none remains. Device revocation is a separate auditable operation, and workspace key rotation is not currently available, so revocation is the supported way to remove a machine’s access. Personal and Team memory do not yet use separate encryption domains, which is one of the reasons Team Sync is not available.
04
Assurance and disclosure
Cross-language test vectors, real database no-plaintext tests, tenant isolation tests, dependency updates, CodeQL, SBOM generation, strict browser policy, and redacted logs are part of CI. The cryptographic design has not yet received the independent external review required for a production assurance claim. See the security disclosure policy.