Putting the WordPress block editor on the AT Protocol

I’ve had my own home on the web, one I fully control, for about 20 years now. It started on a cheap shared hosting plan where PHP was all I needed and knew. I taught myself to build WordPress themes by asking questions in the .org support forums, and I’ve been taking care of my little home ever since. I’ve renovated more than a few times, I’ve experimented with different CMSes, I’ve tweaked things, …

I say that up front because it’s the lens I brought to a small experiment I launched today: SkyPress, a long-form editor for the AT Protocol that happens to run the WordPress block editor. There’s a proper launch post over here, but I wanted to expand a bit on the why, as well as a few of my ongoing thoughts and conflicts about ATProto.

Where it started

I’ve been spending some time looking at how the long-form editors in the atmosphere structure their content. Leaflet has its multi-page document blocks; Pckt.blog has its own block format; both write something structured into the content field of a site.standard.document record. Poking at those got me thinking again about something I was more familiar with: how a WordPress post is put together under the hood.

Some of this came out of work @pfefferle and I did bringing Bluesky, Mastodon, and the fediverse into the WordPress.com Reader. That meant looking closely at standard.site, and at how each platform decides what to drop into that content field. The more I looked, the more I wanted to try it myself.

I had three questions I wanted to answer for myself:

1. How hard is it, really, to build an ATProto editor without taking on a pile of overhead?
2. Could I rely only on data saved to the PDS, with nothing of my own to store on the side?
3. How easy would it be to re-create some of the WordPress block editor experience outside of WordPress?

A lexicon that came together on its own

Here’s the thing that made it click. WordPress knows all about turning post content into structured data, and that structure happened to map neatly onto what an ATProto content field could be. That’s a happy accident for my experiment.

Automattic maintains isolated-block-editor, which is the Gutenberg editor repackaged to run with no WordPress behind it. It hands you an onSaveBlocks callback, and instead of a string of HTML you get the raw block tree: an array of { name, attributes, innerBlocks } objects. Add @wordpress/blocks and @wordpress/block-library for parsing and rendering, and you have a full editor and a renderer, no PHP anywhere.

So the SkyPress content lexicon, blog.skypress.content.gutenberg, ended up almost embarrassingly thin: a version and a blocks array, dropped straight into the document’s open content union. The canonical content is the block tree exactly as the editor produced it, not rendered HTML. Any reader that doesn’t understand the $type falls back to textContent, same as every other custom content format in the atmosphere.

The reason this works is older than ATProto. When Dennis Snell explained the Gutenberg block format back in 2017, he put it plainly:

Thus, a Gutenberg post isn’t HTML, but a tree of objects and associated attributes.

Gutenberg posts aren’t HTML…

That tree is exactly the shape ATProto wants. Matías Ventura framed the bigger move as a Ship of Theseus, rebuilding the materials while the ship keeps sailing, and the block, as a discrete unit of structured data, is the plank we swapped in. So for me the hard part, designing that content model, was already done. I mostly got to borrow it. 🙂

Why hasn’t the atmosphere settled on structured content?

This is where the experiment bumped into something I still don’t quite understand yet. standard.site made a deliberate choice to standardize the metadata around a document and leave content open; bring your own format. I get the reasoning and the flexibility it brings. But that content field is a singular union, so someone building an editor still has to pick one $type and accept that every other reader degrades to plain textContent.

I got into this a bit with @jimray.bsky.team on Bluesky:

In my ideal world, an editor would be able to serve Leaflet readers, Pckt readers, and markdown readers well from the same record, so you read a nicely formatted post regardless of the reader you use.

https://bsky.app/profile/jeremy.herve.bzh/post/3mnxmilp55k2h

That’s not how it works today, and different editors keep building different content formats that only their own readers fully understand. And ATproto seems to be growing a lot right now, so new formats will keep popping up. Hey, I just added one to the pile! 😅

It reminded me of a choice WordPress made years ago. I offer as a data point and nothing more, I don’t mean to offer any advice or recommendation to anyone, I know very little about ATProto!

When Gutenberg moved to blocks, it kept storing that structured data as HTML too, tucked inside comments, so a legacy system that knows nothing about blocks can still render the post. The technical overview from 2017 put it this way:

the source of truth for the content should remain in post_content, where the bulk of the post data needs to be present in a way that is accessible and portable, while still providing additional structure on top of HTML semantics.

Editor Technical Overview

I’m not holding that up as the answer. The block editor itself is divisive enough that I’d never claim WordPress has this figured out; it’s one take on one narrow corner of the problem, a structured format that still degrades into something every reader can show. Whether that’s a good fit for the atmosphere, I honestly don’t know. I just keep poking at it.

Am I sold on ATProto? Not quite

I’m still trying to get on board with the whole idea of ATProto, and this little experiment is a great way to learn more, and poke at those questions.

Part of me still thinks I may not be the person it’s for.

Remember that cheap shared hosting plan. I already own my content, I’ve moved between platforms, built my own themes, broken things and put them back together. Owning my words isn’t anything new to me. And I’m comfortable digging around in my own data inside WordPress, because I know that process inside and out.

So the core ATProto idea, separating where your data lives (the PDS) from where people read it (the AppView), feels a little foreign to me. Having to run, pay, and maintain two systems to control one set of content seems like a lot. And it’s usually not just two systems; it’s two domains as well, one for the PDS and one for the AppView. The PDS gives you portability and the AppView gives you a web address people can actually reach, which makes sense to some extent, but it’s also two of everything to keep an eye on, and potentially two points of failure. It’s hard to go from “I run my little blog and it mostly just works” to that without asking myself some questions. 🙂

Don’t get me wrong though. None of that is a knock on the protocol. I think it’s a fair description of the bet ATProto asks you to make, and for plenty of people, especially folks who never had a home of their own on the web, that bet may make complete sense.

Where do you publish a post about your own publishing tool?

So I built a long-form publishing tool. Cool. Yet, I’m posting about it on my WordPress site. 😅

I spent quite a bit of time deciding where to actually publish this very post.

I wanted to use SkyPress. I mean, I just released it, I probably should! But I already have this home, 20 years deep, with my readers, my RSS subscribers, my Fediverse friends. Why would I switch now? Especially considering that this site runs the ATmosphere plugin: it already publishes my posts to ATProto as site.standard.document records anyway.

By the way, we’re asking ourselves the same questions for the plugin. What exactly should go in that content field, though, is a question we’re still hashing out in an open pull request: HTML, markdown, pckt, Leaflet, and which one wins when content only has room for one. I’m definitely still struggling about that multi-format puzzle!

So for this one, I ended up picking the home I already have. I will be using SkyPress for other posts over the next few weeks, though! Maybe that will help me better understand all of this!

I’ve written before that the web was always social, and that because a protocol isn’t perfect, it doesn’t mean we should drop it. Quite the opposite. A rising tide lifts all boats, and to me the only way to find the gaps in something like standard.site is to build on it and bump into those gaps myself.

If you want to give it a try, the editor is live at SkyPress.blog, and the launch post walks through what it actually does. It’s an alpha, so expect rough edges. And if you’ve thought about the singular-content-union question, or this whole structured-versus-legible tension, I’d love to hear it. Let me know!