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?
You must log in or # to comment.
Basically, RSS as you said, is a one way street. There is no feedback. It’s not so much communication, but broadcasting.
deleted by creator
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.”
Activitypub is based on Activitystreams, and doesn’t define any types of its own. Lemmy is fully compliant with the Activitypub standard as far as I know.
deleted by creator
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.
Or back in the days where Google Reader was a thing, one request from them could represent millions of readers.
I’d argue it’s still a better representation than subscriber count. It is similar to the disparity between YouTube’s subscriber count vs video view count.
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.
Yes, it’s possible to get a rough estimate with some technical work, but AP makes it easy for anyone.
AP doesn’t really do this. A subscriber may be a dead account, or may be someone that hasn’t checked your feed in months. Even a technical analysis would be difficult here.
One single popular cloud service that fetches the data for the users and this stops being true.
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?
Not arguing anything, just asking questions to confirm my understanding (and I believe I got my answers so we’re good).
I don’t know what you mean by single improvement, but I don’t think that is my position, no.
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?
As far as I know, ActivityPub only applies to server to server communication. Still, many applications that implement ActivityPub (for example Mastodon) do use push notifications for their clients.
RSS readers just fetch a certain .rss file from a website and render that for you. RSS is a simple tool, it’s not even comparable to something like ActivityPub.
You also have no way of discovering new stuff, you have to find them yourself. Whereas with ActivityPub you can. Nor can you interact with the feed objects (comment, like, etc).
I’d argue that discoverability on fediverse kinda sucks.
There’s the network effect kind of discoverability, where someone you follow reposts something, and you discover this new something and possibly follow it. RSS has all the technology necessary to make this happen.
There’s the discoversbility where you sort by “New” or “all” on your fediverse feed. I suppose that is discoverability that RSS doesn’t have natively, but I’d argue this sucks pretty badly.
Last, there’s the search engine type of discoverability, where you search through fediverse communities or users. This isn’t native to ActivityPub, and a RSS search engine can be implemented pretty similarly.
In summary, So activityPub might have some discoverability paths, but the one that RSS doesn’t have natively, I argue sucks and is not the right way to do it.
Ok? What exactly are you trying to tell me with this? RSS still has no builtin discoverability tool, that’s a fact and won’t change.
I am responding to your point about RSS not having ability to discover new content whereas activityPub can. I summarized my point in the last paragraph. To reiterate, I agree that RSS doesn’t have built in discoverability, but whatever ActivityPub has is not solving the discoverability problem. Let me know which part you don’t understand please and I’d be glad to clarify.
I disagree. Discoverability is to discover new stuff from new places you haven’t seen before. In Lemmy, for example, I can sort by All/New and I’ll discover lots of new things I haven’t seen from new places. Interesting to me or not, there’s discoverability.
Respond and interact with content. Whatever it may be. In most sites, that means using their singular platform with their rules. With Activity hub, it means using many potentially different platforms to communicate.
I personally use both rss and activity hub. Works pretty well. One to inform and one to communicate with.
The really intriguing thing about ActivityPub, at least to me, is it’s capability and potential to be a bridge for many other protocols.
For example, here’s ActivityPub via email: https://apubtest2.srcbeat.com/apas.html
That page also references the longstanding NNTP(Usenet)-email bridge that existed for the linux-kernel mailing list, so we could get ActivityPub to Usenet.
In fact there are a couple of RSS->Mastodon projects out there already, such as https://github.com/dariusk/rss-to-activitypub or https://github.com/jehna/mastofeeder
Is there something about activity Pub that enables it do this, that other protocols or architectures wouldn’t have?
Depends on your POV.
In one sense, if ActivityPub can be a bridge between two protocols (e.g. RSS vs email) then it’s always technically possible to cut out the middle man. In that sense, no not really.
From my POV though ActivityPub shines because it’s more content agnostic. RSS is specific to feeds and posts, while email is for email, Bluesky is Bluesky (twitter), etc, but ActivityPub can handle video (peertube), images (pixelfed), forums - including likes and downvotes (Lemmy), microblogging (Mastodon), etc. (Note that the ActivityPub to email implementation I mentioned currently doesn’t handle likes/downvotes for example.)
With the possible exception of email, I’d also say that ActivityPub has something these other protocols do not - ownership over your own data. If you run your own instance for yourself, you always retain a copy of your content - you don’t have the situation of ello.co where if the site suddenly goes down without warning you lose years of work. Even if you use someone else’s instance, if that goes down you may be able to recover your content from another instance that was federating to it (retrieving content posted to kbin.social from the copy at fedia.io for example). That’s the beautify of federation.
(This is also true of traditional email, but things like gmail and Outlook - where the email is simply hosted on someone else’s server - are moving away from that.)
Do you know if they’re an ActivityPub-BlueSky bridge in the works?
It’s already up and running. I follow several Bluesky users in my Mastodon, some Bluesky people follow me as well.
It has to be manually enabled on both sides though.
Anyways, did I miss anything?
I think the big problem in link aggregation is how to sort/prioritize content for the end user. RSS does not provide a way to do this, nor should it as far as I’m concerned. It should simply be about public content being tagged in a standardized way for any app to come along and organize it using whatever algorithm.
A simple RSS reader has the problem that the more prolific sites will tend to flood your feed and make it tedious to scroll through miles of links. Commercial news portals try to learn your tastes through some sort of machine learning algorithm and direct content accordingly. This sounds like a good idea in theory, but tends to build echo chambers around people that reinforce their biases, and that hasn’t done a lot of good for the world to put it mildly.
The lemmy approach is to use one of a number of sorting algorithms built atop a crowd-sourced voting model. It may not be perfect, but I prefer it to being psychoanalyzed by an AI.
Btw there was a post from about a month ago where someone was offering to make any RSS feed into a community. I’ve subscribed to a few of them and it’s actually pretty awesome.
From what I see, ActivityPub doesn’t seem to solve the problem of sorting or prioritizing content. In fact, I believe RSS wins here, because it is easier to do this on the client side with RSS, as it is assumed the client has all the content from the RSS feed without any biased order, whereas with activity pub, it varies by provider and instance.
Sorting and filtering can be done well on the client side, and the plus side is the user can have a ton of choice here. It just so happens that our algorithms for that in the open source world are no match for the addiction-inducing ones of Twitter and others.
You raise a good point that it would be nice to have more control over which group of communities you are drawing from at a given time. (Is there a way to group subscriptions and switch between them?) It’s a bit disconcerting to see 5 tech headlines and then suddenly something about the war in Ukraine or whatever. It jars my train of thought. With an RSS client, you can group feeds however you want.
That said, my experience with RSS readers is not quite so idyllic. In the end, rather than having nicely partitioned feed groups by topic, I wind up having to separate the ones that produce content frequently but with a poor signal-to-noise from those that post once in awhile but are generally worth your time. With something like lemmy, people are helping you do the work of finding the more interesting content from that site that posts every 10 minutes.
I fully agree with you, but I think this isn’t because RSS clients can’t do this from a technical perspective. I suppose most RSS clients come from people with anti algorithm sentiment, but realistically, a RSS client has all what it needs to implement basic or advanced sorting and filtering.
But I agree with you that most rss readers out there have that problem.
I suppose the same could be said on the lemmy side. There’s no reason someone couldn’t write a lemmy app that lets you do what an RSS client does in terms of only showing content from a selected subgroup of communities.
ActivityPub acts like two-way RSS
- If you don’t have a specific interest and/or lack the skill of finding new content that you like , RSS mostly won’t help you unless it has a " suggestion " feature , while on ActivityPub ( or any other social media ) you can find new content that might or might not suit you just by browsing
- RSS is read-only , ActivityPub is not
Activitypub can include private messages
deleted by creator
