I’m worried. The current implementation of Bluesky bookmarks is fine, in theory, but it has some implications for the future of atproto private data I’m not sure I love.
The main issue for me is the choice to implement public bookmark counts, where despite the bookmarks themselves being private to you, the AppView uses all the private bookmarks it’s aware of in order to aggregate counts of how many bookmarks a post has. Unfortunately, this is a totally opaque count for which you just have to trust the AppView. Because bookmarks are private state between you and the AppView, nobody else can verify this count. This is very different from basically everything else in atproto.
Private state used by the AppView is fine; mutes, list subscriptions, etc, all do that, and it’s fine. The thing about all of those is that they only affect your view of the network. And bookmarks could work that way too, and it would be fine.
The trouble with having private state that affects others’ view of the network is that, in the manner that Bluesky is doing it, it neccessitates centralization. If you have multiple AppViews, their bookmark counts will naturally diverge because they can only count their own users’ bookmarks. If we want to have accurate bookmark counts, we’re conceding that everyone will just be using one AppView. This is centralization.
And the sad thing is, it’s for a feature which nobody even wants to have. The point of bookmarks is that they’re a private way to save posts for future reference. They’re intrinsically not “social”, so we shouldn’t make them into social indicators.
Anyways, thanks for reading. I kept this one short.
