Subscription-only episodes

[borja-rojano]

Here's an idea on how we could agree on a format that would allow podcasters to sell subscription-only episodes. The best way to explain this idea is to describe the whole journey of a podcaster to getting paid by her listeners.

1. Jane Podcaster hosts her podcast in provider Host. She marks her back catalog as subscription-only and sets a price of $4,99/month for access to her premium content. She marks the 3 most recent episodes as free.

2. Jane gets a feed at host.com/jane that contains the free content only. She also gets a subscribe page at host.com/support/jane where her fans can easily become subscribers.

3. Jane does her thing and gets a loyal audience who want to support her. She directs people to her subscribe page.

4. John listener wants to access to Jane's back catalog and becomes a subscriber. He enters his mail address in the process. When he does so, he gets his personal feed host.com/jane?user=listener@gmail.com that he can copy.

5. John's private feed contains all of Jane's catalog.

6. John likes to use Client, his favourite podcasting app. Since Client is Syndicated-Media compliant, it accepts private feeds. John pastes the feed in Client and he can start listening to Jane's premium content right away.

That's it, in a nutshell. I suggest using personalised feeds instead of a secret premium feed that is the same for all subscribers for two reasons:

a) It allows different levels of subscriptions up to selling individual episodes.

b) Piracy: clients can limit the use of a given private feed to one single listener, so you avoid having people paying once and reusing the feed over and over.

I am very curious to read your thoughts.

[borja-rojano]

Some further points, based on initial reactions not recorded here:

Friction
Yes, there is a back-and-forth between the Client and the Host. It would be great, as a listener, to pay as an in-app purchase in my favourite podcast client. However, for the podcaster this is impractical since by definition there are plenty of clients but only one host. To get paid by a multitude of clients can be a logistical nightmare.

A second note regarding friction is that we are talking of highly, highly motivated listeners who are willing to put effort into supporting their favourite podcaster. I don't think they will be turned away by one extra step. Yes this system is not perfect but I think is far better than using patreon or, as Dan Carlin does, selling the episodes via iTunes as music.

This brings me to think that this model would be much more suitable for subscriptions than selling individual episodes. Yes there is friction but once you are subscribed, the rest of the process is exactly the same as normal podcasting, since the RSS feed works as any other feed.

The role of podcast clients
With this model, all a podcast client app needs to do is accept private feeds. These are feeds a user can paste and subscribe to, but -this is important- they do not get added to the directory of publicly available feeds.

[empaempa]

We at acast have been thinking about this as well, as we have our acast+ offer (think app store for podcasts, where publishers freely can set their prices and offers): https://www.acast.com/plus

I think this is interesting but I also think there are other ways to solve this...

[borja-rojano]

@empaempa Hi there, love to see a fellow European team kicking butt.

Yes, I have been closely following your great work. In acast case, however, the selling of episodes is a 'fenced garden' kind of experience, right? The premium content is exclusive to acast, if I understand correctly. In this case, your model is closer to a Netflix for audio than to podcasting itself.

The proposal above is just a starting point, but it definitely respects the open nature of podcasting.

Nice to e-meet you and look forward to reading your thoughts. Keep up the great work.

[empaempa]

Nice to meet you, too! And I'm really interested in what you're cooking :D

Yes, it's walled right now in the sense that you pay using IAP, but technically it's not limited to our apps and something we're working on. We have a POC on how to solve this without modifying the RSS. I'll discuss internally if we're at a point sharing this implementation idea - one day we will, I'm sure :)

Let me get back on that!

[empaempa]

But I agree that clients should respect private feeds - but what is a private feed, how do the app know that?

[borja-rojano]

@empaempa If we'd go for this method in the specification, then it is easy:
host.com/support/jane (no parameter) = public = can be added to directory.
host.com/jane?user=listener@gmail.com (parameter present) = private = don't add to directory.

Then, hosts that allow premium content under this spec would only recommend clients which also work under it.

[empaempa]

@borja-rojano Just tried omny.fm in Overcast (which is indexing RSSes via their server and then serve to their clients) and it's not making my omny-feed available to others. Apple does seem to play nice, too. Do you know any app that doesn't?

[borja-rojano]

@empaempa not until very recently. I thought all clients worked like that but in the Android world there are some clients that add to their directory any feed a listener uses.

However yes, in the case of the clients, the work is mostly done. One powerful feature would be to prominently display a link to the host.com/support/jane page in the client, so listeners are prompted and reminded but this can very well be optional.

[borja-rojano]

Apple does allow you as a listener to add a private feed via the app or, as a podcaster, submit it to iTunes.
In our example above Jane would submit her public feed to iTunes and John would paste his private feed into the podcast app directly.

[borja-rojano]

OK, sorry I did not disclose this before but I was not allowed to. At TapeWrite we are actually going to build a monetisation solution for podcasters, funded by Google. We want to do it in a way that allows listeners to choose whatever podcast client they want to consume premium content and will make sure that whatever we do is compatible with SM spec.

More info here

[empaempa]

Wow, cool, great news! We're also, as mentioned, working on a variant of private feeds to allow any catcher to be used. Just like you do, we let the publishers set prizes, perks and own their audience. I think this is the way to go.

[borja-rojano]

That is so cool @empaempa! Does acast accept private feeds that a listener can paste in the app? Does that feed become public then?

If we manage to find a way to standardise monetization while keep the format open it will be amazing.

[empaempa]

We've discussed private feeds and think that cache-control header on the response could be a good way to differentiate private from public. So...

"Cache-Control": "private, max-age=0, no-cache"

...(or similar) would signal a private-don't-index-for-search-feed. Feels more appropriate and future-proof than taking the decision on a query. What do you think?

[Cj-Malone]

How's this different from iTunes block tag?

[empaempa]

Good idea, that would work as well. Maybe, for the sake of it, SM should have a similar tag?

[cqr]

@Cj-Malone itunes:block is specifically about blocking iTunes, by design. There are other uses for that, besides private feeds (feed that are specifically for stitcher, google play, or maybe all other podcatchers, for instance).

I think a general block or private tag is necessary.

[empaempa]

<sn:private> maybe?

That said, this kinds of important tags that are dependent on client implementation probably need fallback methods (like <itunes:block> and no-cache header and a query to work across the board in the foreseeable future.

Also, you should implement some sort of server-side protection on private links to prevent them from going viral - there are multiple ways of doing this but not in the scope of SM.

[ziggythehamster]

A simple solution which solves the problem of needing to be blocked by indexers would be to require HTTP authentication. This still results in a copy-pasteable URL for a user to subscribe to paid content in their podcast app:

https://listener%40gmail.com:1784c823b0b27db2757f01d1f74a982b@rss.example.com/podcast.rss

The Cache-Control header can be further used to let intermediate proxies know that this is private, uncacheable content. Indexers and crawlers will ignore these RSS feeds without having to become aware of a new standard.

The barrier to entry here is also pretty small, because most HTTP libraries in use will parse this URL exactly correctly and do the right thing out of the box.

[empaempa]

Wouldn't it be possible that some indexers simply use the supplied URL, which includes the login details, and index it?

[benzimmer]

@empaempa Yes, they do (at least they did when we tested this 2 years ago). Perhaps time for another round of testing.

[empaempa]

Yes, I believe this is impossible to fix using a standard tag-, cache- or authentication-method. In the end, it's up to the platform to make sure the private link isn't consumed by non-authorized parties.

That said, we in this group can and should agree on either a cache-rule or a tag to mark a feed as private.

I vote for <sm:private>

[timpritlove]

A personalized feed model would be a boon for podcasters and they have been used here and there with mixed success. Giving out a personalized URL or using HTTP authentication for this however has been a problem as in the last years more and more podcast clients...

• rely on a cloud model, checking feeds centrally
• storing authentication data centrally (bad idea)
• automatically add feeds to a public directory

A solution to this approach could be to define a HTTP Header that podcast clients can use to access a public subscription feed. In this header, a client can pass a secret that acts as an identifier for a user. This identifier needs to be added to the client once but must never be stored in the cloud.

This approach has many advantages

• podcasters can use a single podcast feed URL for all paid customers and everybody else
  • this means no conflict with public podcast directories and no problem finding the right feed
• any existing subscription can be turned into a paid subscription by entering a single code once per device
• no changes to the feed necessary
• the backend delivers different content just based on the existence of the secret in the HTTP request
• an optional feed element could signal the availability of a paid subscription to a podcast client
  • an optional URL allows the client to direct the user to this upgrade opportunity, possibly receiving the secret automatically in this process (tbd)
• no private data (e-mail addresses etc.) are stored in either the feed URL or the client.
• expiration of paid subscriptions can be completely controlled on the server side, clients needs not to know anything about customer relationship, expiries etc.

[ziggythehamster]

I wouldn't advocate for a new header, but I like the idea of the private subscription feed just being a variant of the public URL. Authorization is the right tool for the job. We would just have to decide on an authorization scheme. The feed could have a tag that tells clients what authorization schemes are supported so that compatible clients know what to do.

<sm:private-subscription-available> in the top level of the RSS feed, with <sm:authorization-scheme type="oauth2" whatever-extra-data-is-needed-for-the-scheme="goes in this tag" /> inside it?

[timpritlove]

If you enforce HTTP authorization then the feed can't be the public feed. A HTTP header is easy to add and all it needs is a user identifying string being passed as value. It is a very simple, easy to add feature: one string, done.

If you come up with complicated auth schemes that need interaction and complicated implementation it will only lead to no client supporting it or not supporting it properly. I don't see where OAuth or simple HTTP authentication would make any sense.

Maybe you can explain where you see the advantage of your suggestion.

[ziggythehamster]

A client can omit Authorization while an endpoint remains public (and returns different data, this is known as a variant).

Adding specialized non-standard HTTP header fields when the standard includes suitable header fields is not a good idea. Intermediate proxies may mishandle your header. You won't be able to get any benefits from technologies like SDCH. There is no standard way to extend the system, so you have to devise your own (but this already exists in the HTTP spec).

If you want to provide a single string to authenticate a user, that's Authorization: Token foo. That might be sufficient security for many providers, but it might not be for others. And I actually see where it might differ across a provider. For example, we might have a customer that wants to federate all private subscription logins through their OAuth system, and another who is totally fine with token authentication. The SM spec should be flexible and support both, or any other scheme that nobody has thought of (Windows Hello?). By deferring to HTTP Authorization, the SM spec only needs to deal with providing hints to the client about how to authenticate.

[empaempa]

Need to add the perspective that most listeners use the Apple's Podcast-app. To get any client-support from Apple feels a bit far fetched. The scheme we cook up here need, in my opinion, be a server-side-only-solution or it won't be practically viable for a long time.

To me, the goal is to signal dont-cache-or-index-for-search. <sm:private>, <itunes:block>yes</itunes:block> and "Cache-Control": "private, max-age=0, no-cache" should work if used in concert.

How you prevent users from sharing the private link is outside of this discussion.