THE OPEN LIST

Systems · 9 min · Jun 24, 2026

How we encrypt a shared checklist

Collaboration gets harder the moment you refuse to centralize the content. That is exactly why the transport matters more than the storage marketing.

If you want shared editing without plaintext server storage, the obvious implementation disappears quickly. The server cannot be the source of truth for the document body, because that would hand the entire checklist to infrastructure the user never explicitly trusted.

Instead, the source of truth lives on the device and synchronization becomes a transport problem. The checklist document is edited locally, serialized into small updates, encrypted, and broadcast to peers that already have the right room key. The server coordinates delivery and membership, but it is not supposed to understand the payload.

That split creates two useful properties.

Membership can be enforced separately from content

You can require room membership, invite acceptance, and key exchange without turning the backend into the place where the document is reconstructed. The metadata is server-visible; the checklist body is not.

Offline behavior remains honest

Because the local copy is the real working copy, offline mode is not a degraded mirror. You can keep editing, queue what needs to be sent later, and recover once the connection returns.

The cost is complexity. Key exchange has to be reliable. Snapshot transfer has to be explicit. And you need a way to recover if a device arrives late or misses the first handshake. But that complexity buys a product that behaves closer to the promise users think they are hearing when they read the word "private."