This post is inspired by this prior post about a blog leaving the fediverse in favor of sticking to RSS:

Why do we advocate for, and pour hours of development into, ActivityPub rather than building clients which add a social layer to existing content distribution and communication protocols? I ask this in earnest, assuming that there is a comprehensive and well thought out array of reasons that I need to learn to fully grasp the project and it’s motives.

It appears the fundamental design decision of Activity pub, shifting the hosting burden from a single host to a distributed network of server instances and user point of access to social content from a single host to any instance that will allow them to join and support the volume of content that they request to federate. This enables a more robust network, with instances holding content the users have interacted with regardless of if the original host instance goes down. It also reduces time to load for content after it has beed federated to a user’s local instance, assuming it is closer in proximity and capable enough. At the same time, this dramatically increases the total storage burden (and to a lesser extent compute burden) of the network and makes content ownership and control a challenge.

Functionally the Fediverse is a public commons with content ownership practically distributed across the network of instances, whether copyright says so or not. Attempts to impose universal author controls on this framework face a lot of dissonance because it is fundamentally at odds with the underlying concept of federation as distributed hosting. The minute a host begins hosting content over which they have no control (such as encrypted posts) the potential for abuse skyrockets, and compromises between these priorities demand at minimum that users outside a host’s instance maintain rights to delete and modify content on their instance whether or not they are otherwise at odds with the instance admin. Encryption also adds substantial compute burden to the network.

Since the popularization of the Distributed Social Network concept I have wondered whether pre-existing content distribution infrastructure like RSS/Atom might not be more advantageous as a backbone for social networking, with the development load shifted mostly to the client side and away from protocols. The IndieWeb project is playing with some of these ideas, and I have seen some prototypes online of RSS based social networks, so my question is, what is the fundamental advantage of ActivityPub over the combination of these other existing protocols with longer histories and broader existing implementation? RSS, Atom, email, XMPP, etc. Is lower latency really a good enough justification for widely redundant data distribution when the aggregation and discovery of content can be handled separately from hosting it?

This question becomes increasingly relevant when it comes to multimedia, and the minute that you offload multimedia to central servers by link embedding instead of hosting within the instance, boom you are back to the old centralized architecture and why are you federating?

So I am going to pose this question to the Fediverse myself, what is the reason that federated content distribution should be adopted for general use rather than distributed aggregation? That is to say of a client performed with the same features as a Fediverse front end, but all of the content was self-hosted and listed via RSS or Atom with comments handled via Webmention, direct messages via email or XMPP, and moderation and discivery handled at the level of aggregation via instances (meaning a user “joins” or “subscribes” to an instance, and that instance provides a ban list, list of feeds subscribed to by its users for discovery, provides a user directory) what would be the features that this type of system would lack that ActivityPub based systems have in place?

There are three advantages I see to AcrivityPub, and I’m not completely sure they justify mass adoption vs. the cost of broad redundancy of content and authorship issues. What am I missing?

1. Choosing local instance for faster loading, but this only is an advantage after content is brought in for the first time, in which case it actually is slower as first the instance has to pull the content and then serve it to the user.

2. “all” content in the protocol is of the same type, allowing for easier interoperability between clients and services. I’m thinking this is the root of what most people will say is the big advantage of ActivityPub vs. older protocols, but I’d like to hear more about why this is enough of a reason to overcome the inertia of existing mass adoption and support of the alternatives. Also, couldn’t this also apply to a service built on an existing self-hosted protocol like Atom?

3. It isn’t based in XML, and modern devs don’t want to use XML. As I’m not a coder, I cant say how big an influence this has, but from what I have seen it seems to be a substantial factor. Can anyone explain why?

What am I missing? I know it must be a lot, and I thank you in advance for cluing me in.