Proposal: List mediums

[agates]

Proposal: List mediums

Currently, there exists no canonical, machine-friendly, way to create a list of RSS items outside of a feed without copying the items outright; such copying presents legal issues around copyrights as well as technical "source of truth" issues. OPML exists for lists of feeds, but remains limited to feeds and also has no way of providing machine-friendly metadata about a feed beyond its location and feed type/version.

Shared, publicly available feeds of referenced items (i.e. items not owned by said feed) would offer a means to share lists of content with people while still being available for applications to parse and understand. Such lists already happen every day, but are often limited to websites or emails, providing a poor user experience.

One example of publicly available lists in use today are Spotify playlists, which allow anyone with a Spotify account to follow music curated by others or even curate music in their own lists. This example can and should be able to be replicated directly in Podcasting 2.0 without creating the headache of copyright issues. Similarly, for podcasts, the same problem would be able to be solved allowing one to provide public recommendations of specific episodes to listen to.

Given the above, I would like to propose the addition of "List" mediums for every medium that already exists and all mediums going forward. For example, podcast would become podcastL, where the original medium is suffixed by the letter L to indicate a "List." music would become musicL. audiobook would become audiobookL.

The reason for brevity is primarily to be able to fit these into Podping character limitations without abbreviation. It is not the intention to display these directly in a user experience, as musicL would simply be a "playlist" of music for a user.

The current available mediums would result in the following "List" mediums:

• podcastL
• musicL
• videoL
• filmL
• audiobookL
• newsletterL
• blogL

Additionally, we will account for lists of mixed content with a dedicated generic mixed "List" medium. This is less for easy consumption and more to give people a place to have lists of sporadic mediums.

These mediums are expected to have no regular <item>, nor <podcast:liveItem>, nor any future similar new item type. Rather, "List" mediums are intended to exclusively contain one or more <podcast:remoteItem> (not yet a finalized tag), allowing one to reference a feed by its <podcast:guid> and the guid of an item.

As for other relevant tags to be included with "List" mediums, that is yet to be determined and is open for discussion.

[thebells1111]

I've been looking at Podchaser, because I want listeners to be able to share their playlists or podcast lists for podcast discovery, but I'd prefer it was done without needing a Podchaser account. I'm trying to wrap my head around your idea, but it seems like each playlist would be it's own feed. For example, create a RSS feed called 'Creepy Podcasts', with several <remote:items> linking to different podcasts or episodes, and the author of the feed is the person who curated the list. Now all that's need for the list to be discoverable is for it to be in a directory that is easily searched. Is that about how you're thinking this would work?

[agates]

I'm trying to wrap my head around your idea, but it seems like each playlist would be it's own feed. For example, create a RSS feed called 'Creepy Podcasts', with several <remote:items> linking to different podcasts or episodes, and the author of the feed is the person who curated the list. Now all that's need for the list to be discoverable is for it to be in a directory that is easily searched. Is that about how you're thinking this would work?

Yes, you understand the intent perfectly. Podping would also support these new mediums so anything that supports Podping would support these (i.e. The Podcast Index). Once @daveajones adds filters to search by medium in the index they would be discoverable that way.

And hosting these feeds would be trivial because they don't contain any external files, except perhaps an optional photo.

[thebells1111]

Yes, you understand the intent perfectly.

This is a killer idea, and one I'd like to see fast tracked. Being able to curate other's content without needing a centralized API is a huge leap forward, and the implementation is quite elegant. Combine this with <podcast:recommendation> and you have a very powerful tool for discoverability of new content.

[daveajones]

Love this proposal. I’d like to put it into phase 5 straight away and start evangelizing it with remote item. I guess they both need to go in together.

[agates]

Love this proposal. I’d like to put it into phase 5 straight away and start evangelizing it with remote item. I guess they both need to go in together.

I'll get around to making a couple test feeds soon and prioritize making List mediums available in podping-hivewriter.

How do you feel about the idea of a generic "list" medium? Something that would reference multiple types of mediums, like both podcasts and music for example.

[daveajones]

Seems like it would be something that is inevitably asked for, but not sure it should be in the initial spec. Seems like something that can be added easily later in an expansion. Just my initial feeling.

[saerdnaer]

Maybe use medien=collection, medium=compilation and/or medium=playlist – the fooL types feel a little bit to developer centric...

[agates]

Maybe use medien=collection, medium=compilation and/or medium=playlist – the fooL types feel a little bit to developer centric...

How would one search for "music playlists" given this suggestion?

These are developer-centric because the purpose is to provide intent to applications.

[thomasrynne]

If a feed has <podcast:medium>Music</podcast:medium> and the feed contains only <podcast:remoteItem .../> tags is there a need to repeat the fact that all the items are remoteItems by adding 'L' to the medium value? What should happen if 'Music' is used but there are <remoteItem>s, or if 'MusicL' is used and there are regular <item>s?
I'm not sure what feature this unlocks.