Improving the preferences API

[pfrazee]

The preferences API is a bit difficult to work with. The way it currently works is as a single object containing an array of typed objects (see https://github.com/bluesky-social/atproto/blob/main/lexicons/app/bsky/actor/defs.json#L97).

The one positive I can say for it is, they're well-typed.

Here are the downsides:

• The typing is nice (and pretty clutch for coordinating between apps) but also extremely tedious to introduce every time we need a new preference.
• All the preferences are stuffed in one object. This wouldn't be a huge problem except...
• There's no subscription API, so the app needs to constantly poll for the preferences to stay in sync with changes from other devices/sessions.
• It's still pretty easy to clobber or drop values -- look at https://github.com/bluesky-social/atproto/blob/main/packages/api/src/bsky-agent.ts#L311-L584 to see what an ordeal it is.

I'm open to suggestions on how we can improve this API. A couple ways it could be better:

• Split the preferences into each type instead of one array object
• Include some compare & swap semantics to avoid clobbering data
• Include some polling semantics, perhaps with version numbers and the ability to give an empty "no changes" response

Additionally I should note: we're looking at adding a private bookmarking API which will replace the savedFeeds preference. The API would be a general-purpose way of bookmarking AT URIs (and can be queried by the NSID of the URI).

[mozzius]

I'd love to see explictly PATCHing or PUTing values, and moving to a more KV based structure.

For example, rather than having 8 different app.bsky.actor.defs#contentLabelPref preferences, you could have:

{
  "$type": "app.bsky.actor.defs#contentLabelPref", 
  "hate": "warn",
  "spam" "hide",
  // etc
}

And then make a request that looks something like this:

{
  "target": "app.bsky.actor.defs#contentLabelPref", 
  "method": "PATCH", // or PUT
  "values": { "spam": "warn" }
}

Polling semantics would be great - returning a cursor so that it could return updates since the last request would be cool.

Also, great to hear that pinned/saved AT URIs is moving to a dedicated place - always seemed a bit jank to keep it here imo

[mary-ext]

I'd love to see saved/pinned feed preferences persisting the names or some basic info about the feed somehow.

As it is right now, if anyone deletes their feeds, then users who had it saved would just have it suddenly missing. This doesn't seem great, ideally the app could still show the feed name with a ⚠️ to let users know that it no longer exists, rather than disappearing outright.

Additionally, this means that apps can show the saved feeds quicker, feed names could just be taken straight from preferences and a later fetch (with a low priority) can be done to update the feed name if it had changed