Proposal - <podcast:remoteItem> tag

[agates]

Proposal: <podcast:remoteItem> tag

The intent of this proposal is to provide a tag that allows another item to be referenced without outright copying it outright. This should be an item in another feed entirely.

Cross-app playlists

This allows one to provide lists of other items which one does not own copyright to, such as playlists of various different types of audio/video mediums. In combination with list mediums, one can use a feed made entirely of <podcast:remoteItem> tags and share them in a manner that allows applications to recognize them as playlists.

<rss xmlns:podcast="https://github.com/Podcastindex-org/podcast-namespace/blob/main/docs/1.0.md" version="2.0">
    <channel>
        <title>My favorite v4v music</title>
        <description>This is a playlist of some of my favorite v4v music</description>
        <link>https://example.com/rss-music-playlist.xml</link>
        <docs>http://blogs.law.harvard.edu/tech/rss</docs>
        <language>en</language>
        <generator>Alecks Gates wrote this by hand in Joplin</generator>
        <pubDate>Thu, 27 Oct 2022 22:56:54 -0500</pubDate>
        <lastBuildDate>Thu, 27 Oct 2022 22:56:54 -0500</lastBuildDate>
        <podcast:medium>musicL</podcast:medium>
        <podcast:remoteItem itemGuid="https://podcastindex.org/podcast/4148683#1" feedGuid="a94f5cc9-8c58-55fc-91fe-a324087a655b" />
        <podcast:remoteItem itemGuid="https://podcastindex.org/podcast/4148683#3" feedGuid="a94f5cc9-8c58-55fc-91fe-a324087a655b" />
        <podcast:remoteItem itemGuid="tag:soundcloud,2010:tracks/319791095" feedGuid="a5ad6f3f-a279-504c-bc6a-30054e6b50e1" />
        <podcast:remoteItem itemGuid="tag:soundcloud,2010:tracks/319789777" feedGuid="a5ad6f3f-a279-504c-bc6a-30054e6b50e1" />
    </channel>
</rss>

Cross-app clips

Using a the same concept as playlists, one can combine the <podcast:remoteItem> with <podcast:soundBite> to share user-generated clips as RSS feeds and similarly share them with in a manner other apps can recognize them as such.

<rss xmlns:podcast="https://github.com/Podcastindex-org/podcast-namespace/blob/main/docs/1.0.md" version="2.0">
    <channel>
        <title>agates' public clips on Podverse</title>
        <description>This is a playlist of podcast clips created by agates on Podverse</description>
        <link>https://podverse.fm/profile/ZTfsvQRLw</link>
        <docs>http://blogs.law.harvard.edu/tech/rss</docs>
        <language>en</language>
        <generator>Alecks Gates' handwritten python</generator>
        <pubDate>Fri, 20 May 2022 20:15:00 -0500</pubDate>
        <lastBuildDate>Fri, 20 May 2022 20:15:00 -0500</lastBuildDate>
        <podcast:medium>podcastL</podcast:medium>
        <podcast:remoteItem itemGuid="PC2040" feedGuid="917393e3-1b1e-5cef-ace4-edaa54e1f810" medium="podcast">
            <podcast:soundbite startTime="3707" duration="36">It was longer than a Glenn Greenwald article ... but I read this all the way through and enjoyed it</podcast:soundbite>
        </podcast:remoteItem>
        <podcast:remoteItem itemGuid="PC2077" feedGuid="917393e3-1b1e-5cef-ace4-edaa54e1f810" medium="podcast">
            <podcast:soundbite startTime="3834" duration="44">Adam Curry: The reason why we even can discuss this is because we have no business</podcast:soundbite>
        </podcast:remoteItem>
        <podcast:remoteItem itemGuid="PC2047" feedGuid="917393e3-1b1e-5cef-ace4-edaa54e1f810" medium="podcast">
            <podcast:soundbite startTime="1515" duration="177">Jack Dorsey: Business models enabled by bitcoin</podcast:soundbite>
        </podcast:remoteItem>
        <podcast:remoteItem itemGuid="Buzzsprout-9880236" feedGuid="396d9ae0-da7e-5557-b894-b606231fa3ea" medium="podcast">
            <podcast:soundbite startTime="1844" duration="33">"Linux" Unplugged shout out</podcast:soundbite>
        </podcast:remoteItem>
    </channel>
</rss>

Definition

• <podcast:remoteItem itemGuid="(guid of the item referenced)" feedGuid="[guid of the feed referenced]" medium="[medium type]" />
  Channel (optional | multiple)

  This element defines a remote item. One or more may be defined per channel.

  It refers to an item outside of the feed. This should only be used for "list" medium types . This should not utilize any value-related tags contained within the feed. Only the value tags on the referenced feed should be respected.

  • itemGuid (required) - The <guid> of the referenced item. If an item does not have a <guid>, it cannot be referenced.
  • feedGuid (required) - The <podcast:guid> of the referenced item.
  • medium (optional) - The medium of the referenced item. The list of allowable values is maintained in the <podcast:medium> specification. If not set, the default non-list medium type of the the feed the tag is defined in is assumed. Cannot be mixed. This allows an application to determine its capability of how to handle the referenced item.

Future stages

There's a lot of potential to use this to reference items for other reasons besides playlists and clips. This could go under some kind of <podcast:related> tag, to reference items within the same feed or outside of the feed. Combining it with with a to-be-defined <podcast:channel> is also a possibility.

Citations

<podcast:guid>00000000-0000-0000-0000-000000000000</podcast:guid>
<item>
  <guid>SomeEpisode</guid>
</item>

<podcast:related>
    <podcast:remoteItem itemGuid="SomeEpisode" />
    <podcast:remoteItem itemGuid="PC20107" feedGuid="917393e3-1b1e-5cef-ace4-edaa54e1f810" medium="podcast" />
</podcast:related>

References

It might also allow multiple items to be linked within the same feed in a way that does not otherwise fit within a structured season, such as a live stream of a podcast and an edited version of the same content.

<podcast:guid>00000000-0000-0000-0000-000000000000</podcast:guid>
<podcast:medium>video</podcast:medium>
<podcast:liveItem>
  <guid>SomeLiveEpisode</guid>
</podcast:liveItem>

<podcast:related>
    <podcast:remoteItem itemGuid="SomeLiveEpisode" type="live" feedGuid="00000000-0000-0000-0000-000000000000" medium="video" />
</podcast:related>

[ryan-lp]

This allows one to provide lists of other items which one does not own copyright to, such as playlists of various different types of audio/video mediums.

Is a playlist a "derivative work" under copyright law?

Spotify's playlists might be legal only because their terms of service contain this clause:

You retain ownership of your User Content when you post it to the Service. However, in order for us to make your User Content available on the Spotify Service, we do need a limited license from you to that User Content. Accordingly, you hereby grant to Spotify a non-exclusive, transferable, sub-licensable, royalty-free, fully paid, irrevocable, worldwide license to reproduce, make available, perform and display, translate, modify, create derivative works from, distribute, and otherwise use any such User Content through any medium, whether alone or in combination with other Content or materials, in any manner and by any means, method or technology, whether now known or hereafter created, in connection with the Spotify Service. Where applicable and to the extent permitted under applicable law, you also agree to waive, and not to enforce, any "moral rights" or equivalent rights, such as your right to be identified as the author of any User Content, including Feedback, and your right to object to derogatory treatment of such User Content.

Penalties for music copyright infringement are quite hefty.

Putting that issue aside, you might also want to specify the intended usage of this tag. For example, podcast apps should probably present the metadata of the remote feed, including the author, link, and any funding and value tags.

[jamescridland]

Is a playlist a "derivative work" under copyright law?

Compilation CDs are copyright, or at least the record companies think so. The case didn't go to trial in the end, and legal opinion is unsure about what would have happened. But a "database" is most certainly copyrightable, and an RSS feed is probably a database in the eyes of the law.

Back to podcast:remoteItem - perhaps a use-case for this is Podnews's New Podcast Trailers, which is an RSS feed consisting of trailers for podcasts. I include all their episode notes, link directly to the audio itself, and show the artwork in the feed. Notwithstanding that, Apple didn't want to list the show, since it contained other peoples' copyrighted material (which is correct, it does). I wasn't expecting it to get into Apple Podcasts, to be honest, which is why I asked them to review it.

I'm a little unsure how podcast:remoteItem does anything different other than the RSS feed for New Podcast Trailers. In one sense it allows the creator more control - they can remove the episode item from their own RSS feed and it automatically disappears from here - but they can still remove the audio file anyway.

[thomasrynne]

If this tag is used to create playlists only podcast apps that support the new tag would be able to use the play list. In RSS terms the feed would be completely empty. I think so far the new podcast namespace tags have been enhancements to a working RSS feed but as described this tag would lead to an unusable feed for most people. Perhaps the remoteItem tag should go inside the normal item tag, with fallback behaviour defined within the item tag?

I do like the idea of directly linking to podcast episodes but I see that was raised in #304 so perhaps this is only for playlists?

[jamescridland]

https://podnews.net/sitemap/trailers-ri.xml is a fully-working, daily-updated example feed for those wanting to test.

It's a feed of new and notable podcast trailers from Podnews. (That page contains a standard RSS feed with full enclosures).

My experience building it was relatively simple: but I would say that the standard RSS feed allows me to make a consistent list of shows, with a description that explains why individual shows have been chosen, including individual artwork items.

I don't believe that any copyright is being infringed in my standard RSS feed since the audio enclosure link points to the individual item. However, it might be interesting if people want to play with the remote:item tag to have a version that fully works (and that contains some weird-looking GUIDs!)

[daveajones]

https://podnews.net/sitemap/trailers-ri.xml is a fully-working, daily-updated example feed for those wanting to test.

Thanks for doing this James.

[paulerskine]

I heard this discussed on Podcasting 2.0 Ep 108 this week and curious if the following three items would need to be addressed:

1. Value-related tags. While I know the proposal indicates no value-related tags, they were discussed on the show. It was discussed a podcast could indicate "#%" goes to a remote link. Assuming the % would be split amongst all links, what happens when fractions of Sats are needed. Simple example: Podcast is set to 1% to remote links, podcast earns 100 Sats, and there are two links to that podcast, what happens? Can each receive 0.5 Sats? I know having two links to a podcast that earns 100 Sats is probably not realistic, but the something like this could happen at a larger scale. I bring this up because if there is a promise of "money" from one entity to another, and then that money doesn't show up or only a portion shows up, a legal issue that could arise. This may be a good reason to go with the definition and not include any value related tags.

2. Circular References / Infinite Loops. What happens if you have two feeds that reference each other (A -> B and B -> A)? Is this just something the podcast players would need to deal with? More complicated is if they're referenced through a few podcasts (A -> B -> C -> D -> A) or even an odd internal reference (A -> B -> C -> D -> B).

3. Block Tag validation. Let's say a Podcast A has Hosting Service 1 blocked in their feed but Podcast B, which references A, is served by Hosting Service 1, what happens? This again gets more complicated in the A -> B -> C -> D link where any one of them could have a block tag that would need to be honored.

None of this is to say this is a bad idea, just items I'm wondering if they need to be thought about.

[jasonyork]

I've been interested in this proposal for a while because I think it would fit well with my podcast sharing app. So, as a test, I built out an alternate feed generator to use remoteItem, similar to what @jamescridland did above.

I made a sample feed available here:
https://podshare.fm/feeds/7hxJB.remote.rss

The "standard" version of the same feed is here:
https://podshare.fm/feeds/7hxJB.rss

Implementing this on the producer side was pretty easy, but thinking about parsing this feed on the consumer / player side I had a few thoughts:

By only providing the feedGuid, it almost always requires the client to hit the podcastindex.org API to find the episode and/or keep a local db of podcasts. A slight change to the proposal could provide the feedUrl as a required attribute, along with the feedGuid as a recommended attribute. This gives the client the ability to fetch the feed directly to find the item if/when it is necessary and not necessarily require a dependency on the API. For example:

<podcast:remoteItem itemGuid="PC20117" 
                    feedUrl="https://feeds.podcastindex.org/pc20.xml"
                    feedGuid="917393e3-1b1e-5cef-ace4-edaa54e1f810" />

Similar to @thomasrynne 's comment above, it does seem odd to have a separate feed just for a playlist. Ideally, this would be an enhancement to a "regular" feed. An end user likely won't know if their player supports this tag so for my use case it's difficult to provide two versions of the same feed and make sure the user picks the correct one. Or maybe there would be a way to provide and "alternate source" tag in the primary feed that links to the "media list" version?

When a client does need to hit the podcastindex.org API to resolve the list, I could see a potential need to allow the client to supply a list of item and feed Urls/GUIDs for search so an entire list could be resolved with one request. Otherwise, if you have a feed with 50 remoteItems it's 50 hits to the API. Maybe that's premature optimization, but something to keep in mind.

Does anyone know if a player/client has attempted to implement this yet? I think a lot would be learned about the feasibility of this proposal once it's attempted in a real client. Thanks!