Lexicon Embeds Overview

Discussion
1

ATProto’s inside out structure provides an opportunity for open, permissionless building on top of any component in the network, including its extensible data schema definition system, Lexicons.

One of the opportunities this presents is users sharing their data and records with multiple apps. Those apps may be direct substitutions (different clients for microblogging say), or apps that use that data in a variety of ways, such as Popfeed an app which aggregates posts about a variety of media types.

Separately ATProto apps provide mechanisms to embed other content types. Bluesky has an allow list for embeddable content (like youtube videos), or Leaflet.pub which has a variety of embedable block types that users can include when writing.

Many of us think this transcluding content can be made more powerful and we should discuss patterns for how ATProto apps might embed any record that has an at-uri.

So this is a call out for interest and questions!

10 Likes
2

I think we’re just going to have to show by doing and have Leaflet / Semble / Smoke Signal / Grain get this done.

2 Likes
3

The OpenAI Apps SDK also looks roughly what lexicon embeds might look like.

4

People like the leaflet quote stuff. I still think aside from Lexicon Embeds – which I consider advanced – extending OpenGraph makes cool interactive units available to any website on the internet.

5

Here is an updated proposal based on my Bluesky thread on this topic.

Proposal: Lexicon publishers should be able to publish an optional com.atproto.lexicon.web record that acts as a bridge between the AT Protocol and the HTTP web, defining how records in that lexicon should be displayed or embedded.

It would include:

  1. URL Template: A scheme for converting an at:// URI into a browseable HTTP URL (RFC 6570 URI Templates).

  2. oEmbed Endpoint: The service URL for fetching JSON embed data.

Workflow: When a client encounters an unknown custom record (e.g., com.example.music.rating):

  1. Finds the com.atproto.lexicon.web record (the same way it finds the com.atproto.lexicon.schema record)

  2. It hydrates the URL template.

  3. Path A (Simple): Fetch the HTTP URL to parse standard Open Graph meta tags.

  4. Path B (Rich): Pass the HTTP URL to the provided oEmbed endpoint for an interactive widget.

Example Record: A configuration for app.bsky.feed.post might look like this:

JSON

{
“lexiconId”: “app.bsky.feed.post”,
“urlTemplate”: “Bluesky,
“oembedApi”: “https://embed.bsky.app/oembed”
}

Rationale: The lexicon publisher is the ultimate authority on how their data should be presented to the user.

While there are valid concerns about centralization here—this does give the lexicon publisher control over the default web URLs—the reality is that publishers already exercise this control de-facto.

For example, bsky.app URLs are already the standard web representation for posts, and Bluesky already serves the OG tags and oEmbed endpoints. This pattern will likely repeat for every new social app built on a custom schema. This proposal simply formalizes that relationship, making the default presentation discoverable for any client rather than hardcoded.

3 Likes