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.

@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.

@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.