Impetus

The idea for these lexicons started with exploring what a standard for bookmarks would mean, beyond what already exists with community.lexicon.bookmarks. Wes and Micheal shared their thoughts about what this could look like back in June. They both explore the tensions of what bookmarking means in various contexts (e.g. bookmark as a reference, reading object, or snapshot) and the struggles of reconciling that.

I picked up where they left off, but soon realized that I don't think we are attempting to standardize bookmarking, per say, rather I think we are trying to reach consensus on a different set of affordances, being able to collect and organize varying sets of data/objects. Thus collections have quite a different intent and design space than a lexicon like community.lexicon.bookmarks, even if they can can represent similar things.

The goal of this proposal is to create a set of lexicons for end-users to collecting/organizing heterogeneous sets of things. While an atproto account's repo is already partitioned into homogenous collections, a group of records with the same shape, we lack affordances for looser forms of organizing data/objects, without needing to define _new_ lexicons on a case by case basis. The hope is that these lexicons facilitate more emergent types of interop between a more diverse set of apps.1

While the ambition here is for something generalized and thus abstract, there are a plethora of examples that can help us ground the design of these lexicons:

Lexicons

The first draft of the lexicon schemas can be found here and the design is elaborated on below:

community.lexicon.collections.collection

A collection is set of URIs that could represent a plurality of things. It has some basic metadata (although I wonder if it should include some more like an image, tags, etc.) and declares the URI schemes that indicated what is expected to be in this collection. This part is important because it provides a shortcut for indexes to know if they can display/operate on this collection without loading all of the items in it. Here are some examples:

Bluesky's private bookmarks could look like this:

{
  "$type": "community.lexicon.collection",
  "name": "bluesky bookmarks",
  "description": "private bluesky bookmarks",
  "schemes": [
    { "type": "at", "lexicons": ["app.bsky.feed.post"] }
  ],
  "createdAt": "2026-10-26T20:14:00.271Z"
}

By looking at the URLs that is classifying, we can say that a collection generated by Semble could look like this:

{
  "$type": "community.lexicon.collection",
  "name": "A semble collection",
  "description": "urls and stuff",
  "schemes": [
    "https",
    "doi",
    {
      "type": "at", 
      "lexicons": [
        "community.lexicon.collection", 
        "app.bsky.feed.post", 
        "site.standard.document", 
        "community.lexicon.calendar.event"
      ]
   }
  ],
  "createdAt": "2026-10-26T20:14:00.271Z"
}

Note that a collection can indicate that it contains other collections by specifying community.lexicon.collection in the at scheme.

It should be possible to collaboratively curate collections, which is why items are a separate record and collections declare how indexes should interpret access (e.g. open vs closed). Anyone can link items to collections that they did not create, collections determine whether those items should be included.

community.lexicon.collections.item

Items link back to the collection they are in, a contain a URI that points to the thing they are referencing, and some optional metadata. 

{
  "$type": "community.lexicon.collection.item",
  "uri": "at://<did>/app.bsky.feed.post/<rkey>",
  "collection": "at://<did>/community.lexicon.collection/<rkey>",
  "createdAt": "2026-10-12T20:14:00.271Z"
}

community.lexicon.collections.itemData

Metadata for items can show up in various ways:

  • some user-defined metadata is per item per collection

    • e.g. title, description, note fields

  • some user-defined metadata is per URI (multiple collections might have items with the same URI)

    • e.g. network.cosmik.card

  • some metadata is not user-defined, but derived from the URI itself

    • e.g. scrapping web metadata

  • some items might have multiple types of user-defined and derived metadata across different apps.

To account for this community.lexicon.collections.itemData should stay small, the rule of thumb is that it should only contain metadata (e.g. name and description) that can be used for display purposes across all use cases. All other metadata should be externalized to the community.lexicon.collections.itemData sidecar. itemData has the ability to link to an item directly (i.e. it's an AT URI to community.lexicon.collections.itemData) or can be applied across multiple items with the same URI.

Similar to site.standard.document the metadata field is left as an open union so that any type of metadata can be used. This means that community.lexicon.collections.itemData is a distribution lexicon that makes it possible for an app to know all of the metadata available based and use it based on it's shape rather than it's existence.

It is an anti-pattern to use the same TID between community.lexicon.collections.item and community.lexicon.collections.itemData because there could be multiple types of metadata per collection item.

{
  "$type": "community.lexicon.collection.itemData",
  "uri": "at://<did>/community.lexicon.collection.item/<rkey>",
  "metadata": {
    "$type": "some.type.of.metadata"
    ...
  },
  "createdAt": "2026-10-12T20:14:00.271Z"
}

community.lexicon.collections.list

Some collections might have a user-defined order instead of the default order based on the createdAt field. Similar to programming languages where collections are an abstract class of lists, this lexicon lets a user take an existing collection progressively enhance it with order. This could be used to sort an entire collection (although there is always the chance it becomes out of sync) pr a partial collection. An example of the later is a pinned section of a collection.

By design there could also be multiple lists (orderings) per collection.

{
  "$type": "community.lexicon.collection.itemData",
  "collection": "at://<did>/community.lexicon.collection.collection/<rkey>",
  "items": [
    { "uri": "at://<did>/community.lexicon.collection.item/<rkey>", "cid": "..."},
    ...
  ],
  "createdAt": "2026-10-12T20:14:00.271Z"
}

What's next

Firstly interested in hearing about more use cases, examples, and feedback about how the proposal, please join the conversation here. There are some open questions that still need answers as well:

  • finishing ironing out these lexicons

  • XRPC endpoints

  • best practices for apps operating on these lexicons

  • lexicons where metadata is existing standards (DOI, web scrapping, etc.)

  • moderating open collections