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