[PIG] Enhancing RSS podcast feeds by using OAuth to access exclusive content

[dmathews]

Team member names
Daniel Mathews
Eleanor Tremeer

Short summary of your improvement idea

Podcasting is a creator-friendly distribution model where creators are not tied to any one tech platform and retain full ownership rights over their IP.

Currently, there is no easy way for podcast creators to distribute paid exclusive content to their listeners. The current solutions involve a user leaving their podcast player to get a private podcast feed using an app like Patreon or Supercast. This has given Apple Podcasts and Spotify an opportunity to launch exclusive episodes that can only be accessed on their platforms. However, Apple and Spotify’s changes are an existential threat to podcasting as this is disassociating podcasting from RSS. If that happens, the most important traits of podcasting — the fact that creators are not tied to any one tech platform and retain full ownership rights over their IP — are no longer true.

We are proposing a solution wherein the details needed to unlock exclusive content are added directly into the RSS feed itself. It would provide a great user experience for podcast listeners while allowing creators the convenience of not having to upload their exclusive episodes to multiple apps.

What is the existing target protocol you are hoping to improve or enhance? Eg: hand-washing, traffic system, connector standards, carbon trading.

We want to enhance RSS, the specification used to power podcast apps.

Currently, a podcast creator can host their own RSS feed or use a tool like Transistor, Libsyn, Acast etc. to publish a RSS feed for them. Podcast listeners get a choice from multiple podcast players (Apple Podcasts, Spotify, Overcast etc) as each one can display any RSS podcast feed.

What is the core idea or insight about potential improvement you want to pursue?

RSS feeds for podcasts are slightly different from other RSS feeds as they contain custom tags that are used to enhance the user experience inside the podcast player. We want to add some new tags, preferably under the podcasting 2.0 namespace, that contain all the information needed to unlock exclusive episodes using OAuth.

The technical problem OAuth helps us solve is that podcast creators self-host or upload their episodes to a podcast hosting provider (eg: Transistor), but podcast listeners use a different app (eg: Podyssey) to listen to podcasts. Therefore, if a creator wants to have exclusive content that is only available to their Patreon backers, how can Transistor and Podyssey work together to verify that only paid users can access exclusive content? We are proposing to use an OAuth workflow to achieve this.

Specifically, the core idea is that an RSS feed can contain a list of OAuth endpoints that allow podcast players to get a valid token needed to consume exclusive content on the RSS feed.

Our OAuth workflow can be summarized as OAuth with one additional step. That additional step is to make one more request to get a content token. The content token gives you access to content for a specific podcast.

Lastly, we are proposing not to create a new namespace but be included in the podcast namespace as we believe this new functionality aligns with Podcasting 2.0’s mission to “preserve, protect, and extend the open, independent podcasting ecosystem.”

What is your discovery methodology for investigating the current state of the target protocol? Eg: field observation, expert interviews, historical data analysis, failure event analysis

We will use a combination of historical data analysis and expert interviews. Historical data analysis will include researching all the ways podcast creators get their audiences to pay for exclusive content, by listening to both the creator’s experience and the listener’s experience. We will also conduct interviews with the developers who are building podcast hosting tools/players. This will allow us to gauge the extent of work needed to add support for new tags, while learning what would incentivize developers to do this work.

In what form will you prototype your improvement idea? Eg: Code, reference design implementation, draft proposal shared with experts for feedback, A/B test of ideas with a test audience, prototype hardware, etc.

A reference design implementation.

We have a working example (see the Larry’s Lullaby section). While it wasn’t created for the podcast use case — and therefore needs modification based on research and feedback — we would appreciate it if you could try it out and give us your input.

How will you field-test your improvement idea? Eg: run a restricted pilot at an event, simulation, workshop, etc.

We plan to create a mock RSS podcast feed, along with test episodes. The RSS podcast tags will contain all the new tags needed to get a content token required to access exclusive content, and also include links to media that need a content token appended at the end to link to work.

We will provide a working example for the podcast use case. We then will share this example with podcast hosting providers and people who run podcast players.

Who will be able to judge the quality of your output? Ideally name a few suitable judges.

• James Cridland - One of the founders of Podcasting 2.0. We have a personal connection.

• Justin Jackson - One of the founders of Transistor, a podcast hosting tool. We have a personal connection.

• Adam Curry - One of the pioneers of RSS podcast feeds. He also is one of the founders of Podcasting 2.0. We do not have a personal connection but we should be able to get in contact with him based on Danny’s relationship with James Cridland.

How will you publish and evangelize your improvement idea? Eg: Submit proposal to a standards body, publish open-source code, produce and release a software development kit etc.

We will submit a proposal to the Podcast namespace to include our new tags. Moreover, we will reach out to all the apps listed on the podcasting 2.0 website and pitch them to adopt the new tags. These are apps that are open to podcasting 2.0’s vision of an open and independent podcasting ecosystem.

James Cridland also has a popular newsletter for people in the podcast industry. Podyssey and Taddy have been mentioned in the newsletter before. We plan to include him as an expert interview and judge throughout the process and have him mention our draft proposal in his newsletter.

Lastly, we have already built Taddy for developers. 904 developers have signed up for our podcast API and are using it to build apps in the podcast space. We will email them a copy of our reference implementation.

What is the success vision for your idea?

Short Term: Add OAuth tags to the podcast namespace. Have one podcast hosting tool (Transistor) and one podcast app (Podyssey) implement this enhancement.

Mid Term: Reach out to all the people who run popular hosting tools and players that are not Apple + Spotify (Overcast, Pocketcast etc) to encourage them to implement this enhancement.

Long Term: Get in contact with Apple + Spotify and pitch our enhancement to them. This conversation only makes sense if the rest of the podcast ecosystem has started adopting these new tags.

[EleanorT]

Super excited to be on this project!!

[boris]

I love that the spirit of podcasting that has remained a decentralized protocol based around RSS is being looked at again, and to try and spread value to creators.

I see this running into other opportunities like Farcaster Frames – but basically, Frames that live everywhere, like ActivityPub and Mastodon.

Click to subscribe in an RSS reader would be amazing, too.

[swaldman]

Hi!

I’m very excited to see more RSS activity here. Podcasts are the clearest demostration of RSS’ potential, the one application domain that has remained largely unenclosed by miserable platforms because RSS’ flexibility enabled a more-than-good-enough, standard-ish approach, and no one has managed to embrace-extend-extinguish it, although it’s clear, as you point out, that several firms are trying to do so, using “premium” content as the hook.

RSS is a metadata format extraordinaire. All useful metadata related to items in a feed should find their way into an XML namespace and be provided within the feed via extensions. That certainly includes information about how to authenticate and become authorized to access linked resources.

An interesting choice implicit in your proposal is that the level at which you propose to require authorization is the item enclosure (or potentially some other resource linked within the item). The feed itself would be public, right?

An alternative approach might be to require authentication to access the feeds themselves. My only experience with “private” feeds has been Substack podcasts, where a basically permanent token is embedded in both the feed URL and enclosure links. Substack’s is a weak model from a security perspective. If the feed URL is shared so is the content. Perhaps Substack monitors for tokens that seem too promiscously used.

Your model is more ambitious, and could be much more attractive to creators hoping to sell access to their work. A public feed can itself be a kind of marketing funnel. Presumably people would marble free content with premium, to entice people to subscribe to the feed before they’re ready to pay for anything. Then premium items, podcast episodes, comics, would ever, would become ads for themselves inside the subscribed feed.

(People do this informally with “promos” and “teasers” already. Apple’s <itunes:episodeType>Trailer</itunes:episodeType> is a bit of existing, related metainformation.)

One really basic piece of metadata you might think about defining is just a tag to indicate whether linked or enclosed content is public or will require some kind of authorization. I would like it if my feed reader put a lock or something to signify links that are going to slam me into a paywall. Podcast clients also should be able to efficiently notify users of the availability status of whatever UI users are scrolling.

It looks like your JWTs would be rich enough to let feed readers and podcast clients know whether they are already authorized for particular items, so one might imagine clients maybe showing no lock for freely-available content, a closed lock for content requiring authorization not yet attained, and an open lock for content requiring authorization but already authorized. (I’m sure three are more beautiful ways to present these three status in clients, but just for example.)

In this model, only linked or enclosed resources could be premium, right? If, for example, you want full-content text to be premium, you’d not embed it in the feed at all, but make that an authenticated link. It might be worth thinking about whether there are ways you can extend this so, perhaps, a full content version of the feed itself is an authenticated resource. As an RSS text enthusiast, I really want my articles in my feed reader. That would also require coordination with clients, so for example users would first subscribe to a public feed without the fulltext resources, but could authenticate and then clients would automatic substitute the richer feed as their subscription.

It’s a very rich mine to vein!

I have mixed feelings about exclusive content in general. I’m a nineties information-wants-to-be-free guy, who understands that humans need to be paid, but still hates every paywall and wishes we’d come up with better models to support creative work.

But in the current, actual world, it’s much much better that there be a standard like the one that you propose than that creators and audiences migrate to proprietary infrastructures. So I think work like this could be a great addition to RSS.

[dmathews]

@swaldman

An interesting choice implicit in your proposal is that the level at which you propose to require authorization is the item enclosure (or potentially some other resource linked within the item). The feed itself would be public, right?

Yup! I’m proposing the RSS feeds are publicly accessible, including the URL links to media. However, to access the media content via these URLs, you need to include a token. Without the token, accessing the media will fail.

@swaldman

It looks like your JWTs would be rich enough to let feed readers and podcast clients know whether they are already authorized for particular items, so one might imagine clients maybe showing no lock for freely-available content, a closed lock for content requiring authorization not yet attained, and an open lock for content requiring authorization but already authorized. (I’m sure three are more beautiful ways to present these three status in clients, but just for example.)

And yes! that is essential what I was thinking as well.

@swaldman

I have mixed feelings about exclusive content in general. I’m a nineties information-wants-to-be-free guy, who understands that humans need to be paid, but still hates every paywall and wishes we’d come up with better models to support creative work.

But in the current, actual world, it’s much much better that there be a standard like the one that you propose than that creators and audiences migrate to proprietary infrastructures. So I think work like this could be a great addition to RSS.

Understandable. The pioneers of RSS were very passionate about content being available to everyone. On the other hand, podcast creator do want to be paid for their work, and if its not on the RSS feed, it makes sense from them to use Apple and Spotify, even if it locks them into these platforms.

Thanks for the thoughtful feedback. It’s much appreciated.