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, dr

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.