Today, implementation is cheap. You are paid to make good decisions. To build software that will scale while managing complexity.

[…]

You need to contribute beyond what everyone already gets by giving an agent a prompt.

We are in the age of AI after all, seems like the perfect time to revisit a classic story about AI and technology. I’m really curious how they’ll manage to stay true to the book’s feel, but I must say that so far, their casting really matches what I remember from Case, Molly, and Armitage! I think I see Riviera for a couple of seconds but I’m not sure who that is; I’m really curious who will be the crazy person they’ll pick for the role

I’m really looking forward to it!

It helps that I’ve been happy with most Apple TV productions in the past few years, so maybe they can pull this off! They have done well with Sci-Fi especially, so I think I can be optimistic.

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.

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!

We went to see a drone show tonight. It was nicely done but somehow the fireworks that came right after were still the highlight of the show.

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.

Somehow @bunniesin.space managed to perfectly summarize why microblogging isn’t for me, and why I think it does more bad than good overall.

You should just go read the whole post

Microblogging sucks

Making applications is surprisingly easy (if you build on atproto) — @bunniesin.space

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

The Dungeon Crawler Carl television series has been officially greenlit at Peacock.

Looking at the folks involved (Seth MacFarlane from Family Guy and American Dad, Christopher Yost from Thor: Ragnarok and Cowboy Bebop), I’m assuming it will be an adult animation series? It would make sense, I don’t see how they could turn the book series into a TV series without a really big budget. I’m really curious about what’s going to come out of this.

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 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!