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 register to comment.
ActivityPub acts like two-way RSS
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.
Basically, RSS as you said, is a one way street. There is no feedback. It’s not so much communication, but broadcasting.
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?”
But it does not have a way for users to interact with the poster, like comments or likes
You answered your own question.
- 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
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.
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.)
