share:
  - mastodon
  - bluesky
  - email
  - copy
  - system

What is prefilled, and what is not

The post's name and its address, where the target takes both. Facebook and LinkedIn take the address alone and read the name off the page. The reader writes the part that is theirs. bluesky, email, facebook, linkedin, threads and x are plain links, one address each, no script behind them.

Three that are not links

The fediverse has as many addresses as it has instances, and a page cannot know which one is the reader's. So mastodon is a button that asks — in a row that opens under the controls, in the site's own type — and remembers the answer in that browser afterwards. Nothing about the reader leaves the page; the instance name is kept where they typed it.

copy puts the address on the clipboard. system hands the post to the operating system's own share sheet, which on a phone is Signal and WhatsApp and Telegram at once, and on a desk is whatever the system offers.

Those three appear only where they can work. A browser without a clipboard API gets no copy button, a desk without a share sheet gets no system button, and a block left with nothing to draw hides itself rather than standing a heading over an empty row.

Why there is no Pixelfed

Pixelfed has no address a page can hand a post to. A button that opened nothing would be worse than none, so there is none, and the changelog says so under "not fixed, on purpose" rather than leaving you to wonder.

One new file

assets/js/share.js is a file every page now loads. On a site that never sets share: it does nothing at all; it is still a file, and a deploy that misses it leaves a 404 in the console. git pull, rebuild, deploy — and it is there.

The controls make no request to anyone until the reader presses one. That is the rule for everything the engine puts on a page, and this row is no exception: the share buttons of the web are usually the one thing on a page that phones home before you touch them, and these do not.

Dialect is not language

Two accents were in the way. GoToSocial writes a status address in its own shape, and the engine's pattern insisted on Mastodon's — a numeric id where GTS answers with a 26-character ULID. And GTS requires a token even to read a public thread, where Mastodon hands it to anyone who asks. The first accent broke the address parsing; the second broke the entire idea of live comments, which is a visitor's browser fetching the thread — a browser you cannot give a token to.

Moderation is the door in

So on GoToSocial, comments are the moderated kind by construction: comments.approval: fav, and the cron reads the thread with the token, server-side, publishing the replies you star. The side effect is one Mastodon sites choose deliberately: visitors' browsers stop contacting your instance at all.

doctor --online now tests the capability, not the brand — can an anonymous request read the thread? — so a Mastodon instance in secure mode gets the same honest answer. And the fix was confirmed where the bug was found: the first starred reply on arch-linux.cz appeared under its post the same day 1.4 landed there.

comments.approval: fav is the third answer. A reply appears under the article once I favourite it, from whatever client I happen to have open.

No queue, no dashboard

That is the point of doing it this way. A moderation queue is a second interface, with a second login, that you visit specially — which means you visit it late, or not at all. Here the interface is the app the comments already live in. I read the reply where I was going to read it anyway, and approving is one tap in that same place.

Two rules keep the result readable rather than merely filtered. My own replies need no star, because nobody stars themselves and half of every exchange would otherwise vanish. And a reply is shown only if everything between it and the announcement is shown too — an approved answer to a rejected comment answers nothing.

What it costs, and the costs are real

A favourite is public. On both networks. Approving is also endorsing in the eyes of anyone who looks, and every star handed out over the years is retroactively an approval. A private signal — bookmarks — would not carry that, and is the obvious second mode if this one chafes.

The moment you switch it on, every comment on the site disappears. Moderation publishes what has been starred, and at that moment that is nothing. A site with years of replies goes quiet in one rebuild. Plan the switch for an hour when you can go and star the keepers, and run ./scripts/refresh-sidebar.sh --full afterwards to settle the old posts on the spot instead of within the week.

Approval is not instant. Up to one cron interval — and up to a week under a post older than about three months, since old posts are only refreshed occasionally. "Did I favourite this?" is a question only an authenticated request can ask, and the token cannot be shipped to a browser, so cron reads the thread and writes the answer; the page renders from that. ./scripts/refresh-sidebar.sh --full does it now instead of eventually.

It makes an older promise on this site conditional. There is a post here saying there is no comment database — nothing to migrate, back up, or moderate at 2am. With approval on, only the last third of that stays true. What has been starred is written to a file the pages read, rewritten from the source on every cron run, with no interface anywhere that can edit it: a cache rather than a database, but other people's words on my disk all the same.

And somebody's deletion can outlive itself here. A reply deleted at the source leaves this site at the refresh cron's cadence rather than immediately — under an old post, up to a week later. --full settles it on the spot, but the lag is part of the price rather than a setting, and it is the part that is paid by someone other than me.

It keeps replies off the blog, not off the network. The thread stays public and this site still links to it. Block, mute and report remain the tools for the rest.

The side effect nobody asks for

With the thread already read on the server, the visitor's browser stops contacting the network at all — and the page's content security policy drops its grant to the instance along with it. The live thread was the one client-side exception to no third-party requests from the visitor's browser. A moderated thread is not live, so the exception lapses with it.

Avatars still come from the instance hosting them. Everything else arrives from this domain.

Turning it on

comments:
  approval: fav      # or "off" (the default)

Three things have to be true, and ./blog.sh doctor --online says so when they are not: the sidebar cron has to be running, a Mastodon token needs read:statuses alongside write:statuses — a token without it gets a perfectly good answer with the favourited field left out, which reads as "approved nothing" — and you have to go and star the ones worth keeping. On Bluesky the app password you already have is enough.

Two networks are in. Two are not — and here's the whole reasoning, because "we decided against it" is not a reason.

./blog.sh announces every published post on Mastodon or Bluesky, and the replies to that announcement become the post's comments. For that to work, the engine needs two things from a network: a way to post, and a way for a browser to read a public thread. Cheap, ideally free, forever — because a personal blog is a decades-long project with a hobby budget.

X: no

Look at that price list again. Announcing a post with a link costs real money. Loading the reply thread — which happens every time anyone scrolls to the comments — costs real money, per read, forever. On a personal blog, that's a subscription to your own comment section, billed by your readers' curiosity.

There's no engineering answer to a pricing decision. So: no.

Threads: not yet

Threads is genuinely feasible, and the design is sitting in a drawer. But look at what "feasible" means here:

Publishing and reading replies to your own posts works — server-side only, through a registered Meta developer app, with OAuth and 60-day tokens.— the Threads API docs, summarized

In practice that's a cron job refreshing tokens so they never silently expire, and comments cached into JSON with roughly a half-hour delay — instead of the live thread Mastodon and Bluesky hand any browser for free. It's all buildable. It's just a lot of standing machinery for a network nobody has asked me about yet. The day someone does, the drawer opens.

Scraping Threads: no, and firmly

The tempting shortcut — skip the API, scrape the web app — fails three ways at once. The app's internals change constantly and no community project maintains a stable interface to them. Meta blocks datacenter IPs and forbids automated collection in its terms, so shipping a scraper in a community engine means handing every user a feature that breaks without warning and can put their account at risk. And the paid scraping services fail the same test with extra steps: per-request pricing, your data flowing through a third party, and a dependency on someone else's ongoing legal cat-and-mouse.

The scoreboard

Mastodon and Bluesky are in because they pass the boring test: free to post, free for a browser to read a public thread, no tokens with expiry dates in the critical path. Any network that starts passing it is welcome. Any network that stops — well, now you know the exit criteria too.

When a post is published, the engine announces it on Mastodon or Bluesky — one network per site, never both; the build refuses a config with two, because comments live in exactly one place. Replies to that announcement are the comments: your browser loads the thread straight from the network's public API, no login, no key, no middleman. The counters under the title are the same numbers, read from the same toot.

What falls out of that

No comment database — nothing to migrate, back up, or moderate at 2am. No spam filter, because the network already has one, and it's better funded than mine. The comment count is just the reply count. And moderation is your instance's moderation: block, mute and report all work exactly where the conversation actually happens.

The comments also belong to the people who wrote them, in their own timeline, under their own name. A reply here is a real post by a real account — not a row in my database wearing a nickname.

What it costs

Honesty first: if you're not on the Fediverse or Bluesky, you don't get to comment. That's a real cost and I won't pretend otherwise. You can still read the thread — it's public — and the bar for joining is an email address. For a personal blog, I'll take that trade over hosting a login system every day of the week.

Two details that earn their keep

unpublish deletes the announcement too. A toot pointing at a dead URL helps nobody, so taking a post down takes its thread anchor down with it.

Imported posts don't announce. The auto-announcement has a 24-hour window around "now" — so migrating a thousand posts from your old blog doesn't turn into a thousand-toot night for your followers. (You can still announce any post manually, whenever it deserves it.)

Try it on this very post

This is the part I can't fake, which is exactly why it's the demo. Reply to this post's toot — what's missing here, what would make you use this engine, or what convinced you not to — and your reply appears below, hosted by no one, moderated by your instance, owned by you.