today i watched christopher webber's panel about activitypub. there was some talk about what activitypub is meant to be, but what really stuck out to me was his commentary about the current state of the fediverse around 24:45:
the way the fediverse is currently designed [is actually really bizarre to me] has been to encourage each one of the projects to come out to brand themselves as like "the activitypub server for this" [...] i don't see why we shouldn't try to pursue this vision of you know, you are able to swap out any client for any server
this is really important! i think what this explanation is lacking, though, is a clear definition of server software, user-agent, and frontend; i will define these here for the purposes of this blog post, though they might be technically inaccurate:
- server: this is the software that talks to other servers on the fediverse and allows for federated interaction
- user-agent: software that acts on behalf of the user (in this case in order to facilitate posting content to the fediverse)
- frontend: this is what allows the user to communicate with the user-agent in a meaningful way
this brings me to my original point, which is that mastodon is not just a server. mastodon is actually a server and a user-agent wrapped up in one tight package (it also serves a frontend, but we'll get to that). mastodon provides a way to communicate with the greater fediverse, but it only lets a user interact with certain types of content it understands, ignoring everything else. it uses its own api to talk to a simple frontend which displays posts and allows the user to post their own content with simple requests to the server via the mastodon api. in this case, the mastodon software is doing most of the heavy lifting aside from just fetching and delivering content, whereas in a separate user-agent model this would be handled aside from the server itself.
why is this bad? well, for one thing it means that the server software only speaks the mastodon protocol. you can't, for instance, hook up a peertube frontend and use it natively; but aside from that it means that the user is restricted to the behavior of the mastodon user-agent and is unable to do anything the user-agent does not understand. if you don't run your own server, this means you can't change the behavior at all beyond the bounds of the built-in user preferences.
let's talk about activitypub c2s, then. while it might seem like just another client protocol on the surface, it uses activitystreams and is therefore as extensible as s2s! the server doesn't have to understand or unwrap what the user-agent gives it, as long as it's a valid activitystreams object. it just takes that and distributes it to its recipients, no heavy lifting required!
if we take this idea and run with it, we can theoretically turn any specific activitypub software into just a user-agent (with some exceptions, we'll get to that). we can host the simpler user-agents on our local computers, or even use them baked into frontends! awesome! of course, for services like peertube we need to add some extra code to the plugin so the server understands how to deal with the new types of content (which could be baked in, or provided by a plugin of some sort), but that doesn't prevent other user-agents from interacting with the same server as well.
obviously, there are going to be some difficulties moving from our current structure to a new one; besides the implicit struggle of rebuilding software for a new model, c2s doesn't have a standardized ways to do some of the things that current activitypub servers provide. c2s doesn't have a way to ask the server to search for a thing, which is a feature that mastodon has. currently you'd either have to implement some nonstandard way of querying a search term, or pull down all the things you want to look through and do it yourself. neither of these methods are very great. it also doesn't specify authentication or authorization (yet). regardless, if we can standardize more of these common features it would be a huge win for the average fediverse user to be able to interact with everyone else closer to their own terms.
if you have questions or anything to add, you can contact me at @email@example.com!
- @firstname.lastname@example.org for co-writing the activitypub spec and giving feedback on this blog post before i put it up.
- @email@example.com for talking with me about potential issues with the approaches i've described
- @firstname.lastname@example.org for helping me sort out my thoughts on the matter and shape them into a useful (i hope) format