3 ms·

Does ActivityPub these days replace the traditional RSS/Atom feeds? Feels like it would be the natural successor. Is there anything missing besides people publi

by zokier 3y ago

Does ActivityPub these days replace the traditional RSS/Atom feeds? Feels like it would be the natural successor. Is there anything missing besides people publishing and consuming?

lapcat 3y ago
> Does ActivityPub these days replace the traditional RSS/Atom feeds? No. In fact, Mastodon has RSS feed support. Downloading an XML file is dead simple. ActivityPub is vastly more complex.
- unshavedyak 3y ago
  I'm writing some ActivityPub stuff, and wanted to make sure to get RSS in, done right, etc. However i never use RSS so i have little insight to good/bad/irrelevant RSS impls. Any wants or must-haves to an RSS implementation over a Fediverse instance? My rough plan is to just include RSS in any places i expose JSON endpoints for data. Though i'm a bit undecided if there's any value in user activity stuff, like comments on an article, etc.
kevincox 3y ago
IMHO no. I thought about this as I run a feed-reader and it would be cool to support ActivityPub as a feed protocol. The main issue is that subscribing shows up on follower lists. Maybe for individual users this is fine but as I ran a service I didn't want to do this. I ended up with a number of reasons why ActivityPub push wouldn't work well. 1. I didn't want to appear to be advertising the service with a generic account subscribed to many feeds. 2. I didn't want a generic account to provide access to "followers only" toots to unintended users. To properly allow access approval I would need to put some subscriber info into the account. It would also be important to make sure that this can't be used as a form of spam (for example if I allowed them to put whatever name/message they wanted). 3. I didn't want to reveal who was subscribed to what. 4. I didn't want to have dozens of different accounts subscribed to popular feeds. 5. If the user also wants to comment on a post themselves they will need a separate account. You can still poll a user's outbox like any other feed, but now you are back to an equivalent to Atom/RSS with no WebSub support. (I mean you could use WebSub, it works for any URL but no one does, and why would you when you already have ActivityPub for push?). So it seems that the anonymity of the older feed formats can be useful in some scenarios. So in the end if I was just going to poll as any other feed format, and most services that support ActivityPub also have other feeds there was really no point to doing this. Feature requests welcome if there is a use case that I missed.
- matsimitsu 3y ago
  I'm in the same boat, and came to the same conclusion. One more point I'd add: 6. Not every ActivityPub enabled service allows for federation. (Some of the more popular block all federation, unless you get allowlisted). So you're stuck polling the outbox regardless.
- cxr 3y ago
  > So it seems that the anonymity of the older feed formats can be useful in some scenarios. Huge understatement; it's more than just "some". None of the blogs in my feed reader are written by people that I have a public (reified) follower/followee connection with over social media. Nor do I have that kind of relationship with the authors of the books I check out from the library, for that matter.
goffi 3y ago
XMPP does use Atom as its (micro)blogging format (XEP-0277), and making followers/following lists (subscribers/subscribed in XMPP terms) public is opt-in with XEP-0465. Note: I'm very involved in XMPP, and the author of the latter XEP. Edit: forgot to mention that it's also available to ActivityPub thanks to the XMPP <=> AP gateway (that I've authored too)
rakoo 3y ago
> Is there anything missing Simplicity. Atom/RSS can perfectly be a static file (it doesn't even need internet connectivity, an Atom file can be passed around on a usb key with 100% of functionality). ActivityPub requires a live server with computation. Think about the step it requires for every website and every account and every service to have an atom feed vs an activitypub actor.
miki123211 3y ago
ActivityPub, despite using JSON rather than XML, is a much more complex protocol with a lot more moving parts. You can technically write an RSS feed by hand, drop it on a virtual hosting provider via FTP, and you have a feed. On the server side, all you need is static file hosting, which is ubiquitous, available for free and amenable to things like CDNs. On the client side, all you need is a single device, which may be behind NAT, and is capable of occasional network connections to pull the updated feeds. With ActivityPub, you're supposed to have an account at an instance and receive content through that instance. This means that the server needs to keep track of followers and automatically broadcast all new content to all of them, which requires a database, some kind of content-publishing API, and probably a job queue and Redis to boot. On the client side, you need a box that is online 24/7 and can be connected to, so that you can receive your content. You get much faster delivery, but at a much higher operational costs and with many more scalability issues. Hosting static content at scale is a solved problem, and you can reuse all that existing knowledge for RSS. Sending AP activities at scale is technically solvable, but the infrastructure just isn't there yet.

by zokier 3y ago

Does ActivityPub these days replace the traditional RSS/Atom feeds? Feels like it would be the natural successor. Is there anything missing besides people publishing and consuming?

lapcat 3y ago

> Does ActivityPub these days replace the traditional RSS/Atom feeds? No. In fact, Mastodon has RSS feed support. Downloading an XML file is dead simple. ActivityPub is vastly more complex.

unshavedyak 3y ago
I'm writing some ActivityPub stuff, and wanted to make sure to get RSS in, done right, etc. However i never use RSS so i have little insight to good/bad/irrelevant RSS impls. Any wants or must-haves to an RSS implementation over a Fediverse instance? My rough plan is to just include RSS in any places i expose JSON endpoints for data. Though i'm a bit undecided if there's any value in user activity stuff, like comments on an article, etc.

kevincox 3y ago

IMHO no. I thought about this as I run a feed-reader and it would be cool to support ActivityPub as a feed protocol. The main issue is that subscribing shows up on follower lists. Maybe for individual users this is fine but as I ran a service I didn't want to do this. I ended up with a number of reasons why ActivityPub push wouldn't work well. 1. I didn't want to appear to be advertising the service with a generic account subscribed to many feeds. 2. I didn't want a generic account to provide access to "followers only" toots to unintended users. To properly allow access approval I would need to put some subscriber info into the account. It would also be important to make sure that this can't be used as a form of spam (for example if I allowed them to put whatever name/message they wanted). 3. I didn't want to reveal who was subscribed to what. 4. I didn't want to have dozens of different accounts subscribed to popular feeds. 5. If the user also wants to comment on a post themselves they will need a separate account. You can still poll a user's outbox like any other feed, but now you are back to an equivalent to Atom/RSS with no WebSub support. (I mean you could use WebSub, it works for any URL but no one does, and why would you when you already have ActivityPub for push?). So it seems that the anonymity of the older feed formats can be useful in some scenarios. So in the end if I was just going to poll as any other feed format, and most services that support ActivityPub also have other feeds there was really no point to doing this. Feature requests welcome if there is a use case that I missed.

matsimitsu 3y ago
I'm in the same boat, and came to the same conclusion. One more point I'd add: 6. Not every ActivityPub enabled service allows for federation. (Some of the more popular block all federation, unless you get allowlisted). So you're stuck polling the outbox regardless.
cxr 3y ago
> So it seems that the anonymity of the older feed formats can be useful in some scenarios. Huge understatement; it's more than just "some". None of the blogs in my feed reader are written by people that I have a public (reified) follower/followee connection with over social media. Nor do I have that kind of relationship with the authors of the books I check out from the library, for that matter.

goffi 3y ago

XMPP does use Atom as its (micro)blogging format (XEP-0277), and making followers/following lists (subscribers/subscribed in XMPP terms) public is opt-in with XEP-0465. Note: I'm very involved in XMPP, and the author of the latter XEP. Edit: forgot to mention that it's also available to ActivityPub thanks to the XMPP <=> AP gateway (that I've authored too)

rakoo 3y ago

> Is there anything missing Simplicity. Atom/RSS can perfectly be a static file (it doesn't even need internet connectivity, an Atom file can be passed around on a usb key with 100% of functionality). ActivityPub requires a live server with computation. Think about the step it requires for every website and every account and every service to have an atom feed vs an activitypub actor.

miki123211 3y ago

ActivityPub, despite using JSON rather than XML, is a much more complex protocol with a lot more moving parts. You can technically write an RSS feed by hand, drop it on a virtual hosting provider via FTP, and you have a feed. On the server side, all you need is static file hosting, which is ubiquitous, available for free and amenable to things like CDNs. On the client side, all you need is a single device, which may be behind NAT, and is capable of occasional network connections to pull the updated feeds. With ActivityPub, you're supposed to have an account at an instance and receive content through that instance. This means that the server needs to keep track of followers and automatically broadcast all new content to all of them, which requires a database, some kind of content-publishing API, and probably a job queue and Redis to boot. On the client side, you need a box that is online 24/7 and can be connected to, so that you can receive your content. You get much faster delivery, but at a much higher operational costs and with many more scalability issues. Hosting static content at scale is a solved problem, and you can reuse all that existing knowledge for RSS. Sending AP activities at scale is technically solvable, but the infrastructure just isn't there yet.