Proposal for lexicon updates to add "followed by" information to profile views (Issue #1302)

[mikayla-maki]

Hi Bluesky folks,

This is a proposed change to some bluesky lexicons for the implementation of #1302.

Proposal

I propose adding an additional definition to app.bsky.actor.defs:

"detailedViewerState": {
  "type": "object",
  "properties": {
    "followersYouKnowCount": {"type": "integer"}
},

as well as an additional property on the profileViewDetailed definition:

"detailedViewer": {"type": "ref", "ref": "#detailedViewerState"},

This property and definition would be used to provide UI on a user's profile page that is similar to twitter's Followed by feature, albeit limited to just aggregate information, as described in the above issue.

I also propose adding an alsoFollowedBy (an at-identifier) parameter to the app.bsky.graph.getFollowers query. If included, the results of the getFollowers query would be restricted to those followers who are also followed by the provided at-identifier. Omission of this parameter would be equivalent to the current behavior of this query. This new query parameter would be used to implement the /profile/:name/followers-you-know endpoint referenced in the above issue.

Discussion:

The first version of this proposal (referenced below) suggested adding the followersYouKnowCount field to the profileViewDetailed definition directly. However, on a second pass I realized that the current organization keeps stateful information in a separate viewer field. Since followersYouKnowCount is inherently stateful, I then thought to add this new property to the #viewerState definition. However, this was also used in other definitions (#profileView, and #profileViewBasic) which had no use for the followersYouKnowCount property. Given this property's computational complexity, it seemed wasteful to add it to definitions which had no use of it. I could just leave it undefined / 0 for those views, but it seemed strange to claim to have a property available in several schemas and then just leave it unset. Given these constraints, I decided that adding a new field to the profileViewDetailed definition would be the most backwards compatible and semantically useful way of implementing this feature.

On performance for followersYouKnowCount, a cursory examination of the profileDetailed function in packages/bsky/src/services/actor/views.ts, shows that the current followsCount and followersCount aggregates are cached in a separate table. A similar approach would probably be infeasible for implementing this feature, as it would require adding a new table with (n choose 2) -> ~n^2 entries (n being the number of users on Bluesky), as well as O(m) (m being the number of followers the user has) book keeping on every follow/unfollow. However, implementing this on each profile load would require adding two SELECTs and an INTERSECTs SQL operation, a roughly O(min(m, n)) performance hit (m and n being the number of followers the two users have) to a currently constant-time query*. I don't have the context to determine if this is acceptable at this time.

On implementing the alsoFollowedBy parameter, this makes the getFollowers query more complex. While the operation is conceptually a simple filter, implementing it in SQL requires an additional SELECT and INTERSECT operation, necessitating a large branch in the query implementation. That implementation complexity could be traded off by implementing this behavior as an additional getFollowersFollowedBy query, instead of as a parameter. I am unsure what the norms are in this space for making this kind of choice.

Please let me know if there's more due diligence I can do for this proposal; I know y'all are swamped by the constant crises on the wider internet :)

* Note though that the average time is probably much smaller than this as there's usually much less overlap between two accounts than there are followers of a given account.

[mikayla-maki]

Immediately after posting this I realized that the followersYouKnowCount variable should probably be in the viewerState definition 🤦‍♀️🤦‍♀️🤦‍♀️. I will rework this proposal with better due diligence before re-opening.

[mikayla-maki]

Proposal reworked :)