In December 2023, this blog joined the fediverse (pt_BR). Thanks to a WordPress plugin — the publishing platform used by Manual do Usuário — it became possible to follow updates here without leaving…
This does remind me that I wish that Fediverse clients would have RSS reader functionality built in by default. I have a sneaking suspicion some do and I just don’t know how to use the feature. Effectively allowing people to “boost” aka repost with backlink RSS updates on a Fediverse client would enable most of what a blogger would want from the Fediverse, with the exception of receiving all the comments on the posts they share.
Bridgy does that, but then it is essentially just a mirror so it does have the server inefficiency of redundant hosting built in.
That you might say is the fundamental design decision of Activity pub, shifting the hosting burden from a single host to a distributed network of server instances. 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 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.
Since the popularization of the Distributed Social Network concept I have wondered whether pre-existing content distribution infrastructure like RSS might not be more advantageous as a backbone for social networking, with the development load entirely shifted 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, email, XMPP, etc. Is lower latency really a good enough justification for widely redundant data distribution?
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 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, and I’m not completely sure they justify mass adoption vs. the cost of broad redundancy of content and authorship issues.:
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 cintent and then serve it to the user.
“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.
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?
This does remind me that I wish that Fediverse clients would have RSS reader functionality built in by default. I have a sneaking suspicion some do and I just don’t know how to use the feature. Effectively allowing people to “boost” aka repost with backlink RSS updates on a Fediverse client would enable most of what a blogger would want from the Fediverse, with the exception of receiving all the comments on the posts they share.
Bridgy does that, but then it is essentially just a mirror so it does have the server inefficiency of redundant hosting built in.
That you might say is the fundamental design decision of Activity pub, shifting the hosting burden from a single host to a distributed network of server instances. 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 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.
Since the popularization of the Distributed Social Network concept I have wondered whether pre-existing content distribution infrastructure like RSS might not be more advantageous as a backbone for social networking, with the development load entirely shifted 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, email, XMPP, etc. Is lower latency really a good enough justification for widely redundant data distribution?
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 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, and I’m not completely sure they justify mass adoption vs. the cost of broad redundancy of content and authorship issues.:
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 cintent and then serve it to the user.
“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.
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?
That’s a very thoughtful comment. Thanks!