A few days ago I wrote about rolld, the little board game tracker I built on the AT Protocol. As I mentioned then, this is very much a learning experiment for me, a way to play with ATProto and learn about it. In this post, I’d like to come back to a few of my struggles and the things I learned while designing it. ATProto is supposed to be about decentralization. But the app I was sketching out didn’t feel decentralized at all: 1. Every record that gets posted on a user’s PDS means nothing without the central record in my app, and ultimately without BoardGameGeek, since rolld’s game pages are powered by cached data from BGG. 2. How do I save board games themselves? A single board game can’t be something each user creates on their own PDS, because then you get a duplicate “Wingspan” for every person who’s ever played it. But it also can’t be a record that lives on a single PDS (say mine), because then it’s centralized all over again. So a “game” either gets duplicated across everyone’s PDS, or it lives in one central place and re-centralizes the whole thing. Both felt wrong, so I had to take a step back. ## It turned out to be a false dilemma What I’d missed is that there was a third option. The way out was to stop trying to model “the game” as a record at all. What if there’s no central “Wingspan” record anywhere? What if there are only per-user **activity** records, one for each thing you’ve played, and each one carries a small snapshot of the catalog facts it needs (the game title, the year it was published in) right inside your own record? So the answer to “duplicated or centralized?” was: neither. There’s no shared record for the thing. There are only activity records that point at the thing by a shared identifier, and carry whatever snapshot they need to stand on their own. My mistake was assuming a “game” had to be a record somewhere. It doesn’t. The game is just an ID everyone agrees on. ## The three layers Once I clearly separated the 3 layers of my app, most of my “wait, is this decentralized?” worry got sorted out. **Layer 1: shared identity.** Everyone refers to a game by its BoardGameGeek ID. This feels like centralization, but mostly it isn’t. Agreeing on an identifier is not the same as depending on a server. “BGG ID 266192” is just a string, a name, like an ISBN for books. Libraries shelve books by ISBN and nobody calls libraries centralized. A shared namespace is the coordination point that lets different people’s records be talked about together. The ID remains unique and keeps working even if BGG vanished tomorrow. **Layer 2: swappable metadata.** The name, the cover art, the complexity rating, and the community rating all come from BGG metadata right now. That said, I only view that information as a way to improve the display of a game. It’s not the source of truth about anything that matters in my app. Whether a cover loads from BGG, from Wikidata, or not at all, my record of having played that game with my friends on Tuesday is unchanged and remains mine. In practice, metadata gets hydrated at read time through a small `resolveGame()` function. All of BGG’s centralization lives in this layer. Tomorrow, I could swap BGG by another provider in that function, and I would be good to go. On top of that, and since BGG is the main source of information about board games today, I can almost guarantee that another provider would carry the BGG ID along with the rest of the metadata, making it easier to match metadata and games. **Layer 3: owned activity.** your play logs and your ratings. These live signed on your own PDS, portable, readable by any AppView. This is the layer I really want to be decentralized. The reason the app felt non-decentralized is that I was judging it by Layer 1 and Layer 2, the layers that I think are supposed to be shared and external, instead of Layer 3, which is the layer decentralization is actually about. ## Reframing the core principles of my app After switching my view to those 3 layers, I took another look at how my app should be designed. **My app is just a lens, not a source of truth.** I’d told myself the records mean nothing without the central record in my app. But that’s not what the AppView is. If rolld disappeared tomorrow, every play record still exists on every user’s PDS, still says “I played this game with these people on this date,” still readable by any other app that understands the format. What rolld provides is aggregation and display: the web page, the “who else played this” view. That’s the AppView’s job everywhere in ATProto. rolld being needed for the nice view doesn’t mean rolld is needed for the data to exist or to mean anything. **Can my app be replaced? I figured this was a good way to test the actual decentralization of my app.** Since my app is just a lens, any other app could come along and use the existing data saved on everyone’s PDS. That seems decentralized enough to me. It’s not really about my app’s external dependencies; I don’t think we can reasonably expect a social app like rolld to work without any external data points. **“BGG-dependent” versus “BGG-enriched.”** Instead of asking myself “do you depend on BGG?”, I choose to ask myself “if BGG vanished, is anything users own lost?” The answer is no. All users would lose is live cover art and other metadata, until someone pointed the resolver at another catalog. People would lose nothing from their records. In practice, it did force me to review and change my data model a bit. To make the records readable on their own, I decided to store a minimal name snapshot in each record: `{ id, name }` (plus an optional year) rather than just `{ id }`. * The ID is the unique reference (matching BGG game ID), building links and linking everything together. * The name snapshot is so it still reads as something a human logged. It’s “what I called the game when I logged it,” captured at write time, so the record stays readable even if BGG dies, if rolld is down, or some future AppView comes along that has never heard of BGG. Live hydration (game covers, complexity, number of players, time, community rating) is just pure enrichment on top of a record that already means something on its own. I purposefully stored very little, because I didn’t want to save everything and end up with: 1. outdated data in PDS records 2. basically rebuilding BGG’s index inside everyone’s PDS; that’s not the point. 3. ## What I’d tell someone else If you’re new to ATProto and you hit this same wall, here are 2 things I wish I’d known going in. 1. The first is that “decentralized” is a property of the data layer, not of the whole app. I was applying the word to rolld as one big monolith, when it really belongs to Layer 3, the owned records. Shared vocabulary and external metadata being a bit centralized is fine and expected i think. Once you know which layer to point the word at, most of the panic goes away. 2. The second is to watch for false dilemmas shaped like “duplicated or centralized.” I was stuck with this because I started with a bad premise: “a game must be a record somewhere.” Once I took a step back and reframed things a bit, it became easier to design the app. ## It’s not perfect It’s not a perfect solution though; BGG-enriched is still a dependency for nice display. If BGG went down tomorrow, rolld’s game pages would look pretty bare until I pointed the resolver somewhere else, and I haven’t built that fallback yet. The catalog metadata is still someone else’s, and I’m still leaning on it. But I think it’s important that I moved it out of the layer that matters. If you’ve hit this same wall building on ATProto, I’d love to hear how you thought your way out of it. And if you missed the first post, you should probably go check rolld.at!

My wife and I play board games. For a few years now, I’ve kept a log of what we played: the date, whether it was any good, who won. I like to quantify things, and it always feels good to be able to answer “What game did we play the most this year” and similar questions. Up until now, that log lived in a quiet corner of this very blog. I’ve written myself a small WordPress plugin that adds a custom post type for board game plays, and I’ve been slowly filling it up ever since. You’ll find games displayed in some of the pages on this blog via bits. It works fine, and maybe most importantly the data is all mine. So this isn’t a story about escaping a silo. If you’ve read my blog in the past few months, you’ll know I’ve been experimenting with ATProto with different projects (SkyPress, comments on atproto, ATmosphere, and most recently AT Mot. Each one has been me taking something I actually use and rebuilding it on the AT Protocol, just to find out what the protocol feels like behind the scenes. rolld is that, pointed at my board game shelf. You can have a look right now at rolld.at. Its name reads as “roll’d”, as in rolling dice, and it happens to end in `.at` because ATproto. Knowing me, you won’t be surprised that I’m still not great at naming things. 🙂 ## What it does The loop is deliberately small, and built for a phone, because you log a game at the table right after you finish, not sitting at a desk an hour later. * **Log a play.** Search the game, set the date, submit. If you want you can add more details, like who played with you, the scores, a winner, how long it ran, a photo of the board, or a note on how it went. * **Rate a game.** * **See what people you follow are playing** , if they’re on rolld too. * Check your history, your most-played games, your top-rated ones, what you’ve played this year. * **Share a play to Bluesky** , if you feel like it. Every game gets its own page as well, bringing a bit of community feeling to the tool. You get to see who’s played it, and what the people you actually know thought about it. My goal wasn’t to out-do BoardGameGeek, obviously, so it pulls data from BGG and uses its API behind the scenes. ## Where the plays actually live Here’s the part that’s different from my old WordPress version. rolld doesn’t have a database of your games. Each play and each rating is written as a record to your own PDS, signed by you. rolld is just a lens sitting on top, reading those records back and turning them into pages. If rolld disappeared tomorrow, your history wouldn’t; it’d still be on your PDS, still yours, still readable by any other app that understands the format. And, same as with AT Mot, there’s very little behind rolld. It’s a folder of static files and a handful of public services I don’t run: * **Constellation** , the backlink index I leaned on for AT Mot’s leaderboard, does the aggregate reads here too: who else has played a game, how it’s been rated across the people you follow. * **Slingshot** handles record and identity reads, turning a handle into the right PDS to read from. * **Spacedust** is the live firehose, so a friend’s play can turn up in your feed without a refresh. All three come from microcosm.blue, run on community goodwill, and here I am leaning on that goodwill again. I’m very grateful it exists. The one piece I do run is a small Cloudflare Worker. Board game metadata, the covers and weights and the catalog all come from BoardGameGeek. The Worker fronts BGG and caches it; the browser never talks to BGG directly. That’s the whole server. My data on my PDS, a few public indexes I don’t own doing the social heavy lifting, and one small Worker handling the AppView. Building rolld also meant accepting some bottlenecks and limitations: * The metadata is all BGG’s, and that’s a dependency. I looked at other options out there, but BGG really is the best there is. I did, however, try to keep it as an enrichment dependency, not an ownership one. Your records name the game themselves, so if BGG ever went away you’d lose the cover art, not the memory of the game you played. * The social half leans on those public microcosm services. It’s the same independence tension I keep bumping into with ATproto: trying to be fully independent somehow keeps adding services to run. 🙂 * A record on your PDS is portable, but it doesn’t have a web page until an app makes one. rolld is that app. The raw, portable version of your data is always yours; the pretty, shareable version needs rolld, or something like it, to keep existing. ## Give it a try! Go and log a play at rolld.at. You can browse the public pages without an account; to keep your own log, sign in with your Bluesky / Blacksky / Eurosky / ATProto handle and your games will follow you around wherever you go. The code is open, dual-licensed MIT / Apache-2.0 like ATproto itself, over on Tangled at tangled.org/jeremy.herve.bzh/rolld. Let me know what you’ve been playing, and what you think of the tool! I’ll keep poking at it and making improvements to the interface in the next few days.

I play Wordle every day. It’s the most boring possible daily habit, and it’s a very simple game, but I like the habit, and from time to time I even learn new words! So when I went looking for my next small experiment on the AT Protocol, I didn’t want to build something clever. I wanted to rebuild something I already use, and find out what the protocol feels like underneath a thing I actually open every day. That’s AT Mot. “mot” is French for “word,” and a little play on ATproto. (I’m not great at naming things). It’s a bilingual daily word game, English and French, each its own series, and **you can play it right now at atmot.herve.bzh**. ## Playing with Constellation In my last post about comments on atproto, I was wondering about a limitation: there’s no way to ask the network “give me every record that references this post.” @pevohr.bsky.social chimed in to point me to Constellation, a backlink index for ATproto, and I said I’d read up on it over the weekend. Here we are 🙂 AT Mot relies on Constellation. When you finish the day’s puzzle, the result is written as a record to your own PDS (well just the tile colours, never the answer or your guesses). Each result links to a canonical per-day permalink, and the leaderboard is built by asking Constellation for every record that links back to that permalink, then adding it all up in your browser. So the “leaderboard” isn’t something I host. It’s a question I ask a public index, computed fresh on your machine every time you look at it. I was originally thinking about looking to host my own Constellation, but that’s not really realistic for now, so I rely on the goodwill of the community! ## No server, on purpose There’s not much behind AT Mot. In my SkyPress post I admitted I wasn’t quite sold on ATproto; the PDS-and-AppView split felt like a lot of moving parts for someone who’s owned his own blog for twenty years. AT Mot was partly me asking the opposite question: how little can an atproto app be? The answer turned out to be a folder of static files and a couple of public services I don’t run. That nudged me a bit. ## It’s not perfect A few caveats, because there always are. The leaderboard reads from the public Constellation instance, so I’m leaning on someone else’s service for the social half of the game. That’s the same independence tension I keep bumping into; being fully independent on ATproto somehow keeps adding services to run. 🙂 ## Have a go Go play: atmot.herve.bzh. If you’re on ATproto, sign in and your results follow you around. If you’re not, you can still play, and it’ll record the game the moment you do sign in. Either way the word resets at midnight UTC. I’ll be doing the 2 words of the day tomorrow morning! The code is open, dual-licensed MIT / Apache-2.0 like atproto itself. I should probably mention that although I took inspiration from Wordle, it’s not a copy. It shares some of the format, but not the words or design. The lists are self-curated from permissively-licensed dictionaries. Let me know what you think, and start your own streak 🙂

I published my first post on this blog almost 20 years ago. I wasn’t always very active on this blog, but one of the things that kept me going was the interactions I got to have with readers. In fact, in the first few years I was part of a small group of people who often commented on each other’s posts one of us would publish. The comments were my community. I mention this because comments are about as old and as basic as the social web gets. So when I started poking at the AT Protocol, building SkyPress and reading up on standard.site, I assumed comments would be a solved problem. A protocol built for social, in 2025, surely has commenting figured out. It turns out it doesn’t, and as I’m digging into the standard some more, I’m really curious about its status and its next steps. ## standard.site left them out on purpose The standard.site lexicon is documented here. Here is what’s currently supported: * Publications: a collection of documents. Let’s call that a blog 🙂 * Documents: a single document, part of a publication. Let’s call that a blog post. * Subscriptions: used to track users following a publication. * Recommends: used to, well, recommend documents. I think of it as likes for documents. Comments are not of there. I went looking for discussions around why those were missing, and got some answers on the Off Protocol podcast, hosted by Jim Ray (@jimray.bsky.team). Their rule of thumb, as Jared (@awarm.space) from Leaflet put it, is that “the amount of existing implementations we want should be proportional to the complexity of the new lexicon.” Comments are complicated, and nobody is happy with what exists yet: > For something like comments, that’s actually pretty complicated and has a lot of implications for content and various moderation things and all these kinds of stuff. Leaflet has a comment lexicon, but we’re not like super happy with it or anything like that. > > @awarm.space So they’ve held off on purpose. As Jared summed it up, “so far we have chosen the easy parts of the problem”, “that sort of maximally useful and least gnarly set of the problems.” I think that restraint is the responsible call. But it does mean that today, if you want comments on your long-form post, you’re on your own. ## So everyone built their own If you’re building your own blog on ATProto today, there isn’t a single work-around. You have a few options: * **A companion Bluesky post.** You publish your article, then also post a normal Bluesky post pointing at it, and treat its replies as your comments. Jim Ray’s `bsky-conversation` web component does this nicely. The catch is that those replies are regular Bluesky posts. They’re capped at 300 characters, you can only use plain text. I know I ramble, but I think that’s annoying whenever you want to post a reply to a well-thought blog post or essay. * **A native comment record.** Leaflet built its own `pub.leaflet.comment`, with no character limit, rich text, threading, even comments anchored to a specific passage like margin notes in a doc. It’s really nice. But it lives in Leaflet’s namespace, so only Leaflet readers see those comments. They’re invisible to Pckt, to my own reader (so far), to anything that isn’t watching for that exact record type. * **A whole separate annotation layer.** Then there’s margin.at, which lets you annotate, highlight, and reply to _any_ URL on the web, using its own `at.margin.*` records built on top of the W3C Web Annotation model. It’s a clever, broader idea, but it’s another shape that doesn’t line up with any of the above. For where I stand, it seems that the hard part isn’t the implementation, or the lexicon, it’s agreeing on the protocol underneath. On that same podcast episode, Jim Ray walked through the problems: > the comment would in theory be stored on my PDS… How do I actually gather up all of the different comments that have been left through some kind of backlinks mechanism? But then, you know, what happens if that PDS disappears? […] How do you show a tombstone comment? […] How do you handle things like moderation? Who does the moderating? > > @jimray.bsky.team Every one of those is real. Your data lives on your PDS, so when you comment on my blog post, that comment record lives on your PDS, not mine. My PDS has no idea it exists, and there’s no query anywhere that says “give me every record on the whole network that references this post.” That question simply can’t be asked directly. So how does a reader show comments at all? It listens to the firehose, the stream of every record being written across the network, catches comment records as they fly past, and indexes them itself. That works, but it means a comment is only ever visible on a reader that happens to be watching for that specific record type. A `pub.leaflet.comment` shows up in Leaflet because Leaflet is listening for it. Nobody else is. And then there’s the deleted-commenter problem Jim flagged. If someone deletes their account, their comment can leave a ghost behind: an indexed copy sitting in some reader’s database with no live PDS backing it. I think we’ve solved some of those problems in other areas of the web, but the decentralization of the data certainly makes things a bit more complicated. So for now we have work-arounds. You can start using the companion-post trick in your implementation already, it’s most likely the easiest to pull off, especially since we’re already creating companion-posts alongside standard.site records to promote the posts on Bluesky. Leaflet’s comment record is lovely. Margin is an interesting idea, brings a bit of a twist on the “threaded comments” idea. And the protocol-level problems really are hard. But I find it interesting that a network built for social interaction hasn’t landed a shared answer to commenting, the thing that made the social web social in the first place. To be fair, there’s something I like in that mess. Different teams each built a comment system because nothing stopped them: the protocol is new and flexible, people sign in with their existing ATProto account, and the data is already on their PDS, so the barrier to trying your own approach is close to zero. standard.site is built to be extended; its own docs say the existing properties “should not be seen as constraints, but rather as starting points.” So going off and building your own thing is the intended move, not a hack. That’s the same energy that makes the whole atmosphere feel vibrant and fast right now. Everyone is shipping new things every day, is finding new creative things to store on PDS. The downside is solutions that don’t talk to each other. Maybe that will change with time. As the dust settles, the most popular solutions to different problems will be the ones the protocol will adopt? Maybe a `site.standard.comment` will eventually show up? I hope so. For now, this problem is, to me, one of the clearest examples of how young this all still is. It does make it interesting to dive in some more!

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!

I follow a few cooking channels on YouTube, and for the past few years it seems all the burger videos used potato buns. I finally gave it a try, and I don’t regret it. They were not much more difficult to make than regular buns, they were really light and fluffy, they absorbed the grease and sauce from the pulled pork I had prepared super well. All it takes is mashed potatoes worked right into the dough (and also a lot of butter 🙂 ). ## 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`). 🙂

This blog runs WordPress with the ActivityPub plugin, so it’s also my account on the Fediverse. Some of you follow me at `@jeremy@herve.bzh`, and when I post here in WordPress, it reaches your timeline on Mastodon / GoToSocial / Misskey / Pleroma… 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 🙂

There’s a certain type of blog post I sometimes save for later. Not because I want to re-read it right away, but because it’s worth revisiting in six months to see how things actually played out. “Migrating PerezBox From WordPress to Flat PHP in 90 Minutes” is one of those posts. > I actually migrated perezbox.com from a full WordPress installation to a flat PHP site with zero external dependencies. > > No database. No frameworks. No build tools. No package managers. No node_modules. No Composer. No plugins. Just PHP, HTML, CSS The “I migrated away from WordPress to something simpler” post is a classic of the genre. I understand the appeal, it can be tempting. In fact, I have tried migrating away from WordPress in the past. About fifteen years ago I tried Jekyll, as a way to experiment and try something new. I came back to WordPress. Twelve years ago I tried Ghost, partly for the same reasons. I came back again. And I published another reaction post 10 years ago, responding to a post saying WordPress was doomed, static site generators were in. I won’t try to convince you not to try alternatives to WordPress. In fact I think you should, from time to time. It’s healthy to look at what’s on the other side of the fence from time to time, it’s always a good learning experience. I do, however, think we should always be honest with ourselves about the trade-offs. Whether it makes sense depends a lot on the type of site you’re running and how often your content or design actually needs to change. For the right project, a flat-file setup can be a good fit. Here are a few questions I would ask, 6 months from now. ## Are you still using your custom solution? WordPress is much more than a post editor ; it’s an ecosystem. And it’s easy to underestimate everything you take for granted until it’s gone. Galleries, embedded content types, archive pages, category views, comments, all the little things that just work. And that’s not even taking plugins into consideration, and the myriad of other features they can bring to WordPress. A few months in, when you need one of those things, you’ll have to build it from scratch or accept that your site won’t support that. WordPress comes with so many little things that come bundled with the software, we don’t even think about them. A good example may be responsive images. It may sometimes seem like bloat to see so many different image sizes generated every time you upload a new image to WordPress, but those can be useful in so many different places. It may not be a feature you’d put in a comparison table. But it’s one of hundreds of small things the platform does for you without you ever having to think about it. ## Are you still publishing? This one matters even more to me. When your publishing flow changes, when it’s no longer a matter of opening a familiar editor (on desktop or on mobile) and hitting publish, the friction adds up. And in a lot of cases like this, people just… publish less. That’s obviously less of an argument with AI: AI can help you with that flow, can publish / push for you, can write your posts for you. AI does change things, for building sites as much as for everything else. Generating code has become (too?) easy. You can reinvent the wheel for every project if you want to ; no need for a library, a plugin, or a third-party service when you can just ask an AI to build you a custom one. But it cuts both ways. You can’t say your site has “zero external dependencies” and then build your entire publishing pipeline around Claude. That _is_ a dependency, a significant one. It’s a paid service, you don’t control it, it can unreliable at times, it can change its pricing tomorrow. You can certainly do without it and edit files the old fashioned way, but then we’re back to the problem I mentioned above. It becomes considerably harder to publish than it ever was with WordPress. So the real questions become: once the site is live, how easy is it to maintain? If updating it requires leaning on AI every time, are you comfortable with that trade-off? Is that really simpler than what you had before, or just a different kind of complexity? **Did you trade one dependency for another?** I am really curious to see what the future has in store for us, and for WordPress as a whole. I’ll check back in six months I guess 🙂

> I’ve been building an RSS reader for the past year. No unread counts, no inbox to clear. Just a river that flows at its own pace. > > Today it’s live on iPhone, iPad, and Mac. I wrote about everything that went into it. > > Current, an RSS Reader, by @tg Current is a new RSS reader that takes a really interesting approach to how we consume feeds. Instead of treating your subscriptions as a to-do list with an ever-growing unread count, it presents your feeds as a river; articles flow in, linger for a while, and eventually fade away on their own. Although the app is mac / iOS only, and paid, it’s not completely closed. You can hook it up to existing RSS backends like Feedbin or Miniflux. The completionist part of me does miss the idea of reaching “inbox zero.” For me, inbox zero was never about obsessive consumption (or at least I like to think so); it was the permission to walk away. When I’ve read everything, I’m done. I can close the app and move on with my day. I wouldn’t want my RSS experience to turn into a TikTok-like endless scroll where I just keep going without thinking. Current isn’t exactly that though, and that’s where its velocity system gets really interesting. Each feed gets assigned a half-life that determines how long its articles stay visible. Breaking news fade away faster than blog posts for example. This means the app naturally surfaces content proportionally to its nature; a prolific news site won’t drown out the small blogs you actually care about. The pace of consumption adapts to the pace of creation, which feels much more respectful of both the reader’s attention and the author’s intent. On top of that, Current watches your reading patterns and offers suggestions to help you “quiet” noisy sources. If a feed floods your timeline with 18 articles in one day, or if you keep skipping posts from the same source, it’ll nudge you to rate-limit or mute it. I would give the app a try, but it’s iOS and mac-only so far, so I guess I’ll have to wait! 🙂

Hello Fedi! Do you have a blog? I want to read real people! Please recommend or link yours below #blog

<p>If you&#8217;re an old-time blogger, you probably remember Freshly Pressed. 16 years ago (!), the folks at WordPress.com launched a new blog where they highlighted interesting blog posts from the WordPress.com community every week. </p><p>We iterated on the idea a few times over the years but the main idea stayed the same:</p><blockquote><p>a curated collection of posts that entertained, enlightened, and inspired. It was our way of saying “we like you, we really like you” to creators, and amplifying their great work for others to find. </p><cite><a href="https://wordpress.com/blog/2026/02/04/freshly-pressed-is-back/">Great Writing Deserves a Spotlight: Freshly Pressed Is Back</a></cite></blockquote><p>Freshly Pressed went away for the past few years, but I&#8217;m happy to say that my team brought it back! It&#8217;s got a fresh coat of paint, and most importantly, it&#8217;s got quite a few interesting blog posts already!</p><p>Im really happy and proud that we were able to get this done. Today, more than ever, I think we could use a bit more humanity on the web.</p><blockquote><p>The old web felt like a city. You could turn down a random alley and find a weird little shop. You could get lost and discover something beautiful by accident. You could end up in a tiny shop you didn’t know existed or sit on a bench and people-watch.</p><p>Now it’s a mall. Every path leads past a store. Every store wants something from you. Even the “public” space is engineered to keep you moving toward purchase.</p><cite>Straight from today&#8217;s Freshly Pressed post,<a href="https://flauntingmyflawsome.wordpress.com/2026/01/18/unmarketable-on-the-internet/"> I miss being unmarketable on the internet</a>.</cite></blockquote><p>So <a href="https://wordpress.com/freshly-pressed/">check some of those blogs out</a>. Give them a Like. Leave a comment. Start following them. And if you find good potential candidates for the next Freshly Pressed post, send them my way! All you need to be featured is a WordPress.com or self-hosted WordPress site running the Jetpack plugin, and most importantly, an interesting, or funny, or unique story to tell! </p><p>Bonus: if you&#8217;re more of an RSS person, you can also get Freshly Pressed posts straight in your RSS reader via <a href="https://wordpress.com/discover">this feed</a>. Pinging <a rel="mention" class="u-url mention" href="https://mastodon.social/@davew">@davew</a>, I know you&#8217;re always looking for good feeds 🙂</p>

A quick recap of my most listened podcasts of 2025

The 18th book of the Dresden Files series is now available! Here is a full comprehensive recap of the first 17 books to get you ready to dive back in.

Thinking about the best approach to make the WordLand editor available for every self-hosted WordPress site

Here is a quick recap of the board games we played the most in 2025. Lost Cities, Splendor, Andor, and a few more...

If you liked Hermanos Gutiérrez, you'll like this one too! The rhythms, base, radio voice samples, guitar, and latin style seem to be sending me towards Manu Chao's Clandestino as a future album on repeat :)

Another year, another recap post! Here is a quick overview of the books I read and enjoyed in 2025.

For better or worse, the value of code itself seems to be dropping precipitously, to be replaced by measures like how well an LLM can understand the codebase (CLAUDE.md, AGENTS.md) or how easily it can test its “fixes” (unit/integration tests). An experiment in vibe coding -- <a rel="mention" class="u-url mention" href="https://toot.cafe/@nolan">@nolan</a> This was a timely post. I also played with vibe coding during the holidays, also to build an app for my wife. And I came to just about the same conclusions :) I've used AI at work ever since […]

It looks like the ESTA application process is about to get quite a bit more complicated. Check this proposal for changes to the process: Agency Information Collection Activities; Revision; Arrival and Departure Record (Form I-94) and Electronic System for Travel Authorization (ESTA) Among the changes, here is what jumps out to me: CBP is adding social media as a mandatory data element for an ESTA application. The data element will require ESTA applicants to provide their social media from […]

After 13 years together, we said goodbye to our dog Watson last Friday. Here is what I'll remember.

It's hard to believe but after 14 years, the Stargate franchise is back. It won't be a reboot, it's backed by Amazon and folks from the original series (Brad Wright, Joe Mallozzi, Martin Gero) are involved in the project. I probably shouldn't get too excited, but... It sounds promising? https://youtu.be/e82uV9sBt4I It's funny how they're completely ignoring the Stargate Origins miniseries in their announcement. It looks like everyone agrees it's better to forget about it. :)

Over at WordPress.com, we recently added a new feature to the WordPress.com Reader. You can now build a list of blogs you like, and recommend them to others. What if your readers could help your blog grow? What if the writers you love could introduce their audience to yours? That’s the idea behind recommended blogs, a feature now available in the WordPress.com Reader that lets you share the blogs you enjoy most with your own audience. Let’s Grow Together: Introducing Recommended […]