A guide to implement ActivityPub in a static site (or any website) - Part 2

In Part 2, we will delve into the design of my implementation. If you want to read about why you should bring your site to the Fediverse, check out Part 1. You can also navigate the other parts of this series here.

So, you’ve decided to bring your blog to the social web, the Fediverse. That’s cool! This guide might be just what you need. And if you’ve got this or any other method working, shoot me a message on the social web, and I’ll gladly follow. But first, a word of caution: if you’re considering adding ActivityPub to your static site (or any site), I strongly suggest you look for existing implementations that could make your life easier:

• If you don’t have a blog, you could install Wordpress or create an account on Medium, they allow federation.
• If you’re already using Wordpress, you could install the ActivityPub plugin.
• If your site publishes RSS or Atom feeds, you could use Bridgy-Fed to bring your site to the social web.
• Another alternative would be to create a Mastodon bot and use the Mastodon API to post messages automatically. This has the advantage that you don’t need to set up anything, and you can do cool stuff like retrieve comments from that toot/post, as Carl Schwan explains in this post.
• You could also create your own Mastodon instance. DigitalOcean has a one-click deploy (which doesn’t work 100%, but almost).

None of these alternatives were enough for me because they didn’t fully cover my constraints/goals:

• I wanted my blog to federate with Mastodon instances through ActivityPub. This means that the blog may appear in other ActivityPub implementations, but the focus and priority are to make it visible in Mastodon, or in other words, the Mastodon implementation of ActivityPub.
• Use static files whenever possible. This allows for maintaining everything cheap, fast, and secure.
• Low maintenance platform. When static files are not possible, use the cheapest and least time-consuming alternative in Azure (I have some credit there). In my case, I chose Azure Functions, but the results can be easily implemented in AWS, GCP, or any other server.
• Use my own domain. It should use the blog domain (e.g., maho.dev).

(Bridgy-Fed came very close).

So, buckle up. This is how to implement ActivityPub on your almost static site. My blog is powered by Hugo, and deployed to Azure, but this should work with other cloud providers and other static site generators.

This is how my resources look:

Most of the lines represent soft relations. If you feel overwhelmed, don’t worry; I will explain in detail.

• You may already be familiar with Hugo; it converts markdown files to HTML files and creates a big public folder that gets uploaded to my Azure container. It also creates XML files for the RSS feeds.
• The RSS2Outbox tool converts an XML feed to ActivityPub format, generating an outbox and notes. I will explain these formats in detail later.
• Webfinger and actor files are generated manually. I will explain these later.
• There are two tables to store followers and replies. These can be an SQLite database, an RDBS, or a document db. I use Azure Table Storage.
• The Azure Function Inbox is the only non-dynamic endpoint, and for good reasons: it needs to respond to POST requests (for example, when someone follows/subscribes to your blog), and it needs to respond with a time-signed, private-RSA-key-signed message.

The Azure Function can be an AWS Lambda, or a Raspberry Pi running in your garage. All other resources are just static files that, in my case, live in Azure Blob Storage, but they can live anywhere, like AWS S3. Btw, there is no reestriction on the domain of this endpoint, it does not need to be the same as the one from your site.

All these resources allow you to do the basic four things explained in the previous post of the series:

1. Be discovered in the Fediverse as an account.
2. Be able to be followed/unfollowed.
3. Generate and federate/broadcast posts to your followers.
4. Be able to receive replies to a post.

To get this done, I experienced the frustration of testing so you don’t need to do it. I even set up my own Mastodon instance just to test. So, I’ve divided this guide into those four topics: discovery, follow, broadcast, and replies.

In the next blog post, I will explain how to make your static site be discovered in the Fediverse. If you’re interested, follow @blog@maho.dev in the Fediverse and let me know what you think!