DEV Community: Mark Thayer

Three Questions Every Zero-Knowledge Builder Gets Asked (And How I Answer Them)

Mark Thayer — Sun, 07 Jun 2026 02:14:59 +0000

Last week, a fellow builder working on a zero-knowledge financial tracker left a thoughtful comment on the Metamorphic Product Hunt page. He hit his first 100% streak, said he liked the product, and then — because he's deep in the same architectural decisions I've been living with — asked me three questions.

They're the same three questions I get asked everywhere: in DMs, in calls with potential customers, in conversations with other founders. So I'm pulling my reply out of the thread and putting it here, because if you're building anything zero-knowledge, you'll get asked all three eventually.

The questions:

Is end-to-end encryption worth keeping in the core, or should it be optional?
Aren't you worried about users losing their data, with no way for you to help?
Don't you feel like the odd one out for not bolting on AI?

Here was my reply:

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

Why this matters

The three questions above all share a shape. They're all variants of the same underlying anxiety: am I making the product harder, slower, or less competitive by holding the line on privacy?

My honest answer, after building two zero-knowledge products and shipping a post-quantum migration to production: no. The constraint makes the product better. It forces clearer UX. It forces honest tradeoffs. It attracts the customers who actually care, and those customers stay.

And to me, most importantly, it makes the product safer.

Software products (therefore developers) have become so integral to our modern life that it becomes borderline negligent to ship a service that isn’t built to protect its customers. It would be like a doctor or surgeon or nurse treating a patient with no regard for the harm their position makes possible.

Software is being used to decide whether your future self-driving car stops for a pedestrian or traffic light. It’s also being proposed to determine whether you should be arrested for a crime you didn’t commit. And currently being used to find, identify, and track you. These systems carry an immense amount of power and wield an immense potential to harm people — privacy and thoughtful, considerate design of software systems have never been more important.

The world doesn't need fewer zero-knowledge builders. It needs more of us — building in public, comparing notes, and refusing to treat privacy as a feature flag.

If any of this is useful in your own build, here are the tools we've open-sourced along the way:

metamorphic-crypto — our Rust encryption library, also packaged for WASM on npm. Hybrid ML-KEM-1024 + X25519 post-quantum KEM, XSalsa20-Poly1305, Argon2id. Dual MIT/Apache-2.0.
metamorphic_crypto — the Elixir NIF wrapper. Honest scoping: this is server-side, not zero-knowledge itself, but it's a useful drop-in enacl replacement for teams migrating toward a ZK architecture. There's a zero-knowledge guide in the repo.

If you want the deeper technical story of how we got Mosslet to post-quantum zero-knowledge in production, I wrote that up here earlier this week.

And if you'd ever like direct help thinking through a zero-knowledge architecture, my company Moss Piglet does consulting. 🦦

Building the World's First Post-Quantum Zero-Knowledge Social Network: A Phased Migration Story

Mark Thayer — Tue, 02 Jun 2026 17:53:38 +0000

There's a specific kind of claim I'm suspicious of when I read it about other products: "zero-knowledge encrypted." It can mean a lot of things — from "we ran AES on it before saving" to "the server architecturally cannot read user content." Most of the time, when you dig in, it lands somewhere in between.

This post is the inside view of moving Mosslet — an open-source social network built in Elixir/Phoenix — from the in-between version to the architectural version, with hybrid post-quantum encryption as part of the move. It's the version with the honest edges intact.

If you just want the result: as of June 2026, Mosslet is a fully zero-knowledge social network. All user-generated content paths use hybrid ML-KEM-1024 + X25519 sealing performed in the browser via WebAssembly. The Rust crypto core is open source. The migration shipped in four phases, audited four times, with Audit #4 confirming zero key-material leaks across 87 JS hooks, 121 push_event calls, and ~230 server-side decrypt call sites.

There’s still more work to be done, but we’ve reached a point where people on the network can post and share in a fully zero-knowledge, post-quantum encrypted architecture.

If you want the story, keep reading.

The starting position

Mosslet was already encrypted before any of this. Content was encrypted with NaCl secret-box keys, those keys were sealed for each recipient with crypto_box_seal, and the database stored ciphertext. That's better than most products.

But the encryption happened on the server, before the row hit the database. Plaintext touched Phoenix memory on every write and most reads.

That's a real property — a database breach exposes nothing legible. But it's not what most people mean when they say "zero-knowledge." It's also not post-quantum. A patient adversary could harvest sealed crypto_box_seal ciphertext today and decrypt it once a cryptographically relevant quantum computer exists. "Harvest now, decrypt later" is a real threat model for a product whose pitch is protecting an inner life — journals, conversations, group chats.

So I committed to two things:

Move all user-content encryption into the browser, before anything reaches the server.
Add hybrid post-quantum sealing (ML-KEM + X25519) so today's captured ciphertext doesn't become tomorrow's plaintext.

What I didn't appreciate at the start was how much of that work would be neither cryptography nor Elixir. It would be discipline about which bytes get to cross which boundaries.

One Rust crate, three targets

The first decision that paid for itself many times over: build the crypto as a Rust crate with three compile targets.

metamorphic-crypto (Rust crate, #![forbid(unsafe_code)])
├── Compiles to WASM   → browser (JS hooks encrypt/decrypt)
├── Compiles to NIF    → metamorphic_crypto Hex package (server-side)
└── Compiles to UniFFI → iOS/Android (future native apps)

Dual-licensed MIT/Apache-2.0, published as a Hex NIF wrapper that's a NaCl-compatible drop-in replacement for enacl. Same Rust code runs in the browser and on the server. Wire format is guaranteed compatible because it's literally the same function compiled to two targets.

That unlocked a property I'd undervalued: migration without data conversion. The browser can encrypt a thing, the server can decrypt that exact thing if it has to (e.g. for public/federated content), and the on-disk format is identical whether the encryption happened browser-side or server-side. The phased migration could move call sites one at a time without a "now we re-encrypt everything" step.

Phase 1: rip out libsodium

Unglamorous, but it set up everything that followed. Replace enacl (C NIF wrapper around libsodium) with metamorphic_crypto (the Rust NIF). Same NaCl wire format. No data touched. libsodium-dev came out of the Dockerfile.

# mix.exs
- {:enacl, "~> 1.2”},
+ {:metamorphic_crypto, "~> 0.2”},

The interesting thing about Phase 1 is what it enabled: every Encrypted.Utils.* call in the codebase was now funneled through one Rust crate I controlled. Adding post-quantum primitives no longer meant coordinating with someone else's release cycle.

Phase 2: hybrid PQ sealing, server-side

Phase 2 added ML-KEM-768 + X25519 hybrid sealing — still server-side, but now post-quantum. Two columns on the users table:

# priv/repo/migrations/20260514155214_add_pq_key_fields_to_users.exs
add :pq_public_key, :binary
add :encrypted_pq_private_key, :binary

The wire format carried a version tag so the unseal side could auto-detect which scheme to use:

v1 (legacy):  raw crypto_box_seal output — no prefix
v2 (Cat-3):   0x02 || ML-KEM-768  + X25519 ct || nonce || secretbox
v3 (Cat-5):   0x03 || ML-KEM-1024 + X25519 ct || nonce || secretbox

Existing ciphertext kept decrypting via the v1 path; new ciphertext used v2; the unseal function checked the first byte and dispatched. No flag day, no downtime.

Phase 3: move the crypto into the browser

This was the hard one.

Conceptually simple: compile metamorphic-crypto to WASM, vendor it under assets/vendor/, serve the .wasm binary from Phoenix static, and rewrite the LiveView hooks to encrypt before push_event.

In practice, this is where 90% of the actual work lived, because zero-knowledge isn't a property of any single function — it's a property of the entire data flow. Every place where the server reads a sealed key, decrypts content, and renders it to HTML is a place where ZK breaks.

Where the keys are born: registration

User keypairs are generated in the browser at signup, not on the server. The password-derived KEK wraps the private keys before they're sent up. The server never sees a plaintext private key — only sealed ones.

// assets/js/hooks/registration-hook.js (excerpt)
async generateZKMaterial(password) {
  // Hybrid PQ keypair (Cat-5: ML-KEM-1024 + X25519)
  const { publicKey, secretKey } = await pqGenerateKeypair();
  const { publicKey: classicPub, secretKey: classicSec } =
    await classicGenerateKeypair();

  // Per-user attributes key (symmetric, used to encrypt profile fields)
  const userAttributesKey = await randomSecretboxKey();

  // Derive KEK from password (Argon2id in WASM)
  const kek = await deriveKekFromPassword(password);

  // Wrap private material with the password-derived KEK
  const encryptedPqSecret = await secretboxSeal(secretKey, kek);
  const encryptedClassicSecret = await secretboxSeal(classicSec, kek);
  const encryptedUserAttributesKey = await secretboxSeal(userAttributesKey, kek);

  // Only these public bytes + sealed-with-KEK blobs go to the server
  this.pushEvent("save_zk_keys", {
    pq_public_key: b64(publicKey),
    encrypted_pq_private_key: b64(encryptedPqSecret),
    classic_public_key: b64(classicPub),
    encrypted_classic_private_key: b64(encryptedClassicSecret),
    encrypted_user_attributes_key: b64(encryptedUserAttributesKey),
  });
}

Full hook on GitHub Gist.

On the server side, the schema receives these as already-encrypted columns. The User schema uses Cloak.Ecto.Binary for an additional server-side at-rest layer over what the browser already did (defense in depth — even if a future bug ever wrote plaintext, it would still be encrypted at the database layer):

# lib/mosslet/accounts/user.ex (excerpt)
schema "users" do
  field :email, Encrypted.Binary, redact: true
  field :email_hash, Encrypted.HMAC, redact: true   # blind index for lookup
  field :username, Encrypted.Binary, redact: true
  field :username_hash, Encrypted.HMAC, redact: true

  field :password, :string, virtual: true, redact: true

  # Browser-generated, server-stored sealed material
  field :pq_public_key, :binary
  field :encrypted_pq_private_key, :binary
  field :key_pair, :map           # classic keypair, private portion sealed
  field :user_key, :binary        # sealed user_attributes_key

  # Virtual: populated by pre_decrypt_user/2 at LiveView mount, never persisted
  field :decrypted, :map, virtual: true
  ...
end

Two things worth pointing out here:

field :password, :string, virtual: true, redact: true — the password is virtual and redacted from logs. The server never persists it; only the password-derived KEK (computed browser-side) is ever derivable from it.
field :decrypted, :map, virtual: true — this is the pre_decrypt_user pattern. At LiveView mount, the server unseals the user's profile fields (which are server-encrypted with Cloak at rest), attaches them as a .decrypted map, and every template reads user.decrypted[:username] instead of decrypting on every render. Cut decrypt churn by an order of magnitude.

Full schema: GitHub Gist.

The write path: a two-phase commit

Saving a post is the most interesting write path. The form is bound to a normal Phoenix LiveView phx-submit=“save_post", but the hook intercepts the submit before it reaches Phoenix, runs the ZK flow, and ends up calling a different event entirely.

// assets/js/hooks/post-form-hook.js (excerpt)
this.el.addEventListener("submit", async (e) => {
  if (this.isPublicPost()) return; // public posts stay server-side (SEO, federation)
  e.preventDefault();

  const postKey = await randomSecretboxKey();
  const ciphertext = await secretboxSeal(body, postKey);
  const cwCiphertext = cw ? await secretboxSeal(cw, postKey) : null;

  // Phase 1: send the encrypted body — server replies with recipient pubkeys + metadata
  this.pushEvent("save_post_encrypted", {
    ciphertext: b64(ciphertext),
    content_warning_ciphertext: cwCiphertext && b64(cwCiphertext),
    visibility,
    shared_user_ids,
  });

  // Hold the post_key in memory; we'll need it again for Phase 2
  this._pendingPostKey = postKey;
});

// Phase 2: server pushes recipient list + display-name metadata back to us
this.handleEvent("encrypt_post_fields", async ({ recipients, metadata }) => {
  const postKey = this._pendingPostKey;

  // Seal post_key for each recipient with their (browser-fetched) hybrid PQ pubkey
  const sealed_keys = await Promise.all(
    recipients.map(async (r) => ({
      user_id: r.user_id,
      sealed_key: b64(await sealForUser(postKey, r.pq_public_key, r.classic_public_key)),
    }))
  );

  // Encrypt everything else (usernames-as-displayed, etc.) with post_key
  const encrypted_fields = await encryptMetadata(metadata, postKey);

  this.pushEvent("finalize_post_encrypted", { sealed_keys, encrypted_fields });
  this._pendingPostKey = null;
});

Full hook: GitHub Gist.

The phx-submit=“save_post" handler in the parent MossletWeb.PostLive.Index LiveView is the legacy / public-post fallback. Private posts never reach it — they're intercepted by the form hook and routed through save_post_encrypted / finalize_post_encrypted on the MossletWeb.PostLive.FormComponent LiveComponent instead. On the server side, those events accept pre-encrypted ciphertext through a changeset_zk/3 that skips all server-side encryption. The server stitches a post together out of parts it can't read.

The "graceful fallback" line is more important than it looks. If WASM hasn't loaded yet, or postKey derivation fails for any reason, the form falls through to the server-side path. The product never breaks. Over time, the server-side path runs less often, but it remains correct.

The read path: sealed key → WASM unseal → DOM

The read path is the mirror image. The server sends ciphertext + sealed post_key as data-* attributes on the post node. A LiveView hook (DecryptPost) unseals the key in WASM and writes the plaintext into the target DOM node.

// assets/js/hooks/decrypt-post.js (excerpt)
async mounted() {
  const sealedKey = this.el.dataset.sealedPostKey;
  const ciphertext = this.el.dataset.encryptedBody;
  if (!sealedKey || !ciphertext) return;

  // Use cached conn_key if we've unsealed this connection's keys before (LRU, max 50)
  const postKey = await unsealForUser(
    sealedKey,
    this._myClassicSecret,
    this._myPqSecret,
  );

  cachePostKey(this.el.dataset.postId, postKey); // cached for later fav/edit ops

  const plaintext = await secretboxOpen(ciphertext, postKey);
  this.target.innerHTML = renderMarkdown(plaintext); // markdown rendered browser-side
}

Full hook: GitHub Gist.

Two details worth flagging:

Markdown rendering happens browser-side. For private posts, the server never sees the rendered HTML — only the encrypted markdown source. (For public posts, markdown renders server-side, because federation and SEO need it. Different code path, same data flow direction.)
Cross-instance _connKeyCache LRU (max 50 entries). Once a connection's conn_key is unsealed, it's cached in a module-level Map keyed by connection_id. Subsequent posts from the same connection skip the unseal step. Bounded so an attacker who pops a single session can't pull every key the user has ever touched.

Two-phase commit for group creation

Groups are the hardest write path in any ZK social product. A group_key has to be sealed for every member without the server ever holding the raw key.

The browser handles it as a two-phase coordination:

Phase 1: browser generates group_key, encrypts name/description, seals the key for the creator, fetches each member's hybrid pubkeys.
Phase 2: browser seals group_key for every member, encrypts member metadata (display names, monikers, avatars), and pushes everything in a single create_group_zk call.

On the Elixir side, this is one function that accepts pre-sealed material — the two-phase complexity lives entirely in the browser:

# lib/mosslet/groups.ex (excerpt)
@doc """
Creates a group from browser-encrypted fields (ZK two-phase commit).

The browser generated the group_key, encrypted name/description, sealed the key
for the creator and all members, and encrypted member display names. The raw
group_key NEVER exists in server memory.
"""
def create_group_zk(zk_attrs, owner, users, sealed_members) do
  group_changeset = Group.create_changeset_zk(zk_attrs)
  owner_changeset = UserGroup.owner_changeset_zk(zk_attrs)

  sealed_by_user_id = Enum.into(sealed_members, %{}, &{&1["user_id"], &1})

  Ecto.Multi.new()
  |> Ecto.Multi.insert(:insert_group, group_changeset)
  |> Ecto.Multi.insert(:insert_user_group, fn %{insert_group: g} ->
    owner_changeset |> Ecto.Changeset.put_change(:group_id, g.id)
  end)
  |> Mosslet.Repo.transaction_on_primary()
  |> case do
    {:ok, %{insert_group: group}} ->
      for u <- users, sealed = sealed_by_user_id[u.id], sealed do
        UserGroup.member_changeset_zk(%{
          sealed_key: sealed["sealed_key"],
          encrypted_name: sealed["encrypted_name"],
          encrypted_moniker: sealed["encrypted_moniker"],
          encrypted_avatar_img: sealed["encrypted_avatar_img"]
        })
        |> Ecto.Changeset.put_change(:group_id, group.id)
        |> Ecto.Changeset.put_change(:user_id, u.id)
        |> then(&Mosslet.Repo.transaction_on_primary(fn -> Mosslet.Repo.insert(&1) end))
      end

      {:ok, adapter().get_group!(group.id)} |> broadcast(:group_created)

    error -> error
  end
end

Full module: GitHub Gist.

Phase 4: Cat-5 default

Phase 4 swapped the default from Cat-3 (ML-KEM-768) to Cat-5 (ML-KEM-1024). The version-tag design paid off again: existing v2 ciphertext kept decrypting via auto-detection, new operations sealed as v3, and a background worker progressively re-sealed users' context keys on login.

The re-seal worker is the part I'm most quietly proud of, because of what it isn’t:

# lib/mosslet/workers/pq_reseal_worker.ex (excerpt)
defmodule Mosslet.Workers.PqResealWorker do
  @moduledoc """
  Progressively re-seals a user's context keys to Cat-5 hybrid.
  Re-seals v1 legacy and v2 Cat-3 to v3 Cat-5.

  Runs as an in-memory background task via `Mosslet.BackgroundTask` so the
  session key never touches persistent storage (DB, logs, etc.). If the BEAM
  restarts mid-reseal, remaining keys are picked up on the next login —
  the version-tag check makes this idempotent.
  """

  @cat5_version_tag 0x03

  def run_async(user, session_key) do
    Mosslet.BackgroundTask.run(fn ->
      user = Accounts.get_user!(user.id)

      user
      |> list_context_keys_for_user()
      |> Enum.reject(&already_cat5?/1)
      |> Enum.each(fn sealed ->
        sealed
        |> unseal_with_session(session_key)
        |> reseal_as_cat5(user.pq_public_key, user.key_pair["public"])
        |> persist_resealed(sealed.id)
      end)
    end)
  end

  defp already_cat5?(%{sealed_key: <<@cat5_version_tag, _rest::binary>>}), do: true
  defp already_cat5?(_), do: false
end

The thing this isn't is an Oban worker. Oban persists job args to the database. The session key — the thing required to unseal v1/v2 ciphertext so it can be re-sealed as v3 — is exactly the bit of material that must never touch disk. So this runs as an in-memory Task via Mosslet.BackgroundTask.run/1, fire-and-forget on login.

The version-tag check (already_cat5?/1) makes the whole thing idempotent. A BEAM restart mid-reseal isn't a problem: next login enqueues another pass, and keys already at v3 are skipped on the first byte. No flag day, no stop-the-world, no risk of writing a session key to a job-args column.

Audit #4: the part where you check your work

Architecture claims are cheap. The fourth audit is the part that turns the claim into evidence.

Scope: every server-side decrypt call site (~230), all 87 JS hooks, all 121 push_event calls, every sessionStorage access, every data-* DOM attribute, and every .toLowerCase() call that crosses the server boundary (because lowercasing is how blind-index pre-images get built, and a stray one is how plaintext leaks).

Findings:

All 270 tests pass.

The remaining ~102 server-side decrypts

Here's the part most "we built a zero-knowledge X" posts skip. There are still ~102 server-side decrypt call sites. None of them are write paths. None of them are high-traffic read paths. They break down like this:

Each one is documented with its call site in docs/PQ_ENCRYPTION_MIGRATION.md. Some of them — the edit-form pre-fill in particular — are queued for a Phase 5 migration to client-side hooks. Some of them (federation, S3 URLs, SMTP) are architecturally required: if a feature is "show this to an unauthenticated viewer" or "hand this to a third-party protocol," there is no version of that feature that's also zero-knowledge. That's not a flaw to paper over. It's the trade-off being honest about itself.

One pattern worth naming explicitly, because a careful reader of the codebase will spot it: there is a server-side helper called pre_decrypt_post/3. It does not decrypt the post body. It decrypts post metadata (the owner's display name as it should appear to the current viewer, for instance) — fields that are server-encrypted at rest with Cloak. The body itself is handed to decrypt-post.js as opaque ciphertext and unsealed in WASM. Same name pattern, different layer.

What I'd tell someone starting this

A few things I'd save you if you were about to do this:

Build the crypto as one library with multiple targets, not two libraries that happen to agree. The single biggest source of bugs in cross-environment crypto is the wire format drifting between the browser and the server implementation. Compiling the same Rust to WASM and to a NIF made that class of bug impossible.

Version-tag your ciphertext from day one. A single leading byte (0x02, 0x03, …) lets you migrate forward forever without data conversion. The cost is one byte. The payoff is every future migration being a default-flip plus a background reseal instead of a downtime window.

Zero-knowledge is a property of the data flow, not of a function. Most of the work is not writing seal() and unseal(). It is auditing every data-* attribute, every push_event payload, every sessionStorage.setItem, every IO.inspect someone left in during debugging. The fourth audit was not redundant; it was the one that caught the last {:ok, _} = pattern that would have crashed loudly on a malformed ciphertext instead of falling back gracefully.

Plan the graceful fallback before you plan the happy path. WASM doesn't always load in time. Keys aren't always derived on first render. Caches get evicted. If your ZK path is the only path, your product breaks the first time the network hiccups. If your ZK path is the default path with a correct server-side fallback, you get to ship one call site at a time and let the server-side path quietly retire as the browser side proves itself.

Be honest about the edges. "World's first post-quantum zero-knowledge social network" is a defensible claim because every write path and every high-traffic read path is browser-encrypted. It would not be defensible if I tried to also claim the SEO crawler page or the ATProto export is zero-knowledge. Naming what's in scope and what isn't is what makes the in-scope part believable.

Where to look

Crypto core (Rust, MIT/Apache-2.0): github.com/moss-piglet/metamorphic-crypto
Elixir NIF wrapper: hex.pm/packages/metamorphic_crypto
Mosslet (AGPL-3.0): github.com/moss-piglet/MOSSLET
Full migration doc & remaining-decrypt inventory: docs/PQ_ENCRYPTION_MIGRATION.md
ZK architecture guide: docs/zero-knowledge-guide.md

Mosslet is live at mosslet.com. It's the first one. It probably won't be the last, and that's the point — the crypto core is open source specifically so it doesn't have to be.

What Post-Quantum Encryption Means for Your Data

Mark Thayer — Mon, 11 May 2026 14:23:08 +0000

Your encrypted data might already be compromised. You just don't know it yet.

The attack is called "harvest now, decrypt later." Intelligence agencies and well-funded attackers are collecting encrypted traffic today, banking on quantum computers being able to break it tomorrow. If your data is encrypted with classical algorithms alone — RSA, ECDH, X25519 — that bet might pay off.

This isn't theoretical. NIST spent eight years evaluating post-quantum algorithms and finalized its first standards in 2024. The message was clear: start migrating now, not when quantum computers arrive.

We took that seriously. Metamorphic is a zero-knowledge encrypted habit tracker, and the data it protects — sobriety counters, mental health habits, fitness patterns — is the kind of data that stays sensitive for a lifetime. So we built metamorphic-crypto, an open-source Rust encryption library with hybrid post-quantum encryption, and it's running in production today.

Why hybrid?

A hybrid key encapsulation mechanism (KEM) combines a classical algorithm with a post-quantum one. In our case: X25519 + ML-KEM-768.

The reasoning is simple. ML-KEM (formerly CRYSTALS-Kyber) is NIST's primary post-quantum KEM standard. It's well-studied and conservative. But post-quantum cryptography is young. If a flaw is found in ML-KEM, the classical X25519 layer still protects your data. If quantum computers break X25519, the ML-KEM layer still holds. You need to break both to compromise the encryption.

The combined shared secret feeds into the symmetric layer — XSalsa20-Poly1305 for authenticated encryption, with keys derived through Argon2id where passwords are involved.

Version-tagged ciphertext

Algorithms change. Migration is inevitable. So every ciphertext blob produced by metamorphic-crypto carries a version tag — a prefix byte that identifies the encryption scheme used.

Version 1 is classical-only (X25519 + XSalsa20-Poly1305). Version 2 is hybrid post-quantum (X25519 + ML-KEM-768 + XSalsa20-Poly1305). When we decrypt, we read the tag first and select the right path automatically.

This means we can migrate users progressively. When a user logs in, the client checks whether they have hybrid keys. If not, it generates a new ML-KEM-768 keypair, encrypts it with their session key, and sends the public key and encrypted private key to the server. Then it re-seals their existing data with the hybrid scheme. The server never sees any plaintext during this process — it just stores updated ciphertext blobs.

If we ever need a version 3, the same mechanism works. No flag days, no forced migrations, no downtime.

Why Rust, compiled to WASM

Metamorphic is a web app. The zero-knowledge architecture means all encryption and decryption happens client-side, in the browser. That means the crypto library needs to run in JavaScript's environment.

We originally used libsodium-wrappers-sumo (the JS build of libsodium). It worked, but it didn't support ML-KEM, and extending it would have meant wrapping C code in JavaScript bindings ourselves.

Rust gave us several things at once:

RustCrypto primitives — pure Rust implementations of X25519, XSalsa20-Poly1305, Argon2id, and ML-KEM-768. Well-audited, actively maintained, no C dependencies.
#![forbid(unsafe_code)] — the entire library is safe Rust, enforced at the compiler level.
wasm-pack compilation — one build step produces a WASM binary and JS bindings that run in any modern browser.
UniFFI targets — the same Rust core can compile to native iOS and Android libraries when we build native apps. One cryptographic implementation, every platform.

The WASM module loads asynchronously on first use. Every function calls ensureReady() before executing, so the rest of the application doesn't need to care about initialization timing. The public API is identical to the old libsodium wrapper — same function names, same base64 string inputs and outputs. We swapped the implementation without changing a single call site.

The three-layer model

In production, user data is protected by three independent layers:

Client-side zero-knowledge encryption — data is encrypted in the browser with the user's keys before it ever leaves the device. The server receives and stores only ciphertext. This uses the hybrid post-quantum scheme for users who've migrated and classical for those who haven't yet.
Server-side application encryption — the Ecto fields are wrapped in AES-256-GCM via Elixir’s Cloak libraries, keyed to a server-side secret. This protects data at rest against database compromise, even though the server can't read the inner plaintext layer.
Database-level encryption — our infrastructure provider uses LUKS to implement full-disk encryption on the database volume, providing a third and final layer of encryption at rest.

An attacker who compromises the database gets AES-256-GCM ciphertext. An attacker who compromises the database and the server's Cloak key gets zero-knowledge ciphertext. They still can't read it. They'd need the user's password-derived key, which never leaves the browser.

What's in the open-source library

metamorphic-crypto contains the full cryptographic core:

Hybrid KEM: X25519 + ML-KEM-768 key generation, seal, unseal
Classical KEM: X25519 sealed boxes (NaCl-compatible)
Symmetric encryption: XSalsa20-Poly1305 secret boxes
Key derivation: Argon2id with configurable parameters
Version-tagged ciphertext with automatic scheme detection
Recovery key generation and encryption
WASM build via wasm-pack, UniFFI scaffolding for future native targets

The library is MIT-licensed. If you're building something that needs post-quantum encryption in the browser, you can use it directly or use it as a reference for how to structure the hybrid KEM flow.

The trade-off

Zero-knowledge encryption with post-quantum protection means we can't offer server-side features that require reading your data. No AI that analyzes your journal entries. No recommendation engine based on your behavior. No aggregate analytics across users.

We think that's worth it. Your habits reveal who you were, who you are, and who you're trying to become. That data deserves encryption that will hold up not just today, but decades from now.

metamorphic.app · metamorphic-crypto on GitHub · Encryption deep-dive

The Science Behind Your Habits (And Why Most Trackers Ignore It)

Mark Thayer — Wed, 06 May 2026 13:10:31 +0000

Most habit trackers are built on vibes. Streaks. Green checkmarks. A dopamine hit when the number goes up. A guilt trip when it resets to zero.

It works — for about two weeks. Then you miss a day, the streak breaks, and the app that was supposed to help you change quietly becomes the thing you avoid opening.

We built Metamorphic differently. Not because we think streaks are bad, but because the behavioral science says there's a lot more going on — and almost none of it shows up in the apps people actually use.

Here's what the research says. And here's what we did about it.

Missed days don't destroy habits

This is the big one. The popular belief is that habits are fragile — miss a day and you're back to square one. The research says otherwise.

Lally et al. (2010) ran a study tracking how habits actually form in real life. The average time to automaticity was 66 days, not the 21-day myth that won't die. More importantly: missing a single day had no measurable effect on habit formation. The curve barely blinked.

Most habit trackers punish you for missing a day. Your streak resets. Your progress visualization drops. The implicit message is: you failed.

Metamorphic has streak forgiveness. A single missed day doesn't break your streak. Skip days are first-class — you set them when you create the habit, and they're respected, not penalized. Because the science says flexibility predicts long-term success better than rigidity does.

The strongest behavior change technique isn't tracking

If you had to pick one intervention — one single thing that moves the needle on whether someone follows through — it's implementation intentions. "When X happens, I will do Y."

Gollwitzer (1999) found an effect size of d=0.65. That's large. Larger than goal setting alone. Larger than motivation. Larger than tracking.

The reason is simple: decisions are expensive. Every time you have to decide when and where and how to do a habit, you're spending willpower. Implementation intentions pre-load the decision. You've already decided. The cue fires, the behavior follows.

Metamorphic has a first-class "When → Then" field on every goal. Not buried in a settings menu. Not a tooltip. It's right there when you create the goal, with a timed reminder attached. Because the most effective technique in behavior change deserves more than an afterthought.

We also built contextual cue prompts directly onto habits — an "After I…" field that links your habit to the thing you already do before it. After morning coffee → Meditate. After I sit down at my desk → Review my goals. Wood & Neal (2007) showed that contextual cues — preceding activities, locations — are stronger triggers than time-based reminders alone. Your life already has a rhythm. We want to hook into it, not override it.

Habits and goals are not the same thing

This sounds obvious. Most apps ignore it anyway.

A habit is something you do repeatedly. A goal is something you're working toward. The connection between them — how daily actions compound into outcomes — is where behavior change actually happens. And it's where most people get stuck.

Locke & Latham (2002) spent decades studying goal-setting. Their central finding: specific, challenging goals with clear feedback mechanisms outperform vague intentions by a wide margin. But the mechanism matters. You need the bridge between "I want to run a marathon" and "I ran 3 miles today."

Metamorphic lets you link habits directly to goals. Not as a tag. Not as a folder. As an explicit connection: this habit serves this goal. You can see how your daily actions feed into your larger aims. That bridge — from action to outcome — is the hardest thing to build into a product because it requires the system to understand that a check-in today is part of a trajectory that spans months.

Emotions aren't decoration

Most habit trackers either ignore mood entirely or give you a 3-point smiley face scale. Happy, neutral, sad. Done.

Barrett et al. (2001) found that emotion differentiation — the ability to make fine-grained distinctions between emotional states — is directly linked to better emotion regulation. People who can distinguish between "frustrated" and "anxious" and "overwhelmed" handle those states more effectively than people who lump them all into "bad."

Metamorphic has a 9-point mood scale and 46 distinct emotions. Not because complexity is a virtue, but because granularity is a skill. The act of choosing between "restless" and "anxious" is itself a form of self-awareness. The tracker becomes a mirror, not just a ledger.

Reflection without action is just venting

Pennebaker (1997) showed that expressive writing — writing about your emotional experiences — has measurable psychological and even physical health benefits. Journaling works. This is well-established.

What's less discussed is the gap between reflection and behavior change. You can journal every day and never change a thing. The insight stays on the page.

Kolb's Experiential Learning Cycle describes the loop: experience → reflection → conceptualization → action → experience. Most apps give you the reflection step and stop there.

Metamorphic has habits, goals, reflections, journal entries, and a daily schedule — and they're connected. A reflection can surface a pattern. A pattern can become a goal. A goal can spawn a habit. A habit gets a cue, a reminder, a link back to the goal it serves. The system is designed to close the loop, not just document it.

We're building this further. After you write a reflection, we'll gently ask: Want to carry something forward? You can create a habit, set an intention on a goal, or add something to tomorrow's priorities. Or dismiss it with a tap. The prompt only appears when the reflection suggests deeper processing — certain mood states, longer entries. It's never forced. Because autonomy matters more than engagement.

Gamification should celebrate, not control

There's a fine line between motivation and manipulation. Variable ratio reinforcement — unpredictable positive feedback — is the most psychologically engaging reward schedule (Schultz, 1997). It's also the mechanism behind slot machines.

Metamorphic has 18 tiered achievements across 6 categories. We use gamification deliberately. Celebrations are earned, not manufactured. They acknowledge what you've done without creating anxiety about what you haven't.

The design principle we follow: whispered, not shouted. A subtle glow, not a modal. A brief animation, not a notification. Confetti for genuine milestones, silence for ordinary check-ins. The app should feel like a quiet ally, not a needy coach.

Privacy isn't a feature. It's the foundation.

Becoming a parent inspired me to create Mosslet, our privacy-first space online for social and journaling, where people could be safe from the surveillance economy.

The first version of Mosslet was actually called Metamorphic, but when Facebook rebranded to Meta, I felt we needed to change and my partner came up with Mosslet from our public benefit company's name Moss Piglet. Later, when Meta announced removing E2E encryption from Instagram DMs, I was inspired to implement zero-knowledge messaging in Mosslet. This would become the inspiration for our zero-knowledge, quantum resistant, architecture on Metamorphic today.

With a privacy-first architecture in hand and the Metamorphic brand on the shelf, I was in need of a new idea. And that was when inspiration found me.

My partner is passionate about psychology, particularly behavioral science, and self-improvement. Observing her, I was struck with a thought: a habit tracker built around behavioral science could be helpful for people, even people like me who traditionally forgo any kind of habit tracking and forming. And a habit tracker is something that should be private.

And that was how Metamorphic transformed itself into a privacy-first app to help us transform ourselves.

Every mechanism I've described — mood tracking, emotion differentiation, honest reflection, habit-goal linking, streak forgiveness — depends on one thing: honesty. The data is only useful if it's true. And the data is only true if you feel safe entering it.

Your habits reveal what you're trying to change about yourself. Your mood logs reveal your emotional patterns. Your reflections reveal your inner life. Your goals reveal your vulnerabilities. This is some of the most intimate data a person can generate.

Most habit trackers can read all of it. The company, its employees, its partners, its acquirers, and — depending on jurisdiction — law enforcement. Your behavioral data sits on their servers, readable, queryable, sellable.

Metamorphic uses zero-knowledge encryption. Your data is encrypted on your device before it ever reaches our servers. We can't read it. Not because we promise not to — because we're technically unable to. The architecture doesn't allow it.

We also use post-quantum encryption — designed to resist not just today's threats but the quantum computing attacks that researchers expect within the next decade. Your habits from 2026 should still be private in 2036.

This isn't a premium feature. It's not an add-on. It's how the entire system works, free tier included. Because the behavioral science is clear: self-tracking only works when it's honest, and honesty requires safety.

We built what the research said to build

We didn't want Metamorphic to be another app where marketing picked the features and science got a footnote. We wanted it to actually work — to do what the literature says matters, not what looks good in a screenshot.

Habit strength indicators. Lally's research shows habit formation follows a curve — rapid gains early, plateau around 66 days. Every habit shows a strength percentage on your dashboard. Not just "14-day streak" but "78% formed." Realistic expectations based on actual science instead of arbitrary streak counts.

Contextual reflection prompts. Reflection prompts respond to your current state — a different prompt after a streak break than after a milestone, a different tone after a tough mood than after a good one. All of this runs on metadata alone — dates, counts, scores — never on your encrypted content.

WOOP-based goal setting. Oettingen & Gollwitzer (2010) developed Mental Contrasting with Implementation Intentions — wish, outcome, obstacle, plan. It outperforms positive visualization alone by 2-3x for goal completion. Goals include obstacle identification and confidence calibration, so you're thinking about what might get in the way before it does.

Contextual cue prompts. Every habit has an "After I…" field that links it to the thing you already do before it. After morning coffee → Meditate. Your cue shows right on the habit card and in your reminders — anchoring new behaviors to your existing routine.

The bottom line

Behavior change is hard. The research says it's also predictable — not perfectly, but enough to build better tools. Most apps don't bother. They give you a checkbox and a streak counter and call it done.

We think you deserve more than that. And we think you deserve it without giving up the most personal data you have.

Metamorphic is free to start. Your data is encrypted before it leaves your device. And the science is built into the product, not bolted onto the marketing.

Create your free account →

References

Barrett, L. F., Gross, J., Christensen, T. C., & Benvenuto, M. (2001). Knowing what you're feeling and knowing what to do about it. Cognition & Emotion, 15(6), 713–724.

Fogg, B. J. (2009). A behavior model for persuasive design. Proceedings of the 4th International Conference on Persuasive Technology.

Gollwitzer, P. M. (1999). Implementation intentions: Strong effects of simple plans. American Psychologist, 54(7), 493–503.

Lally, P., van Jaarsveld, C. H. M., Potts, H. W. W., & Wardle, J. (2010). How are habits formed: Modelling habit formation in the real world. European Journal of Social Psychology, 40(6), 998–1009.

Locke, E. A., & Latham, G. P. (2002). Building a practically useful theory of goal setting and task motivation. American Psychologist, 57(9), 705–717.

Oettingen, G., & Gollwitzer, P. M. (2010). Strategies of setting and implementing goals. In Social psychological foundations of clinical psychology (pp. 114–135).

Pennebaker, J. W. (1997). Writing about emotional experiences as a therapeutic process. Psychological Science, 8(3), 162–166.

Schultz, W. (1997). Dopamine neurons and their role in reward mechanisms. Current Opinion in Neurobiology, 7(2), 191–197.

Wood, W., & Neal, D. T. (2007). A new look at habits and the habit-goal interface. Psychological Review, 114(4), 843–863.

Your Habit Tracker Knows More About You Than Your Therapist. Mine Can’t Read Any of It.

Mark Thayer — Fri, 17 Apr 2026 16:10:58 +0000

I built a habit tracker where the server has no idea what you’re tracking.

Every habit app I looked at stores your data in plaintext on their servers. Your daily check-ins, your goals, your mood journal, your streaks — sitting in a database, readable by anyone with access. That felt wrong to me.

So I built Metamorphic: a habit and self-improvement tracker where all your data is encrypted in your browser before it ever reaches the server. The server only stores opaque blobs of ciphertext. Not even your email address is stored in plaintext.

Why encrypt a habit tracker?

Think about what a habit tracker actually contains. It’s not just “drink more water” and a checkbox. Over time, it becomes a detailed map of what you’re trying to change about yourself — your struggles, your patterns, the things you fail at repeatedly. That’s more intimate than most of what you’d share on social media.

The idea came from watching my partner, who has a background in psychology and behavior science. She’s always thinking about how to break old habits and build better ones. It clicked: if your habits, goals, and self-reflections are this personal, they should be private to only you. And you shouldn’t have to worry about whether they are.

The backstory

I run Moss Piglet, a bootstrapped public benefit company. Our other product, MOSSLET, is a privacy-first social platform built with Elixir. When I was becoming a new dad, I’d just finished reading The Age of Surveillance Capitalism by Shoshana Zuboff — and I wanted a better digital world for my daughter. When Meta rolled back end-to-end encryption on its messaging, I was pushed to implement real E2EE in MOSSLET.

Metamorphic takes that work further. Instead of encrypting just messages, the entire application is zero-knowledge. The server can’t read your habits, your goals, your reflections, your schedule, your group data — none of it. If our database were fully breached tomorrow, an attacker would get nothing useful.

What Metamorphic actually does

It’s a complete self-improvement platform, not just a checkbox app:

Habit tracking — Daily and weekly check-ins, streaks, drag-and-drop reordering, categories
Self-reflections — A journal with mood tracking and daily prompts
Goal setting — Milestones, progress bars, and the ability to link goals to habits so check-ins automatically advance your progress
Schedule and calendar — Recurring events, a day planner, and printable views for people who like paper
Family and group accountability — Shared habits, shared goals, a group dashboard, and member spotlights
Progress insights — Activity heatmaps and completion stats
Data export — JSON and CSV, decrypted entirely in your browser. The server never sees the plaintext, even during export

One thing I feel strongly about: encryption is not a premium feature. Every tier — including the free one — gets full end-to-end encryption. Paid tiers unlock convenience features like unlimited habits, reminders, data export, and groups. But privacy is not something you should have to pay extra for.

How the privacy works (without the jargon)

When you create a habit, type a journal entry, or set a goal, your browser encrypts that data before sending it to the server. The server stores it, but has no way to read it. When you load the page later, the server sends the encrypted blobs back, and your browser decrypts them using keys that only exist on your device.

Your password is never stored or transmitted in a usable form. Instead, it’s used to derive a cryptographic key locally, and that derived key unlocks everything else. If you lose your password and haven’t set up a recovery key, your data is gone — by design. That’s the real trade-off of zero-knowledge, and it’s the correct one.

For the more technically inclined:

Client-side encryption uses libsodium (XSalsa20-Poly1305)
Key distribution uses a hybrid post-quantum scheme: ML-KEM-768 combined with X25519 — the same approach Signal and Apple iMessage have adopted to protect against future quantum computers
Three independent encryption layers at rest : client-side E2E, AES-256-GCM in Postgres, and LUKS disk encryption on the hosting infrastructure
Zero-knowledge email : no plaintext email column in the database. Only a one-way hash for lookups and an encrypted blob
A detailed architecture writeup is at metamorphic.app/encryption

The interesting tension

Metamorphic is built with Phoenix LiveView, a framework where the server renders the page. But in a zero-knowledge system, the server can’t render the content — it doesn’t know what it says. The result is a choreography: the server sends the page structure with placeholder skeletons, and JavaScript hooks decrypt and fill in the real content on arrival.

It works. The skeletons flash in briefly, then the real data appears. UX-wise, it’s not dramatically different from any app with a loading state. Architecturally, it’s a very different beast — 15+ JavaScript hooks managing the encrypt/decrypt lifecycle across habits, goals, reflections, events, groups, and export.

The real trade-offs

I won’t pretend zero-knowledge doesn’t have costs:

No server-side search. If you want to filter habits by name or search your reflections, that happens client-side after decryption. Fine at our current scale.
If you lose your password and your recovery key, your data is unrecoverable. This is a real UX concern. The recovery key flow mitigates it, but the fundamental constraint is by design.
Testing is harder. You can’t assert on decrypted content in server-side tests because decryption only happens in JavaScript. Tests verify DOM structure and that encrypted fields are stored correctly — the decrypt-and-display pipeline is the gap.

These are trade-offs I’m willing to make. Your habit data being unreadable to everyone except you — including me — is worth it.

Try it

I’m not very good at habit tracking myself, which is partly why I built this. I’ve been using Metamorphic to get back into yoga, meditation, and running. So far, so good.

Check it out at metamorphic.app.

I Built a Zero-Knowledge Encrypted Habit Tracker with Elixir & Phoenix LiveView

Mark Thayer — Thu, 16 Apr 2026 23:16:47 +0000

I'm the solo dev at Moss Piglet, a bootstrapped public benefit company. I've been building Metamorphic — a habit and self-improvement tracker where all personal data is encrypted client-side before it ever reaches the server. The server only stores opaque cipher-text blobs.

Why encrypt a habit tracker?

I was inspired by my partner's background in psych and behavior science. It clicked that something as personal as your habits, goals, and self-reflections — basically a map of what you're trying to change about yourself — should be private to only you, and you shouldn't have to worry about it being otherwise.
Every other habit tracker I looked at stores your data in plaintext. Metamorphic doesn’t.

What it does

Habit tracking — daily/weekly check-ins, streaks, drag-and-drop reordering
Self-reflections — mood tracking and daily prompts
Goal setting — milestones, progress bars, habit linking
Schedule/calendar — recurring events, day planner, printable views
Family/group accountability — shared habits, shared goals, group dashboard
Progress insights — activity heatmaps, completion stats
Data export (JSON/CSV) — decrypted entirely client-side, server never sees plaintext

Encryption is not a premium feature. Every tier gets full E2E encryption. Paid tiers gate convenience (unlimited habits, reminders, export, groups), not privacy.

How the crypto works

Client-side encryption via libsodium-wrappers-sumo — XSalsa20-Poly1305 for data, NaCl box/seal for key distribution
Hybrid post-quantum key encapsulation (ML-KEM-768 + X25519 via @noble/post-quantum) — the same approach as Signal and Apple iMessage
Three independent encryption layers at rest: client-side E2E, Cloak AES-256-GCM in Postgres, and LUKS disk encryption on Fly.io
Zero-knowledge email: no plaintext email column in the database — only an HMAC blind index for lookups and an E2E-encrypted blob
Password never touches sessionStorage — only the Argon2id-derived session key
Persistent key cache using Web Crypto API (non-extractable AES-256-GCM wrapping key in IndexedDB) so browser restarts don't require re-entering your password
Recovery key flow for password reset without server access to private keys

More detail on the architecture: metamorphic.app/encryption

The interesting tradeoff: LiveView + zero-knowledge

This is the part I think other Elixir/Phoenix devs will find most relevant.

LiveView is server-rendered by design. Zero-knowledge encryption means the server can't see the content it's rendering. These are fundamentally in tension.

The result: brief placeholder skeletons that JS hooks fill in after client-side decryption, and a lot of push_event/handleEvent choreography (15+ hooks). It's not too different UX-wise from a trust-the-server model — the skeletons flash in briefly — but architecturally it's a very different beast.

Other tradeoffs:

No server-side search on encrypted fields. Filtering by habit name or reflection text happens client-side after decryption. Fine at current scale.

Testing is harder. You can't assert on decrypted content in LiveView tests since decryption is JS-only. Tests focus on DOM structure and data attributes. Context-level tests verify encrypted fields are stored and retrieved correctly — the decrypt-and-display pipeline is the gap.

If you lose your password and haven't set up a recovery key, your data is gone. By design. Real UX tradeoff, but correct for zero-knowledge.

Stack

Elixir/Phoenix LiveView — full-stack web app
Ecto + Postgres (Fly.io Managed Postgres)
libsodium-wrappers-sumo + @noble/post-quantum — client-side crypto
Cloak/cloak_ecto — application-level at-rest encryption
Oban — background jobs (reminders)
Tailwind CSS v4 + daisyUI — UI/theming
Sortable.js — drag-and-drop
JSZip — export packaging
Tidewave — AI-assisted development (runtime introspection, live SQL/eval, a11y diagnostics)

A lot was shared from my work on MOSSLET, a privacy-first social platform with private journal and Bluesky interop, also built with Elixir.

Try it

I'm not very good at habit tracking myself, so I've been using Metamorphic to get back into yoga, meditation, and running. So far so good.

Check it out at metamorphic.app. Happy to answer questions about the architecture, the zero-knowledge approach, bootstrapping a public benefit company, or anything Elixir-related.