Zero-knowledge habit tracking. Your growth belongs to you.

@isaac_dominic1Great question — this is the tradeoff that comes with real zero-knowledge encryption. If you forget your password completely and haven't set up a recovery code, your encrypted data is unrecoverable. We can't decrypt it for you because we never had the ability to.

That said, we make it easy to protect yourself: during signup you can generate a recovery code in settings. If you ever forget your password, that recovery code lets you reset it and re-encrypt your data. We also encourage storing it somewhere safe like a password manager.

It's a similar model to Proton Mail — real privacy means only you hold the keys. 🔐

@daisy_morgan2 No noticeable performance hit. The heavy crypto (key derivation) only happens once at login. After that, decrypting each item uses NaCl/libsodium compiled to WebAssembly — each decrypt takes under a millisecond. Loading a page with dozens of items adds maybe 10-20ms of total decrypt time. Any performance hit you might notice is minimal and will be more noticeable due to general internet latency.

@bella_christine Great question, Bella! Family groups use the same zero-knowledge, end-to-end encryption as everything else in Metamorphic. Here's how it works:

1. Each group gets its own encryption key — when you create a family group, a random symmetric key (group_key) is generated entirely in your browser. The server never sees this key in plaintext.

2. Keys are distributed per-member using asymmetric encryption — the group key is encrypted individually for each member using their public key (box_seal). So each member gets their own sealed copy that only their private key can open. The server stores these encrypted blobs but can't read any of them.

3. Shared habits and goals are encrypted with the group key — when you create a shared habit or goal, the data (name, description, check-ins) is encrypted with the group key before it leaves your browser. Every group member can decrypt it because they each have their own sealed copy of the group key.

4. Member removal triggers key rotation — if someone leaves or is removed, a brand new group key is generated. All shared data is re-encrypted with the new key, and the new key is re-sealed to each remaining member. The removed member's copy of the old key can't decrypt anything going forward.

5. The server is zero-knowledge — it only ever stores encrypted blobs and blind indexes. Even a full database breach reveals nothing about your family's habits, goals, or progress. There's also a second layer of AES-256-GCM encryption at rest in the database (via Cloak).

In short: every member can see the shared group data, but the server (and anyone who isn't in the group) cannot. It's the same architecture used by apps like Proton Mail — just applied to habit tracking.

@yara_simone Yes — the client-side encryption is verifiable right now in your browser.

But, thank you for this question, because we just released a page explaining how our encryption works and how people can verify: https://metamorphic.app/encryption

All encryption and decryption happens in JavaScript that ships to your browser. You can open DevTools, inspect the source, and see exactly what's happening. The crypto code uses libsodium-wrappers-sumo (a well-audited, widely-used NaCl implementation) — not custom cryptography. You can verify:

• Network tab: No plaintext user data ever leaves the browser. You'll see only encrypted blobs in requests.

• Source tab: The crypto modules (key generation, encryption, decryption) are all in the client-side JS bundle.

• sessionStorage: Your derived keys live only in your browser session — the server never receives them.

We use standard, proven primitives: XSalsa20-Poly1305 for symmetric encryption, X25519 for key exchange, and Argon2id for key derivation. No homegrown crypto.

The codebase is private today, but we're considering publishing the crypto modules independently so anyone can audit the encryption layer without needing access to the full app source. A formal third-party security audit is also on our roadmap.

@sienna_claire Great question. It starts with my other app, Mosslet. I was becoming a new dad and had just finished reading The Age of Surveillance Capitalism by Shoshana Zuboff -- and I wanted a better world for my little one. At the time I went with a trust-the-server model for Mosslet (which is fine -- the code is open source and you can verify it). But when I read about Meta rolling back end-to-end encryption on its direct messaging, it pushed me to implement real E2EE in Mosslet's messaging, built on an asymmetric, password-derived key architecture.

As for Metamorphic’s features itself, I was inspired by my partner who is always thinking of ways to improve, figuring out how to break old habits and form better ones — she’s passionate about psychology and behavior. And then it just made sense to me that something so personal as your habits/goals should be private to only you — and you shouldn’t have to worry about it being otherwise.

@noah_bennett5 Thanks Noah — that's a really valid concern. Onboarding is something we've put a lot of thought into precisely because of this tension. The encryption setup happens transparently during sign-up — you create an account with email and password like any other app, and all the key generation happens automatically in the background. There's no key management, no seed phrases, nothing extra to configure.

The one intentional friction point is the recovery key — we prompt you to save it after sign-up in case you ever forget your password, since we can't reset it for you (by design). But day-to-day usage feels like any other habit tracker.

Would love to know how it went for you.

@violet_amelia Yes. I would say they are:

1. If you lose your password and don't have a recovery key, your data is gone. That's the real cost of zero-knowledge encryption -- we genuinely cannot reset your password or read your data on the server side. We mitigate this with a recovery key you can set up (like Proton or Signal), but it's on you to write it down and keep it safe.

2. No server-side search. Since the server only stores encrypted blobs, we can't search your habits or reflections server-side. Search and filtering happen client-side after decryption. For a habit tracker this is a non-issue (you're not searching thousands of records), but it's a fundamental constraint of the architecture.

3. Reminders are generic. Because habit names are end-to-end encrypted, our reminder emails and push notifications can't say "Time to meditate!" -- they say something like "You have a habit reminder." You'll know what it's for; we won't.

4. A little more responsibility than a typical app. Between the recovery key and the "Stay signed in" preference (which controls whether your decryption keys persist across browser restarts), there are one or two decisions a normal cloud app wouldn't ask you to make. We've tried to make the defaults sensible -- keys persist by default so it feels like a normal app, and recovery key setup is guided -- but it's still a bit more to think about than a zero-friction sign-up.

The short version: you get real privacy, but real privacy means we can't bail you out if you lose your credentials. We think that's a worthwhile trade for something so personal as your habits and goals.

@gaurav_singh91 Really appreciate this, Gaurav — I actually use almost that exact line on the site: "We can't read your data, even if we wanted to." Glad to hear it lands. Finding that balance between "this is serious cryptography" and "you don't need to care about any of that, it just works" is an ongoing process. To me, it just matters that people have another service out there they can trust.

Best of luck with ad-vertly, it looks really fascinating — solo founder life is a journey. Rooting for you too.

@sai_tharun_kakirala Thanks — that's a really thoughtful observation about the tension between AI usefulness and privacy, and I ran into that when designing Mosslet’s privacy-first AI features. You're right that they pull in opposite directions: AI needs context to be helpful, but context means data exposure. The fact that you're having those internal conversations about what stays ephemeral vs. what gets stored is exactly the right instinct. Most teams don't even ask the question. I’d also look into Confer and Proton Mail’s Lumo if you haven’t already.

To answer your question: your encryption keys aren't at risk from losing local access. Your private keys are stored on our server — encrypted with a session key that's derived from your password via Argon2id. The session key lives temporarily in your browser, but if your device dies or your session is wiped, you just log in again. Your password re-derives the session key, which unlocks your private keys from the server. Nothing critical is local-only but it is only able to be decrypted locally by you.

On top of that, we have a recovery key system for the "forgot my password" scenario. You can generate a human-readable recovery code in Settings that acts as a backup decryption path — it lets you re-derive your private keys and set a new password. The recovery key is shown once, never stored by us (only an Argon2 hash for verification), and consumed on use.

Without your password or recovery key, your data is permanently unrecoverable — by design. It's a real tradeoff: we give up "forgot password" email resets in exchange for genuine zero-knowledge. For us that's worth it, but it means we have to be clear with users about setting up their recovery key early.