End-to-end encrypted sync

DeepJournal uses selective field-level end-to-end encryption (E2EE) to protect configured sensitive fields before they are synchronized. It is not full-row or full-metadata E2EE: the service can still see operational metadata it needs to synchronize, route, and maintain records.

This protection is separate from local encryption, which protects the journal database stored on your device.

Encryption password and key hierarchy

DeepJournal uses a separate encryption password that is distinct from the account authentication password.

• Argon2id derives a key-encryption key (KEK) from the encryption password and a random salt.
• A random 256-bit data-encryption key (DEK) encrypts configured sensitive fields and derives the local database key.
• XChaCha20-Poly1305 wraps the DEK and encrypts configured synced fields.
• Supabase stores the wrapped DEK and salt, never the plaintext DEK.

Logging in to an account does not, by itself, decrypt a journal.

What is end-to-end encrypted during sync

The current field-encryption layer protects these fields before upload:

• journal entry content
• thread names and summaries
• moment names, summaries, descriptions, and importance
• chat names
• chat message content and citations

The list is maintained in the desktop application's services/crypto/constants.ts.

What the sync server can still see

Operational metadata and some tables remain plaintext so the service can synchronize, route, and maintain records. Examples include:

• record and user identifiers
• entry dates, update dates, deletion dates, and word counts
• thread and moment types and dates
• relationship and pinned-item records
• settings
• analysis status and errors
• chat roles and selected model names
• wrapped key material

The server can therefore observe some record structure and usage patterns even though configured sensitive content fields are ciphertext.

Recovery phrase

DeepJournal can generate a 24-word BIP39 recovery phrase. The phrase's entropy wraps the same DEK used by the journal.

• The phrase is shown to the user and is not stored in plaintext by DeepJournal.
• The service stores only recovery_wrapped_dek.
• A recovery phrase can reset the encryption password without changing the underlying DEK.

If both the encryption password and recovery phrase are lost, encrypted content cannot be recovered.

Security boundary

End-to-end encrypted sync protects configured sensitive fields stored by the synchronization service and keeps the plaintext DEK out of remote storage and the React renderer. It does not hide all metadata, protect an already unlocked compromised device, or provide a separate encryption key for every record or device.