I gotta say I don't deeply understand ActivityPub, but one of the first things I thought when trying to grok it was "how does this improve on RSS?". Like another commenter here I think a big part of it is that it's JSON and not XML, but I think another thing people would say is that you aren't storing things locally, that is you don't have an application pulling things onto your local machine (phone, laptop, whatever).
But I've evolved lately, and now I strongly feel like we're missing the forest for the trees here. These things aren't just RSS; they're email. They're email lists. ActivityPub even uses the language of email; it has `to` and `cc`, and `replyTo` fields, in/outboxes. There are (media)Types, i.e. MIME types.
There are differences. ActivityPub basically exists to be an underlying protocol for Twitter-like social media, so it specs out things like Likes or Undo. But IMO, stuff like this is either superfluous/harmful (chasing likes/views maybe isn't a good idea), or maybe unclear what a lot of people would want out of a conversations platform. I don't really want someone else to irrevocably edit the stuff I've pulled down; sure I'll let you send a diff or something, but I want the history. Or, on the other hand, maybe I don't want someone to store a history of my worst posts, ready to unleash them whenever I dare to do something public. Or, on the other hand, maybe this has been a really useful tool to speak truth to power. Or, maybe we shouldn't create a protocol that seems to guarantee this, only to have rogue servers that store these things as diffs anyway to lull you into a false sense of "posting hot takes is OK I can always undo/edit/blah".
> I gotta say I don't deeply understand ActivityPub, but one of the first things I thought when trying to grok it was "how does this improve on RSS?". Like another commenter here I think a big part of it is that it's JSON and not XML, but I think another thing people would say is that you aren't storing things locally, that is you don't have an application pulling things onto your local machine (phone, laptop, whatever).
Both of those honestly sound like a disadvantage. Like yeah , plenty to hate about XML but at least it has defined schema language, and I want to have an application and not be dependent on some shitty website to act as aggregator for me.
All of the "features" ActivityPub has could be pretty easily just added to RSS too
There are the superficial features and then there are the super features built so deeply in the architecture they can be game-changing and invisible at the same time. (e.g going from XML to JSON is trivial in comparison, it wouldn't matter if it went to ASN.1 and EBCDIC)
ActivityPub puts timestamps on things so you can ask your Mastodon server for everything that's been updated since the last time you polled. RSS makes you poll over and over again and download everything. so instead of downloading X kb of content you could be downloading 20X kb if you are polling too fast, alternately you could be losing content if you poll to slow.
It is routine for ActivityPub servers to work in an aggregating mode so I can subscribe to 2000 Mastodon users who are spread across 300 servers and still be able to update my feed by making one request.
There are numerous reasons why "RSS died" but one of them is surely that phones became more popular than desktops and it is absolutely unthinkable that a phone would be polling and polling and polling hundreds of severs all day... It would kill your battery!
for the ingestion front end which provides an ideal API from my point of view. When a new feed item comes in Superfeedr sends an https request to an AWS lambda function, that stores the feed items into an SQS queue, and YOShInOn's ingest script fetches items from its queue at its convenience. The one trouble with it is that it costs 10 cents/feed/month... It's quite affordable if I want to subscribe to 100 feeds (which I do currently) but subscribing to 2000 independent blogs that get one post a week is getting pricey.
On the flip side is the effect this all has on servers: I think people are often looking at Google Analytics now and not looking at their http logs, if they did they might find there is a huge amount of polling going on and not a lot of clarity on how this connects to users. There's the strange story of Feedburner, which offered some analytics for feeds and then got bought by Google. I think the best kept secret of black hat SEO in the early 2010s was that anything you put in a "burned" RSS feed was certain to get indexed in Google's web search index almost immediately. (I'd hear other people on forums complaining about pages they put up that were perfectly fine and not spammy but would go unindexed for 2-3 months.) If you wanted to get 200,000 slightly spammy pages indexed your best bet was to set up WordPress and roll the content over the
course of a few weeks.*
> ActivityPub puts timestamps on things so you can ask your Mastodon server for everything that's been updated since the last time you polled. RSS makes you poll over and over again and download everything. so instead of downloading X kb of content you could be downloading 20X kb if you are polling too fast, alternately you could be losing content if you poll to slow.
You have to download the feed when something changes, correct. But you do not and should not download the whole thing over and over again. That is exactly what If-Modified-Since [1] is for.
> ActivityPub puts timestamps on things so you can ask your Mastodon server for everything that's been updated since the last time you polled. RSS makes you poll over and over again and download everything. so instead of downloading X kb of content you could be downloading 20X kb if you are polling too fast, alternately you could be losing content if you poll to slow.
This is a pretty obvious consequence of trying to misuse HTTP (or debased "REST") to get it to do something it's just not very well-suited for.
A client-to-server protocol like XMPP that's tailor made for this application would be a better fit, but what captures public attention rarely involves coming up with answers to questions like, "First, which is the superior technology?"
> When a new feed item comes in Superfeedr sends an https request to an AWS lambda function, that stores the feed items into an SQS queue, and YOShInOn's ingest script fetches items from its queue at its convenience. The one trouble with it is that it costs 10 cents/feed/month... It's quite affordable if I want to subscribe to 100 feeds (which I do currently) but subscribing to 2000 independent blogs that get one post a week is getting pricey.
Wow, that seems overengineered to me. I use a cron job on my phone, and taskspooler as a queue. It has no operating costs, doesn't rely on any third-party infrastructure, can be edited/audited/executed locally, etc.
> it is absolutely unthinkable that a phone would be polling and polling and polling hundreds of severs all day... It would kill your battery!
How often are you polling? I usually set several hours between cron runs; any more frequent and I find myself mindlessly refreshing for updates. I have a few Bash commands to check if we're on WiFi/Ethernet, if we're plugged into a charger, etc. which also control some systemd targets. That makes it easier to avoid using any mobile data or battery power.
PS: Planet is alive and well (at least, the FOSS project ones I read, like Planet Haskell) :)
Activitypub is far too heavy. It literally requires a cryptographic exchange which makes a static setup for Activitypub infeasible. All activitypub based communication requires a big complex, fragile, exploitable dynamic backend on both sides that require ongoing mantainence.
RSS/Atom + Indieweb MF2/webmention is the way to go. It can be implemented by a static site with no moving parts to break.
>but one of the first things I thought when trying to grok it was "how does this improve on RSS?".
there's a lot of discussion that doesn't answer this question so let me do it quickly:
a homeserver can POST updates to other homeservers that have followers on them, instead of relying those remote servers polling the one that originates the content.
This is the main thing that ActivityPub brings over RSS, making it a different type of protocol entirely: updates can be pushed between servers
Storage can be decoupled from location/host using protocols like BitTorrent or IPFS. Many years ago I pushed my site to IPFS, including its RSS and ATOM feeds. That worked great for static content, but I never found a decent mechanism for pointing a URL to the latest version. I tried IPNS, and added a "DNS link", but it was super flaky.
I'm currently pondering whether the GNU Name System would be better suited...
> there's a lot of discussion that doesn't answer this question so let me do it quickly:
Yes, love it, OK
> a homeserver can POST updates to other homeservers that have followers on them, instead of relying those remote servers polling the one that originates the content.
This is definitely a difference but there are a couple of reasons I'm not sure I'd call it strictly an improvement.
The first is that it feels like it would have been pretty easy to have ActivityPub allow everything to filter by a (created and/or updated) date. People don't like pull protocols, but hey guess what any Mastodon client (JavaScript or otherwise) is doing. Pulling isn't as bad as its reputation would suggest, plus we're great at serving/caching this stuff now. Like, one of the main benefits of HTTP is that it basically has encryption and caching built in. Pulling would have been fine for probably everything--and you can imagine designing the protocol to make it even more efficient than something like POSTing every new update to every federated server w/ a follower (batching would be a big win here).
Second, the ActivityPub spec is pretty cagey on retries ("[federated servers] SHOULD additionally retry delivery to recipients if it fails due to network error"). Who knows if the existing servers implement some strategy, but the spec has no guidance AFAIK. Also, is a recipient server being down/erroring a network error? Also, nothing says POSTs have to be sent immediately. These aren't niche concerns; you can imagine a server being under heavy load or experiencing some network problems and reacting by limiting the number of update POSTs it sends.
SMTP [0] on the other hand says you should wait 30 minutes and try over 4-5 days. We can quibble about the values or w/e, but a federated sync protocol should have more to say about sync than "POST updates, retry if it fails".
Anyway, all of that is to say that I think ActivityPub probably would have been a lot simpler, faster, consistent (clients basically have to be pull because phones) and robust if server-to-server interactions were pull and not push.
> the ActivityPub spec is pretty cagey on retries ("[federated servers] SHOULD additionally retry delivery to recipients if it fails due to network error"). Who knows if the existing servers implement some strategy, but the spec has no guidance AFAIK. Also, is a recipient server being down/erroring a network error? Also, nothing says POSTs have to be sent immediately.
I don't know much about ActivityPub; do you know whether updates from individual topics / subscriptions contain sequence numbers? If a recipient server receives updates 12, 13, and 14 on topic ABC, but then has a network blip and drops update number 15-17, and then successfully receives 18, it could know that it's missing some (and presumably poll for the dropped ones).
Likewise, if a receiving server notices that it hasn't received any updates on one topic for a week when before it had been receiving multiple per day, it could proactively poll the sending server.
> one of the first things I thought when trying to grok it was "how does this improve on RSS?"
Well it certainly ups the ante for a participant to add a node to the network with their own hand-rolled software, which can improve interoperability SNR from a certain Postelian perspective.
But I've evolved lately, and now I strongly feel like we're missing the forest for the trees here. These things aren't just RSS; they're email. They're email lists. ActivityPub even uses the language of email; it has `to` and `cc`, and `replyTo` fields, in/outboxes. There are (media)Types, i.e. MIME types.
There are differences. ActivityPub basically exists to be an underlying protocol for Twitter-like social media, so it specs out things like Likes or Undo. But IMO, stuff like this is either superfluous/harmful (chasing likes/views maybe isn't a good idea), or maybe unclear what a lot of people would want out of a conversations platform. I don't really want someone else to irrevocably edit the stuff I've pulled down; sure I'll let you send a diff or something, but I want the history. Or, on the other hand, maybe I don't want someone to store a history of my worst posts, ready to unleash them whenever I dare to do something public. Or, on the other hand, maybe this has been a really useful tool to speak truth to power. Or, maybe we shouldn't create a protocol that seems to guarantee this, only to have rogue servers that store these things as diffs anyway to lull you into a false sense of "posting hot takes is OK I can always undo/edit/blah".