| Disclosure: I work at Anytype. This is the architectural bet we took, so I'll answer your four problems directly. 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. any-sync and our data format (any-block) are MIT, if you want to poke at how it works: https://github.com/anyproto |