I know they’re quite different technically. But practically, what does ActivityPub unlock that was not previously possible with RSS and basic web tech stack?
I think I have an idea of the answer. RSS may provide a way for users to “subscribe” to content from a feed, equivalent of following and putting it in a unified feed.
But it does not have a way for users to interact with the poster, like comments or likes. This may be possible with a basic web stack though, but either users will have to make accounts on every person’s site, or the site has to accept no user auth. (but this could be resolved with a identity provider standard, like disqus does)
I suppose another thing activityPub does is distribute content to multiple servers. Not sure if this is really desirable though?
Anyways, did I miss anything?
Basically, RSS as you said, is a one way street. There is no feedback. It’s not so much communication, but broadcasting.
Thanks for confirming! However my question is if that’s all, or if there’s more. I assume you mean that’s it.
Yep, that’s basically all of it. ActivityPub allows a reader to send messages back to the original poster. Those messages can be a comment, or a like, an upvote, a downvote, or a many others. That’s what ActivityPub unlocks compared to RSS.
RSS only goes one way: the reader can read messages from the poster, but not send any messages to the poster.
edit: if anyone is curious about what the “many other” messages can be, the list is here, under Verbs: https://github.com/activitystreams/activity-schema/blob/master/activity-schema.md#verbs
Technically, that is part of ActivityStreams, not ActivityPub. But there is a lot of overlap there, and ActivityStreams is a necessary addition. For example, downvotes on Lemmy are not part of AP, but you’ll find them in AS, called “dislike.”
That’s most of it. ActivityPub also makes it possible to know who is subscribed. It’s very hard to count how many people are subscribed to an RSS feed.
Not really. They’re making requests, probably at least once a day. That makes it very easy to count active users. With subscribers, you can have a big number, but they’re not necessarily all active, and unless they’re on your instance, you can’t see how often they’re reading.
They’re making requests at unknown intervals, often many times per day. Each IP address might represent multiple unique users, or one user might have multiple IPs.
Deduplicate by IP/user-agent and you’ll get a pretty accurate count. Some people might be moving between wifi and data, but for the most part you can account for that. Same process as fingerprinting a browser.
This may be possible with a basic web stack
“basic web tech stack” is quite a bit hand-wavy, don’t you think?
Yeah, indieweb sites could do a lot of things: authn and authz, content syndication, backlinking, Social Graph, etc. But none of them had been standardized and put into one single protocol. ActivityPub is precisely this protocol.
Saying that “we can do that with a basic web stack” is not that different from saying “we can have a protocol to publish XML content without styling using a basic web stack, why do we need RSS or Atom?”
You’re right, it is hand wavy.
But I think it is valid for every blog to have things like comments and likes in their own way, if they’re okay with users not being authenticated.
But yes, it makes sense this is where activity Pub shines.
But I don’t understand what you are trying to argue. Do you think that AP is only meant to be a single improvement about existing implementation for (micro)blogs?
One more difference is that RSS is polling based, meaning that subscribers have to actively ask every hour or so if thre is new content.
On the other hand, ActivityPub knows who is subscribed and can actively distribute new content to other servers who can in turn send push messages to their users, letting you know about new content within seconds.
So activityPub uses push architecture to push to other servers / instances, but it doesn’t push to users does it? I would imagine from instance to user, it is still pull based.
So effectively it’s a load distributer thing, I suppose, right?
