Application
Cloud Drive
Personal file storage where the operator holds nothing but ciphertext — and still gets deduplication, resumable uploads, and quota accounting.
The problem
A file store the operator cannot read still has to behave like a file store. Large uploads must resume. Identical data should not be paid for twice. Quotas have to be enforced, and durability has to survive a lost shard. Every one of those features normally depends on the server understanding the bytes it holds.
How it works
Files are split into chunks and each chunk is encrypted with AES-256-GCM under a key derived from the user's vault. The encrypted chunks are then erasure-coded with Reed–Solomon, so losing a shard costs nothing — the file reconstructs from the survivors.
Shards are content-addressed, which is what makes deduplication possible without comprehension: two users who happen to store the same shard produce the same address, and the origin stores one copy, having learned nothing about what it contains. The manifest that records chunk order and keys is itself encrypted, so even the shape of a file stays private.
What I'd do differently
Content addressing plus deduplication has a consequence I did not design for up front: a shard can be referenced by many files and many users, so deleting a file cannot simply delete its shards. Without refcounting, deletion either corrupts someone else's data or silently leaks storage forever. I shipped the store first and worked that out second, which meant retrofitting refcounted garbage collection onto live customer data — reconciling real shards against a model I was still writing.
Ownership and lifecycle belong in the first version of a storage schema, not the third.