Add bookmarks natively to Bluesky

[ebwinters]

This PR adds native bookmarking to Bluesky. I understand it is likely this PR will implement Bluesky's bookmarking feature, so here are the:

Goals

Groundwork for eventual bsky-team supported bookmarks implementation

• Get community feedback on initial bookmarking design
• Write code that can be used as a starting point for feature development

Personal interest

• Introduce a 3rd party lexicon inside of Bluesky
• Bring a long-awaited feature to Bluesky that I’m also excited about

Non-UI design choices

Using community.lexicon.bookmarks

Note: There is an active discussion thread in the atproto repo on using 3rd party lexicons in Bluesky

Implementation was done using community.lexicon.bookmarks for the following reasons:

1. Flexibility: Bluesky at:// URIs are a subset of the uri type, meaning developers can more easily integrate bookmarks from Bluesky into other apps
2. Avoid duplication: Simply put, a bookmarking lexicon already exists along with a types package, both of which have gone through a community design review. That lexicon will also be integrated into more 3rd party clients to come, so it makes sense to reuse it or extend it rather than make a new bookmarks schema
3. Open source collaboration: Adopting a third-party lexicon in Bluesky aligns with its goals of true decentralization and interoperability within the larger Atmosphere

Public bookmarking

There is currently no way of making a private lexicon on atproto. This is generally a limitation within the protocol and I don't believe it should block development of bookmarks. There are workarounds for privacy, such as creating an anonymous account and bookmarking to that account, as well as extensions and labelers.

UI design choices

Putting bookmarks in the side bar

INSERT PICTURE HERE
I put bookmarks in the side bar for easier access. Another placement option is inside of the user profile, next to your likes.

Potential problems

Hydrating the equivalent of an isBookmarked on every post

Showing a user if they've already bookmarked a post through icon highlighting is important so they don't make duplicates. However, since bookmarks are not build in to the response of getPost(), a post has no notion of a bookmark. To compensate, I fetch all bookmarks by the current user, cache them in memory, and then do a bookmarks.contains(post.uri) for each post rendered to the page. When a bookmark is removed/added, the cache is updated.
I can see this becoming a problem if a user has thousands of bookmarks, and am curious about other designs, tradeoffs, or approaches here. Some possibilities I can think of are

1. Building bookmarks into PostView at the protocol level, simiar to likes
2. Only caching bookmarks that have been created recently, which could fail when a user pulls up a post they've bookmarked from a while ago
3. Not highlighting bookmarks on posts in the feed view, and allowing duplicates

Pagination of bookmarks

On the "my bookmarks" page, rather than fetching the entire list of user bookmarks, they should be paginated and shown on scroll. However, I was not able to figure out pagination, since the getActorBookmarks method does not exist on the Bluesky PDS. For this feature to move forward, this is a blocker that I'd need some help on.

Future work

Filtering and searching bookmarks

The community.lexicon.bookmarks.bookmark allows for tagging bookmarks. This brings up more complicated UI designs that might not be worth fleshing out right now. However, in the future I can some popup when a bookmark is created for adding tags, and then searching/filtering on the "My Bookmarks" page.

Screen shots and other links

Bookmarking on a feed:

Bookmarks page

Discord thread with gif

[oracularhades]

that bookmark button location on the post actions should be changed
also those lexicons don't look private? unless that's new. It'd be a very bad idea to leave bookmarks publicly exposed.

[ebwinters]

Valid point, but also Why would it be a bad idea for them to be public? Your likes are also public. More discussion on that here

lexicon-community/lexicon#12

[pyxfluff]

Public everything isn't great and I wish my likes were private but thats more of a protocol issue. Bookmarks being public seems like a poor idea but unfortunately maybe it makes sense but I still think you should change it. Also, move the bookmark button to the far right with only a little big of padding with the menu button.

[davidcelis]

I agree that it doesn't make sense for bookmarks to be public and there should be no need for that in the lexicon if it can be avoided

[erlend-sh]

Count me in for ‘okay with public bookmarks’. Yeah it’s not ideal, but it’s simply the limitation of the platform as it exists right now, and it’s a great start for client convergence.

The notion of all-public-activity when using Bluesky is already deeply engrained for me, so my use of bookmarks won’t be any different.

Worth noting that the most popular method of bookmarking to date has been to reply with a 📌 to a post. Making that inadvertently noisy practice obsolete would be a big improvement on its own.

Also, here’s a workaround that multi-account clients could easily accommodate:

1. make an anonymous alt-account
2. anything you want to privately bookmark, you bookmark with that account

This shouldn’t have to require constant account switching, as there’s already prior art (in Mastodon at least) for clients that have a UI utility like “repost/favorite from: acc1, acc2..”

[oracularhades]

I strongly disagree. Likes and blocks are public because they have to be. Bookmarks do not have to be. Parts of Bluesky are "public" because they have to be, it doesn't mean everything is public. Bookmarks being public would allow Cambridge-Analytica like scraping, it would show what a user really liked. It's a very bad idea to make bookmarks public, and the team doesn't seem very interested in that.

[ebwinters]

@oracularhades my problem with private bookmarks, rather than using an anonymous account, is that it takes away portability. The data for bookmarks would be stored on a private server, which seems wrong at a protocol level, rather than chats being stored on a private server. If anything, it made sense for blocks to be stored privately. Blocking someone can have real-world implications, and its better for those who are blocked to not know.

As for scraping, I don't see a reason why bookmarks are any different than likes or reposts. I could make the argument that reposts are actually what I'm truly interested in and support, and bookmarks are just a way of saving things like recipes to come back to later. That's just the nature of Bluesky, all the data is public.

EDIT:
There is some effort going on internally to support private state on PDS, which, if/when completed, bookmarks would be a great candidate for

[oracularhades]

my problem with private bookmarks, rather than using an anonymous account, is that it takes away portability. The data for bookmarks would be stored on a private server,

your entire PDS is the portability. That's its job :) - so no, that's not true

[surfdude29]

It's a very bad idea to make bookmarks public, and the team doesn't seem very interested in that.

@oracularhades is right, bookmarks should be private, like mutes are. Users expect this, as this is how bookmarks work elsewhere (most notably on Twitter). We already have a workaround to make public bookmarks, although it's certainly not ideal. However, it would confuse users to add a built-in bookmark function but with everything you bookmark being public.

It's possible that once we have private bookmarks an option to share some of them publicly would be a good idea (e.g. here's a curated collection of posts on a certain topic), but it's clear from user feedback that private bookmarks must be the first step.

my problem with private bookmarks, rather than using an anonymous account, is that it takes away portability.

@ebwinters Portability can be implemented by allowing users to export their bookmarks into a file and that file can then be imported elsewhere.

As for scraping, I don't see a reason why bookmarks are any different than likes or reposts.

I understand that you personally would be happy for your bookmarks to be public, but it's clear from feedback that there's a strong desire from many users for a way to save posts privately for future reference.

[oracularhades]

@surfdude29: It's possible that once we have private bookmarks an option to share some of them publicly would be a good idea

I think if we do this it should be "bookmark collections/folders" with an option to make those public, and they can display on the user's profile.

EDIT: @surfdude29 sorry it's 5am and I missed your "(e.g. here's a curated collection of posts on a certain topic)," lmao, you already suggested this.

[ebwinters]

@surfdude29 I wouldn't be happy with public bookmarks per se, that's just the limits of the protocol right now. I'd rather bookmarks be stored in the PDS for portability, but if private state on the PDS is a thing, that is the ideal solution, and I'd imagine a lexicon/client change would be in store for the community.lexicon.bookmarks schema.

[surfdude29]

@ebwinters Based on all the feedback I've seen from users on Bluesky, my view is that a fundamental requirement of any implementation of bookmarks on Bluesky is that they be kept private.

Therefore, I would suggest that we need to wait until this can be done in a way that's consistent with other goals – private state on the PDS seems a promising way to do that – instead of going ahead with public bookmarks as an interim solution, simply because that's all that can be managed at the moment.

I think doing this would be confusing for Bluesky users ("we're releasing a half-finished version of bookmarks, they're all public, but we hope to make them private at some point in the future") and would not meet their expectations.