A static blog with the fediverse as its comment system

Tue, 03 Nov 2026 14:30:00 +0100

I wanted comments without running a comment system. Forms get spammed the moment a search engine finds them, a comment database is one more thing to patch, and the hosted widgets all phone home. And I already had a Mastodon server sitting there, where the conversation would end up anyway.

So the toot is the comment thread. I publish here, announce it on the fediverse, and the post page fetches the replies to its own toot (and its Bluesky post) and shows them underneath. Readers answer where they already have an account, and I moderate with the tools those networks already have. It took one evening to build and about three to debug, and the debugging is most of this post.

The site

Hugo with the PaperMod theme, markdown in a git repository on a box at home. The output is plain files, served by nginx in a small isolated container that only the reverse proxy can reach. GET and HEAD; everything else gets a 405.

Publishing is a git push. A cron job on the build box fetches the repository every five minutes and, when the commit has changed, builds twice: the public site, and a preview behind basic auth that includes drafts and scheduled posts. The public build goes through the redaction check described further down and is then unpacked next to the live directory and swapped in.

Scheduling came for free. A post with a future date is skipped by Hugo until the time has passed, so the build job keys its “anything changed?” test on the commit plus the list of still-future posts, and the first run after the time publishes and announces.

There is one more gate, and it exists because of the first post. A scheduled post only goes out if the version I reviewed is the version in git, recorded as a hash of the file. Edit the post after approving it and the build holds it with a line in the log until someone approves again. I found out how that feels on launch day: three small edits after the morning approval, and the 15:00 slot came and went while I was wondering why nothing had happened. Ten minutes of annoyance. It was doing its job.

The announcement

After each deploy a script reads the site’s RSS feed and, for every post it hasn’t announced yet, does the rounds.

A public toot from my account: title, summary, link, up to eight hashtags from the post. The toot’s id is saved against the post’s path, and the request carries an idempotency key so a retry can’t post twice. Then a Bluesky post with a link card and the social-card image as its thumbnail. Then an IndexNow ping, and the full article to dev.to with a canonical link back here.

Lemmy is the interesting one. If the post’s front matter names a community, the toot mentions it, and Lemmy turns the mention into a post in that community; replies there federate back as replies to the toot. The catch is that the mention only becomes a real mention if my instance has seen that community before. The first time it hadn’t. The mention stayed plain text, no Lemmy post appeared, and I sat there refreshing the community page until I understood why. Looking the community up once in the web UI and editing the toot fixed it; Lemmy created the post from the edit within seconds. The publisher now asks the instance to look the community up itself before posting, which needed a token that is allowed to search.

dev.to deserves its own paragraph, because its API has three habits the documentation doesn’t mention. It refuses the default Python user agent outright (“Forbidden Bots”). It renders every single newline as a line break, so hard-wrapped markdown arrives as a poem. And it drops SVG images. The publisher now sends a descriptive user agent, unwraps the paragraphs, swaps an SVG for its PNG twin when one exists, and picks the four tags dev.to readers actually follow.

All the saved ids go into a syndication.json on the site. That file is the only state the comments need.

The comments

A small script on the post page reads syndication.json, finds the toot id for the current path, and calls the Mastodon instance’s public context endpoint for that status. No token needed: public statuses and their replies are public. Bluesky’s public API gives the same for the post thread.

The rendering rules are the whole security story. Everything from either API is inserted as text; reply HTML from Mastodon is converted to plain text with the paragraph breaks kept, and nothing is ever parsed as HTML on my page. Links in replies become plain anchors with rel="nofollow ugc noopener noreferrer". Avatars load only from the two known hosts, as small thumbnails, and a missing one is dropped rather than shown broken. Only public and unlisted replies, at most 200. The page sends nothing anywhere.

Moderation is no extra work. Block or mute an account on Mastodon and its replies disappear from the API response, and so from the page.

Because nothing on the page is dynamic, the Content Security Policy can be strict: default-src 'none', scripts and styles from the site only (the theme needs inline for its dark-mode toggle), connect-src limited to the Mastodon instance and Bluesky’s public API, img-src the same two hosts plus self, no framing, no forms, no base tag. Add nosniff, a referrer policy, the cross-origin isolation headers, rate limits per client, and an access log with the last part of every address removed. No cookies, so no banner.

The redaction check

The biggest risk on a blog about your own network is you. My notes are full of internal addresses, hostnames, identifiers and the odd token, and the posts are written from those notes. So the public build is grepped before every deploy: private IP ranges, the public IP, MAC addresses, the street and the town, phone numbers, e-mail aliases, anything shaped like a bearer token or an API key, serial numbers, internal hostnames, and a list of things I have decided never to mention. One hit and the deploy stops with a notification. An allow-list covers deliberate mentions. It has already caught a home-page title, which is not where I expected the first hit.

Two bugs a real browser found

Before the first post I loaded the preview in headless Chrome on a VM, with the comments pointed at a test thread. Every unit-level check had passed. The browser found two things that would have shipped.

The preview never showed comments. The page’s lookup key kept the /preview prefix, so it never matched the keys in syndication.json. Trivial, and invisible without a browser.

The second one was stranger: nobody at home would ever have seen comments. My other public hostnames resolve to the reverse proxy’s LAN address when you are on the LAN (split DNS), and the new blog name didn’t yet. To Chrome the blog was a public page trying to read a private address, and its private-network-access rule blocked the request. Visitors on the internet were fine. The author was not. One DNS override fixed it, and “every public name gets the override” is now written down.

That check is part of publishing now. Load the draft in Chrome, collect console errors, failed requests, broken images and links, confirm the comments widget works, take phone and desktop screenshots, and put it all on a review page behind the preview login.

The bug a browser could not find

The announcement toot for the first post went out fine. Text, hashtags, link. No link card.

Bluesky’s card was there. Every other crawler on the fediverse had fetched the page. My own Mastodon instance had not even tried: nothing in its logs, no failed job, no retry. I looked at that empty space under the toot for longer than I’d like to admit.

The cause was the fix from the second bug above. Split DNS makes the blog’s name resolve to the reverse proxy’s LAN address inside the house, and the Mastodon server lives inside the house. Mastodon’s HTTP client refuses to fetch private addresses, a sensible guard against server-side request forgery, and the link-card service swallows that refusal without a word. So every link to one of my own sites, posted from my own instance, would never get a card.

I didn’t loosen the guard. The Mastodon containers got public DNS instead, so my names resolve to the public address for them and the fetch loops back in through the firewall like any outside visitor. Running the card service by hand on the toot produced the card a second later.

So the DNS lesson has a footnote: split DNS is right for the clients and wrong for any service on the LAN that is supposed to behave like a stranger. I’m fairly sure there are more of those on my network that I haven’t found yet.

After the first post

Replies are fetched every ten minutes and each new one arrives as a push notification with its text and a link to answer. Answering within the hour instead of the next morning is what makes this feel like a comment system rather than a mailing list.

The Lemmy community mention did more than everything else combined. Within an hour of the post, a few hundred fediverse servers had fetched the page for their link previews, almost all of them subscribers of that community. Page views were a fraction of that, in the low hundreds on the first day, two thirds of them within two hours of the announcement. Previews are reach, not readers.

The comments came in the way I had hoped, more or less. The first was from an account that describes itself as an AI agent; it asked a precise question about the matching rule and followed up with a sharper one, and since it is a public thread I answered it like any other reader. A few days later someone on another Mastodon server asked what the weekly spot-check actually catches and, in passing, described their own convention for records they are not sure about yet. I’m borrowing it.

Every page also carries a rel="me" link to my Mastodon profile, which gives the profile its verified tick, and each post names my account as its author, so shared links show “More from” on servers that support it.

If I were starting again I’d keep almost all of it. Static files plus “comments live elsewhere” is a comfortable place to be: the attack surface is a web server serving files. The toot id is the only state, so save it first and never re-announce. Render other people’s content as text, always. And test from the network your readers are on, which is not your own.

Tools: Hugo, PaperMod, nginx, Nginx Proxy Manager, Mastodon, Lemmy, Bluesky’s AT Protocol API, dev.to’s API, IndexNow, Playwright with Chrome, Python 3, cron. The scripts are specific to this setup and not published; ask in the comments if you want more detail on a step.

Lemmy on fullast.nu