Add Comments to Your (Static) Blog Using Fediverse Hashtags

• Updates
  • 2026-08-28:
    • added the suggestion to use a general blog hashtag in combination with the article hashtags.
    • added kamm as a tool to follow lots of article hashtags.
  • 2026-09-05: There is a Håck ma’s 2026 talk by me covering that topic: CCC-server and YouTube

(Note: there is a similar German article available as well.)

If you run a (static) blog, you probably ran into the same wall everybody else does eventually: readers want to react, ask questions, or add their own two cents, but static sites - by design - don't ship with a comment section. The classic answers to this problem (Disqus, giscus, utterances, a self-hosted forum, ...) all reintroduce exactly the kind of server, database, or third-party tracking dependency that made you choose a static site generator in the first place.

There is a much lighter alternative: let the Fediverse be your comment system.

Furthermore, you can also use this method for your non-static web-blog. But static blogs do serve as a much better use-case example here.

The idea itself isn't new and isn't mine alone - once you go looking, you'll find it popping up independently in several corners of the IndieWeb and static-site community. What I want to do here is explain why the Fediverse is a good fit for this job in the first place, walk through the two approaches people actually use, explain why I settled on one of them, and give you enough to try it on your own blog today.

You publish an article as a (static) file. Some time later, a reader wants to comment. Where does that comment live, and how does anyone else ever find it again?

Before comparing implementations, it's worth asking the more basic question: why reach for the Fediverse (Mastodon, and anything else that speaks ActivityPub) at all, instead of a purpose-built comment widget?

• Almost no setup cost. You don't need to run a server, a database, or a JavaScript widget. You need one hashtag per article.
• Already available to huge numbers of people. Anyone with an account on the Fediverse (Mastodon, Pixelfed, PeerTube, Lemmy, WordPress with the ActivityPub plugin, …) can comment - no new sign-up required for most readers.
• Built-in following. On Mastodon (and elsewhere), people can follow a hashtag directly and get notified of new posts under it - free "subscribe to comments" functionality you didn't have to build.
• Open standards, low technical barrier. ActivityPub is an open W3C standard. You're not locking your comments - or your readers - into a single vendor's proprietary API.
• Comments belong to their authors, not to your database. Each comment lives on the commenter's own account. They can edit or delete their own words at any time, the same way they would any other post. You're not accumulating a pile of third-party content you now have to store, back up, and moderate yourself.
• No tracking, no cookie banners, no ads. Unlike most hosted comment widgets, there's no third-party script loading on your article page, and no consent banner to bolt on just for comments.
• Moderation is already solved, and it's distributed. Every Fediverse instance already has moderation workflows and instance-specific rules. Problematic posts can be flagged and reported by anyone, and action can be taken at the level of a single message, an account, or - in the worst case - an entire instance. You inherit all of that for free instead of building (and staffing) your own moderation queue.
• Spam resistance for free. Because posting requires an existing Fediverse account on a moderated instance, you skip almost all of the anonymous comment-spam problem that plagues open web forms.
• Fits a static site perfectly. There is no server-side component needed on your end at all - which is exactly the property that made people pick a static site generator to begin with.
• Accessible by design. Readers can use whatever client works best for them - a phone app, a desktop client, or a text-based interface for people with visual impairments - instead of being stuck with whatever accessibility level a specific embedded widget happens to offer.
• Follows the ideas of POSSE. With "Publish (on your) Own Site, Syndicate Elsewhere" you do support the ideas of IndieWeb which promotes a decentralized, independently-hosted web.

Therefore, the Fediverse doesn't force you into an interface dictatorship, rule monopoly or account hurdles like other web forums like reddit, Hacker News, Slashdot, Facebook have.

Once you accept that the Fediverse itself is a solid foundation for comments, there's still a design decision to make: how exactly do you tie a Fediverse conversation to one specific article?

As far as I'm aware, there are two major patterns for doing this:

1. One thread per article. You (the author) post one toot announcing the article and pin/link that specific post. All comments become replies within that single thread. Readers need to locate that one post in order to participate.
2. One hashtag per article. You assign each article its own (reasonably unique) hashtag. Anyone, anywhere in the Fediverse, can start their own toot using that hashtag whenever they want to comment - independently of everyone else's toots.
   • Actually, it would be even better to include a second hashtag: the hashtag that relates to the blog itself. This way, people might follow that general blog hashtag and still get messages referring to one single article.

Both approaches are valid. My personal preference is clearly the hashtag approach, and I use it on this very blog. Here's why.

• No need to locate (or resurrect) an old thread. With a single thread, a reader has to first find "the" canonical post before they can reply. Weeks or months later, that's real friction - and if the original post is ever deleted, edited away, or the account behind it moves or disappears, the entire comment section goes with it. A hashtag has no single point of failure like that.
• Every new thread can bring its own framing. People commenting under a shared hashtag aren't forced into someone else's opening sentence, tone, or context. Proper, independent threading happens naturally - a discussion about one paragraph of your article doesn't have to be a sub-reply buried six levels deep inside an unrelated discussion about another paragraph.
• Effortless following of updates. Following a hashtag on Mastodon is a first-class feature. Readers who want to keep up with an article's discussion just follow the tag - no bespoke tooling required.
• Low barrier to start commenting. Nobody has to "join" a stranger's conversation or worry about whether they're allowed to reply to the first commenter. Starting a fresh toot under the hashtag feels much more natural than replying into someone else's thread.
• Resilience through redundancy. Because comments are spread across many independent posts (often on many different instances), the loss, deletion, or moderation of any single toot doesn't take out the whole discussion the way it would with a single-thread setup.
• No coordination or gatekeeping needed. Nobody needs to wait for you, the author, to post first, and nobody needs special permission to "own" the discussion. The hashtag exists the moment you decide on it.
• Easier for tooling. It's simpler to write a bot or script that aggregates "everything under #your-article-tag" than one that has to track a single, specific post ID and its entire reply tree across instances.

To be fair to the alternative: the single-thread approach has real advocates, and it's a legitimate design too - if you'd rather have one clean, linear conversation that's trivial to embed in full, it might suit you better. I've seen the idea written up elsewhere as embedding one Fediverse thread as the entire comment section for a post. Where it falls short compared to hashtags, in my experience, is durability and discoverability over time: a late reply to an old thread is easy to miss (people replying into an existing thread often default to a quieter visibility setting rather than fully public), whereas a late post under a followed hashtag reaches subscribers just as reliably as an early one. And if the one post everything hinges on ever disappears - account migration, deletion, moderation action - your entire comment section disappears with it.

The trade-off to my own preference: a single thread gives you one linear, easy-to-embed conversation, while hashtag-based comments are scattered and need to be collected (e.g., via a hashtag search link, or a small script that fetches and embeds matching public toots). In practice I've found that a plain link to the hashtag search is enough - readers are used to clicking through.

The hashtag approach isn't free of downsides:

• Comments are scattered across instances rather than sitting in one place, so you (or a script) need to actively pull them together if you want them visible on the article page itself.
• Very generic hashtags will collide with unrelated content, so choose something specific to the article.
• Not every reader has a Fediverse account yet - though given how widely ActivityPub is now supported (Mastodon, Pixelfed, PeerTube, Lemmy, WordPress, and more), the reach is larger than most people expect, and the barrier is roughly the same as creating an account anywhere else.

None of these are showstoppers; they're just things to plan around.

The mechanics are refreshingly simple:

1. Pick a hashtag for your blog in general. In my case, this is #publicvoit.
2. Pick a hashtag scheme for your articles. It just has to be reasonably unique so it doesn't collide with unrelated toots. A good option is deriving it from the article's slug or publishing date, e.g. something like #20260822_BlogCommentsViaHashtags (from this article) or a short, distinctive slug. If you publish often under a shared project name, combining a short prefix with a running number (think #project42) also works well and keeps tags short.
3. Announce the hashtags. Add a line to the bottom of your article like "Discuss this article using #your-blog #your-hashtag" and link it straight to a hashtag search/timeline (e.g. https://mastodon.social/tags/your-hashtag, or better, a search on your own instance).
4. Post about the article yourself, including the blog + article hashtags, from whatever Fediverse account you use for your blog or project. This seeds the tag and gives people something to reply to if they'd rather join an existing toot than start their own.
5. Optionally, embed recent toots. If you want a "comments" look directly on the page, you can fetch and embed public toots matching the article hashtag at build time - several small static-site-friendly tools exist for this, or you can write a short script yourself since Mastodon's public API is simple and well documented.
6. Let go of a central inbox. You don't need to collect, approve, or store anything. The Fediverse is the comment database.

That's it. No plugin, no database migration, no privacy policy update for a third-party widget.

If you maintain a static blog and have been putting off adding comments because every off-the-shelf option felt too heavy, too tracking-laden, or too locked-in, give the hashtag approach a try on your next post. It costs you a single link at the bottom of the article, and it hands the entire hosting, moderation, and notification problem to infrastructure that already exists and that you don't have to run yourself.

In case you're using my static blog generator lazyblorg, you don't have to do anything at all: the proper hashtags are auto-generated and published in the comment section below.

One issue might remain, depending on your situation: when people are using your article hashtags and not your blog hashtag as I sugested, you most probably will miss those messages.

To fix that problem, I added a feature to my static web page generator --hashtag-file which writes all auto-generated article hashtags into a CSV file.

You may generate the article hashtag list via an alternative method of your choice if you are using a different method to generate article hashtags. Either way, you need the list in some form.

Then I made kamm which stands for "Karl's Awesome Mastodon Manager". Yes, I obviously felt bold that moment. ;-)

This little tool is able to digest hashtags provided in form of a CSV file. It understands multiple CSV formats but the hashtags need to be in the first (or in the only) column.

After the basic kamm setup (see README), you can use a command like

 uv run kamm.py --new-hashtag-file YOURHASHTAGFILE.csv	  

to update your Mastodon account so that you now follow all the new hashtags. It automatically checks your settings and creates follow requests for missing tags only.

Isn't that neat? ;-)

This way, I follow hundreds of auto-generated article hashtags, in my case.