End-to-End Encryption
Dialogue uses end-to-end encryption (E2EE) so that your notes and transcripts remain private. The sync server is zero-knowledge — it stores only opaque encrypted blobs and cannot read your data.
Key Hierarchy
Dialogue uses a two-level key hierarchy:
Master Key
The master key protects all of your per-document keys. It operates in one of two modes:
- Local-only mode (default, no account): A random 256-bit key generated on first launch and stored in your macOS Keychain. Device-bound — no password needed.
- Password-derived mode (after sign-in): Derived from your password via PBKDF2-SHA256 with 600,000 iterations and a unique salt. Reproducible on any device you sign into.
When you enable sync, the vault seamlessly upgrades from local-only to password-derived. When you disable sync, a new local-only key is generated. In both cases, all per-document keys are preserved with zero data loss.
Per-Document Keys
Every note and transcript gets its own random 256-bit symmetric key, generated on your device when the document is created. These keys are stored in an encrypted key vault that is itself protected by the master key.
Encryption Algorithm
All data is encrypted with ChaCha20-Poly1305, an authenticated encryption algorithm that provides both confidentiality and integrity:
- ChaCha20 is the stream cipher (256-bit key, 96-bit nonce)
- Poly1305 is the message authentication code
- Every encryption operation uses a unique random nonce
- Tampering with encrypted data is detected and rejected
What Gets Encrypted
| Data | Encrypted? | Details |
|---|---|---|
| Notes (content, title, metadata) | Yes | Per-document key, ChaCha20-Poly1305 |
| Meeting transcripts | Yes | Per-document key, ChaCha20-Poly1305 |
| Audio recordings | Yes | Per-blob AES-256-GCM key, uploaded via presigned S3 URLs |
| Key vault | Yes | Encrypted under master key |
| Workspace index | Yes | Per-document key, ChaCha20-Poly1305 |
Wire Format
Encrypted data is transmitted over WebSocket using a binary frame format:
[4-byte doc_id length] [doc_id bytes] [encrypted payload]The encrypted payload contains a random nonce followed by the ChaCha20-Poly1305 ciphertext and authentication tag.
What the Server Sees
The sync server receives and stores:
- Document IDs (opaque strings like
users/{id}/notes/{name}) - Encrypted binary blobs
- Connection metadata (timestamps, message sizes)
It cannot see:
- Note content or titles
- Transcript text or speaker labels
- Audio recordings
- Any document metadata beyond the ID
Cross-Device Key Sync
When you sign in on a new device:
- Your password + salt derive the same master key (PBKDF2-SHA256)
- The encrypted key vault is downloaded from the sync server
- The vault is decrypted locally to recover all per-document keys
- All your documents are available on the new device
The password never leaves your device. The server only stores the encrypted vault blob.
Collaboration Layer
When a document is shared for real-time collaboration, the collaboration server (Y-Sweet) can see document content during the active session. This is a fundamental requirement for live CRDT merging.
This tradeoff is scoped:
- Only documents you explicitly share enter the collaboration layer
- Persistent storage always goes through the E2EE sync layer
- Unshared documents never touch the collaboration server