The platform
Muhkoo
An application platform where the server is never trusted with anything — not the password, not the message, not the file.
The problem
Every platform that offers authentication, storage, and messaging asks you to trust it with the plaintext. That trust is the weakest link in the product: it turns every breach into a total breach, and it makes compliance a matter of promises rather than math.
The question I wanted to answer was whether a full application platform — signup, databases, file storage, group chat, hosting, billing — could be built so that the operator is structurally incapable of reading customer data, while still feeling like an ordinary developer product. Not a research prototype. Something you could ship a real product on in an afternoon.
How it works
Identity is the root. A user proves knowledge of their password with a zero-knowledge proof, so no password, hash, or offline-crackable verifier ever reaches the server. That proof unlocks a key vault in the browser, and every other subsystem derives its keys from there. The vault is the boundary in the diagram below: everything above it is public, everything below it is sealed.
What I'd do differently
I put the first authentication service behind a single Durable Object. It was the simplest thing that worked, and it worked right up until it didn't — that singleton became a global chokepoint and took production down. The fix was a proxy fanning out to sharded auth objects, which is what I should have built first: anything on the critical path of every request deserves a sharding story before it ships, not after an outage supplies one.
I would also have metered storage from day one. Adding refcounted garbage collection to a content-addressed store that was already live meant reconciling real customer data against a model I was inventing at the same time. Billing and lifecycle are not features you retrofit cheaply.