Extensible, user-defined curation mechanism

[imw]

In this proposal, we (myself and @MrChico) imagine an AT Protocol extension that allows for powerful, novel feed curation mechanisms. In particular, we propose a system that would transform the nature of online relationships from a simple broadcast dynamic to a much richer and more nuanced conversational dynamic. While Bluesky already supports creating custom feeds via feed generators, and even allows for the inclusion of post metadata via tags, there is presently no way for users to emit information regarding the intended reach of their posts.

Essentially, what is proposed here is a mechanism by which the 'speech' layer of the AT Protocol can effectively signal to the 'reach' layer. By optionally including such information at a protocol level, a vast array of new feed modulation techniques become possible - most notably, that the 'follow' relationship can transform from a binary to a scalar value.

Of course, what is presented here is just an idea, and our intent here is to start a conversation around the minimal set of additions to the protocol that would allow not just for 'moderation' but also for 'modulation', i.e. controlling the volume of one's own voice.

Description

We propose a curation mechanism based on assigning weights the people that you follow and to individual posts, which we call gain and level. A basic relevancy ranking of a post would then simply be the product of these two quanties:

$$relevancy = gain \cdot level $$

gain – Follower weight

Instead of the binary relation of following or non-following, a user may assign a gain value between 0 and 1 to other users. This indicates their interest in seeing that persons posts; how their posts should be valued in your feed.

level – Post weight

Anytime a user wants to make a post, they assign a level to that piece of content, indicating to their followers how strongly they believe that their followers should see it. Later, when calculating post relevance, this value can readily be normalized between users for a given timeframe.

Relevancy

Let's refine our relevancy calculation above to include level normalization over a time window t_2 - t_1and note a few things:
$$relevancy = gain \cdot \frac{level}{\sum_{t1}^{t2}{level}} $$

First, it is important to notice that this score is not universal; when we speak of relevancy of content it is always with respect to a user, just as gain is a relation between users.

Second, what we imagine here is an extensible curation mechanism, in other words, a set of tools and customs which lets users define their own relevancy ranking based on commonly accepted variables.

With the quantities of level and gain in place, it is easy to imagine other relevancy ranking algorithms: those that favor quieter voices, or users' self-selected best posts, or even interpolate likes and reposts with gain as indicators that a piece of content should be treated as relevant.

Implementation

The following protocol sketches are intended to help elucidate how this proposal might be implemented. Of course, it is possible that other, and perhaps better, implementations can be thought of. Our hope is that this can be a starting point for conversation.

gain

Updates to the gain value applied to a particular actor are also emitted to the network, in keeping with the design philosophy of account portability.

{
  "lexicon": 1,
  "id": "app.bsky.modulation.updateActorGain",
  "defs": {
    "main": {
      "type": "procedure",
      "description": "Changes gain applied to network actor. Requires auth.",
      "input": {
        "encoding": "application/json",
        "schema": {
          "type": "object",
          "required": ["actor","gain"],
          "properties": {
            "actor": { "type": "string", "format": "at-identifier" },
            "gain": { "type": "integer", "minimum": "0", "maximum": "100" }         
        }
      }
    }
  }
}

Note that we can interpret ordinary follow events as having maximum gain of follower to followee.

level:

Level records would be emitted alongside posts or other objects in order to communicate the intended level for a particular piece of content:

{
  "lexicon": 1,
  "id": "app.bsky.modulation.level",
  "defs": {
    "main": {
      "type": "record",
      "description": "Set the output level of a piece of subject content.",
      "key": "tid",
      "record": {
        "type": "object",
        "required": ["subject", "createdAt", "level"],
        "properties": {
          "subject": { "type": "ref", "ref": "com.atproto.repo.strongRef" },
          "createdAt": { "type": "string", "format": "datetime" },
          "level": {"type": "integer", "minimum": "0", "maximum": "100"}
        }
      }
    }
  }
}

Pseudo algorithm

In a bit more detail, here is a suggested algorithm for calculating the relevancy of content to a user u

1. Choose a time window of posts to rank.
2. For each user v to which u has assigned non-zero gain:
   2.1. Set g to the gain of u assigned to v
   2.2. Sum the level of all posts from this time period to tot_level.
   2.3. For each post p, assign the relevancy g * level_p / tot_level

Next Steps

As relative novices to the Bluesky/ATProto ecosystem, we thought it prudent to seek early feedback/critique for this idea. We attempted a crude implementation, but got bogged down in the intricacies of bundling a novel addition to the lexicon. We thought the idea was worth sharing nonetheless, and would be happy to hear your thoughts and feedback!

[bnewbold]

This is really cool! An interesting way of thinking and should work as an extension to the lexicons, especially as this is context mostly consumed by feed generators.

Some quick notes:

• as you've probably discovered, we don't support floats in the data model 😿. integer ranges are a good workaround
• I would be bold and put this in your own lexicon namespace! eg, not in app.bsky.*. you should use a domain name you control, so that you can register/host the lexicons once lexicon resolution is implemented (and specified)
• a trick we have used a couple times for "sidecar" record types, like modulation level, is to specify that the record-key (rkey) of the sidecar record must exactly match that of the corresponding post record in the same repo. instead of having a URI reference from the "level" record pointing at the post record. this makes it easy to fetch a "level" record when you know the post (eg, fetch both together), and makes it impossible to have multiple "level" records for the same post. Not sure if this will be a long-term design pattern, but it works right now.
• "bogged down in the intricacies of bundling a novel addition to the lexicon": we will have some examples coming out soon on how to do new lexicons, especially using the TypeScript APIs
• we have OAuth rolling out soon, at least in a dev preview phase, which should make it easier to build quick web interfaces to create/update records
• just as my own opinion (not protocol guidance), maybe "gain" could be replaced or complemented with a "budget" or "quota" for how many posts to include per user? "gain" implies that there still might be an arbitrary number; in some cases you might want to say "show me at most 3 posts a day from this user", regardless of how many posts from other users are available to be included

[bnewbold]

oh, shit, also, you are isaac wilder! what's up it has been a long time!

[imw]

Hi Bryan! It sure has been :-) Hope you're well.
Thanks for the feedback, and great job with Bluesky. It's been cool to see it evolve.

We may circle back in a bit once the examples for how to do new lexicons are available. In the meantime, if these ideas are useful/interesting to anyone reading this, please feel free to run with them!