Atproto is a filesystem of the social internet. Just like how in desktop computing there isn't a single app to view or modify the files on your computer1, with atproto there is not a single social media platform that controls access to our social data and the interfaces that we use to inhabit digital spaces. In practice, there are any number of apps and websites that people are using. This is great, end-user's deserve new forms of agency in a world filled with increasingly hostile and closed platforms!

But there is simultaneously an unrealized story of interop that results from such an open ecosystem. End-users's are using the URLs of these apps for all kinds of interactions like pasting a link to embed a quote post on , bookmarking links on , paste links into a document, etc. But, so far, not all links are being treated equally.

Take, for example, these URLs of a Bluesky posts:

They all point to the same underlying AT record, they even have the same URL structure. But pasting these links into different post editors will result in different embeds; some an actual quote post, others an Open Graph preview. Behind the scenes each app has special handling to try to parse the AT URI for a predetermined set of URLs. Many apps across the Atmosphere do have these types of integration and they bear the choice of who to integrate with and the burden of keeping those lists up to date.

A consequence of this is the network effect that emerges where the most popular Atmosphere apps are prioritized with these rich integrations and the long-tail of other apps/websites lose out – existing popularity unintentionally reinforces future interop.

This particular network effect is not inevitable though, we can widen the interoperability the ecosystem needs, while also minimizing the burden placed on actors in the ecosystem to interop from both sides. The problem is that any URL can be referencing an underlying AT record and there is no general way to parse that directly from a URL. There is a disconnect between the social filesystem and the ecosystem trying to interoperate on top.

To solve this, the community has drafted a proposal for web pages to be able declare the AT URIs they are referencing.2

<!-- AT records that denotes the exist of a web page -->
<meta name="at:canonical" content="at://did:plc:abc123/nsid/rkey" />

<!-- AT records that are referenced but auxilary. -->
<meta name="at:alternate" content="at://did:plc:abc123/nsid/rkey" />

<!-- The account(s) that authored the web page. -->
<meta name="at:author" content="at://did:plc:abc123" />

<!-- The account(s) that own/made the website. -->
<meta name="at:me" content="at://did:plc:abc123" />

This idea is not new, it's been discussed and implemented on a few different occasions:

  • There is an old discussion about a atprotocol:creator tag,  used to provide it.

  • The documented a rel="atproto" tag.

  • Miscellaneous apps like Bluesky and Leaflet use rel=alternate with an AT URI.

  • uses their own <link> tags to bidirectionally verify the web page to it's corresponding AT record.

The community proposal attempts to address all of these uses with a small surface area and fix the errors that were popping up when AT URIs are used in <link> tags. And... a couple of days after the first draft was announced there are close to 20 atproto apps that implemented the proposal! As says, the Atmosphere has strong asabiyyah.

The initial reception has been wonderful, but there is still much work ahead. The interop that this proposal enables is only as powerful as the communal practice that forms around it. I'd love to continue seeing more apps producing and consuming these tags. There are already a bunch of ways that these tags are finding use:

  • turning URLs into rich embeds

  • verification

  • redirecting links to apps end-users prefer

  • reducing the amount of websites you have to log into

    • e.g. using a web extension to like/subscribe/comment to personal blogs using standard.site

  • notifying authors when their web pages have been linked

  • links from personal websites can have the same rich integrations as apps

And I'm certain the community will find more fun and surprising uses! If you have feedback on the proposal please don't hesitate to reach out. And if you end up implementing this for an app or project make sure to ping me on bluesky and I'd love to highlight it!