The Fediverse and the feed reader solve the same problem. One is a live wire, the other is a filing cabinet. Publishers who understand the difference need not choose.

The Shared Enemy

Platform dependency is the condition in which a publisher's relationship with their audience is mediated, and therefore revocable, by a third party. Twitter can suspend an account. Facebook can collapse organic reach. A newsletter platform can change its terms. RSS and ActivityPub are both responses to this structural problem, and for the past decade they have been developing in parallel, largely without acknowledging each other's existence.

Small self-hosted server on a home-office shelf with ethernet cables routed neatly, indicator lights lit
Miniflux and FreshRSS will run on hardware of this order. That is the whole argument for hosting a reader yourself.Photo: panumas nikhomkhai / Pexels

The confusion about whether they compete comes from the word "subscribe." Both protocols let a reader subscribe to a source. But the similarity ends there. RSS is a pull protocol: the reader's client polls a URL on a schedule, retrieves an XML or JSON document, and parses it locally. ActivityPub is a push protocol: when a Mastodon user publishes a post, the server fans it out to every server that holds a follower, in near real time. These are not two implementations of the same idea; they are two different ideas that happen to solve a related problem.

What Each Protocol Actually Does

RSS, as stabilised in Dave Winer's 2.0 specification, is fundamentally archival. A feed is a document — a snapshot of recent content at a URL. It requires no authentication, no server-to-server negotiation, no account. A reader can store it offline, forward it, parse it with a script, or pipe it into another tool. That statelessness is precisely its resilience. A feed published today will still be readable in a decade by software that does not exist yet.

From the record

Two-protocol comparison

  • RSSpull protocol; reader polls a URL; stateless; archival; no server-to-server negotiation
  • ActivityPubpush protocol; server fans posts to follower inboxes; requires persistent server infrastructure; carries social interactions (replies, boosts, reactions)
  • WebSuba third layer that adds push to RSS, but does not carry social graph data

Timeline markers

  1. 2018ActivityPub standardised by W3C
  2. 2022Fediverse growth accelerates following Twitter turbulence
  3. Late 2023Mastodon network reported over 8 million registered accounts

ActivityPub, standardised by the W3C in 2018, operates on actor-to-actor messaging across a federated graph. An actor — a Mastodon account, a PeerTube channel, a Pixelfed profile — sends activities (Create, Follow, Like, Announce) to inboxes on other servers. The protocol is social in design: it carries replies, boosts, and reactions, not just content. That richness is its advantage and its complexity. ActivityPub requires persistent server infrastructure, and federation breaks when a server goes offline.

Since 2022, the Fediverse has grown substantially. Mastodon gGmbH reported over 8 million registered accounts across the network as of late 2023, with hundreds of independent servers — instances — administered by individuals, universities, and journalism organisations. That growth, driven partly by turbulence at Twitter, demonstrated genuine appetite for a social layer that no single company controls. It also demonstrated RSS's continuing relevance: every public Mastodon account exposes a per-account RSS feed, quietly, at a documented URL path, because the underlying use cases overlap even when the protocols do not.

Terminal window on a dark monitor showing a raw Atom feed in XML, angle brackets and namespaces visible, person's hands on keyboard
A feed is a text file sitting on a server. Between the publisher and the reader there is a fetch, and nothing else.Photo: Tima Miroshnichenko / Pexels

Why the Argument for Both Is an Argument Against Neither

The publisher who sets up a Mastodon account gains social graph portability — followers are stored in a format that can, in principle, be migrated between instances using ActivityPub's own export conventions. The publisher who maintains an RSS feed gains something different: an audience that requires no account, no algorithm, and no real-time infrastructure to reach. A feed reader user who loses internet access for a day returns to a queue; a Mastodon follower who disconnects misses the stream. Neither is superior; they are optimised for different reading behaviours.

The IndieWeb's POSSE principle — Publish on your Own Site, Syndicate Elsewhere — is the clearest articulation of how both protocols fit into a single publishing practice. The canonical post lives on a domain the publisher controls, emitted into an RSS feed. From there, it can be syndicated to Mastodon via ActivityPub, to email via a newsletter pipe, to Bluesky via the AT Protocol. The feed is the origin; everything else is a copy.

What this means practically is that RSS and ActivityPub occupy different positions in the same escape route from platform lock-in. RSS covers the archival, discovery, and interoperability layer — the quiet infrastructure that lets content travel across time. ActivityPub covers the social, conversational, and real-time layer — the infrastructure that lets content travel across networks of people. A publisher who treats them as rivals is choosing between a library card and a telephone. The correct answer is to carry both.