Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: List mediums #363

Closed
agates opened this issue Apr 4, 2022 · 8 comments
Closed

Proposal: List mediums #363

agates opened this issue Apr 4, 2022 · 8 comments
Labels
phase6 Namespace Phase 6 proposal An idea for a new tag

Comments

@agates
Copy link
Contributor

agates commented Apr 4, 2022

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
Copy link
Contributor

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
Copy link
Contributor Author

agates commented Apr 8, 2022

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor Author

agates commented Apr 9, 2022

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
Copy link
Contributor

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
Copy link
Contributor

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

@agates
Copy link
Contributor Author

agates commented Apr 18, 2022

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.

@daveajones daveajones pinned this issue Aug 8, 2022
@daveajones daveajones unpinned this issue Aug 8, 2022
@daveajones daveajones added proposal An idea for a new tag phase6 Namespace Phase 6 labels Oct 26, 2022
@Podcastindex-org Podcastindex-org locked and limited conversation to collaborators Mar 25, 2023
@daveajones daveajones converted this issue into discussion #480 Mar 25, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
phase6 Namespace Phase 6 proposal An idea for a new tag
Projects
None yet
Development

No branches or pull requests

4 participants