Proposal: <podcast:private>

[aegrumet]

When developing podcast playback applications, it's helpful to know whether an rss feed is intended to be public or private. Two particular use cases are worth noting:

1. Background attempts to match the rss feed with a podcasting 2.0 guid. This should be skipped if the feed is known to be private.
2. UI that offers to "share this show" or "share this episode". These should be hidden if the feed is known to be private, unless we have a way to offer the public version of the show or episode.

The proposal is to create a channel-level tag

<podcast:private publicFeedUrl="someUrl">Yes</podcast:private>

• The tag is either Yes or No.
• publicFeedUrl may optionally set to help with the sharing use case.

By itself this would help a lot with application development.

Optionally we could go deeper...

Episode Sharing

If we want to share an episode from a private feed that has a public version, how should we designate which episode? One option is to suggest that publishers use the same item guid for both. That seems simplest, and is what I'd recommend.

A more complex option would be to specify an item-level version of podcast:private.

Additional Considerations

We could also recommend that private feeds having a public version, set podcast:guid to their public feed to help with sharing. Specifically, an application could resolve the podcast:guid to the public feed, as opposed to looking for a publicFeedUrl attribute. This might be easier to maintain for podcast publishers.

[Dwev]

I like the idea of having something in the index, even for a private feed, and maybe the "additional consideration" solves that.

For example, I see this as useful with audiobook medium feeds, where the public side can be a sample chapter or promotion, and the private feed is the full audiobook (for premium / paid access). The index would pickup the public feed with all the relevant meta data.

[samsethi]

Captivate support Private Feeds not sure which other hosts do? TrueFans will support this Private tag as we want to enable private feeds. I agree with @aegrumet, we will disable the copy/share options in the UI.

However, for premium content, there are two solutions.

1. Make the premium content a private feed, but this has the issue that a private feed can be shared, and then the premium content is no longer safe. This is the weakness with Patreon and Memberful. - Pay Once, Copy Everywhere

2. PodToo and TrueFans have developed SecureRSS using L.402 - this means the assets of the RSS feed can still be published and displayed by any app but the enclosure content is encrypted. So, TrueFans disable the play button and it only works when the payments have been confirmed. However, if someone tried to copy the RSS feed before payment, the enclosure is still encrypted, so they can't just copy the MP3 like Patreon/Memberful) and play it without paying.

But combining SecureRSS and Private Feeds would be double protection. Note the price for a SecureRSS file can be zero.

[fritz-fritz]

@samsethi L.402 is interesting but I can't see details of SecureRSS anywhere (I presume this is proprietary). After looking at it, I would guess that SecureRSS w/ L.402 works by implementing both server and client side code and that clients that don't handle the 402 response body would simply not have access. I'd note that the enclosure content is not encrypted here with L.402 alone just simply not served until payment is confirmed. I presume since this would require custom client support, you would indeed encrypt the audio file that is served and use the data from the L.402 flow to decrypt the file in memory on playback so as to preserve the protection on device. This is a novel but proprietary design which locks podcasters/listeners to a host/client for the premium feed. What would be the benefit of this over say applying DRM to the file which the client knows how to unlock?

[nathangathright]

I really like the idea of accommodating podcast sharing, both show and episode levels, but I wonder if it’d be better to handle that with a separate tag. Maybe something like a <podcast:canonical> tag at both the channel and item levels where private feeds can link to the public feed/GUID?

<item>
  <podcast:canonical>
    <podcast:remoteItem
      feedGuid="917393e3-1b1e-5cef-ace4-edaa54e1f810"
      feedUrl="https://feeds.example.org/917393e3-1b1e-5cef-ace4-edaa54e1f810/rss.xml"
      itemGuid="asdf089j0-ep240-20230510"
    />
  </podcast:canonical>
</item>

[theDanielJLewis]

I like these ideas. I only worry that it's a lot of special development for very little audience-facing benefit or use.

[fritz-fritz]

I'm running a private and unlisted podcast for a group. I put the feed (and api) behind basic auth and generate tokens for each episode that bypass the basic auth. The channel link is to the auth page. This way the feed rss doesn't contain the basic auth credentials and share buttons from episodes give access just to that episode's web page/player. It works pretty well for this particular group's needs.

Sharing the podcast channel lands the recipient at the auth page for some clients, is refused by others, and unfortunately includes the basic auth on certain others. Apple Podcasts shares the feed url without the auth which would let me serve a public feed at the same url if desired.

Additionally, we already have the <podcast:block> tag which should hint towards if it could be indexed. For a private feed I would expect this to be set to all aka <podcast:block>yes</podcast:block>.

I'd suggest sharing the channel or item <link> if block is yes or just disabling entirely.

I think running a private feed (whether unlisted, or authenticated) would still ultimately have the same issues if this proposal were adopted as many clients would simply not implement it. Restricting access is probably best to be tracked/managed at the host by watching for abuse of tokens or impossible travel.

While it would be nice if everyone could be on the same page with these tags, I think the problem is we simply can't force clients to respect this proposed tag. The sharing functionality can mostly be handled server side and so introducing this doesn't gain much.

[aegrumet]

Good points. Sharing item <link> is a great idea for fallback when the feed has a block tag. Thanks for that suggestion!

It'd still be nice to have a way to provide an alternate public/shareable feed, e.g. for podcasters publishing both public/ad-supported and private/no-ad feeds, which is common.

Amending <podcast:block> to support that, could also work.

[aegrumet]

Also worth noting that <podcast:block> has per-platform semantics, which complicates things a bit. One option is to just ignore the platform variants and only look at the main block tag. The alternative would be to first prompt the user ("Which platform are you sharing to?") and then proceed accordingly depending on the contents of the tags. But that's not a particularly good user experience. I think this boils down to a partial venn diagram overlap between existing tag's intent and the public/private sharing case outlined in the original post.