Adoption of 3rd party lexicons

[ebwinters]

Goal of this discussion

I want to understand Bluesky's view is on integrating 3rd party lexicons into the social app, using community.lexicon's bookmark lexicon as an example

Motivation

3rd party lexicons, such as the ones maintained by lexicon-community could be leveraged for features inside of Bluesky without building custom lexicons. In this case, a highly requested bookmarking feature, which was implemented in inside the social app in this PR

Questions

• If Bluesky will support 3rd party lexicons, is there a process through which the team decides if it passes some quality bar?
• What steps can a developer checklist when creating a Bluesky compatible lexicon (i.e. must go through design review with xyz group, must publish a consumable package generated by lex-cli)
• Is there a path for developers to be able to use XRPC methods in the Bluesky app if a lexicon is supported? So as to avoid calling .repo methods for CRUD operations

[bnewbold]

There are two aspects to this:

• on principle, from a protocol and policy standpoint, is the Bluesky team open to using Lexicons not in the app.bsky.* namespace, and not controlled by Bluesky PBC, in the Bluesky Social app (mobile app, web app)?
• what is the process for getting features on the Bluesky Social roadmap, especially collaborations with external devs?

For the first, we have not done it yet, but there are no hard blockers. It is definitely part of the atproto vision to enable borrowing and cross-namespace use of Lexicons. We'd perhaps like to get the Lexicon Resolution system fully shipped: the protocol design is complete, but supporting tooling and SDK support hasn't been implemented yet. The social and process side of this is open ended, in that we don't have any formal process or criteria for making "reuse existing versus build-from-scratch" decisions, but i'm sure we can work it out over time.

For the second, I can't speak authoritatively for the product team, but I think the root of the question is around when bookmarks as a feature for the Bluesky app will get scheduled for implementation. There will be a lot that goes in to this apart from Lexicon design, and we have a lot of urgent issues and frequently-requested-features to prioritize between. We have generally avoided having structured public roadmaps of which features will be worked on in which order or on what timeline, because we are constantly re-prioritizing, and abandoning public deadlines is frustrating for everybody. Which I guess is another way of saying that we make these decisions internally and privately, and there isn't a process for external folks to get features scheduled.

At least for our own process, we usually do draft Lexicon schemas, but don't really "finalize" them until they have been implemented in both the client (front-end) and AppView (backend). We find that implementation results in corrections or small iterations pretty frequently. I'm not sure what that will mean for adopting existing Lexicons, other than that we will probably "give it a try" before fully committing to any specific Lexicon. We should probably publish a style guide, but this is probably going to be something like choosing software libraries: nothing is perfect.

I'm not sure what you mean by the last question, could you clarify? Are you asking whether other app developers can re-use the Bluesky AppView API endpoints (XRPC endpoints) in their clients?

[ebwinters]

Sure - the last question is more a technical question about lexicon method types and how they can be used in Bluesky. For bookmarking, I have a getActorBookmarks method schema, and I generated a client package using lex-cli to try and maintain the structure of atproto's client library. I found I can't actually use the generated client code (below) in Bluesky because the xrpc method for getActorBookmarks doesn't exist on the server - so I end up just using repo.list or repo.create

export class CommunityLexiconBookmarksNS {
  _client: XrpcClient

  constructor(client: XrpcClient) {
    this._client = client
  }

  getActorBookmarks(
    params?: CommunityLexiconBookmarksGetActorBookmarks.QueryParams,
    opts?: CommunityLexiconBookmarksGetActorBookmarks.CallOptions,
  ): Promise<CommunityLexiconBookmarksGetActorBookmarks.Response> {
    return this._client.call(
      'community.lexicon.bookmarks.getActorBookmarks',
      params,
      undefined,
      opts,
    )
  }
}

but I think the root of the question is around when bookmarks as a feature for the Bluesky app will get scheduled for implementation

let me rephrase #2: Is there/do you think there should be a set of guidelines for developing of a lexicon that you think should be followed before being supported in Bluesky? I.e. a lexicon-community schema can show we kept the schema open for discussion for some amount of days (30 I think), and publish a consumable types package generated using the lex-cli tool.

[erlend-sh]

what is the process for getting features on the Bluesky Social roadmap, especially collaborations with external devs?

There could be a lot more leeway in such a process if Bluesky formally adopted a Labs approach to community-contributed features. This notion has already proven effective at charting a middle path for the bookmarks implementation.