If you’re looking to move beyond the silos of social media sites run by individual companies, you’re maybe looking for federation, which allows multiple sites to communicate and interoperate with each other. You post a photo on this site, your friends on another site can share it, your family on a third site can comment on it. Assuming that’s what you want.

The current best standard for this is ActivityPub which builds on the Activity Vocabulary to define how these different sites and servers can communicate. In theory, it’s very flexible, allowing video hosting and photo sharing and microblogging to all work together. In practice, reading the standard is not nearly sufficient to interoperate with real world implementations.

I’ve written my own implementation of AP and worked most of this out the hard way. Then I wrote some posts about this and that as I experienced it. I’m done writing about it now, so here’s a capstone post collecting everything together, along with links to articles by many others. It’s mostly of interest to implementors, but could also be useful to anyone using the network. Understanding the operation of the protocols involved explains certain behaviors one will observe that perhaps contradict the user manual.

servers

ActivityPub is a federated protocol, which means servers talking to other servers. Servers can also be called sites, or instances. mastodon.social, bsd.network, and pleroma.site are all separate instances.

Pretty much everything here and below is about the server to server aspect of ActivityPub. There is a client to server protocol in the standard, but to the best of my knowledge it is not used anywhere.

ActivityPub servers include Mastodon, Pleroma, Misskey, Honk, Pixelfed, Friendica, PeerTube. It’s the server software that holds your account. All or nearly all AP servers include some form of web interface.

Many people may access their ActivityPub server with a client app. Fedilab, Tusky, etc. These programs communicate with servers using a separate protocol (MastoAPI as Pleroma calls it) that was originally developed for Mastodon, and now also supported by some but not all other implementations. It’s quite outside the scope of anything described here. In general, I assume everybody is using the web interface, but it rarely makes a difference.

ActivityPub

Here are some posts looking at some real world ActivityPub exchanges.

What happens when you activity post is a high level overview of the (many) messages and requests that pass back and forth between servers. How your post goes from here to there.

The activity person examined looks much closer at the actor object, which is how ActivityPub represents you.

Activity notes is not just notes about activities, but in particular about the Note activity type used for microblogging.

Finally AP networking considers some other aspects of networking between servers, message delivery, and security.

honk

My own implementaiton of ActivityPub microblogging is honk.

The honk preview just said it was coming, and expresses some dissatisfaction with the way of the world.

The honk 0.1 post is increasingly dated, but contains some thoughts on the minimal viable features needed for launch. Or at least what I felt I needed. I really did go live with this, and for the most part things were fine.

The followup honking for fun and profit reflects on everything I learned since the previous post, necessary changes, and evolving thoughts on how things should work.

links

A first round of links to get you started understanding ActivityPub. I’d say read these first.

How to read the AP spec. tinysubversions.com/notes/reading-activitypub/.

The ActivityPub philosophy. cjslep.com/c/blog/an-activitypub-philosophy.

Here’s a good post describing shortcomings and compromises in ActivityPub. Also, it’s okay to break stuff. ehiad.org/blog/000002.

Some advice on processing ActivityPub messages. ehiad.org/swaps/000003.

How messages flow around the network. blog.dereferenced.org/federation-what-flows-where-and-why.

And now a pile of links that I found interesting. No particular order.

Some notes about the times before ActivityPub and leaking info: blog.soykaf.com/post/pleroma-encyclical-activity-pub/.

Some notes about implementing AP: blog.soykaf.com/post/activity-pub-in-pleroma/.

Some notes about problems in AP: schub.io/blog/2018/02/01/activitypub-one-protocol-to-rule-them-all.html.

A follow up. schub.io/blog/2019/01/13/activitypub-final-thoughts-one-year-later.html.

AP is still good, despite its flaws. With a section on the magic heuristics used to determine if a post is a direct message or a group message, followers only posts, and more, oh boy! blog.dereferenced.org/activitypub-the-present-state-or-why-saving-the-worse-is-better-virus-is.

A post about dealing with abuse. nolanlawson.com/2018/08/31/mastodon-and-the-challenges-of-abuse-in-a-federated-system/.

OcapPub may solve some of our abuse problems. gitlab.com/spritely/ocappub/blob/master/README.org.

A shorter read on ocap. blog.dereferenced.org/what-is-ocap-and-why-should-i-care.

Interview with Mike Macgirvin and building protocols. medium.com/we-distribute/got-zot-mike-macgirvin-45287601ff19.

Review of Hubzilla. medium.com/we-distribute/the-do-everything-system-an-in-depth-review-of-hubzilla-3-0-692204177d4e.