Proposal - <podcast:remoteItem> tag #481
Replies: 11 comments 6 replies
-
Is a playlist a "derivative work" under copyright law? Spotify's playlists might be legal only because their terms of service contain this clause:
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. |
Beta Was this translation helpful? Give feedback.
-
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 I'm a little unsure how |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
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!) |
Beta Was this translation helpful? Give feedback.
-
Thanks for doing this James. |
Beta Was this translation helpful? Give feedback.
-
|
I heard this discussed on Podcasting 2.0 Ep 108 this week and curious if the following three items would need to be addressed:
None of this is to say this is a bad idea, just items I'm wondering if they need to be thought about. |
Beta Was this translation helpful? Give feedback.
-
|
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 I made a sample feed available here: The "standard" version of the same feed is here: 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 <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! |
Beta Was this translation helpful? Give feedback.
-
|
I agree the feedUrl seems ideal, so the remoteItem can be fetched directly from the feed itself without reliance on the Podcast Index. I would also like to see something like enclosureUrl as a way to fetch the media file directly without needing to go to the feed. This allows for immediate playing of the file while the other resources are being fetched. So something like this, The potential issue I see with this is broken links if the podcaster or musicians moves their feed or files to a different host. |
Beta Was this translation helpful? Give feedback.
-
|
For those that are creating an alternate feed with a remoteid-only feed several questions
|
Beta Was this translation helpful? Give feedback.
-
|
@geeknews - I created the feed more as a proof-of-concept that could be used by someone updating an app to consume this type of feed. As far as how a "master" feed would reference a remote-id feed - that's a good question. I don't even know if that would be the desired intent. |
Beta Was this translation helpful? Give feedback.
-
I coded it as a weekend relaxation project, and to give this group something to play with
It isn't designed to, as far as I'm aware. They're separate feeds (and/or items). In this case, my remote feed RSS feed does exactly the same job as the full RSS feed - both link directly to the audio from a third-party podcaster. Advantages with my technique of linking directly to the audio are: Advantages with the remoteItem feed: I must be honest, I don't see the use-case for this feed format at all. |
Beta Was this translation helpful? Give feedback.
-
|
What is the advantage of remoteItem over having hosts resolve remote items serverside and generate normal item item tags (as @jamescridland demonstrated above)? |
Beta Was this translation helpful? Give feedback.
-
|
I think it's an ownership thing. It's one thing to create a link to someone else's file. It's another thing to take the items out of their file and paste them into your file. I'm not sure how any copyright laws would effect it. |
Beta Was this translation helpful? Give feedback.
-
|
In fact, playlists are also subject to copyright, just as any database is. |
Beta Was this translation helpful? Give feedback.
-
|
I wonder if a list of links that point to the different sources would be considered a playlist and subject to copyright, especially since a fundamental trait of the internet is linking to different files. |
Beta Was this translation helpful? Give feedback.
-
|
I think the spec should give an indication of when apps are expected to re-resolve the referenced item. Podcast apps already poll feeds but expectations regarding resources referenced by feeds are not clear. The primary motivation for polling a feed is to see new items in the feed. At the same the less common modifications to existing items are noticed. Polling of a feed containing remote items would capture any new remoteItems in the feed, but without an extra step any modifications to the referenced item will not be noticed. In practise, the referenced item is unlikely to change, so there may be a reluctance to add the extra step, but without it a mistake (for example in the value tag) might never be fixed. I don't know what the right balance is though. Perhaps the expectation should be that feeds referenced by remoteItems are polled as if they were a normal subscription |
Beta Was this translation helpful? Give feedback.
-
|
Added to phase-6 branch: https://github.com/Podcastindex-org/podcast-namespace/blob/phase-6/docs/1.0.md#remote-item |
Beta Was this translation helpful? Give feedback.
-
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. 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.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.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 bemixed. 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
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.
Beta Was this translation helpful? Give feedback.
All reactions