Adding Mastodon links to Jekyll

03 Mar 2023
6 minute read

I’ve added Mastodon links to the blog. In the process I created a Jekyll plugin that does all the work.

Jekyll meets Mastodon.
Jekyll meets Mastodon. Image by Dall-E.

Mastodon has been having a bit of a moment recently. Ever since the man-child took over Twitter it’s been in a downward spiral and it seems if you’re one of the dwindling group that’s still trying to use it, the biggest question is whether you will eventually leave it because the technology is failing, the audience is failing, or its CEO is a racist narcissist.

I have a Twitter link on this blog. It’s a standard social link that takes you to a tweet that gets sent out with every blog post. I wanted to do the same for Mastodon but ran into a couple problems.

First, the Twitter link is being done through Bridgy. Bridgy is a site that handles webmentions for you. Any time I link from this site to another site that supports webmentions, that site gets notified and links back to me, and vice-versa. For webmentions, Bridgy works fine.

But Bridgy also supports something called POSSE (Publish Own Site, Syndicate Elsewhere) which is just the concept where I write my own blog posts here, and only link them on Twitter or anywhere else, and that way I get to control my own content.

The POSSE support from Bridgy is kind of a hack. You have to put a fake link in your site text, which Bridgy then interprets as a command to execute the POSSE (making a post to Twitter on your behalf, for example). I tried using Bridgy for Mastodon, but it didn’t work. It turns out there’s a 2-year-old-bug that prevents Bridgy from working with Mastodon. It’s one of those things where each site is pointing the finger at the other, and it didn’t look like it would be resolved anytime soon.

So I decided to roll my own. Instead of relying on a hack to forward my POSSE through a third party, I could just handle it myself and make the Mastodon post directly. How hard would that be?

Update: It looks like Bridgy actually fixed the bug! I still like my direct solution better, though.

If you’d like to use my code, I’ve made it available on GitHub: mastodon-social. To use it, add mastodon-social to your Gemfile. Then in _config.yaml add this section:

  cache-folder: .cache

Set the server to whichever instance you use for your mastodon account.

Next, you need to give the plugin authorization to post to mastodon for you. You can run jekyll mastodon setup to do the initial setup, and then jekyll mastodon authorize to authorize the plugin. You only need to do this once. When you do the authorization, you will have to enter your mastodon account password. The password isn’t saved, but it creates an authorization token which is saved to disk (in the cache folder), so you might want to make sure that’s not world-readable.

Now when you build your site, the plugin will cache the info it needs to post to mastodon. After you do a build, you will want to run jekyll mastodon mark to mark all posts and having been published. Otherwise, the plugin will send a status post for every post on your blog, all at once, which is probably not what you want.

Finally, running jekyll mastodon post will post a status to mastodon for every new post it sees. Typically after you create a new post, you want to run this once to send it to mastodon. It remembers what’s been sent, so if you run it again it won’t post a duplicate.

The other piece of the code is tag to give a Mastodon link for any post. In your template, you can add a link to the Mastodon status like so:

{% mastodon_social %}
Boost on Mastodon
{% end_mastodon_social %}

When you click the link, it sends you to the Mastodon post that references the article.

Mastodon, Likes, and Federation

What I really wanted to do was have a button users could click which would simply boost the status post, similar to a Like button for Facebook. I thought that Xe had something like that on their blog, but it turns out it’s not so simple. Their setup has the user type in the URL for their own Mastodon instance, then redirects them there with a manual boost filled in for them. That’s pretty awkward; I think it’s asking too much of users to type in their instance URL.

The problem is with federations, of course. Every user could have their own Mastodon instance, and there’s no way for a website to figure out which instance any particular user has as their home base. You wouldn’t want that either, it kind of goes against the whole concept of federation.

But then it struck me: there is a way to find out what the user’s home instance is. Or at least, there’s a place where that information is kept.

If someone is using an app to post to Mastodon, say, Ivory for instance, then that app knows the user’s home Mastodon instance. If I could redirect to that app, it could automatically post a boost with a single click.

The way to do that is with a custom URL scheme:

  • Define a mastodon: custom URL scheme
  • Have Ivory register ‘mastodon:’ as a scheme it will respond to
  • Then, if I have a link in my blog like mastodon:/statuses/:id/reblog, and the user follows the link, it will launch Ivory, and…

well, Ivory won’t do anything, because this depends on Ivory responding to the link. But let’s say we define a set of actions, defined by the Mastodon API, so that /statusus/:id/reblog (which is the API path to boost a status), would ask the responding app to take that action. It would work.

All it needs is for this to become a standard. Every Mastodon app would have to comply with this, which is a big ask I admit.

Tagged with

Comments and Webmentions

You can respond to this post using Webmentions. If you published a response to this elsewhere,

This post is licensed under CC BY 4.0