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!

Ingredients

• 600g T45 flour
• 200g warm milk
• 60 to 100g warm water (adjust as needed)
• 140g cooked potato flesh, peeled
• 60g soft butter
• 1 medium egg
• 40g sugar
• 13g salt
• 10 to 12g active dry yeast
• A little milk, to brush before baking
• A little melted butter, to brush after baking
• ½ teaspoon turmeric, for color

Cooking the potato

1. Cut the peeled potato into cubes.
2. Cook them in water for about 10 minutes, until very soft when pierced with a knife.
3. Set the potatoes aside, let them cool and dry as much as possible
4. Mash them in a bowl.

Kneading

I don’t have a stand mixer, so I did the whole thing by hand. It works, but I won’t pretend it’s effortless. A stand mixer with a dough hook would have saved my arms a good twenty minutes

1. In a large bowl, add the flour and make a well in the center.
2. Add the egg, salt, sugar, mashed potato, and turmeric to the well.
3. Add the dry yeast on one side, away from the salt and sugar.
4. Pour in the 200 g of milk gradually, mixing as you go.
5. Once the milk is absorbed, add 60 g of warm water in a thin stream and keep mixing for 2 to 3 minutes.
6. Work in the soft butter gradually. If the flour isn’t coming together, add more water a few drops at a time, and stop as soon as a ball forms.
7. Turn the dough out onto the counter and knead for a good 15 to 20 minutes, bringing it back together as you go. You’re after a smooth dough that’s barely sticky. (This is the part where a stand mixer really earns its keep.)
8. Finish by kneading a little more energetically for 2 minutes (slapping the dough against the counter) to build up some elasticity.

One thing that threw me: my dough was super sticky the whole way through; I was worried it wasn’t going to work. It turned out perfect in the end, but I suspect a stand mixer would have made the stickiness less of a worry, since you’re not fighting it with your hands. So if yours feels the same, don’t panic

First rise

1. Gather the dough into a ball, no flour needed.
2. Cover the bowl tightly with cling film or a cloth.
3. Let it rise in a warm room (21°C minimum) until it triples in volume (1 to 2 hours depending on temperature).

Shaping

1. Once tripled, knock the dough back with your fist and gather it into a ball.
2. Give it 2 or 3 folds.
3. Divide into pieces and shape each into a ball. I went with 120 to 130 g per piece, which gave me about 9 buns, but they ended up a little too big for my taste. Next time I’ll aim for around 100 g.
4. Place them spaced apart on a baking sheet lined with parchment paper. I also spread a bit of semolina on my parchment paper, it helped the buns not to stick.

Second rise

Let them rest 30 to 45 minutes. The buns should puff up nicely. That’s at this point that I realized my buns were too big

Baking

1. Preheat the oven to 180°C.
2. Brush the buns with milk.
3. Bake for 15 to 20 minutes (18 minutes with a fan oven), until just golden.
4. Out of the oven, lift them off the sheet and brush butter over the tops while they’re hot.

Enjoy!

Bridging protocols is how we preserve that without locking into any one silo.

Following my last blog post about what I’ve been working on in the past month, @davew and I had an interesting conversation around what it means to develop for the web, and to work to improve the web.

My recommendation for Automattic and Bluesky.

It’s really simple

It got me to think:

Does building bridges between social networks like ATproto or the Fediverse, and reading tools like the WordPress.com Reader, contribute to improving the web?

Given that I chose to work on just that for a month, you know my answer. But our conversation made me think. We may not have the same views on what the web is, and what it should be.

I am a child of the Web 2.0. The Social Web was my first real entry into the web. I started participating and getting involved with the web when the “web 2.0” term was coined, when online forum boards were popular. I became a forum mod, I started building phpBB themes, I learned how to do that on forums. A year later, I started blogging and quickly found myself in small community of like-minded people commenting on each other’s blog posts every day (aka a blog ring). In parallel, I learned how to build my own WordPress theme by asking questions in the WordPress.org support forums.

I am now old enough to say “back in my day”, I felt part of multiple communities of like-minded people. Those people were the reason I kept coming back. Those small communities are what makes the web interesting to me.

While some may think of the social web as the chase for the most Likes, Retweets, and overall baiting for engagement, I see it as a group of individuals exchanging ideas, communities.

And more generally, I see the web as social by default. Although maybe not for much longer, the web is made for humans exchanging ideas.

In that way, “social web” really should just be “the web”.

The tools, technologies, protocols, and standards used to help people find each other continuously evolve.

20 years ago, the tools were fewer, RSS, blogging, and forums were at the center of many communities. Today, the landscape is fragmented into an increasing number of different corporate tools and services. Some of them were clearly introduced not to make the web better, but to make money (surprise, surprise).

But that doesn’t mean we should thrive towards a web with only one tech behind it all, or that the social web has to be just RSS. I think there is room for new standards to grow.

New protocols like ActivityPub and ATproto were introduced because they add additional interaction layers on top of basic content consumption. They make it easier to Like, reply, and build community in different ways.They are still the web, though. They make up a place to create, consume, and interact like everywhere else.

As more and more people use those tools, gaps start appearing though:

• ActivityPub is great, but its standard needs to grow to make it easier to create, consume, interact, from different clients. It’s why the W3C Social Web Community Group and its ActivityPub API task force work to address the gaps real clients run into.
• ATproto works well, but needs to grow for folks who don’t want to be limited to 300 characters. This is why folks are working on implement support for long-form content with standard.site.

That said, because those protocols aren’t perfect, it doesn’t mean we should drop them. Quite the opposite.

I think that building bridges between protocols can help all of them grow and close their respective gaps.

• Now that we use the ActivityPub API in the WordPress.com Reader, we can follow the work of the API taskforce and chime in with real-life examples.
• Now that you can publish long-form content to ATproto from your WordPress site, we’ll see more and more long posts on ATproto services like Bluesky, and it will help Bluesky implement better support for long-form content in their apps.

By building these bridges, we aren’t fracturing the web; we are pushing the underlying standards to mature.

All in all, I truly believe that “a rising tide lifts all boats”, and I’ll continue to work and experiment with all those tools, in the hopes that the web can stay a good place for humans for a little bit longer.

To put my money where my mouth is, this post is available via RSS, via a REST API query, via ActivityPub, as a Bluesky short record (app.bsky.feed.post) with a link to the full post, and as a standard.site long-form record (site.standard.document).

Nicolas Furno

nicolasf@mastodon.social

Le champ derrière chez nous a déjà été fauché et les meules sont prêtes à partir. Je ne me souviens plus exactement quand ça avait lieu les années précédentes, mais pas avant l’été pour sûr.

2026-05-27, 16:14 1 boosts 5 favorites

En Bretagne la saison des foins c’est typiquement entre mi-avril / mi-mai pour les couverts végétaux qui sont ensuite retournés pour y faire du maïs, ou jusqu’à juin pour les prairies plus permanentes. Plus tard et l’herbe est de moins bonne qualité, et ça stresse la prairie avec les chaleurs de l’été.

Si l’agriculteur de derrière chez toi fauche en été d’habitude, c’est peut être plus pour gérer les restes après que les vaches soient passées par là, ou alors parce que c’est une petite parcelle dont il ne se sert pas trop, et où il fauche plus pour garder ça propre que pour autre chose ?

Chinese lessons may be the perfect example of that. Not sure my signature on a Chinese writing test means much when I don’t understand what I’m signing.

That’s the publishing side, and it works well. The reading side is newer. The ActivityPub plugin has a Fediverse Reader inside wp-admin, but we’re still building it out. In practice, I’d been doing most of my reading elsewhere. When I first joined the Fediverse I set up a GoToSocial instance, and I’ve continued to use it to consume content, on my phone, in Tusky. The UX was just simpler.

That setup works for me. It only works because I’m tech-savvy enough to keep a spare account on a GoToSocial instance, and juggle between 2 instances to read or write. That’s probably not a setup that will attract more people to the Fediverse.

This past month, Automattic ran an internal experiment called Radical Speed Month. For the whole month, I got to pair with one other person in my timezone, pick a project that interests me, work on it, and ship it. I got to decide what to work on, how I wanted to work, how I wanted to communicate about it. This was a great opportunity to focus on one thing and one thing only, to avoid other distractions. Maybe most importantly, it was a chance to reflect on how we’ve been working in the past few years, and compare that with a focused effort in a much smaller team. When we resume regular work on Monday, one of the first things I’ll do is chat with my team, and figure out if there are things we can drop or change from our past team workflow and routine.

For me, the point of that “radical month” wasn’t just about the projects, although there are some cool ones coming out! It was the chance about triggering some introspection, re-examining our processes: what would change about how we work, and what would we want to keep.

I paired with @pfefferle. We already work on the same team, so I knew it’d be a good month. We picked a project that fit the both of us. We turned the WordPress.com Reader into a place where you can now connect Bluesky (or any other ATProto platform), Mastodon (or any other Fediverse tool using the Mastodon API), and Fediverse accounts. You can now read, react, and post from one place. Three protocols, one Reader. We called the project Reader Everywhere.

One of the pieces I’m proudest of is on the Fediverse side. @pfefferle was really the driver behind this part of the puzzle! The integration is built on top of the ActivityPub Client-to-Server API. As far as I know it’s the first product at this scale to be built on top of it. We’re hoping that by shipping and iterating on the client, we’ll help the standard grow. There’s a longer write-up of this on the ActivityPub blog: Your WordPress Site — From RSS Feed to Social Account.

Here’s what we shipped, in a 90-second walk-through:

This was also a good opportunity to get back to a full focus on coding. I moved into a leading role a while ago, and as one can expect, it involves some meetings, reviews, planning, discussions. That’s useful and important work, but I will say that it felt good to be back to building things for a month. Matthias and I would think about solutions, push code every day, review each other’s PRs, smooth out the rough edges, ship. I really enjoyed it!

If you have a WordPress.com account, I would encourage you to check the Reader! I’d love to know what you think

Yes, my site logo was a drawing of a cool rabbit with a trenchcoat, a briefcase, and a KISS makeup. Why not?

I was wrong.

I finally got access today, configured it, and asked it a few questions. It was noticeably slower to respond, which I can understand. That would be okay if its answers were good.

Here is an exchange from 15 minutes ago:

• In English: “Hey Google, what will be the weather tomorrow?”
• Google replies in English: “it will rain, temperatures between 7 and 19° C.”
• I immediately ask a follow-up question, still in English: “Will it rain all day?” Even old Google could be helpful with that.
• Google replies in English: “you can expect showers in the evening. Temperatures will vary from 7 and 17° C.” Somehow the forecast got 2° colder with that follow-up question?
• My kids hear me complaining, don’t understand the problem, so I ask again, in French this time.
• Google replies, in French but with a strong English accent!!, and the temperature is back to 19° C. No Google, I don’t need you to speak like a British person who is trying their best to speak French!

(╯°□°）╯︵ ┻━┻

If you needed a little push to give the tool a try, watch this space! Over the next few weeks, @pfefferle and I will be working on a small Hackathon to bring the open social web into the WordPress.com reader (or the other way around), so you’ll have more reasons to like the Reader!

Em :official_verified:

Em0nM4stodon@infosec.exchange

@macmanx Have you used this solution yourself? How much control do you have on the data collected from visitors on WordPress?

2026-04-23, 21:26 0 boosts 4 favorites

I’m replying to you from a WordPress site. Since WordPress is open-sourced, you get to decide:

• Where you host it
• What analytics services you use on your site (if any)
• what data you collect about your visitors.

It’s your website, you’re in control.