There's something quietly revolutionary happening in the AT Protocol ecosystem, and most people aren't paying attention to it. Which is fine, honestly – revolutions don't need an audience to be meaningful. But this one's worth understanding, because it's solving a problem that's plagued decentralised systems since... well, since we started building them.

I'm talking about standard.site, and before you click away thinking this is some dry technical specification document (it sort of is, but bear with me), let me explain why this matters – particularly when you're someone who sits at the intersection of two groups that rarely overlap: ATProto developers and writers actually using these platforms for their own work.

Because here's the thing that makes this particularly exciting for me: I'm not just building on AT Protocol (I'm part of @jollywhoppers.com, I've been working on various ATProto projects), and I'm not just theoretically interested in long-form publishing infrastructure. I'm actively using @leaflet.pub for this blog. I'm both a builder and a user. And standard.site is one of those rare coordination efforts that makes both sides of my brain light up.

The Problem Nobody Wanted to Acknowledge

Here's the thing about building on open protocols: everyone starts with the best intentions. You're going to build something better, more open, more user-respecting than the centralised platforms that came before. You define your data structures, you write your schemas, you implement your features. And it works! You've built a blogging platform on AT Protocol, or a document system, or whatever your particular vision happens to be.

Then someone else builds something similar. They've also defined their data structures, written their schemas, implemented their features. And it also works! Except... their data structures are slightly different from yours. Their schemas use different field names. Their implementation makes different assumptions about what a "publication" or a "document" actually is.

Both of you are technically correct. Both of you are building on the same protocol. But your systems can't actually talk to each other meaningfully, because you've made different choices about how to represent fundamentally the same things.

This is the coordination problem, and it's boring as hell until you realise it's the difference between a protocol that enables genuine portability and a protocol that's just decentralisation theatre.

What Standard.site Actually Does

Standard.site is, at its core, a coordination mechanism. Not a standards body (they're explicit about this – minimal governance, coordination through adoption rather than committee). Not a platform. Not even really a product in the traditional sense.

It's a shared set of lexicons for long-form publishing on AT Protocol. Which sounds incredibly mundane until you understand what that actually enables.

Three platforms are working on integration: Leaflet.pub (which I use for my blog), pckt.blog, and offprint.app. More are apparently coming. Each of these platforms does something different, has different features, makes different design choices. But they're aligning on the same basic schema for what a publication is, what a document contains, where it lives.

This means – and this is the bit that actually matters – your content will be portable between them. Not in the theoretical "you can export and import" sense that we've been told about for decades whilst watching platform after platform lock us in. But actually portable. Your publication record points to your domain. Your documents have consistent metadata. If you decide Leaflet isn't working for you and you want to try pckt.blog instead, you'll be able to just... move. Your audience follows you because your identity is yours, your content follows you because the schema is shared.

(According to Leaflet, users won't need to do anything when the integration happens – it'll happen at the platform level, which is exactly how this should work.)

The Principles That Matter

Standard.site is guided by four principles, and I think they're worth examining because they reveal something about how to actually build coordination mechanisms that work:

Unified discovery – one schema for indexers and tooling. If you're building something that needs to find and display long-form content on AT Protocol, you don't need to support three different lexicons. You support standard.site and you've covered multiple platforms.

Content portability – users move between hosts without losing their content, audience, or metadata. This isn't a nice-to-have feature. This is the entire point of building on open protocols in the first place.

Community ownership – maintained by the developers building on it, not controlled by any single platform. Which is crucial, because the moment one platform starts controlling the standard, you're just back to centralisation with extra steps.

Minimal governance – coordination through adoption, not committee. The schema evolves as the ecosystem does, which is a much more pragmatic approach than trying to design everything perfectly upfront and then fighting about edge cases for years.

These aren't revolutionary ideas. They're just... sensible. Which is probably why they're working.

What This Enables (and What It Doesn't)

Here's what standard.site actually specifies: metadata. What a publication is (a URL, a name, optional icon and description, optional theming). What a document contains (a site reference, a title, publication date, optional description and cover image). How to verify the connection between your records and your domain (.well-known endpoints and HTML link tags, because of course).

What it doesn't specify: content format. That's deliberately left to each platform. Leaflet uses its own document structure. Other platforms might use different formats. Standard.site doesn't care, because that's not what it's trying to coordinate.

This is actually quite clever – and I can appreciate it from both angles. As a developer, I love that it's focused and modular. It solves one problem (metadata coordination) really well, without trying to solve every problem. The scope is tight, the lexicons are independent, and platforms can adopt incrementally.

As a writer, I love that this means platforms can still innovate on the things that matter for the writing experience – the editor, the rendering, the features – whilst coordinating on the infrastructure layer that makes portability possible.

By focusing only on the metadata layer – the structural information that makes discovery and portability possible – standard.site avoids the trap of trying to standardise everything. Platforms can still differentiate themselves, still experiment, still build the features they think are important. But the underlying structure is consistent enough that content can move between platforms without being completely lost in translation.

It's the right level of abstraction. And you only really appreciate that when you're both building things that need to interoperate AND using the results of that interoperability for your own work.

Why This Will Work as a User

I use Leaflet.pub for my blog. It works well – the editor is clean, the rendering is solid, and everything lives in my PDS the way it should. But the real value isn't just that Leaflet works. It's that when Leaflet integrates standard.site (which they're planning to do), my content won't be trapped if I ever need to move.

With standard.site integration, the metadata layer will be portable. My publication record, my document records, the connections between my content and my domain – all of that will follow standard.site's schema. Which means other platforms that implement the same standard will be able to understand my content without needing to know anything specific about Leaflet.

And here's the crucial bit: according to Leaflet, I won't need to do anything when this integration happens. The platform will handle it. I won't need to migrate my content, update my posts, or change how I write. It'll just... happen. Which is exactly how infrastructure should work – invisibly, until you need it.

Why This Makes Me Unreasonably Excited

Look, I need to be honest about something: the intersection between "people who build things on AT Protocol" and "people who actually use long-form publishing platforms built on AT Protocol for their own writing" is... small. Vanishingly small, honestly.

Most developers building on the protocol are focused on the technical challenges, the infrastructure, the tooling. They're not necessarily sitting down to write blog posts on the platforms they're building. And most writers using these platforms aren't diving into the lexicon specifications, thinking about schema design, or getting excited about metadata coordination mechanisms.

But I'm in both groups. I've been building with AT Protocol for a while now – working on projects with Jollywhoppers, creating integrations, thinking about how the protocol can enable new kinds of applications. And simultaneously, I'm using Leaflet for this blog. Writing regularly. Experiencing the platform as a user, not just as someone theoretically interested in how it works.

And this is where standard.site becomes genuinely thrilling in a way that's probably only exciting if you're in this particular intersection.

Because as a developer, I understand why this coordination matters. I know what it's like to build tooling and have to make decisions about which schemas to support. I know the pain of ecosystem fragmentation, of everyone defining their own slightly different versions of the same fundamental concepts. I know how much friction that creates, how much it slows down the ecosystem, how much it limits what's possible.

But as a writer, I also understand the impact of that coordination. I'll experience it directly when Leaflet integrates standard.site. My content will become more portable. The tools people build to work with standard.site will automatically work with my blog. The discovery mechanisms, the indexers, the aggregators – they'll all just work, because we're coordinating on shared schemas.

And that's the exciting part – not just that it'll work eventually, but that I can see it coming. I can watch the coordination happening in real time. I can see Leaflet planning to integrate, pckt.blog and offprint.app doing the same, and know that when it happens, I'll benefit from it both as someone building on the protocol and as someone using platforms built on it.

It's one thing to understand the technical value of coordination mechanisms. It's another thing entirely to use a platform daily for your writing whilst simultaneously understanding the infrastructure that makes it work and anticipating the improvements that coordination will bring. The two perspectives reinforce each other in ways that are genuinely exciting.

I get to see both sides: the elegance of the technical solution (minimal governance! coordination through adoption! modular lexicons!) and the practical reality of what it'll mean for using something built on that solution (my blog! working! portably! with proper metadata!).

This is rare. And it's brilliant.

Coordination Isn't Just About Technical Compatibility

Here's the thing: coordination isn't just about making sure different platforms can read the same data structures. It's about reducing friction. Every time someone builds a new tool for AT Protocol – an indexer, a discovery service, a client, whatever – they have to decide which schemas to support.

If everyone building long-form publishing platforms is using their own bespoke lexicons, that tool builder has to either support all of them (exhausting) or pick favourites (fragmenting). Standard.site means tool builders can implement one schema and cover multiple platforms. Which means better tooling gets built faster. Which means the ecosystem grows more effectively. Which benefits everyone, even people who aren't directly building anything.

And here's where the dual perspective gets really interesting: as a developer, I know exactly how much work goes into supporting multiple schemas. I've been there. I've written the code that has to handle three different ways of representing the same concept. It's tedious, it's error-prone, and it slows everything down.

But as a writer using Leaflet, I also anticipate the direct benefits of not having that fragmentation. When Leaflet integrates standard.site and someone builds a discovery tool or an indexer or a reader app that supports it, it'll automatically work with my blog. I won't need to lobby them to add Leaflet support. I won't need to wait for them to prioritise my platform. It'll just work, because we'll all be coordinating on shared schemas.

This is what makes coordination exciting rather than just technically necessary. It's not abstract infrastructure work that might theoretically benefit someone someday. It's concrete improvements that I'll experience directly, both when I'm building things and when I'm using them.

Verification and the Domain Connection

One detail that's worth highlighting: standard.site isn't just about data portability, it's about verifiable data portability. The verification system works through two mechanisms:

For publications, you add a /.well-known/site.standard.publication endpoint to your domain that returns the AT-URI of your publication record. This proves you control both the domain and the atproto identity.

For documents, you add a <link> tag in your HTML that references the document's AT-URI.

This bidirectional verification – the atproto record points to the domain, the domain points back to the record – is crucial. It means you can trust that a publication or document claiming to be associated with a particular domain actually is. No DNS spoofing, no fake records, no confusion about what belongs where.

(Leaflet will presumably handle this for users automatically when they integrate, which again is exactly how it should work – the complexity is abstracted away, but the security guarantees remain.)

The Lexicons Themselves

I won't reproduce the entire schema here (you can look it up on standard.site if you're curious), but the basic structure is straightforward:

site.standard.publication defines what a publication is. Required fields are the URL and name. Optional fields include icon, description, basic theming (background, foreground, accent colours), and preferences.

site.standard.document defines what a document contains. Required fields are the site reference, title, and publication date. Optional fields include path, tags, content reference, description, cover image, and a reference to the Bluesky post if you've shared it.

There's also site.standard.graph.subscription for declaring subscriptions to publications, and site.standard.theme.basic and site.standard.theme.color for the theming system.

It's all quite modular. You can implement just the bits you need. Want to support publications but not documents? Fine. Want to add theming support later? Also fine. The lexicons are independent, designed to be adopted incrementally rather than requiring all-or-nothing implementation.

Why This Matters for the Ecosystem

AT Protocol is still relatively new. The ecosystem is still finding its shape. And one of the questions that keeps coming up is: how do we build things that are actually interoperable rather than just theoretically interoperable?

Standard.site is one answer to that question. Not the only answer (there are other coordination efforts happening in different areas), but a working example of how developers can align on shared needs without requiring central control.

The alternative – everyone defining their own schemas and hoping things work out eventually – is how we ended up with RSS and Atom both existing, with half the ecosystem supporting one and half supporting the other, with endless edge cases and compatibility problems. Standard.site is an attempt to learn from that history and coordinate before we have multiple competing standards for the same thing.

(Though, to be fair, the fact that it's called "standard.site" and is explicitly described as a standard whilst simultaneously insisting it has minimal governance and coordinates through adoption rather than committee is... a bit funny? But I suppose "coordination-through-adoption.site" doesn't have quite the same ring to it.)

The Platforms Integrating It

Leaflet.pub is one of the three platforms planning to integrate standard.site. It's a long-form publishing platform where everything lives in your atproto account – your content, your metadata, everything. The editor is clean and functional, and the integration with Bluesky works well (posts about your articles can show up with proper context, which is neat).

offprint.app is one of the platforms working on integrating it, whilst pckt.blog already has it done. I haven't used either of them myself, so I can't speak to their specific approaches, but the fact that three different platforms are coordinating on the same schema suggests that developers building in this space recognise the value of not fragmenting unnecessarily.

More platforms will likely adopt it over time. Or they won't – adoption is voluntary, after all. But seeing this early coordination is encouraging.

What Comes Next

standard.site is still evolving. The schema will probably expand as platforms identify new shared needs. More platforms will likely adopt it. And there might be other coordination efforts that emerge for different types of content.

The interesting question is whether this model – minimal governance, coordination through adoption, maintained by the developers building on it – actually scales. Can you have a standard that evolves organically without eventually needing more formal governance? Or will there be a point where the lack of a central authority becomes a problem rather than a feature?

I don't know. Nobody knows yet. We're still in the early experimental phase where informal coordination works because the community is small enough that everyone can more or less talk to everyone else.

But for now, standard.site is doing something valuable: making it possible for multiple platforms to coexist on AT Protocol whilst actually being interoperable in practice, not just in theory. And that's more important than it might sound.

Should You Care About This?

If you're building on AT Protocol, absolutely. If you're building anything related to long-form publishing, documents, or publications, you should probably implement standard.site from the start. Save yourself (and everyone else) the headache of supporting multiple schemas later. Trust me on this – I've seen both sides of the coordination problem, and it's much easier to start with a shared schema than to retrofit compatibility later.

If you're a user rather than a developer... you probably won't interact with standard.site directly. You'll just use platforms that implement it, and benefit from the portability and interoperability without needing to think about the underlying coordination mechanism. Which is sort of the point – good infrastructure is invisible.

As a Leaflet user, I won't be doing anything different when standard.site integration happens. But I'll benefit from knowing that my content is structured in a way that other platforms can understand. That if I ever need to move, the path will exist. That the ecosystem is building towards genuine interoperability rather than just talking about it.

And if you're in that rare intersection – if you're both building on AT Protocol and using these platforms for your own work – then you already know why this is exciting. You've probably already read the lexicon specifications. You've probably already thought about how this affects your projects. And you're probably quietly thrilled that coordination is happening before the ecosystem fragments irreversibly.

(It's a good place to be, honestly. You see the technical decisions that will make the user experience better, and you'll experience the user benefits that make the technical decisions worthwhile. The two perspectives inform each other in ways that make both more meaningful.)

If you're neither building on AT Protocol nor particularly interested in decentralised social protocols... well, you probably stopped reading several paragraphs ago, which is fair. This is niche stuff. But it's niche stuff that enables things that aren't niche – like being able to move your content between platforms without losing everything, or building tools that work across multiple platforms without heroic integration efforts.

That matters. Even if it's not obvious yet. Especially when you're anticipating experiencing it from both sides.

Final Thoughts

Standard.site isn't trying to solve every problem in decentralised publishing. It's focused specifically on metadata coordination for long-form content on AT Protocol. And by keeping that focus narrow, by building for adoption rather than specification completeness, by letting the ecosystem evolve the standard rather than trying to design everything upfront... it might actually work.

Which would be nice, honestly. We've been promised interoperable, portable, user-respecting platforms for decades. Standard.site is one small piece of actually building that rather than just talking about it.

And here's what makes this particularly exciting from my perspective at the intersection of building and using: I'll get to experience both the technical elegance of the solution and the practical benefits of that solution in my daily work. When I'm writing a blog post on Leaflet after the integration happens, I'll be directly benefiting from the coordination work that developers (including the Leaflet team) have done to implement standard.site. And when I'm building things on AT Protocol, I can see how that same coordination benefits the tooling I'm creating.

It's a feedback loop that reinforces itself. Better coordination makes better platforms. Better platforms make the writing experience better. A better writing experience makes me more invested in the ecosystem. More investment makes me more motivated to build things that work within that coordinated framework.

This is what decentralisation is supposed to feel like – not fragmented chaos where everyone's doing their own thing and nothing interoperates, but coordinated infrastructure that enables diverse implementations whilst maintaining compatibility.

I'm properly excited – not just quietly glad – that Leaflet is planning to integrate this, even though I won't need to do anything about it as a user. Because I know what it'll enable, both technically and practically. I know what it'll make possible for the ecosystem. And I'll get to experience that from both sides.

Sometimes the best infrastructure is the infrastructure you never think about as a user but deeply appreciate as a developer.

And sometimes you're lucky enough to be both, watching coordination happen in real time and knowing you'll benefit from it in multiple ways.