Self-discovery, self-love, personal growth.
← All posts
·3 min read

KindMind Is Moving to Zero-Knowledge Encryption

In February 2026, we announced a rebuild around zero-knowledge storage. The central change was straightforward to describe, even though implementing it touched the whole application: journal entries would be encrypted on your device before being stored, with a content key the server could not unlock.

Updated September 13, 2026: the new KindMind is at www.kindmind.com. Classic readers can use the migration flow. This post describes the storage decision; the separate AI privacy page explains the processing that happens when you use hosted AI.

Before and after the rebuild

On the original platform, the application encrypted entries with server-managed keys. That protected stored data while leaving the application able to decrypt it. In the new design, encryption and decryption of journal content happen on your device.

How a journal entry reaches storage

Classic

  1. Device sends entry over HTTPS
  2. Application encrypts with a server-managed key
  3. Database stores encrypted content

New KindMind

  1. Device encrypts with your content key
  2. Device sends ciphertext over HTTPS
  3. Database stores content it has no key to unlock

The diagram concerns journal storage. It does not describe every account record, an unlocked device, or the separate AI request path.

Why the key matters

The new system uses a content key to encrypt entries and a password-derived key to wrap that content key. The server stores the wrapped key and encrypted content, not a key it can use to open the writing.

That limits what a database copy reveals about the entries. It also means support cannot open an encrypted entry to inspect its wording, or simply recover the content after all usable access to its key has been lost.

For a fuller explanation, read what zero-knowledge encryption means for a journal app.

Account recovery is not the same as data recovery

A password reset may restore the ability to sign in without restoring access to older encrypted content. Keep the recovery key given to you during setup. It is a way to recover access to the content key if you forget your password.

A successful recovery process is not proof that a provider can read stored content; designs can use user-held recovery material. What matters is who can obtain the key, not whether a reset button exists.

Moving from classic

Because the storage design changed, moving existing entries requires decrypting the old content and encrypting it for the new system. The migration flow guides that process, with encryption on your device before imported writing is stored in the new database.

For account or subscription questions, use the support details in the classic-user update. Current migration guidance takes precedence over the earlier wait-for-an-announcement instructions and open-ended availability promises.

The rebuild changes the storage boundary. Choosing to use AI still adds a separate processing decision, and both should be clear before you entrust the app with private writing.