Proposal: universal method for premium subscriptions

[theDanielJLewis]

After Apple's announcement about premium subscriptions (which many had expected), I've been thinking of a way that we could build a more universal "subscription" method that app developers could support.

Goals

1. To let podcasters monetize their podcasts directly via subscriptions, donations, exclusive access, bonuses, and more.
2. To provide podcast-app developers a framework to launch their own support and earn some extra profit, too.
3. to create a universal standard that would be easy for podcasters and podcast-consumers, and support the freedom of choice for consumption platforms.

Proposal: <podcast:exclusive>

My proposal is for a new <podcast:exclusive> tag and framework. The could be used at the channel level to lock an entire feed, at the item level to lock individual episodes, or even within an item to lock specific portions of content or additional bonuses.

While I think some of my idea might be invalid RSS or otherwise rough, I'll share it anyway to help inspire ideas for the problems I'm trying to solve.

Code concepts

There would be two ways to apply the "exclusive" feature: tag and attribute.

Tag: <podcast:exclusive roles="bronze,silver,gold">

Attribute: <enclosure exclusive-url="…" … /> or <title exclusive="90-minute episode">60-minute episode</title>

The idea is that the exclusive tag would wrap or mark whole items as exclusive, while the attribute would mark smaller pieces as exclusive.

A probably-invalid method for making an exclusive episode in a public feed could be like this:

<exclusive role="subscriber">
  <item>
    …
  </item>
</exclusive>
<item>
  …
</item>

My theory with this example is that it hides the item from unauthenticated users and from default RSS-reading apps (podcast apps or feed readers). This is not creating any security, only acting as a way to prevent exclusive content from showing in normal feed-reading places.

Or if you want the episode to be visible, only not downloadable, you could add the <podcast:exclusive> tag inside the item.

And if the only difference for the exclusive item is the media (like maybe an ad-free version), you would use the exclusive attribute on the enclosure (or maybe alternate enclosure).

Security and Authentication

Media would need to be stored in a secured method, such as with the Amazon S3 protocol. So the URL in the feed would be a normal URL that works for everyone, but the podcast app would have the access key stored to authenticate and access the media.

This would require some cooperation with podcast-publishing or hosting tools, to host with the authentication requirement. But neither the podcaster nor the host would have to manage the memberships, roles, and payments. That could be left to app developers.

I'm thinking that the podcaster could get an API key from their hosting account, sign up with the app-dev's website, give the app the API key and set pricing and roles, and then the app would handle payments, authorization, and access.

There could even be a way for the hosting provider or publishing tool to handle the admin while the podcast app simply interfaces via APIs, but I think that could be more difficult and more complicated than letting the app handle the admin.

Experience

The resulting experience would be very similar to the new Apple Podcasts Subscriptions, but in any supported app.

For example, PodFriend could integrate with this, apply ~3% for payment processing, pocket 12%, and the podcaster keeps 85%.

Maybe this could be merged in some way with the value block, too, so that if you stream a certain number of sats, you unlock exclusive access.

These are my rough thoughts for now.

[daveajones]

Yes, that is invalid RSS. But, I'm following what you're logic is and I understand what you're trying to get at. I think it can be done without wrapping by just tagging an item with a public key and then sending back a hash as an authentication that you have a private key given out by the feed owner.

Perhaps like this:

<item>
    <podcast:exclusive pubkey="1jfi3083ydnei228954fonnuroe" alternateEnclosure="[alternateEnclosureGuid]">
    <enclosure url="[episode teaser mp3 file url]" ...>
    <podcast:alternateEnclosure guid="[unique id]">...</podcast:alternateEnclosure>
</item>

Then the standard would be that the pubkey gets hashed with your private token and send back as a query param with the alternateEnclosure url like "https://example.org/path/to/privateaudio.mp3?token=1jdko4hw9aotv8aaahg"

[theDanielJLewis]

What I'd like to try avoiding would be letting exclusive episodes display at all in "dumb" podcast apps that will list anything in the feed with a media file.

[daveajones]

What I'd like to try avoiding would be letting exclusive episodes display at all in "dumb" podcast apps that will list anything in the feed with a media file.

I think for something like that we'd need to have a whole separate item tag, like <podcast:item>.

I think this overall concept is really neat and ambitious. I'm willing to devote some time to fleshing it out.

Hey @agates , should alternateEnclosure's have some sort of unique identifier for situations like this where they might need to be addressable by other tags?

[agates]

Hey @agates , should alternateEnclosure's have some sort of unique identifier for situations like this where they might need to be addressable by other tags?

If it's within the same item it could be the title of alternateEnclosure, although I don't quite understand what you mean.

How would the token be generated and why is it per alternateEnclosure? It could be a child item of alternateEnclosure if that's the case, no?

<podcast:alternateEnclosure ....>
  <podcast:pubkey>1jfi3083ydnei228954fonnuroe</podcast:pubkey>
</podcast:alternateEnclsoure>

Although having it under the item makes sense -- I'm just not seeing the alternateEnclosure connection :). And it wouldn't work with something like IPFS or magnet URLs either.

[theDanielJLewis]

I don't know why the pubkey would need to be in the feed. I would think only the app would be given the pubkey by the podcaster.

[agates]

The public key in the RSS feed would work perfect actually -- the application would need to support a private key added by the user. This would definitely be an application-agnostic method to sign requests and make your proposal work, I'm just not sure of the specifics from dave

[yoshimo]

Exclusive episodes should be able to hide free episodes. There are podcasts that offer ad free versions for subscribers. Some also do extended versions with pre and post shows.

[theDanielJLewis]

Exclusive episodes should be able to hide free episodes. There are podcasts that offer ad free versions for subscribers. Some also do extended versions with pre and post shows.

This could be handled by defining the alternateEnclosure as the exclusive, thus replacing the normal enclosure.

But I could see instances where you want something to display only to free followers and no alternative to subscribers. For example, a promotional episode for the premium content.

In such case, we could add an attribute to the exclusive tag that blocks the content from certain roles. So, instead of my roles attribute described above, it could be allow and block.

For example, <podcast:exclusive allow="silver"> shows the episode for only silver subscribers and no one else. And <podcast:exclusive block="silver"> hides the episode only silver subscribers, but anyone else (including free followers) can get it (assuming it's a native <item> visible to traditional apps).

[daveajones]

The public key in the RSS feed would work perfect actually -- the application would need to support a private key added by the user. This would definitely be an application-agnostic method to sign requests and make your proposal work, I'm just not sure of the specifics from dave

Yes that’s exactly what I envisioned. When the feed gets added, the app asks for the private key and keeps it in remembered for signing.

[theDanielJLewis]

Sounds good. Whatever it takes to make it work easily. Not like "my mom can't do it" level, but easy enough that the process doesn't turn people away and complements an app's smooth experience.

Tying this into a Satoshi-streaming app could let you set predetermined sat level(s) to unlock bonus content. Kind of like how Humble Bundle deals work, "Contribute more than __ sats per month/episode/week and unlock exclusive subscriber benefits!"

[chiragnd]

Love the idea. In a way this would be a higher tier than a ‘support the show’ tag potentially? Which is essentially a subscription without exclusive content.

Agree that looking at how the subscription is applied is useful since it’s a good implementation—correlating a subscription episode against a free one and showing it based on that, and having the option to tease content for free ones but not show up for paying subscribers is great.

Apps that implement this can create a URL-based flow, so we could show members a one-click add for compatible apps which adds both the feed and the pvtkey to make that slightly frictionless.

[keunes]

Great initiative @theDanielJLewis. I think I understand how it could work with private-public keys – but is it then easy for a podcast to 'depricate' a key of an individual subscriber, e.g. if their payments failed, so they no longer get access to new exclusive content?

There could even be a way for the hosting provider or publishing tool to handle the admin while the podcast app simply interfaces via APIs, but I think that could be more difficult and more complicated than letting the app handle the admin.

Not sure if that's still relevant with the latest ideas, but I'm thinking that the podcast apps should be as simple as possible.

• As a listener, I wouldn't want to have any problem to move to another app; I wouldn't want to have payment issues or be afraid that my new app might not include payment systems (preventing me from enjoying exclusives). When working with keys, they might be included in OPML files (?) that allow me to easily switch apps.
• As a FOSS podcast developer I wouldn't want to deal with payment systems, just implement support for user access to private content. (Actually in general I'd say offering payment/exclusive content services should be one of the things that hosters can/should offer - taking admin out from the hands of the podcaster.)

[douglaskastle]

There are some interesting ideas here. However there is a mechanism to handle content like that already, usually password protected files. I know that AntennaPod already supports this. This can be reused today and is supported today. It is the RSS feed is where the problem is.

The big problem is the different RSS feeds required to show the free feed versus the paid one. Typically if one gets their hands on the paid feed it can't be taken back, which isn't great.

I think the above goal is to have one feed, but lets say contain 2 episodes, one with ads and one without, free and paid respectively, and only have the episode that one has access to to show up in the feed.

One can possible set your own permissions level, which could just filter the feed accordingly, it is only when the user tries to fetch the paid file that the password will be requested and at that point success or blocked. So it is in the users interest to set the correct level even, it could be as simple as that.

I love public key signing and verification in ways I can't describe, but it is a order of magnitude jump in terms of support, do the gains justify it?

[theDanielJLewis]

I realized a ridiculously easy way to write standard RSS while keeping some episodes exclusive: the alternate enclosure tag.

I believe all the podcast apps behave this same way: they'll display anything from the RSS feed as long as it has an enclosure. If an item doesn't have an enclosure, it won't display in the podcast app. That's our exclusive content right there. The apps will skip an item that has only alternateEnclosure, or it could display them disabled, but pay-subscribing will unlock those alternate enclosures that have the "exclusive" attribute.

About feeds, yes, the goal of this is to make it as seamless as possible for the listener. They click subscribe, enter their payment info, and they immediately get access to the exclusives. No additional feeds, no password entries.

And here's a new idea for how to handle this across apps, should a subscriber want to move: oauth.

If the app developer wants to support exclusive content in their app, but doesn't want to handle the admin (or share in the profit), they could authorize the user through an oauth token. The podcast would need the payment system set up (so this makes it suddenly much more complicated), but the user would simply click "subscribe" or "restore purchase," be prompted with an oauth sign-in, and then that unlocks the content, allowing them to switch to a different oauth app.

Then again, this doesn't work well moving from oauth to fully integrated app, or vice versa.

The other hurdle is, at least for iOS, I think Apple might have issues with an app that takes payments but doesn't give Apple their 15–30%.

But I like the discussions we're having. We can figure this all out and make something great that will be a win for everyone!

[douglaskastle]

The other hurdle is, at least for iOS, I think Apple might have issues with an app that takes payments but doesn't give Apple their 15–30%.

If the user permission is on the Web server not the app, can they charg? In the password protected case I believe that paradigm is already in play. One regularly access different parts of a website based on your login credentials.

Apple is a strange beast, but it does not deserve 15-30% for the work they do. It probably shouldnt be free either, but I would like to see a more healthy competition in this space.

[theDanielJLewis]

Password-protection works on only the entire feed. And I'd rather users not have to enter login information in the app at all. This can really mess with password auto-fills and also means the app is storing that private login information.

[douglaskastle]

@theDanielJLewis

I don't see why the RSS feed can't be in an unpassword protected part of a site and it is only the files that are password protected (or not). The issue here is correctly constructing a feed that can a) contain both the content for paid and unpaid b) only show the files you have permission for. Support needs to be added to do that

As to password logins etc etc, that is a known problem that has been solved loads of times, it might be a pain to do, but sure. Firefox and Chrome ask for you password once and stores it, what's wrong with that model? In terms of getting something working with existing infrastructure this is probably the easier path.

However view my opinion as an "also" thing not an "instead of". There is no reason why both ways can't be listed as possibilities.

[PofMagicfingers]

IMHO, it's better to not reinvent the wheel, and I agree with @douglaskastle on using HTTP Authentication :

• it's already implemented on many podcasts clients
• You enter your login/password once, the client remember it.
• You can technically serve the free content when no login/password is used and switch to paid content when you enter a login/password
• You can easily provide links with included token or login/password
• Most podcatchers, directories, etc understand its a private feed when they see a username and password in URL

The main issue with HTTP Auth is getting all podcasts clients to understand they should not share this feed with logins when exporting or ingesting in their own directory. And I guess it's already a problem right now and most directories are already working on this.

I'm not sure what advantages you get from using private/public key on this, but I'm all hears. It's as easy to revoke either a private key or a login/password, and user/password is already largely implemented on client and on server side.

EDIT:

Here is an example of the same feed providing different content when given a username/password

curl https://assets.podcloud.fr/feed/ curl -u michel:secret1234 https://assets.podcloud.fr/feed/

You also can achieve the same thing with a token inside the URL.

[agates]

HTTP won't always be the only option for file transport. Public/private keys would at least function for the file itself and be usable with IPFS etc.

Plus HTTP basic auth really isn't that secure, which is typically replaced with asymmetric encryption anyway.

It should be noted the irony of wanting DRM for podcasts leaves one thinking why not just stick with Apple

[douglaskastle]

It should be noted the irony of wanting DRM for podcasts leaves one thinking why not just stick with Apple

Just on this point. I don't think there is anything wrong with what Apple is doing technically, it is just that it is Apple and once you are inside their walled garden they run the table. Being able to recreate the feature they are adding and providing it out of their domain is still of value.

[douglaskastle]

HTTP won't always be the only option for file transport. Public/private keys would at least function for the file itself and be usable with IPFS etc.

@agates is there a way to protect an IPFS file so that a person can see it exists but can't down load it unless they have some permission? I thought if you are on the network it is open season, I personally have no problem with that.

[douglaskastle]

Here is an example of the same feed providing different content when given a username/password

curl https://assets.podcloud.fr/feed/ curl -u michel:secret1234 https://assets.podcloud.fr/feed/

You also can achieve the same thing with a token inside the URL.

This is creeping into an idea I have had for a while, per user RSS feeds. Potentially everybody gets their own feed of .... The options here are enormous, maybe deserves its own issue ...

[PofMagicfingers]

@agates IMHO Public/Private key is a bit overkill for this, and user specific tokens in file URL (HTTPS or IPFS or anything else) seems less work for the same result.

If the goal is to prevent files from "leaking", and be given to people whom didn't paid for it... One could easily share his private/public key, as they could with a "unique token URL". I think building an asymetric cryptographic DRM system for podcasts episodes seems too much a hassle for the result we will get on either way : people will share the mp3 files if they want to.

Being able to recreate the feature they are adding...

@douglaskastle This is where I'm a bit lost, because we already have hundred of premium subscriptions podcasts in the wild. It seems we are kind of recreating an Apple re-creation of something that already exists and works.

I do understand the need to make it future proof etc, but we should not forget this kind of thing already exists and maybe we should build on it, and salvage some concepts and ideas, and not re-start everything from scratch.

[PofMagicfingers]

per user RSS feeds

IMHO that's the way to go. You can have a main guest feed, and users subscribing to exclusive content get their own RSS feed.

[douglaskastle]

@douglaskastle This is where I'm a bit lost, because we already have hundred of premium subscriptions podcasts in the wild. It seems we are kind of recreating an Apple re-creation of something that already exists and works.

@PofMagicfingers yes you are right. I think the best feasible solution should be used and not be limited by the Apple solution either.

I do find though that some of the premium solutions that low level podcasters are using are not fit for purpose. A lot of people who are on patreon are usually putting out two separate feeds. I think I know that patreon have a better solution, but the people that I am supporting are struggling then to figure out how to use it. Believe it or not a simple UX on the hosting side here will make or break this one. Too hard, it won't be used.

[PofMagicfingers]

Believe it or not a simple UX on the hosting side here will make or break this one

Exactly, I think here the main problem is an UX problem, not a technical problem. Maybe we could imagine something like a channel wide attribute and something that kind of works like oauth : <podcast:exclusive uuid="anuuid" authUrl="https://hostingplatform.com/premium-feeds/login/" label="Unlock exclusive content">

Your podcast client will then show you a button "Unlock exclusive content", opening a webview to the URL given. There, the hosting platform will inform you about the exclusive content and let you subscribe, register, login, etc.

Then it will redirect you to your own personally crafted RSS feed. This is when the podcast client detects the redirection to a RSS feed and understand this is an update of the feed which you clicked on the button. If you use a redirect url to open the premium feed into the app, it should compare the uuid to update the existing feed instead of adding a new one

[jamescridland]

Earlier in this thread, people are writing about producing dynamic, personally-crafted RSS feeds for everyone. https://medium.com/acast/an-ode-to-rss-and-a-toast-to-the-future-e181a9f65a39 is Acast selling exactly this. (And I'd agree with the idea - indeed, I could already produce a dynamic RSS feed for Podnews which gives US people different content to UK people.

For login, I would be very keen to use OAUTH or similar; noting that https://www.facebook.com/login might open in the Facebook app rather than in a webview, and therefore the user might see nothing at all (or a simple consent screen). But I agree with the above that it is not a technical issue, and more of a UX one. Current solutions are clunky, or just don't work.

[satoshisstream]

Adding my 2 satoshis here. I was thinking about the app sending a header with the mp3 download.

The header could hold the sender GUID and signature. If the downloader/app has donated enough sats, the server could send a customized MP3.

[PofMagicfingers]

personally-crafted RSS feeds

Yup ! I think that could be a great idea. That's what we're doing at podCloud : we are both a hosting company and a listening webapp / catalog. When you subscribe to a podcast on podCloud, you can get a personal RSS feed.

We're not providing premium subscriptions (yet), but every user can have his own personnal RSS feed for a podcast, a playlist or subscriptions. It allow us for example, to gather all subscribed RSS feed into one : when I change my phone, I only re-subscribe to this feed on my podcast app (Podcast Addict)

We mark items as played when downloaded : we add a token inside the enclosure url. Items already played are shown with an :heavy_check_mark: in the title.

User tailored RSS seems a more reliable method for serving premium content. However, it does have its issues, especially with privacy : you can track precisely which user has listened to what etc. Some hosting services/podcasters already do it, some listeners won't care, some will not like this.

[douglaskastle]

Earlier in this thread, people are writing about producing dynamic, personally-crafted RSS feeds for everyone. https://medium.com/acast/an-ode-to-rss-and-a-toast-to-the-future-e181a9f65a39 is Acast selling exactly this.

Jebus! I have been thinking about this for years, the day I mention it online there is a article and product doing just that!

I also had been looking at it though as a curated feed. You might be delivered suggested podcast episodes from a variety of different podcasts delivered into one feed based on some aspect of preference. I am sure it could be widely abused, but driving new podcast discovery right inside your own podcatcher, and that would be a service providable in any podcatcher as is.

[keunes]

your own personally crafted RSS feed. This is when the podcast client detects the redirection to a RSS feed and understand this is an update of the feed which you clicked on the button. If you use a redirect url to open the premium feed into the app, it should compare the uuid to update the existing feed instead of adding a new one

Without knowing the tech details, I'm just thinking this might be tricky. E.g. quite a few FOSS enthusiasts combining AntennaPod and Gpodder.net are already faced with duplicate feeds (because the URL is different, or mal-redirected). I imagine the same would be true for (many) other client-server combinations. This makes it arguably less backwards compatible (compared to more generic authorisation mechanisms which might not have this issue). And indeed there's the privacy issue @PofMagicfingers mentioned. And I'm wondering: would I still be able to share my OPML file with my parents to get them started with a great set of podcasts? Or will half of the links don't work because they're personal to me?

For the podcaster, they’re also safe in the knowledge that each paying member’s private feed is unique to them, which — along with plenty of other security measures — protects against piracy. Acast firmly believes that podcasting, both now and in the future, should remain open and accessible to all.

Dynamic RSS sounds super interesting. But this somehow reads to me as (technically) incompatible. I.e. what does an open feed contain if it's tailored to every individual user?

[PofMagicfingers]

quite a few FOSS enthusiasts combining AntennaPod and Gpodder.net are already faced with duplicate feeds (because the URL is different, or mal-redirected). I imagine the same would be true for (many) other client-server combinations.

There should not be any issues with duplicates : premium feeds are not meant to be part of public catalogs/directories. Well in fact, it is a current issue, that some directories are indexing premium/private feeds. But that's a discussion for another topic ( #179 could help maybe? )

In the authentication flow I'm describing, the podcast client itself is opening the provider website for you to login, and it gets back the user tailored rss feed, and replace the generic one with the premium one. Therefore the podcatcher cannot be confused between the 2 urls, because it is itself that is requesting the latter one.

This makes it arguably less backwards compatible (compared to more generic authorisation mechanisms which might not have this issue).

Well, the flow I'm describing is using in the end, current authentication mechanism (either http auth or a secret token in the premium feed url). It's just an UX improvement allowing to jump from a generic feed to a user specific premium feed from within the podcatchers, without having to remove and replace the feed url.

And indeed there's the privacy issue @PofMagicfingers mentioned. And I'm wondering: would I still be able to share my OPML file with my parents to get them started with a great set of podcasts? Or will half of the links don't work because they're personal to me?

All links will still works, but they're tied to your "user". It's already the case when you share an OPML with, for example, a patreon exclusives rss feed.

[keunes]

premium feeds are not meant to be part of public catalogs/directories. the podcatcher cannot be confused between the 2 urls, because it is itself that is requesting the latter one.

I was referring to duplication with internal syncing, not indexing in public catalogs. I.e. if I am subscribed to a podcast, it gets updated to a private version in the database by AntennaPod as you describe, gpodder.net might not recognise this 'change' and add the private feed as an 'extra' feed. The mechanism with UUID recognition should be present in all clients/private servers in order for this to work in all cases. I don't think that's realistic, and as far as I can see it'll be a breaking change for the users of such 'legacy' systems (whereas tags would be less breaking).

the flow I'm describing is using in the end, current authentication mechanism (either http auth or a secret token in the premium feed url). It's just an UX improvement

I agree the UX flow is nice. My point is that the authentication happens on feed level – I don't see why it shouldn't happen on file level. If authentication happens on file level (even with the UX you describe)

• the feed remains the same (no clients or private servers have to implement feed-replacing/changing mechanisms) and
• differentiation between users happens on client level based on tags in the feed (support for tags should be implemented by clients).

All in all: I see that Personal feeds/Dynamic RSS can offer cool new things. But it is not required to achieve premium feeds (topic of this issue). And my gut feeling is that it's more work for developers and more breaking than including support for hiding/displaying feeds based on tags (e.g. enclosure). So maybe personal/dynamic RSS deserves its own issue?

[jamescridland]

One issue has come up as part of the Spotify Paid Subscriptions today - here's a snippet from Podnews later:

• Listeners can't buy a paid subscription to your podcast in the Spotify app. (If they did, Apple and Google would want up to 30% of the money). Instead, they'll get taken to an Anchor web-page, and listeners will be asked to enter their credit card details. For Apple listeners, it's as simple as buying an app.

Worth just bearing in mind that, therefore, the UX is likely not to include podcast apps - merely a link to subscribe.

Also worth bearing in mind that podcast developers need paying too, and if we expect them to write this code, we might wish to consider how they can benefit.

[PofMagicfingers]

gpodder.net might not recognise this 'change' and add the private feed as an 'extra'

I'm sorry, I don't use AntennaPod and gpodder... But right now, if you are subscribed to a feed on your app, and edit that feed to update its URL, or if the feed redirects you to a new one, what does happen in gpodder? If gpodder duplicates the feed, maybe it's an issue in the sync system between them.

If we design a new system/ux for premium subscriptions, yes it will work better with apps supporting it. I can't imagine AntennaPod implementing the new premium feed system, and forgetting to take gpodder sync into account...

Right now, if I'm listening to a podcast and it has premium episodes... if I pay for it, they will give me a new secret rss feed, and I'll go to my podcast app, and I'll edit that podcast subscription to change the URL. Or maybe I'll delete the old one and add the new one.

In either case, I'm describing exactly the same thing but paying is inside the app if supported and RSS url update is done automatically if supported.

I don't see why it shouldn't happen on file level. I don't see why it should happen on file level : you will most likely only have only one account on the podcaster/hosting website... I don't see why you would authenticate for each premium content.

If you're offering a pay-per-episode podcast, you will still be able to purchase the episode, it will be linked into your account, and updating the feed makes appear the new premium episode you bought 🤷 You will anyway have an auth to do per feed, or per hosting service...

The UX I was describing is just an idea, maybe the auth mecanism can be something else, maybe we can imagine a Authorization header supported by apps and servers, allowing them to get the user purchased content in the feed on the fly.

• differentiation between users happens on client level based on tags in the feed (support for tags should be implemented by clients).

I strongly disagree on this one. As a hosting company I'd rather include only what the user is requesting than all episodes "just in case" they have bought one.

Netflix is only showing you shows and movies you have access to, not the whole catalog, filtered on client side.

If you go to an onlyfans page, they do not include all pictures hidden or encrypted on the page, and unlock them when you pay 😁

[douglaskastle]

If you go to an onlyfans page, they do not include all pictures hidden or encrypted on the page, and unlock them when you pay

The porn guys figured this stuff all out years ago, we should be looking at them to see what they do ... is the excuse I'll be using if my wife catches me on one of their sites.

[agates]

I don't really see what any of this has to do with the Podcast Namespace?

[PofMagicfingers]

I think we're discussing the best way for a rss feed to advertise to podcast client that a premium version is available, with tags.

[agates]

That sounds like a terrible user experience and asking applications to implement it would be a tough bargain when they don't gain anything, doesn't matter how good the standard is.

The podcaster can announce it in the podcast/description itself and they have done so for a long time.

Alternatively, allowing the user to actually reward the podcast in real time while listening is already there, no?

[PofMagicfingers]

asking applications to implement it would be a tough bargain when they don't gain anything

Well, they already show funding links without gaining anything.

But as I said before, I think this should be taken care of on server / hosting side, with custom rss feeds, like everyone is already doing right now.

I don't really think all app developers would be keen to implement a whole pub/priv key DRM system on each app.

[theDanielJLewis]

• You can technically serve the free content when no login/password is used and switch to paid content when you enter a login/password

Can we? I think the best user experience is to default to the public view, with a login button that can appear when the feed contains exclusive content, for example, "log in for exclusives."

we already have hundred of premium subscriptions podcasts in the wild

Yes, but they're 100% exclusive, not the hybrid model I'm proposing where logging in grants access to content already in the feed. Users should not have to resubscribe.

per user RSS feeds

IMHO that's the way to go. You can have a main guest feed, and users subscribing to exclusive content get their own RSS feed.

This already exists for years. I think Wishlist Member was the first highly available publishing tool to allow it. But it's a total pain for users. Again, users should not have to resubscribe.

That sounds like a terrible user experience and asking applications to implement it would be a tough bargain when they don't gain anything, doesn't matter how good the standard is.

That's why I started this suggesting a way app devs can benefit and take a reasonable cut (maybe 5–10%).

I'm absolutely anti-DRM. I think that provides way too many complications for everyone.

[daveajones]

If we go down this road, I would aim for a solution like SQRL uses, with a master key that can be used to derive individual public/private key pairs per subscriber:

SQRL Exaplainer - page 7

I'm not sure it would work any other way.

[chiragnd]

Just had an additional thought; in addition to helping standardise / deliver a subscription podcast or offering across apps vs being tied to a single one, this would also promote discovery.

A subscription podcast today cannot even be listed in the directory or be searchable. The only path is through the ‘free’ show or member program that then showcases the private feed/s a creator has available. Having subscription support built into the index would allow shows to be listed even if member-only, and of course enable subscription via the lightning block even down the road.

While on this, might give a shoutout to @daveajones for this week’s Podcasting 2.0 episode. The note about ad-free being premium definitely was a 💡moment

[theDanielJLewis]

A subscription podcast today cannot even be listed in the directory or be searchable. The only path is through the ‘free’ show or member program that then showcases the private feed/s a creator has available. Having subscription support built into the index would allow shows to be listed even if member-only, and of course enable subscription via the lightning block even down the road.

Yes, this is what I'm hoping we can make: a single RSS feed that can be listed in any podcast app, but that Podcasting 2.0 apps will be able to unlock the exclusives.

[agates]

I think standardizing on use of Authorization headers might be a good start. A standard way of token retrieval would be even better. This would allow use of traditional auth services and potentially even something like #355 for lightning payments.

EDIT: @daveajones, I know we discussed JWTs elsewhere, was that in another repo?

[daveajones]

Not yet. I haven’t written that proposal up into the namespace docs yet. Still trying to figure out how it relates the podpass system we found.