Status note (Honesty axiom). For a long time this feature was roughly eighty percent built — around a placeholder. A shim stood in for the real proxy-re-encryption library: the surrounding plumbing existed, the tests went green, but the actual cryptographic library was not present and not building. What landed this week (2026-06-11) is the part that was missing the whole time: the real library, finally compiling on a clean machine — desktop, Android, and iOS — and replacing the shim. That is the milestone, and it is more interesting than "we wrote some code."

Fellow travelers: the people who built the primitive

Before our story, the people who deserve the credit. The whole reason any of this exists is a project called recrypt — part of the Identikey family of work — and the builder behind it.

What they made is a beautiful, specific thing: proxy re-encryption. The ordinary way to let a new person read your encrypted data is to decrypt it and re-encrypt it for them — which means, for a moment, someone has to hold the plaintext. Proxy re-encryption removes that moment entirely. A semi-trusted helper can transform a ciphertext that was sealed for you into one that only the new recipient can open, without ever seeing the message in between. The helper does real cryptographic work and learns nothing. That is not a small trick; it is exactly the primitive a system like ours needs, because our entire premise is that you should be able to share without ever having to expose.

flowchart LR
  A["Your encrypted data
(sealed for you)"] --> H["Semi-trusted helper
transforms the ciphertext"]
  H --> B["New recipient
can now open it"]
  H -.->|never sees the message| P(["plaintext"])

Recrypt builds this on a modern, post-quantum lattice scheme — the kind of math designed to stay safe even against the computers we expect to exist later — and wraps it in a clean, honest trust model: the storage is untrusted, the helper is only semi-trusted, and your own device is the only place a secret is ever held.

We did not invent any of that. We use it — and, just as importantly, we work with it. This is a real collaboration, not a one-way dependency. NAOMS runs on a fork of recrypt, and the relationship goes in both directions: when we found a sharp edge in how the library handled malformed input — a case that could crash the whole process instead of failing cleanly — we wrote the fix and offered it back upstream as a contribution to the project, rather than quietly keeping it to ourselves. We also carry build improvements that teach the library to compile cleanly for phones and tablets, the kind of cross-platform plumbing that's tedious to get right and valuable to share. We trade fixes, we report what we learn, and we build on top of work that someone else had the vision to start.

So: thank you to the author of recrypt and the Identikey project. The hard, generous, foundational part — the cryptography that makes "share without re-encrypting" possible at all — is theirs. What follows below is our side of that shared road: the unglamorous, honest work of actually getting their library to compile and run everywhere we needed it. It is only worth telling because the foundation under it is solid enough to build on.

The honest timeline: a placeholder that went green

Here is the part most write-ups would quietly skip, so we'll lead with it.

For a long stretch, this feature looked finished and was not. The architecture was there — the key-wrapping scheme, the routing that decides which backend handles a given ciphertext, the call sites, the test suite. Call it eighty percent. But the one part that mattered most, the real proxy-re-encryption library, was not actually wired in. In its place sat a shim: a placeholder backend that produced the right shape of output — the right bytes in the right slots — without doing the real lattice cryptography at all.

And everything went green. That is the trap worth dwelling on. The everyday test run exercised the placeholder, so the suite passed — keys "generated," messages "encrypted" and "decrypted," round-trips "verified." It looked like the backend worked end to end. It did not. The real library wasn't present, wasn't building, and so was never being exercised. The green was the placeholder agreeing with itself. It is the same trap we owned up to elsewhere — [the day we a green mark can outrun the thing it certifies, and the standing reminder that green isn't done.

We know exactly how thin that ice was, because when we finally forced the suite to run against the real library instead of the shim, it didn't go green — it crashed. The first honest run aborted the whole process: a serialization path in the real cryptographic context didn't survive a save-and-reload cycle, something the placeholder never had to do because it was only ever pretending. A defect that breaks real key creation at step one had sailed through every "passing" run, because every passing run was the stub.

So the honest status, for that long stretch, was: mostly built, around a placeholder, with the real thing neither present nor proven. Not a finished feature. A finished frame with the load-bearing piece missing.

What actually landed this week

This week is when the real library showed up and stayed.

The order of operations was the unglamorous kind:

• Run the real thing and let it fail loudly. The first step was simply to stop trusting the placeholder's green and run the suite against real lattice cryptography. It crashed. Good — now we had a real bug instead of a fake pass.
• Fix the crash at its root. The serialization path that couldn't survive a save-and-reload cycle was repaired so the real cryptographic context is carried and restored correctly. The general flow stopped aborting.
• De-theatre the tests. Several tests had been quietly skipping themselves whenever the real backend was selected — passing by not running. We made the backend-agnostic ones actually run against real cryptography, and proved the remaining skips were genuinely specific to the placeholder rather than hiding a failure. A wrong-key safety property that the stub had asserted-away now runs against the real library and is shown to fail closed.
• Make the real backend the default. The selector that chooses between the placeholder and the real library was flipped so the real, lattice-backed backend is what you get by default; the placeholder is now an explicit opt-out, not the silent fallback. The heavyweight native cryptographic dependency was baked into the default build, so a plain build links the real library instead of skipping it.

After that flip, the suite that had been green-on-a-stub was green on real key generation, real encryption, real decryption, and a real re-encryption round-trip — the actual proxy-re-encryption operation, performed by the actual library. Same word, "green," but for the first time it meant what everyone had assumed it meant all along.

For builders

The last mile: making it build everywhere, on a clean machine

A library that compiles on the author's laptop and nowhere else is not done. Real, hard-to-build cryptography earns its keep only when a colleague — or a phone, or a fresh checkout that has never seen the code — can compile it too. So the closing stretch was pure build work, and it is where "it just builds" stops being a throwaway phrase and becomes the feature.

Two kinds of breakage had to go.

A build override pointing at a hole. At one point the build carried a local override that told the compiler "use this copy of the library, on disk, right here." That copy lived in a directory that was deliberately never committed — it existed only on the one machine where the mobile build had been done. On every other fresh checkout, on every other machine, that directory was simply absent, and the build collapsed during resolution — before a single line of code compiled. It worked flawlessly for the author and failed silently for everyone else, at the worst possible moment: someone else's clean machine. The fix was to remove the override entirely and fold the platform-specific build logic into the pinned fork of the library itself, so the library is self-describing. Now a fresh checkout fetches a known, pinned version over the network and compiles it in place — no private directory, no machine trusting another machine's local state.

Cross-platform compilation. Getting a large cryptographic library written in C++ to compile is hard on one platform and harder across three. The mobile builds needed the right toolchain wiring — the correct standard library on Android, the correct build target and software-development kit on iOS, a compatibility floor for an older build-system dependency. Each of these was a small, sharp, tedious fix, and each was folded into a durable place — the pinned fork, or the documented setup — rather than left as an incantation in someone's shell. The proof is the unglamorous receipt: a fresh checkout with none of the private state present resolves and compiles the desktop library; and the Android build produces a shared library with the real lattice cryptography linked inside it. The library that once existed only as a placeholder now compiles, for real, on desktop and on a phone, from a clean machine.

Why this is the real milestone

It is tempting to tell the flattering version: "the backend shipped, and this week we polished the build." That version is a lie, and a less interesting one. The honest version is better. The feature spent a long time looking finished while standing on a placeholder; the green light was the stub nodding at itself; and the genuine accomplishment of this week is that the real cryptographic library — a notoriously hard-to-build one — finally landed, ran, passed against real cryptography, and compiled everywhere, replacing the shim for good.

That is why "it just builds" is the feature, not the footnote. A placeholder always builds; that is the whole problem with placeholders. Getting the real, post-quantum, hard-to-compile library to build cleanly on a machine that has never seen it — desktop, Android, iOS, no private state assumed — is the moment the feature stopped being eighty percent and started being true.

And the deepest version of that isn't ours at all. It's the primitive the recrypt / Identikey project built — sharing without exposing, trust you can remove rather than trust you have to extend. We get to stand on that, send our fixes back, and tell an honest story about the day the placeholder finally became the real thing. With genuine thanks to the people who made the hard part.

Written by AI agents from real project logs; owned and edited by Mujo.