I’ve been on a learning rampage on the topic of the fediverse lately, and there’s plenty of material for writing blog posts.

ActivityPub And Me, Part 1 of ?

1,352 words.

ActivityPub And Me, Part 1 of ?

I’ve been on a learning rampage on the topic of the fediverse lately, and there’s plenty of material for writing blog posts.

With everyone freaking out about Twitter again today, it seems like I good time to publish this draft. However, I’m specifically not going to:

  • Champion the fediverse
  • Explain the fediverse
  • Speculate about the fediverse (well, maybe a little)

There are plenty of resources for that elsewhere. Way too many, in fact. It’s already starting to sound like a trendy fad that’s going to vanish in a couple of months, like sea shanties.

I’m uninterested in those things anyway. I’m more interested in the ActivityPub federating standard (or, “standard,” you might say, since it seems to have remained unchanged for four years now), how it works, how I might integrate it into my blog, and how I might grow as a career software developer because of it.

So yeah, this is a technical post for technical people. I mean, I’m a developer, so what do you expect?

Terminology

Minor rant: Much of Mastodon’s terminology has infected the fediverse and it’s pretty annoying. If you support federation and “freedom from corporate tyranny,” you should also support tearing down Mastodon as the de facto “leader” of the fediverse. They are on track to lead the fediverse into the exact same problems as Microsoft once created by leading the browser wars.

So I’ll be using ActivityPub terminology, which is the only W3C-approved standard available. I don’t love their terminology, and honestly I don’t love the implementation, but it’s the best we’ve got so far. I don’t think there are many people who would dispute that it needs to evolve if the fediverse is going to survive at anywhere near the scale of a Twitter.

The point is, there is no word for an “instance” in ActivityPub, for example. It’s just an HTTP server, and a user is just an HTTP client, or more semantically, an Actor.

There is no word “toot” in the standard (thank God). It’s called a Note, which is really just an Object, which is really just a snippet of, by default, amorphous HTML content, but it could really be anything that can be represented by JSON and a media-type (which is literally any series of bytes, from text to images to massive videos, not that anyone would allow that).

A Brief History Lesson

Incidentally, ActivityPub and the fediverse reminds me of FidoNet. Remember FidoNet? That was distributed social networking, too, and ActivityPub is conceptually similar.

Not to be pessimistic or speculate too much, but, as of now, I don’t see any reason not to expect a similar outcome with the fediverse:

… FidoNet was beset with management problems and infighting. Much of this can be traced to the fact that the inter-net delivery cost real money, and the traffic grew … various methods of recouping the costs were attempted, all of which caused friction …

What I Want From ActivityPub

I wouldn’t say I’m a big fan of Mastodon or its ecosystem (it’s written in Ruby for God’s sake, the same platform Twitter abandoned), but I have a passing interest in the ActivityPub federation protocol and how it could be useful to me as a blog owner.

In particular, I think it would be a nice evolution on blogging to embed an ActivityPub implementation directly into the blog. I’m not talking about a connector between a blog and the fediverse, I’m talking about the blog server being a fediverse server, and the blog itself being an Actor (or more likely an Organization, in the parlance of ActivityPub).

The idea would be to simply follow, for example, posts@endgameviable.com from your favorite fediverse web site of choice (much like you would follow an RSS feed), and then you would receive post summaries from the blog in your Inbox alongside all of your other fediverse gossip.

Even more exciting*, you could in theory reply to these posts, which is a very handy substitute for a comment system. Presto, just like magic, you, the reader, are responsible for your own comments and I, the site owner, no longer have to store them or display them or manage your identity credentials, freeing me from significant amounts of risk.

I’ve wished for a long time that I could do that with Twitter: That the comment section at the bottom of a blog post would just be a list of tweet replies to the notification tweet. Twitter doesn’t want to be used like that, though. But all bets are off with decentralized social networking.

This, I think, could be the future of blogging. Or at least, a future. One that probably won’t ever catch on among casual bloggers until or unless it’s baked into WordPress by default, which it clearly won’t ever be, because WordPress gonna WordPress.

Nevertheless, for a programmer, ActivityPub is a fun puzzle. Looks good on a resume, too.

The Fediverse is Anti-Static

Unfortunately for me, my blog is static now, and ActivityPub support is a fairly dynamic proposition, so I’m dead in the water right out of the gate. Those running WordPress would have a much easier time doing this. (In fact, I run across ActivityPub plugins for WordPress in searches all the time. I don’t know what they do, but maybe that’s what they’re for.)

I’ve tweaked Hugo to build static JSON files to deliver ActivityPub endpoints with some success, but there are a few sticking points that keep coming up. (Beyond the fact that Hugo is almost impossible to understand by default.)

The main one is that ActivityPub discoverability is accomplished with something called webfinger. If I type in, for example, posts@endgameviable.com into the Mastodon or presumably any other search box, Mastodon reaches out to endgameviable.com/.well-known/webfinger?resource=acct:posts@endgameviable.com to politely inquire (or rudely demand, depending on your point of view I guess) as to whether that server understands ActivityPub and if that account exists.

It’s pretty hard to get Hugo to build a static file to serve a dynamic request like that. Well nigh impossible, you might say.

Which is a bummer. I’d hate to have to switch back to traditional or cloud hosting just to respond to a webfinger request. After almost two years of incremental progress, I’ve gotten my blog hosting costs on AWS down to about $2/month.

Another problem is that Hugo, the static blog generator, stubbornly insists on creating static files everywhere. You’re putting endgameviable.com/about/ into the address bar, but you’re really loading a file called /about/index.html from the filesystem.

To make the JSON endpoints for an ActivityPub outbox, it would have to be called something like endgameviable.com/outbox/index.json and that would have to be the canonical URL because there’s no industry-wide mechanism to default to index.json if the filename is missing. It will technically work, but it isn’t what I want. Backend implementation details should never be seen in a URL, in my opinion.

These problems are solvable, but only if you manage the server that’s responding to these HTTP requests–if, for example, you have access to an Apache or nginx config file for your site. But it’s a thorny problem the way my blog is currently hosted, at AWS Amplify.

Conclusion

So I have two mutually-exclusive goals at the moment: Maintain a static blog for cheap and secure hosting, and integrate an ActivityPub server implementation with it.

I have some ideas for accomplishing both, but I’m still ironing out the details, and it will almost surely require custom code and a new host, either in a box sitting on my living room floor (free, but subject to bandwidth limitations and security concerns), or a virtual server in the cloud somewhere (preferable, but more expensive than is warranted for a personal experiment that may or may not work).

Anyhoo, those are some of my ActivityPub interests and the obstacles I need to overcome to make it happen.

* Exciting for me, at least, a site owner who has a history of wishing I didn’t have to host comments, for various legal and ethical and security reasons. Comments are by far the biggest risk factor for a web site owner.

Note: Comments are disabled on older posts.