The endless bashing of RSS (most recently by Spotify executives at their “investor day” event) and its role within the technology of podcasting is honestly baffling, and shows a fundamental misunderstanding of what RSS is and what function it serves within the open podcast ecosystem. So, let’s explore that topic a bit and set the record straight.
RSS is not a protocol. It’s not a platform. It’s not a “technology”. It is simply a data delivery format. The open podcast ecosystem could just as easily use some other data delivery format like YAML, JSON, TOML, CSV or just about anything else you can think of. RSS just happened to be in the right place at the right time to be useful in that role. It’s an accident of history that we ended up with RSS instead of something else. We have lots of ways to describe data. Arguing that one format is better than the other (with data sizes as small as podcasts are) is silly. RSS does its job just fine.
So, in some ways you could argue that, as a format, RSS is irrelevant to podcasting. And, that might be somewhat true on a whiteboard. But, the fact that it’s what we already have is what matters. It might just be one of any number of data interchange formats, but it’s the one we all have and use. It’s the currency of podcasting. And, that makes it critically important.
This, incidentally, is the reason I’ve been publicly so against things like JSONfeed in the podcast world. It’s not because JSONfeed is flawed. It’s a very well designed spec. But, it’s irrelevant to the ecosystem because RSS is already there and already serves its role admirably. Changing to JSONfeed would involve massive, industry wide retooling for virtually zero benefit. We would still have the exact same systems we have today doing the exact same things. So let’s just move on from that debate please. You can change the door knob to a pull handle, but it still just opens the door.
RSS itself was never the sole piece of the podcasting puzzle. The ecosystem has always relied on a constellation of various formats and protocols (http, mp3, xml, iso formats, mobile api’s and libraries) to function properly. Call it a technology “stack” if you want to. Without web servers there would be no podcasting. Without MP3 compression there would have been no podcasting. Without XML there would’ve been no RSS at that critical moment to catch Adam and Dave’s lightning in a bottle. Without mobile platforms to listen on there would have been too little demand to sustain it.
You get the idea. It takes a (protocol) village.
So, again, let’s get this idea out of our heads that somehow RSS is what the open podcast ecosystem solely depends on to deliver complete features, and therefore anything that RSS “can’t do” on its own is somehow a direct limitation on what the open ecosystem itself can do. Because that’s not the case. RSS can deliver any feature we want it to because it doesn’t have to do every bit of the work. At the appropriate time it can hand off the work to other layers of open technology that will do the heavy lifting. Just like podcast apps call out to a web server to download an mp3 file, apps can also call out to a web server to get a transcript. Or, they can launch a chat window for a comment thread referenced in the feed. Or, maybe they can download a chapters file for an episode when the feed points to it. This is what RSS does so well. It delivers information that apps and platforms then act upon. Sometimes that information is a one way street and sometimes it goes both ways. There are no limits here.
Think of it this way: if RSS is “outdated technology” then so is HTML. We should ditch it and just get every web page as a JSON object from Google’s API. That’s the analogy. But, we all know that’s silly talk. Just like RSS, HTML simply delivers the information needed for open, standards compliant web browsers to act upon and deliver a great web experience to the user. And, it does this while providing creators sovereignty over their content. This is how open systems work. And, it works just fine.
But, to be honest, I don’t think all of what’s been said here is really what is in mind when people say things like RSS is “outdated technology“, or “You can’t innovate on RSS” or that RSS is holding back podcasting. I think it’s obvious that what they really mean is something more like: “building open interoperable systems, advocating for them and shepherding them to maturity is hard, and we just want to make money so let’s build a closed API and call it a day.”
That’s what’s really being said. It’s not really RSS that is under attack. It’s the open, decentralized (unowned) podcast ecosystem that many would-be walled gardens find so very annoying.
So, let’s talk about what you can do in the open, RSS based podcasting ecosystem today. RSS was made to be extensible from day one, using namespaces. And, the Podcasting 2.0 project has been innovating on top of RSS with the “podcast” namespace for about two years now. Here are some things that modern podcast apps are doing right now which enables collaboration between multiple parties using RSS as the backbone:
Transcripts: Creators can generate their own transcripts using whatever tools they want and give them to their listeners through their RSS feed. Because it’s an external file, cloud based services can be used to generate, refine and index these transcripts on the fly.
Cloud Chapters: Every week on our show we use a cloud based chapter editor called Hypercatcher Studio to generate a chapters file and include it in our RSS feed. Then, later, one (or many) of our supporters collaborate on marking chapter points in that file. Podcast apps see those new chapter markers and update on the fly as they are added. This is crowdsourced episode chapters.
Soundbites: Platforms like Headliner, and apps like Podverse are already pulling in defined Soundbites from RSS feeds to build and distribute clips. Clips on other platforms could even be published back out in their own feeds.
Person: Services like Podchaser do a great job, but nobody can index everything. It’s just too much manual labor. By including the Person tag in your RSS feed, you can enable everyone to see your host, guest and cast information and index it immediately without all of the human interaction.
Location: Yet another indexing and discovery possibility exists with the Location tag. Including this in your RSS feed can allow apps and services to feature your content when searching for podcasts about a certain region or location - even fictional ones.
Value: With the value tag in an RSS feed, the creator can specify a wallet to receive digital currency directly from the listeners app. These payments (called “boosts”) can include messages from the listener. That’s a two way interchange built directly on RSS as the information delivery mechanism. There are 7000 feeds and 7 podcast apps doing this already.
Medium: One of the newer RSS tags is the “medium” tag which allows a creator to say, within their feed, what type of content the feed contains. It can be “music”, “podcast”, “film”, “audiobook” and more. Using this data, new podcast apps can be developed that target only a certain subset of podcasts and design their user interface to be appropriate for that medium. Imagine a podcast app that only plays music from indie musicians. That’s coming. It won’t look like a normal podcast app, but it’ll all be regular RSS podcasting on the back end, just like we’re all used to.
Live Item: Over the recent weeks we have been refining the software to power this new RSS feature. Creators can signal to their subscribers that they will be doing a live stream at a certain date and time. Using the Podping notification system (built on the hive public blockchain) to send a push notification, apps can alert their users instantly if they subscribe to a show that just went live. Multiple podcasts including ours are doing this on a weekly basis now. It’s amazing to watch. There’s even a Twitter bot where you can see which shows go live in real time. That’s turbocharged discovery.
Social: This is an RSS tag that is currently under development but already being beta tested in multiple shows and apps. It allows the creator to specify where they would like comments and discussions to take place around episodes or an entire show. It can use ActivityPub for a decentralized experience or even a Twitter reference if wanted. It’s working well and hopefully will be formalized soon.
That’s an incredible amount of RSS based innovation in just two years time. No other closed, proprietary podcasting platform has come close to that speed and breadth of innovation. So, anyone that tells you RSS is just an “outdated” one-way street, or that it limits progress is either uninformed or dishonest. Let’s go with the former, for now.
Hi Dave. I listen to the No Agenda podcast (https://www.noagendashow.net) almost every time. I saw the "Live" function in my Podverse app work; it's amazing what you guys have done and are doing.
My 'problem' is ... I guess many people with a myriad of interests in so many topics is ... that a day has only 24 hours. I assume everyone has content that's more ore less prioritized ... and other content that's also interesting, but that's secondary or even tertiary. The latter two are now "only to be clicked on" if there's time left.
What I am thinking about is whether you are already working on the following idea; is it possible and maybe could be seen to attract more traffic when a podcast as-a-service could include a different idea of Chapters but akin to it; additionally a chapter or maybe in the hierarchical sense built on the same level as the podcast itself ... to cut audio sections and once clicked it plays all chapters automatically (for instance a whole podcast lasts 180 minutes with 20 chapters -median time 9 min- and play in that file 20 times 20 seconds).
For the NA podcast that wouldn't be necessary because there's lot's of fun interspersed over the whole podcast (so you wouldn't like to skip that) ... but listening to a business podcast or any podcast that is more monotone /tedious ... it'd be an asset to skip the currently built-in chapter-part where the user still has to manually skip through chapters (which isn't safely doable as a driver in a car for example). I am thinking "wouldn't it be appealing to click on one button and hear/skip through a podcast in 1/20th of the time (in normal speed of course).
Thanks for making podcasting a far better experience