Open Graph Protocol aka OGP https://ogp.me/ is used today by bazillions of web pages and the apps that generate them to expand/unfurl previews of the pages in lots of different contexts.
You put a few standard tags in the header of your HTML pages and various social apps then make previews out of them with text and images.
@rude1.blacksky.team asked me about this, so I’m going to write up my thoughts around this. What can we do about extending OGP (and the general model of header tags in HTML) for atproto apps / appviews to do interesting things with the display of links? And how can we do it so it can get to very wide support so you do nothing but modify HTML, but lead to potentially progressively more interesting things with “just” static HTML pages.
I’ve explored Open Frames (originally targeting the Farcaster ecosystem), and more recently have talked about Lexicon Embeds (original thread, WebTiles thread). Call those things “out of scope”, although Open Frames starts with vendored head tags so is the closest.
embed an atproto account to link to an author (basically, like mastodon) – with a way to one click follow or similar (or notification?)
supporting rich text links
embed an image gallery carousel
play a video or audio that isn’t hosted on a platform (this is kind of an EMBED category – embedding a player from eg. Vimeo or Bunny CDN, which is not quite the same thing as OGP – but appviews can allowlist more embeds)
show extended info kind of like Slack unfurls that leads to interesting layouts
So, the work to do here is
come up with an atoproto-vendered superset of OGP that does interesting things
modify / build a website embed fetcher (e.g. an open cardyb that Blacksky or microcosm could run? maybe also Tyler / Sill, or Semble?)
Why?
So that atproto apps can give creative toolkits to website builders without having to go full atoproto native. Artists, creatives, media, and others can start experimenting right away.
This feels like the all-important one to me. It’s such a cool feature for bloggers and journalists, helping get your name/profile more out there when an article is being shared beyond your own posts and immediate circles.
Not exactly sure how it’d look, but in addition to just the ‘by [atproto-acc]’ attribution, it’d be really cool if I could see at a glance that the article author did indeed share that link themselves in a recent post, so I can easily opt to reshare the original source.
Here’s what I’d personally find most useful as a first, shippable iteration:
Start with an ogp+atproto minimal spec
Rather than designing something totally new, define a tiny, conservative superset of OGP that appviews can start experimenting with:
meta name="at:author" content="at://did:plc:…" – canonical atproto identity for the page author, for both attribution and follow UI.
meta name="at:author-handle" content="@name.bsky.social" – optional, for nicer display and easier debugging by humans.
meta name="at:embed:kind" content="gallery|audio|video|article" – hint to appviews about the preferred card layout (gallery carousel, audio player row, etc.).
meta name="at:embed:feed" content="at://…" – optional link to a feed or collection that this page “belongs to” (series, tag, publication), so appviews can show “More from this series”.
That keeps the initial surface area small but already unlocks several interesting behaviors without new protocols.
Then make “author unfurl” the flagship feature
I agree that the author account embed is the killer feature here. A concrete behavior I’d love to see:
When a link is shared, the card shows By @author with avatar + display name, derived from at:author / at:author-handle .
The following is harder, but would be so cool:
If I don’t follow them yet, the card offers a single-tap “Follow author” affordance.
If the author has posted this URL in the last N days from that handle, show a “Originally shared by @author” state with a one-click “reshare original” button.
This directly incentivizes writers and journalists to add those tags, because it turns every share into a growth surface for their atproto identity, not just their site traffic.
Progressive enhancement rules for appviews
To keep things sane for implementors, I’d suggest some explicit fallback rules:
If no at:* tags exist, treat it as plain OGP and render the classic link card.
If at:author is present but unknown/404, just show a neutral “Byline not verified” state instead of erroring, or simply not display it at all.
If at:embed:kind is unrecognized by an appview, ignore it and fall back to a standard card rather than hiding the preview.
That way, authors can safely experiment with new tags without breaking anything for users on older clients.
Does this get at being able to have an ecosystem of mini app builders like Farcaster has? Personally less interested in the attribution stuff and more interested in recreating the magic of custom feeds. And particularly wondering if it’s possible to introduce social games that can be embedded in posts
As @erlend.sh has answered for me, yeah, that’s the more complex path of WebTiles.
My thinking with starting with OGP is getting a media system up and cranking.
Wordpress plugin, Ghost support, Substack, Medium, 11ty and Astro add ons - basically a very low barrier to entry that sits closer to the realm of designs and media people for rich feed units. HTML and some images in the header are the only knowledge required.
The author display is an example of a product feedback loop. If integrating this grows your audience and grows click throughs, people will do it.
Lexicon Embeds / mini apps means growing a dev ecosystem and tools around it - which is totally doable and I want to do that - but it will grow slower because it takes more work. LLMs will in part solve this …
Thanks for this! Yes this is the structured version of what I had in mind.
Aram and I had a multi threaded back and forth and says we should just use Schema.org instead, because all the big media companies use it because it’s required for search indexing AND it’s a maintained spec rather than abandoned like OGP.
My perception has been coloured by both what Open Frames did and that OGP just “feels” simpler?
anyway @pixeline.be - I think you’ve scope a nice minimal thing here, appreciate it.
I get the intent here and the app / client could do this in some way (maybe constellation) - but at its maximum popularity many more people will share the link themselves.
Specifying display rendering and the smallest set of client affordances will help. Glad that you resonated with the author use case - it’s also my thinking of leaning into client affordances that already exist!
I guess I also felt for the simpler feel of OGP and was unaware it’s a facebook creature that hadn’t evolved in ages. Schema.org is much less known beyond tech folks but it is solid at least and it does make a lot of sense. So, back to the drawing board…
If we lean into Schema.org, I could imagine a very small atproto-flavoured profile for common types (Article, VideoObject, AudioObject) with just a couple of extra fields for author identity and maybe a “series/feed” pointer. Something like a JSON‑LD block that publishers / plugins can copy‑paste, where:
the card content comes from standard Schema.org fields (headline, image, description, datePublished, etc.), and
atproto‑specific bits are namespaced propeerties on the author and/or the page.
For example, a bare‑bones “Article” could look like:
Appviews that understand the atproto:* properties can upgrade the card with author avatar + follow button and a more from this series link, while everyone else just sees standard Schema.org.
I think that would be very cool. Not really sure how to get that ball moving though…
It’s important to include something like atproto:site in this, as well. For example, if I’m posting in my personal blog I’ll only use atproto:did and `atproto:handle’ because I’m the explicit owner of that web property.
But if I have a guest post on another blog, e.g. gamedeveloper.com, GD will also want their attribution to make this a worthwhile implementation for them. For articles, Schema.org provides the Article.publisher and Thing.owner fields for this.
To support this in @pixeline.be’s example, we’d actually need to extend Organization to also have the atproto:did and atproto:handle fields. This is necessary work anyway since the author field can be either a Person or an Organisation.
If I do, it won’t be for a couple of weeks. I’m trying to limit my code contributions to HappyView and related work ahead of AtmosphereConf. I just wanted to weigh in here because I’ve been involved in some work towards Schema.org and OGP adoption at various orgs, and I did a fair amount of work with JSON-LD the year before last.
Yep, that’s fine … wanted to kick off this discussion, and the next would be working through this spec in a way that converges / reaches consensus. Appreciate your comments!
