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.

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

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

@platypus_cash Thank you — and congrats on your first 100% streak! That's the loop the whole product is built around. Also, it’s aimed at being simple and forgiving. You’ll notice confetti when you hit your first 7day streak, and the nudges when you are in a group with someone have a real positive surprise effect on the other person (at least in my experience).

On your three questions — happy to go deep, because these are exactly the calls every zero-knowledge builder has to make.

1. Is E2EE worth keeping in the core?

Yes — and I'd encourage you to hold the line on financial data especially. Financial behavior is one of the most sensitive datasets imo. If you've already done the architectural work to support it, that's compounding value you don't want to throw away. Every time you re-litigate the decision, you pay the migration tax twice (I’ve been there too). Build it in, document the tradeoffs honestly, and move on to features. The customers who care will be the ones worth keeping. Also, the more we build with zero-knowledge, privacy-first architectures in mind — the more we’ll start to innovate there too.

2. Worried about users losing their data because we can't recover it?

Yes, but it doesn’t keep me up at night, and I built around that constraint. A few things that I think help:

• Password reset flows preserve data. When users reset their password, their data stays accessible — we use password-derived keys with a recovery mechanism that doesn't give us access to the cleartext.

• Data export, always. Users can export everything at any time. The strongest user protection isn't us holding their data hostage — it's making sure they can walk out the door with it whenever they want.

• Human readable recovery keys so people can be proactive to have a second layer of protection against accidental data loss due to forgotten passwords. All while remaining zero-knowledge.

• Clear UX around the tradeoff. We're explicit during signup: this is zero-knowledge, which means you hold the key. The customers who choose us choose us partly because of that constraint, not despite it.

The worry never fully goes away, but I try to reframe it because what's the alternative? Being able to recover data because we hold the keys — that seems worse in terms of failure for the people who actually need privacy.

In your case, I would think failure is even higher-risk than a service like Metamorphic. Or take our other product, Mosslet (a social network), you could have journalists, abuse survivors, people with controlling family members, people in regulated industries.

The "we can recover anything" architecture is the architecture that gets subpoenaed, breached, or sold. Maybe you can protect it for a while, but it’s a hard thing to do the longer you stay in business. Being able to say, “Okay we got breached, but all they got was encrypted blobs that they can’t do anything with” — that seems better to me than “Okay — it happened to us too".

3. Feeling like the odd one out for not bolting on AI?

Sometimes it does seem like only AI-heavy products are getting attention. But, honestly? No. The opposite. And DuckDuckGo just saw huge adoption numbers after Google started force-feeding people AI, showing customers might still prefer choice and considerate design.

And in terms of privacy, AI-in-the-product almost always means "your data goes to a third-party model provider," which collapses zero-knowledge the moment you ship it. There are emerging patterns for on-device / WASM-resident inference that could preserve E2EE, and I'm watching that space — but I'm trying not to ship AI features that quietly undo all the wins for people from our privacy-first zk architecture — so I have to be slower perhaps than others in that space.

Although, I have started to use some WASM/on-device AI on Mosslet to get some of the automation benefits while preserving people’s privacy. I think that’s an area you may want to explore because there is some real value to the speed and automation you could achieve with AI models and financial data, you’d just want to ensure they’re running locally on the client-side with no exposure of people’s decrypted data.

I’ve heard people say the market will split to be either AI products or privacy products, but not both — I tend to push back a bit there. I think the more we develop privacy-first products then the more we will start to think about how we can make AI fit that model — and then we’ll have some real innovation. And hopefully also innovation around the production of AI (as it’s not a bright spot in my opinion).

Excited to follow your financial tracker — let me know when it's further along. The world needs more zero-knowledge product builders, not fewer. I’ve also recently open-sourced a lot of our tools to help others make zero-knowledge post-quantum architectures: metamorphic-crypto (Rust available on crates.io and packaged in WASM on npm) and metamorphic_crypto (server-side not ZK but helpful for anyone migrating) for the Elixir folks with a guide on how we did the zk architecture. My company, Moss Piglet, does consulting too if you’re ever inclined for my direct help/support.🦦

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