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
Great project! I’ve had a similar experience with Rewind and the related privacy concerns. A quick thought: if I recall correctly, Rewind performs OCR locally, so it only needs to send textual data. Since you’re focusing on macOS, you could rely on VNRecognizeTextRequest and skip the extra OCR complexity. It might also help to detect and mask sensitive information with lightweight models (e.g., BERT), especially when leveraging cloud-based AI.
Self‑hosting swaps one risk for another. A cleaner option may be local‑first apps that speak an open sync protocol: your data lives on your phone/laptop/homeserver; an optional, end‑to‑end‑encrypted relay just moves opaque blobs for backup and multi‑device access.
Why this matters: the No. 1 failure I see isn’t servers getting hacked. It’s users losing the only copy of their files.
* ~70 million phones are lost annually; most are never recovered. https://snohomishcountywa.gov/Archive.asp?ADID=543
* Consumer hard‑drive AFR hovers around 1‑2 %—≈7 % fail within five years. https://blocksandfiles.com/2024/05/02/disk-failure-rates-in-...
* 29 % of people have already suffered data loss from deletion, ransomware, or disk death. https://www.worldbackupday.com/en
With odds like these, an off‑device, unreadable backup is basic hygiene, not a luxury.
Disclaimer: I work on Anytype, which follows this model: local ownership, open‑source sync protocol, source‑available clients.
Thank you, I made an update to the original post with your explanation, and because you stated that the output was a pure hallucination, I also attached one of them.
In one of the responses, it provided the financial analysis of a not well-known company with a non-Latin name located in a small country. I found this company; it is real and numbers in the response are real. When I asked my ChatGPT to provide a financial report for this company without using web tools, it responded: `Unfortunately, I don’t have specific financial statements for “xxx” for 2021 and 2022 in my training data, and since you’ve asked not to use web search, I can’t pull them live.`.
In one of the responses, it provided the financial analysis of a not well-known company with a non-Latin name located in a small country. I found this company; it is real and numbers in the response are real. When I asked my ChatGPT to provide a financial report for this company without using web tools, it responded: `Unfortunately, I don’t have specific financial statements for “xxx” for 2021 and 2022 in my training data, and since you’ve asked not to use web search, I can’t pull them live.`.
No, definitely not the empty string hallucination bug. These are clearly real user conversations. They start like proper replies to requests, sometimes reference the original question, and appear in different languages.
Reported a flaw to OpenAI that lets users peek at others' chat responses. Got an auto-reply on May 29th, radio silence since. Issue remains unpatched :(
Avoided their bug bounty due to permanent NDAs preventing disclosure even after fixes. Following standard 45-day disclosure window—users should avoid sharing sensitive data until this is resolved.
We do releases in the Github Actions CI. So you can inspect the CI logs and published artefacts(desktop/android). Then you can compare the binaries checksums. I would appreciate ideas on how we can make it more transparent
Hello, I’m Roman and I’m a technical co-founder at Anytype. We are building a new operating environment that breaks down barriers between apps and gives back privacy and data ownership to users.
Anytype runs locally and exchanges data directly in a peer-to-peer way without exposing it to intermediaries even when users work across devices and with each other. Because of this, Anytype is free without storage and upload limits. We plan to open-source it with the public release.
This is our early demo and I’d like to get feedback on what we are building, so we can incorporate it into Anytype. Also, if you have any questions, I’d love to answer them.
1. In case of public pages, as far as any of the nodes has your page saved it will be available.
2. In case the data is shared with someone(e.g. teammate or family) you always be able to restore it with the seed phrase. In case of private-only data, our plan is to encourage users to have multiple devices(mobile+desktop) to have a data backup
3. We plan to implemet per-device private key(like the keybase does) and use it to decrypt files' private keys. In case the device's private key was stolen you can remove this device from the list and it will not be able to receive new changes
Think it like Chrome browser transformed into Chrome OS. Currently we are at the 1st step :)
But the whole idea is that most of the users can create their own apps without code (airtable way) using existing building blocks(no need for APIs). And a small amount of users who code can create new building blocks
- Your devices(mobile+desktop) share your private files
- Anytype provides nodes that store a small amount of encrypted data for free. Later we will provide an option to buy more backup space on our nodes to pin your encrypted data
- You also will be able to set up your self-hosted anytype node to pin your data
> Who pins the files when my laptop is offline? Who pays for this?
Currently, Anytype provides a small cache on our public nodes to store the last encrypted versions to mitigate offline/online problems.
You also will be able to set up your self-hosted anytype node.
> What keeps my files online in the event of high node churn?
- Peers who are interested in the content actually store it
- Anytype nodes
> What happens if malicious nodes join the IPFS swarm and censor key/value lookups
- First, you will do the local-network lookup.
E.g. if you are working with your team in the same network you will be able to discover local-network nodes via broadcast msgs
- Anytype provide nodes that index the encrypted content. That nodes expose additional API that can be used to speed up P2P content discovery in that cases while being fully secure (because it is content-addressable)
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