This month, we — the creators of , , and — announced , a set of shared standards for longform publishing on the open social web:
At its core standard.site is a set of AT Protocol lexicons for:
publication metadata: what a publication is, like its name, description, and basic theme
document metadata: basics of what a given post contains, with content optional
subscriptions: records of who’s following a given publication
TL;DR — [standard.s…
This month, we — the creators of , , and — announced , a set of shared standards for longform publishing on the open social web:
At its core standard.site is a set of AT Protocol lexicons for:
publication metadata: what a publication is, like its name, description, and basic theme
document metadata: basics of what a given post contains, with content optional
subscriptions: records of who’s following a given publication
TL;DR — standard.site makes it easier for platforms and publications to coordinate and build cool things together!
The initial focus is facilitating interoperability around content discovery and social features like subscribing and commenting.
Importantly, this is not a standard for site content.
We each want to explore different things with our platforms, from block-based editors to unique theming. We also want to make it easy for existing sites to adopt without fully syndicating content.
Publishing apps can implement to make content discoverable across platforms, so we can build a richer ecosystem together.
Individual sites can publish records — WordPress, self-hosted, wherever, from indie blogs to big publishers — to give their content a presence on the open social web.
See below for examples of what folks are doing with this already!
⁂ ⁂ ⁂
Leaflet has migrated to standard.site!
We’ve just finished our migration to standard.site lexicons! This was a big project, to our knowledge one of the largest schema migrations in the atmosphere so far.
How it works, TL;DR:
We’re migrating relevant records for publications, documents, and subscriptions; Leaflet-specific records (e.g. for document content) remain the same
For now we’re also keeping all existing Leaflet records around, so that other tools querying them won’t break
We’ve run this migration proactively for folks with active sessions; otherwise it’ll run the next time you log in
What to know — readers and writers:
No need for you to do anything special — just log into Leaflet! We’ll handle the relevant migrations automatically.
What to know — Leaflet tinkerers:
If you’ve built apps or custom integration apps that use Leaflet records, ping us if you need help migrating to use standard.site records. We’ll figure it out together!
⁂ ⁂ ⁂
An ecosystem emerges…
2026 is the year of atproto publishing — many are saying this!
In just the first few weeks, we’ve seen a strong positive reception for standard.site and adoption by both platforms and individuals:
Publishing Platforms
Several other publishing platforms have implemented, or have indicated they’re working on it:
Publishing Platforms
Several other publishing platforms have implemented, or have indicated they’re working on it:
Aether OS — planned
Blento — recent posts list
The Blogosphere
Individual blogs are starting to adopt, too!
The Blogosphere
Individual blogs are starting to adopt, too!
— Standard.site: the Publishing Gateway
"At this point I started to question the value of all of this given the amount of work it took to get what I wanted, but in the end we had something special. Within a week, my site had actually turned ATProto into a CMS. I could make posts, update them, or delete them, and all the while these updates are broadcasted to a network that anyone could index. It was like an RSS feed that because it met a standard could be aggregated with a single tool. When I sign into my site using my own PDS and make posts, it’s totally independent. I have total control over everything. The hype of Standard.site was starting to click."
also tinkering!
Once upon a time, I had a local mirror of medium.com, collected by scraping the sitemaps. Imagine the potential for interoperability, portability, accessibility, and archivism if @standard.site had been around. How safer all that knowledge would have been from disappearing behind a paywall.
Community Tools / Apps
Finally, we’re seeing some awesome community tools emerge for things like discovery, search, and more, like:
Community Tools / Apps
Finally, we’re seeing some awesome community tools emerge for things like discovery, search, and more, like:
pub search — search across all standard.site compatible atproto publishing platforms, from
potatonet.app — "read-it-later social network", working on standard.site search + subscription management, from
AT Sites — listings and feeds for standard.site publications, from
What’s more:
⁂ ⁂ ⁂
Open social publishing — blogosphere to atmosphere!
With standard.site we can make atproto publishing platforms more interoperable — and we can make it easier to bridge between atproto and the rest of the internet, both platforms and individual sites.
For example, Leaflet and Pckt can both render previews of posts created on the other platform — and by Offprint, or anyone else — in our respective Reader pages. Others can make entirely separate readers, or search engines, or bookmarking tools (to name a few examples already emerging!) and all experiment with different features and ways to add value for readers and writers.
We’re particularly excited about how standard.site offers publishers a flexible way to bring existing publications onto atproto.
We see this as complementing, not replacing, existing standards for the open web. You can still use RSS! This gives publications a standard social layer, wherever they may live.
If you have a self-hosted static site or WordPress blog, you can publish these records to make your site discoverable on atproto, without having to migrate your content.
We also want to make it easier for existing sites to both implement standard.site and layer on social pieces like comments and subscriptions. If that sounds interesting, reach out, let’s chat!
⁂ ⁂ ⁂
Open questions and things to explore further
We intentionally started with a pretty minimal set of lexicons, and we’re already seeing a lot of good questions and suggestions for extending and improving standard.site, like:
How should platforms treat posts made elsewhere in discover / reader…render the full post? preview + link? something else?
How should we go about collectively evolving these standards, e.g. adding new lexicons like authors or content types or alternate URLs or other social primitives like comments?
We developed standard.site collaboratively, and intend to evolve it collaboratively as well — what should governance look like?
Can we get larger publishers and platforms onboard? What paths for adoption might make the most sense?
Please let us know any thoughts on how we can make Leaflet + standard.site work better, and tag on Bluesky for questions / ideas.
There’s also an open Signal group for folks interested in more detailed discussion on lexicons, implementation, and so on.
Thanks and for joining together to get this off the ground. Excited to see what everyone continues to build!
Subscribe to Leaflet Lab Notes
to get updates in Reader, RSS, or via Bluesky Feed