I'm getting truly fed up with spam in my wiki. At this point, all comments are manually approved and I still get trouble: now it's scammers spamming the registration form with dummy accounts, which bounce back to me when I make new posts, or just generate backscatter for the confirmation email. It's really bad. I have hundreds of users registered on my blog, and I don't know which are spammy, which aren't.

So. I'm considering ditching ikiwiki comments altogether and I'm turning towards Mastodon as a commenting platforms. Others (JAK) have implemented this [as a server](https://github.com/julian-klode/mastodon-comments) but a more interesting approach for me is to simply load them dynamically from the server, which is what [this person has done](https://carlschwan.eu/2020/12/29/adding-comments-to-your-static-blog-with-mastodon/). They are using Hugo, however, so they can easily embed page metadata in the template to load the right server with the right comment ID.

I'm not sure how to do this in ikiwiki: how can we access page-specific data in [[templates]]?

Or maybe i just need to make a new template and insert it in my blog posts... pondering. --[[anarcat]]

> I have tried to make a template, and that (obviously) fails because the `<script>` stuff gets sanitized. It seems I would need to split the javascript out of the template into a base template and then make the page template refer to a function in there. It's kind of horrible and messy. I wish there was a way to just access page metadata from the page template itself... I see that the [[plugins/meta]] plugin passes along its metadata, but that's not extensible, so i'd need to either patch that or make yet another plugin. Ugh.

>> Update: I did it. I have something that kind of works that's a combination of a `page.tmpl` patch and a plugin. The plugin adds a `[[!mastodon]]` directive that feeds the `page.tmpl` with the right stuff, and adds comments through Javascript and the API. It's not pretty, but it works. You need [this page.tmpl](https://gitlab.com/anarcat/ikiwiki-bootstrap-anarcat/-/blob/01524241a1346211bad2d681f0ed634af29d5c38/templates/page.tmpl) (or at least [this patch](https://gitlab.com/anarcat/ikiwiki-bootstrap-anarcat/-/commit/491dd6bfba3bee3ce702545e7f445e227dc66b30) and [that one](https://gitlab.com/anarcat/ikiwiki-bootstrap-anarcat/-/commit/c0abd79e53b8fee60cf4582971df35e6feb957fd)) and the [mastodon.pm plugin](https://gitlab.com/anarcat/ikiwiki/-/blob/2400baee8f5bc06f810b5ed96395ee84b05943ed/IkiWiki/Plugin/mastodon.pm) from my [mastodon-plugin](https://gitlab.com/anarcat/ikiwiki/-/tree/mastodon-plugin) branch.
>>
>> I'm not even sure this is a good idea. The first test I did was a "test comment" which led to half a dozen "test reply" and then I realized i couldn't redact individual posts from there. Ugh. I don't even know if, when I mute a user, it actually gets hidden from everyone else too...
>>
>> So I'll test this for a while, I guess.

# Update: the feed2exec diversion

There's another thing that's needed to make this work, which I didn't mention above, which is to automatically *post* new entries to Mastodon when they show up, because otherwise the above needs you to manually post the thing to Mastodon. It's kind of a mess. At first, I implemented this as a [feed2exec](https://gitlab.com/anarcat/feed2exec) plugin called [ikiwikitoot.py](https://gitlab.com/anarcat/feed2exec/-/blob/main/feed2exec/plugins/ikiwikitoot.py) but that didn't work reliably: there was this horrible bootstrapping issue that you had to first post the article, then run the RSS feed, and that modifies the article again.

This didn't work reliably for me, so I added more duct-tape so you can now run the command directly without going through the RSS feed. I ended up with the following post-receive hook in my `source.git`:

```
w-anarcat@marcos:~/source.git$ cat hooks/post-receive
#!/bin/sh

/home/anarcat/src/feed2exec/feed2exec/plugins/ikiwikitoot.py --post-receive --base-url https://anarc.at/ 
```

And the code still lives in feed2exec... It makes use of my second Python parser for ikiwiki directives (ugh) which really makes me feel like this should be implemented natively as a real ikiwiki plugin instead.

I'm not sure how this would work: we'd need to somehow keep state of which page is associated with which mastodon post. In theory, this could be kept in .ikiwiki, but i find that iffy: i really like the idea of having the mastodon post directly in the git source, but i'm not aware of any ikiwiki plugin actually modifying the source, that seems to be traditionnally a "no no".

I would also really like ikiwiki to render comments as static HTML. This would add a couple benefits over the current approach:

 1. no javascript necessary
 2. reduce load on the mastodon server (the current approach hits the server for every *visitor* that hits the "load comments" button, which is not kind to the mastodon server)
 3. reduce reliance on the upstream mastodon server to be up (right now, if mastodon goes away, comments disappear)
 4. allow for moderation on the ikiwiki side (right now, we're completely subject to the mastodon server moderation, if we don't like a comment, we can't remove it without removing it from the mastodon server)

But that's even more work. I definitely like the idea of adding `!comment` directives to existing posts though, this feels nice, and it's easy to remove them to do moderation.

The trick is "when do you post updates": short of having a daemon (or CGI?) that receives activitypub pushes, we'd need *something* that pulls new updates on a regular basis anyways, so it's not clear how easy it would be to actually implement.

Still, moving that code from feed2exec/python to ikiwiki/perl (or ikiwiki/python, there's precedents here), would be an important step, IMHO.

Thoughts? -- [[anarcat]] 2025-03-03

> I agree that, for this workflow, what you describe is a great improvement: getting the supplementary code into IkiWiki.
> 
> I've been wondering about a different approach to Fediverse-enabling an IkiWiki site. Instead of the chicken-and-egg problem of toot-about-post, then update post with toot-id; what if the post itself was a first-class Fediverse object from the start? You could "follow" your blog directly, and re-toot (or toot about) a blog post once that post existed in the Fediverse, which would ideally be as soon as it existed anywhere else. I'm exploring what might be required for this approach, starting with stuff like [Mastodon instance with 6 files](https://justingarrison.com/blog/2022-12-06-mastodon-files-instance/). *— [[Jon]], 2025-05-20*

> > Yeah, that's what I initially thought of doing, but that seemed even harder to implement. That post, for example, mentions "posts don't work", which is the critical part that we actually need here. We'd also need to handle `POST` requests for the /inbox endpoint, which would require CGI (which I'm trying to get rid of in my deployments...). But yeah, this would be pretty awesome! -- [[anarcat]]
