Social Graph Lexicon

[maxfzz]

Abstract

This RfC proposes a standardized approach to managing social graph relationships on the AT Protocol through a community-governed namespace, community.lexicon.graph.

Intent and Rationale

This proposal aims to provide AT Protocol services with a unified method for storing and accessing edges on a wide AT Protocol-based social graph as well as their relationship types. The status quo as of this proposal is that the largest ATP service, Bluesky Social, primarily uses the record types app.bsky.graph.follow and app.bsky.graph.block to establish a social graph on the AT Protocol. No other service currently implements a social graph, and most plans to implement one usually include borrowing Bluesky's social graph and underlying record types. In the spirit of lexicon.community, this social graph should be implemented within a community-governed namespace such as community.lexicon.graph.

Examples

Following Lexicon

{
  "lexicon": 1,
  "id": "community.lexicon.graph.follow",
  "defs": {
    "main": {
      "type": "record",
      "key": "tid",
      "record": {
        "type": "object",
        "properties": {
          "subject": {
            "type": "string",
            "format": "did"
          },
          "createdAt": {
            "type": "string",
            "format": "datetime"
          }
        }
      }
    }
  }
}

Block Lexicon

{
  "lexicon": 1,
  "id": "community.lexicon.graph.block",
  "defs": {
    "main": {
      "type": "record",
      "key": "tid",
      "record": {
        "type": "object",
        "properties": {
          "subject": {
            "type": "string",
            "format": "did"
          },
          "createdAt": {
            "type": "string",
            "format": "datetime"
          }
        }
      }
    }
  }
}

Example Block Record

{
  "$type": "community.lexicon.graph.block",
  "subject": "did:plc:z72i7hdynmk6r22z27h6tvur",
  "createdAt": "2024-12-01T17:25:54.382Z"
}

Implementation Details

The primary issue in changing the underlying record types for a social graph is the large amount of existing records using the prior record types within the Bluesky-controlled namespace. Will these records be left alone and treated as if they were community.lexicon.graph.* records by clients? Should servers automatically convert these records to the lexicon.community-controlled namespace? Is com.atproto.graph a more preferable namespace, considering the protocol-wide scope of the social graph? This issue could hinder further development of the community.lexicon namespace, and likely requires cooperation from the Bluesky Social developer team.

The proposal has been amended to more closely match the behavior of an "ATmosphere-wide" social graph Lexicon that service-specific social graphs can "override" with their own Lexicon. If User A blocks User B with a community.lexicon.graph.block record, this should have the same behavior as User A blocking User B on every AT Protocol service that is compliant with lexicon.community. The behavior for a community.lexicon.graph.follow record can be inferred. A repo's service-specific follow record for a user should be invalid if a "lexicon.community" block record exists on that repo for that same user. A repo's "lexicon.community" follow record for a user should be invalid if a service-specific block record exists on that repo for that same user.

[ngerakines]

I think these need to be scoped by how they are used and what they apply to. The simple solution to be scoping them to a single collection which is documented by the application(s) using them.

Not all applications want to share the same social graph. The people I follow on Smoke Signal will probably be different than I follow on bsky.app and the same for frontpage.fyi.

[maxfzz]

I can agree that having different social graphs for different services is ideal, but the use-case of following or blocking someone regardless of the service ("block everywhere") remains. I can envision this being used more for blocks than follows, but it is still a beneficial feature. In that vein, I suggest amending my original proposal to share similar ideas to my Profile Lexicon proposal; the Lexicon types under community.lexicon.graph would form a "base" social graph that is referred to in the absence of an edge on a service-specific social graph. As an example, if I blocked User A with a community.lexicon.graph.block record, this should have the same behavior as blocking them on every AT Protocol service that is compliant with lexicon.community. A repo's "service-specific" follow record for a user should be invalid if a "lexicon.community" block record exists for that same user on that repo. The behavior for a community.lexicon.graph.follow record can be inferred.

[maxfzz]

Open question: Are there other types of social graph edge types besides "following" and "blocking" that should be specified?

[maxfzz]

Maybe a trust/distrust system could be implemented under the graph namespace.

[essential-randomness]

Hello! I led a discussion on this Lexicon with my community like previously done with #9. Here's our comments on the current proposals, as well as some additions:

• A global blocking graph makes sense. Generally, a block is a very strong signal that you don't want someone to interact with you.
• A global following graph is more iffy. Different contexts have different implications for the type of content one publishes (e.g. a "personal blog" vs a "dating site" vs a "niche interest I'm ok with people knowing if they go look for it but I might not want to advertise site"). Especially for some of these cases, it's important that there be a specific consent to follow someone in that different context, even if it's a "follow all the same people" button.
• In our opinion, "follower" is better implemented as a trait (if we get the concept correctly): this way every service can surface who you're following, and that information can be used by other services to populate a "maybe you want to follow these people" list, but there's no automatic "this is my global following graph for every site I join".
• For new edge type, a mute edge might make sense. This is a bit weird until there's private PDSes since people seeing they're muted is ripe for drama (and supposedly when you mute someone you aren't as keen to burn bridges completely as with blocking). It could again be better as a trait too, since muting across services might not make that much sense.
• Speaking of consenting to following someone in a different context, a discoverability edge would be nice. With this edge, one could indicate if they want to be recommended to others when people join a service, or if they'd like to be kept out of recommendation systems.
• Another proposed edge was "pinned/starred/bookmarked" connections (we couldn't decide on a neutral-enough term), which could be prioritized when surfacing recommendations on different services. I don't think it'd make sense to start with having it, but it's a possible extension. Similarly, the idea of circles/lists was also proposed.
• Regarding the trust/distrust system, the main issue is "trust/distrust to do what?". Without a clear semantic meaning to the edge, it's hard for services and users to decide how to use it, and it would end up used in many different ways that are hard to tease apart.

Happy to work on more concrete proposal for any of these if there's interest!