Suggestion: Add "personalized" boolean to app.bsky.feed.generator lexicon

[redsolver]

I would like to suggest adding a new personalized boolean value to the app.bsky.feed.generator lexicon, enabling feed authors to specify whether their custom feed is personalized or not. Most feeds on Bluesky are not personalized, so this would bring the following benefits:

• Massive privacy improvements, because most feed generators would no longer know who is requesting a feed (non-personalized feeds don't need an auth header with the DID of the requesting user).
• Non-personalized feeds can be cached if a lot of users request them, which significantly reduces load and makes running a simple feed with minimal resource requirements easier
• The "personalized" label could be visible in the UI and help users better choose new feeds they like and understand how they work

[whyrusleeping]

I like

[dholms]

I actually like this idea quite a bit

We've been discussing some mechanisms for generators to declare what they're doing/what they need. And ways for the client to opt in to reporting more info to a generator.

This seems like a simple first step into that.

Thoughts @pfrazee @devinivy

[pfrazee]

I'm +1

[bnewbold]

I like this! A few notes below, but nothing that would block moving forward.

Who would be responsible for keeping track of whether to send auth'd or not? Would this be a client thing or a PDS thing? It is application-specific and we are mostly moving to minimize app-specific behaviors of PDS, but as the proxy it does seem like a reasonable place to implement the logic.

How do we roll this out? Do we just stop sending the DID in feed generator requests unless the flag is set to true? Do we default to sending unless false for some transition period? I'm sure we can do this without too much disruption, but need to think it through and do proactive comms.

I don't think we really want to do it, but noting that we could allow something like hashtags or self-labels on feed generator records to both improve discovery and make this kind of feature-flagging more flexible. I think for basic/core flags like this it should be a boolean flag though.

There are a few possible options around the combination personalization (by indicating the declared DID in request) and auth (proving the request is on behalf of the DID, for access control):

• no auth required (and no personalization supported at all
• no auth required, personalization is optional (works with and without)
• no auth required, personalization is required
• auth required, but no personalization, just access control
• auth required, and feed is personalized

I don't know that we need to support all that, we can just start with "auth=false" in all cases (default), and personalization is either supported or not (not optional).

Is personalized the best name for the boolean field? I think it is pretty good, alternatives like accountSpecific, perAccount, accountAware, identityAware, requiresIdentity are verbose and not much clearer.

[ShreyanJain9]

Is personalized the best name for the boolean field? I think it is pretty good, alternatives like accountSpecific, perAccount, accountAware, identityAware, requiresIdentity are verbose and not much clearer.

how about authRequired?

[redsolver]

How do we roll this out? Do we just stop sending the DID in feed generator requests unless the flag is set to true? Do we default to sending unless false for some transition period? I'm sure we can do this without too much disruption, but need to think it through and do proactive comms.

I think sending the auth header unless it's explicitly set to false is the best approach for now during a transition period (maybe until 01.01.2024) and then after that only send the auth header when explicitly set to true.

I like both personalized and authRequired as names for the field.

[Bossett]

One of the things I've had to do is start using the auth header as an abuse preventer - users have been using my feeds to identify content to post under. I don't think that use-case should necessarily block an implementation like this (this is one of those 'someone is relying on every bit of undefined behaviour' things), but it would mean all my feeds would become 'auth required, no personalisation'. Just speaking in favour of careful UX here: so it doesn't freak users out (i.e. why are you collecting my data?)

[bnewbold]

We are pondering things for an iteration of feeds. Don't want to pre-empt the design process on that, but some things under consideration:

• mechanism for sending usage/interaction data back to feed generators, as a feedback loop on how folks actually use the feed. feeds could probably configure this behavior; it won't make sense for many.
• making some feeds public, on the not-logged-in bsky.app website. this may also be configurable by feed generators, and related-but-slightly-different from the "personalized-or-not". we would cache these pretty heavily.
• possibly sending language prefs via Accept-Language header or similar (this one is pretty speculative)

There are a bunch of ideas bouncing around, and the above are just hints not final plans.

@Bossett that is interesting. a concept of "blocking" accounts from a feed sort of makes sense. we definitely want to leave the door open to feeds being relatively private/closed or with gated access.