AT Protocol & RSS
A Superset, Not a Replacement
wesbos.com recently responded to a comment of mine and something stuck with me! Its nearly impossible to break away from RSS.
He's not wrong. I honestly do agree with Wes but it's pretty difficult to completely break away from RSS. RSS is creating an artifact. The AT Protocol doesn't replace RSS but it makes it unnecessary as a source of truth, while keeping it alive as a distribution format.
The problem with RSS as podcast infrastructure
RSS was designed for a simple job and that job is syndication. It's a feed, not a database. Podcasting hijacked it and turned it into a metadata store that every podcast app on earth depends on. Since this repurposing of RSS, it has created problems that have added up over the years.
No identity verification - Anyone can publish an RSS feed claiming to be anyone! There's no cryptographic proof that the person publishing "XYZ" is actually XYZ. I believe Apple Podcasts relies on manual verification but the rest of the ecosystem just trusts the feed URL. There is no per-episode signature verification. (Correct me if I'm wrong please 😊)
One way interactions - RSS is one way, in the fact that it doesn't allow for likes, follows, comments, play tracking. Every social feature in podcasting is bolted to separate platforms like Spotify, YouTube, Reddit because RSS can't express these features.
No push updates - RSS clients poll on intervals. Sometimes hourly, sometimes daily. When you publish a new episode, your listeners might not see your podcast for hours. There's no real webhook, no push, no real-time anything.
Portability compatibilities - Your feed URL IS your identity. If you change your hosting provider, users redirect their old feed to the new one and hope that every application follows the redirect. Some do and some don't. In result of possibly losing subscribers.
What ATProto brings that RSS can't
AT Protocol helps attack a lot of these problems. Not by replacing RSS, but by providing better foundation for the data that RSS currently holds. A lot of us devs within the Atmosphere understands these concepts but I want to touch on them for others.
Signed records - Every record that a user creates is cryptographically signed by that user's DID (Decentralized Identifier - basically your ID). When a podcaster publishes an episode, the record carries their signature. Proof over promises. No more "is this really their feed?"
Content addressing - Records are referenced by CID (Content Identifier) - a hash of the content, think of the CID as being a digital wax sealed stamp. Instead of pointing to where a file lives on the web, a CID points to what the file actually is. If anyone alters the a second of that episode, the seal breaks and the CID changes. This means you can be 100% sure the episode playing is the exact, untampered original episode the creator published.
Real-time push - AT Protocol has a firehose. When a user publishes a new episode, the event/episode is broadcasted through the network in seconds. No polling or crawl delay. Apps that subscribe to the firehose know about the new episodes instantly.
Native social layer - Follows, likes, replies, and reposts are built into the protocol. A listener following a podcaster on Bluesky, Blacksky, Eurosky, and others can see new episodes in their feed. The conversations lives in the open and not in a siloed network.
Portability - Your DID is your identity, not your feed URL. You can move your Personal Data Server (PDS) and bring your entire podcast catalog. Your followers follow your DID, not your URL feed. You never lose subscribers by moving.
The "not really replace" part, RSS as a generated compatibility layer
Here's where it gets practical. We can't just ask Apple, Spotify, Overcast, and Pocket Casts to rewrite their apps to support the AT Protocol. That's not going to happen and it shouldn't have to.
The solution I believe that could work: RSS becomes a generated artifact, not a primary data source.
Think about it like a database view. The underlying data lives in AT Protocol records that are signed, queryable(searchable), and portable. RSS feeds are generated from those records on demand, cached at the CDN edge and served to any app that still expects RSS.
- Creator publishes in Studio: Trigger.
The podcast host or creator hits publish inside the studio dashboard.
- AT Protocol record written to PDS: Decentralized Storage.
The episode data is cryptographically signed and stored on the Personal Data Server (PDS) as a content-addressed record.
- Database indexed with AT URI + CID: Prisma DB.
The application database saves the reference using its AT URI and CID hash for rapid querying.
- RSS feed generated on-demand: Compatibility Layer.
The server dynamically constructs an open RSS XML feed using the indexed database records.
- Edge cached via CDN: Performance.
The generated feed is cached globally at the CDN edge for fast, low-latency delivery.
- Distribution to legacy apps: Output.
Traditional platforms (Apple Podcasts, Spotify, Overcast) fetch the cached RSS feed seamlessly without knowing ATProto exists underneath.
The RSS ecosystem keeps functioning exactly as it does today. But the source of truth has moved upstream to the AT Protocol. RSS is a projection, not the original.
If a podcaster tries VoxPort and later decides to go back to raw RSS, their episodes keep the same GUIDs. Subscribers don't see duplicates. The migration is reversible with no lock-in.
One thing I recently found out about was Podping(https://podping.cloud/). It is a notification system for podcast RSS updates. When an AT Protocol record is created or updated, VoxPort could send a Podping notification. RSS apps get push. AT Protocol clients get firehose push. This creates two channels, one source of truth.
Podcasting 2.0 maps cleanly to AT Protocol
The Podcasting 2.0 community has been working on extending RSS with richer metadata. The irony is that their extensions map pretty close to AT Protocol record fields.
Podcasting 2.0 Tag | AT Protocol Equivalent | Technical Role |
<podcast:guid> | AT URI | Stable, content-addressed identifier |
<podcast:chapters> | chapters array | Array embedded in episode record |
<podcast:transcript> | transcript object | Structured object in episode record |
<podcast:person> | DID + Bluesky handle | Cryptographically verified, portable identity |
<podcast:soundbite> | soundbites array | Highlight clips array in episode record |
The Podcasting 2.0 movement is trying to solve the right problems. AT Protocol is just a cleaner way to solve them. Instead of extending the XML with namespaces that may or may not be supported by each app, you would define a typed schema (lexicon) that any AT Protocol client can consume.
The viral loop RSS cannot do
This is the exciting part that gets me going! RSS is a broadcast medium, meaning its one-to-many, no feedback loop. AT Protocol is a social platform, meaning its many-to-many, with discovery built in!
When a creator publishes and episode on VoxPort:
- The episode appears in followers' feeds. Not because they checked a feed URL, but because they follow the creator's DID and the firehose pushed the new record to them.
- Listeners can repost the episode. Their followers see it. Free distribution to audiences the creator doesn't have access to.
- Listeners can reply to the episode. Their reply is a post on whatever AT Protocol platform of their choice with a strong reference to the episode recording.
- Play counts combine with social engagement. A trending score can factor in plays, likes, reposts, and replies. A multi-dimensional signal that RSS-based platforms can't compute because RSS doesn't carry any of that data.
This is the viral distribution channel that podcasting has never had. Every RSS based platform tries to build social features on top of a one way protocol. AT Protocol give you social for free.
The competitive framing
Feature | RSS-Only Platform | AT Protocol + RSS |
Distribution | Apple, Spotify, etc. via RSS | Traditional RSS platforms + AT Protocol clients & social graph |
Identity | Unverified, vulnerable feed URL | Cryptographically verified, portable identity via DIDs |
Data Portability | Tied to feed URL (changing hosts breaks identity) | Tied to DID (move hosts freely without losing audience) |
Content Verification | None | Cryptographic signatures (CID hash matching) |
Real-time Updates | Polling (delays up to several hours) | Instant push via Firehose (seconds) |
Social Engagement | Non-existent (reliant on 3rd-party platforms) | Native follows, likes, replies, and reposts built-in |
Comments & Discussion | Fragmented (Reddit, X, Discord) | Native ATProto threads directly attached to episode records |
Discovery | Platform-specific algorithms & walled gardens | Open XRPC querying + global relay indexing |
Analytics | Opaque, platform-controlled metrics | Open firehose data + first-party server analytics |
It's not AT Protocol versus RSS. It's AT Protocol and RSS. The same distribution, plus everything RSS couldn't do.
The Migration Path
The beauty of this approach is that no one has to switch all at once.
- Import from RSS. Bring your existing feed. AT Protocol records are created automatically. Your RSS feed keeps working, now its generated from AT Protocol records instead of being the source of truth.
- Publish to AT Protocol. New episodes go to AT Protocol first. RSS is generated. Followers get new episodes in their feeds. Apple Podcasts gets the RSS feed. Everyone is served.
- Adopt AT Protocol navigate features. Episode replies, social mentions, cross-platform follows, real-time discovery. These are capabilities that RSS physically cannot provide. Apps that adopt the protocol get them. Apps that don't are still served via RSS.
- Leave whenever you want. Your GUIDs are stable. Your RSS feed works. Your subscribers are intact. You can go back to raw RSS at any time. Zero lock-in.
RSS isn't going away. It shouldn't. It's the universal standard of podcast distribution, and it will be for a long time. But it shouldn't be the source of truth anymore.
AT Protocol gives podcasting what RSS was stretched to do but couldn't. Verifying identity, native social engagement, open discovery, real time push of podcasts, and full data portability. RSS keeps working as a generated compatibility layer.
The migration is gradual. No one loses anything. Everyone gains!
It's a superset, not a replacement.
ps.
I will always state, "If I have misspoken, please call me out and correct me" 😊 I love to learn.
Give VoxPort a try in your free time if you are a podcaster and if you're a listener, tag your favorite shows to get them on VoxPort. lol 😊
Hope for good health and happiness for all!
Sources:
Log in to leave a note.