requilence

Premise: treat it as certain that the server will eventually be compromised, subpoenaed, or misconfigured. So the server must hold nothing that can be decrypted or linked to a specific user's content. Users hold their own encryption keys, the server stores ciphertext, and there is no UUID→identity mapping at the sync layer. Sync runs over any-sync, which is peer-to-peer-capable; intermediate nodes see ciphertext.

On your four problems:

1. O(x*y) joins - pushed to the client, because the server can't decrypt enough to do them.

2. Offline members - eventual-consistency sync and CRDT.

3. Client-side theft - if an attacker has the user's keys, they have the data. Intentional: no server-side gate to break means no server-side gate to exfiltrate at scale. We're considering optional 2FA at the infrastructure layer as an additional barrier to data retrieval.

4. Unwanted modifications - content is signed with user keys and validated on read.

Real cost is on the product side: no server-side AI over your notes, no server-side full-text search, slower cold-start, and harder to build product analytics (no access to user data). Granular ACLs are also harder — permissions are enforced by key possession, so revoking access often requires key rotation rather than a permission-flag change.

But the exact bug this post is about (a server endpoint that maps a public UUID to an email) is structurally impossible in this model, because there's no such mapping on our servers to misuse.