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?
-
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.
-
“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?
-
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.
Web 1.0 was great. Why Web 2.0?
RSS still leaves data in silos. If I love the content on site.com and they decide to put it behind a paywall, enshittify it, or the site goes down, that content is lost. On the fediverse, as long as it has propagated across the network it can be found on other instances (the content being comments in this case, not offsite-linked materials).
The main advantage is efficiency. You don’t need to poll 1000 servers every minute to get fresh content because everything is delivered straight to your inbox.
the cost of broad redundancy of content and authorship issues
ActivityPub doesn’t have redundancy or authorship issues. An object only exists on the originating sever, other servers merely cache it. This is not different from what RSS readers do, for example.
WebSub solved the efficiency issue, no?
That’s my impression. I haven’t seen an argument yet as to what I’m describing not being fundamentally feasible.
It seems like most people here’s opinion is essentially that ActivityPub is a better option mostly because it is one unified protocol vs having to develop around multiple protocols adding complexity. This seems to be why ActivityPub emerged out of OStatus, which was more similar to what I was describing.
Many things are fundamentally feasible. I see 2 things you argue for.
One is changing the caching strategy. I don’t think that’s wise in terms of load sharing, but certainly feasible on a small scale. In certain circumstances, it may be preferred.
The other thing is using older protocols and standards. The practical reason to do this would be to use existing tooling, libraries, code. I’m not seeing such opportunities. I’m not that familiar with these, but it seems like they would have to be extended anyway. So I don’t really see the point.
Good to know.
Regarding polling efficiency, that makes sense. As I understand it ActivityPub uses a combination of push notifications at time of publishing and pull notifications at time of subscription/query for objects? I can see how offloading that to an instance for multiple users vs every user definitely increases efficiency for content discovery/inboxing. I know there are protocols like websub to add push notifications to blog publishing, but they are required to be done at the publisher/host side. I do see this as a big nudge in ActivityPub’s favor.
Duration of caching is set by the instance admin I take it?
At a minimum this is adding the number of instances that federate a given content streams to the multiple of storage needed to host the content, even if that storage is ephemeral. Not so big a problem at 100,000 users, but at 100,000,000 users this is a lot of storage cost we are talking about. Unless somehow the user/client doesnt cache the content they pull from an instance locally on their device when they view it?
Regarding Authorship, if there wasn’t an issue then ATProtocol devs wouldn’t have made it the cornerstone feature of their network. The ability to move accounts between instances and maintain content control permissions is currently one of the big focuses of development on ActivityPub as I understand it. Also as I understand it many Fediverse instances dont have edit functionaly enabled, meaning once the content goes out it is out of Author control. I’d like to know how delete requests propagate, when the “Object” is deleted does a request to clear cache go out to all federating instances?
My point was this isn’t an issue when all content is self-hosted, because the author as the host can edit, delete, or migrate all they want and maintain full direct control over the source of that content the client interacts with whenever a pull request comes in. Yes the user Caches the content when they read it, but there is no intermediary copy.
At a minimum this is adding the number of instances that federate a given content streams to the multiple of storage needed to host the content, even if that storage is ephemeral. Not so big a problem at 100,000 users, but at 100,000,000 users this is a lot of storage cost we are talking about. Unless somehow the user/client doesnt cache the content they pull from an instance locally on their device when they view it?
Worry more about the bandwidth. Your instance would have to serve your content to all these 100M users. The way it is, much of the load goes to the instance where a user is registered. That means that an instance can control hosting costs by closing registrations.
My point was this isn’t an issue when all content is self-hosted, because the author as the host can edit, delete, or migrate all they want and maintain full direct control over the source of that content the client interacts with whenever a pull request comes in. Yes the user Caches the content when they read it, but there is no intermediary copy.
There’s the fundamental problem. What you think of as “your” data, other people think of as “their” data. That can’t be resolved. What’s worse is that controlling “your” data requires controlling other people’s computers and devices, as with DRM.
As I understand it ActivityPub uses a combination of push notifications at time of publishing and pull notifications at time of subscription/query for objects?
It’s a mix of pushing and pulling. When something happens, the server pushes a notification (“activity”) to other servers. But recipients often need to pull additional data, such as user profiles or related posts.
Duration of caching is set by the instance admin I take it?
Yes, and it also depends on the software. Some applications may keep cached objects forever and only prune cached media (because objects don’t require much space).
Regarding Authorship, if there wasn’t an issue then ATProtocol devs wouldn’t have made it the cornerstone feature of their network
Moving in ActivityPub world is difficult because authorship is tied to a specific server. We can solve this problem by using cryptographic identities and signing everything, like ATProto and Nostr do.
I’d like to know how delete requests propagate, when the “Object” is deleted does a request to clear cache go out to all federating instances?
Deletes and edits are usually sent to followers of a user or a community. Delivering them to all known instances is not practical.
Thanks, this is helpful.
Regarding encryption for signatures, that would be for edit and delete permissions only while the content stays unencrypted? Admin keeps delete control.
Delete requests go to all instances where followers reside then, but if someone has unsubscribed and is the only follower on the instance the content persists in cache?
ActivityPub messages are not encrypted, but they could be signed. Signing doesn’t prevent edits and deletes.
Yes, if someone has unsubscribed they are unlikely to be notified about the deletion.
RSS for me is good for one way communication. Magazines, blog posts, ect…
Fedi is great for two way. If I want to communicate with both.
There’s also some nuances around XML vs fedi in protocol.
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?
If clients built their own social layer, those would be limited to users of that client. If they opened up the social layer with an interoperable protocol, now you just made ActivityPub again.
Yes, but almost no developer is looking at ActivityPub as a protocol to “add a social layer to their websites and applications”. Instead, we are stuck in this “let’s replicate the centralized social networks! With blackjack! And hookers! And ActivityPub!” way of thinking.
Webmention already exists and is service agnostic and interoperable. My assertion is that protocols for handling the social function of ActivityPub predate ActivityPub’s development and could be unified by a client without creating any new protocols that aren’t already in use, so what is it that ActivityPub is doing better than those protocols that justifies intermediating the social graph with group servers? I’m sure there are good answers to this question, I just want to know what they are with more clarity.
If you’re a publisher only then RSS/Atom makes much more sense, especially if you want to retain ownership and control over content you created. If control is not important to you and you want to incorporate social aspect into your website (comments, reactions) then ActivityPub seems like a convenient way to go about it.
One thing that I strongly disagree with author of the blog post is the discoverability aspect. Yes, initial federation kind of sucks but at the same time your readers on Mastodon will be able to boost it and increase your reach.
You’re missing a very basic and fundamental concept: RSS is unidirectional.
If you read the post you’ll note I mention Webmention, email, and XMPP, which all handle bidirectional communication in different ways. Webmention in particular enables implementation of both on-site comments and pulling comments from off-site services to display locally on a post/page, as well as replies to those comments.
I’m not suggesting RSS alone is sufficient, but rather that existing solutions/protocols appear to exist for the problems ActivityPub seems to be solving, but without the step of intermediating publishing through federated servers. A client could be built tying these protocols together as a social networking front end.
My question is, what is ActivityPub solving that the combination of these existing services do not? Unidirectionality isn’t it, though someone’s prior comment pointed out the efficiency of push vs pull in terms of content distribution and I do see that point.
I mention Webmention, email, and XMPP
None of those are part of RSS. Webmention does not appear to be federated. Email? How do you figure that works? XMPP is for private messages, not public discussion.
what is ActivityPub solving that the combination of these existing services do not?
The simple fact that it is not a “combination of services”, it is a single service.
XMPP is for private messages, not public discussion.
XMPP is just the transport. You can build a public social network on top of XMPP just fine.
Interesting, I have actually used Movim for xmpp chat before but not fully explored its publishing features. This is a good nudge to do so. I wonder how it handles “communities”. I have been tracking XMPP recent development and threads are just now getting support, though they function more like tags in chat streams than like threads in a Lemmy sense in current implementations. It seems like the “Spaces” concept proposed in XEP-0503 would round this out, and I have discussed how Nicolo of Slidge plans to work on this woth the Movim dev team, it would make sense Spaces would much improve the blogging/forum functionality of Movim. I was asking about it for the potential of replacing Matrix/Discord with XMPP.
I’m suggesting federation is not necessary, thats the whole point.
Use Atom or RSS for content identification / distribution.
Use Webmention for comments and cross-posting.
Use email or XMPP for direct messages.
Build a client that provides these functions and with these protocols and what is it missing that ActivityPub provides? That’s my question.
Your answer, that it is one protocol, is fair enough.
Why do we advocate for, and pour hours of development into, ActivityPub rather than
Because that’s what the devs are interested in doing. If you’re going to ask anyone, ask them.
a big thing you’re missing is discovery of old content and searching. You’re describing a purely ephemeral social network. Activitypub itself can’t solve that, but this is why federated networks exist instead of purely P2P.
Maybe some people want that, after all Snapchat became popular. But it wouldn’t work for something like Lemmy.Also isn’t this where Fediverse devs might be looking? I am hoping so.
Maybe? But I wouldn’t hold my breath.
I mean, it’s the best option you have, but that doesn’t make it a good option.
Why would it be purely ephemeral? The content isn’t going anywhere, and an RSS reader can crawl a whole archive.
It’s ephemeral because now you’re demanding that everyone stand up their own web-addressable servers that the rss readers can search, if they want their own content to be searchable. Which isn’t going to happen. So in practice, it’s going to be either federated, or ephemeral.
Free and premium blog and website hosting services are abundant, for those who dont want to self host directly this is the easy option. There is no reason a host of this type couldn’t adopt or be set up to have the protocols I’m discussing baked in to their CMS/templates as options. Fundamentally I don’t see how hosting peers in this way would be more onerous than hosting an activitypub instance.
Because with federated services people don’t have to host an activitypub server, you can join a federated instance that someone else maintains.
The typical Twitter user balked at just selecting a mastodon instance when they signed up in the app… similar issues for reddit users looking to come to lemmy. If you think that they’re going to be willing to go and set up and manage their own server, even on a free hosting site, you’re wildly mistaken.
If you don’t think you need the normies on your social network anyways, I have no polite way to tell you that most people want to join social networks with their friends.
I’m not sure I understand your substantive question very well.
There already is a bridge from RSS feeds to ActivityPub: https://rss-parrot.net/ (there are plenty of sources I follow through that).
The clue of what ActivityPub is for is in the name: it is for publishing one’s activities. For example “I’ve written a new blog post”, “I’ve commented on someone else’s activity”, “I’ve upvoted someone else’s comment”.
RSS is really just a structured format to describe the content of a website in simpler terms. It doesn’t ever send any information to anyone, it doesn’t have any mechanism for anyone else to interact.
I used to follow news sites directly through an RSS reader. But I would need to set that up separately on each device, including after reinstalling, which I just can’t be bothered to do. I know there are things like Feedly, but not everyone likes proprietary services and software that much. I like the fact that on Mastodon nowadays, I can follow both microbloggers and RSS feeds.
deleted by creator
But I would need to set that up separately on each device, including after reinstalling
It’s called OPML. Set up your feeds. Export OPML. Back it up using your preferred method. Export it to readers on other devices. Optionally, sync the OPML using SyncThing or similar.
Also there are integrations through FreshRSS and similar.
Also there are FOSS hosted readers like Commafeed.
If I look at ActivityPub as simply a push notification layer for publishing then it makes me think it could be implemented straightforwardly without needing intermediating instance servers? I got some hint of this via IndieWeb discussions but haven’t seen a great description of how it would work, would it basically just cache all activity/content/objects from “subscribed” federated sources on the local host, basically a one-person instance?
Does ActivityPub provide the ability to receive notice that content has been posted without caching the full content, essentially indexing posts?
@rglullis@communick.news I think you might have some insight.
Your entire post is advocacy for jabber, and all it’s current and ongoing features [database is down, I am aware].
ActivityPub has been a fascist project since its inception.
Best way I can describe the situation is NIH.
Yes, I mentioned XMPP for good reason, but I haven’t seen it implemented in a way which makes it a replacement for persistent content like forums, blogs, etc.
I don’t know if ActivityPub is a fascist project, but it is effectively a fully public communications network and so can be analyzed and utilized by anyone for any purpose. What I’m proposing wouldn’t be any more opaque, it would be built on the open web.
persistent content like forums, blogs, etc.
I don’t know if [Jabber] is a fascist project, but it is effectively a fully public communications network and so can be analyzed and utilized by anyone for any purpose. What I’m proposing wouldn’t be any more opaque, it would be built on the open web.
Now, how aware are you that GNUSocial was built upon jabber technology?
I did not mean to say Jabber is a fascist project. You said “ActivityPub has been a fascist project from its inception.” and I was responding to that. XMPP has end to end encryption protocols and so is not a part of the open web fundamentally.
GNUSocial was built on OStatus which actually is the closest thing to the tech stack I am talking about in my post. It did not include XMPP/Jabber as far as I can tell. Interestingly the Wikipedia article on OStatus claims that ActivityPub arose out of the OStatus project in order to reduce the complexity of implementation, so another mark towards that explanation, but I’d like to hear more from devs involved.
The replacement of Jabber from ActivityPub on that paragraph was intentional retrospective exercise for you to read that Jabber has been part of the open web since pubsubhubbub was a thing. That fact that you denied, while not detailing that OStatus is a Websub (XEP 60) implementation, shows me that you were incapable of connecting Jabber webclients, like GNUSocial, Friendica, Movim, Kaidan, Libervia, and most famously Converse.js, have already implemented fora, weblogs, and more, without the need to JSONify the web.
Lol, bro, my incapability or your lack of clear communcation? Modifying a quote of my comment is about as obtuse as you can get.
GNUSocial had an XMPP plugin, it was not built on Jabber. Yes XMPP clients have microblogging built out, but still lack some competitive features to the Fediverse, and fundamentally are still a server-based ecosystem rather than a self-hosted p2p ecosystem for persistent content which is what my post was discussing.
lack some competitive features to the Fediverse
like?
a server-based ecosystem rather than a self-hosted p2p ecosystem for persistent content which is what my post was discussing.
So, unlike Peertube, that is a server hosted p2p system with persistent infohashing content, that aggregates under ActivityPub, which requires a native webclient, or a custom one?
