Proposal: <podcast:channel> (a group of podcasts)

[tomrossi7]

One of Apple's features is the grouping of podcasts into a channel. I kind-of like this idea and wonder if we could incorporate a way to do this within the RSS feed. Perhaps, we provide a podcastChannel tag that uniquely identifies the channel? Or a relatedPodcasts tag that points to a JSON of all the related RSS feeds?

[daveajones]

You beat me to this Tom. This is absolutely a good idea.

[theDanielJLewis]

Isn't this what the recommendation tag is supposed to support?

[tomrossi7]

A channel is not a recommendation, but a collection of related podcasts. A podcast could belong at most to only one channel. The should be grouped together under a name as well.

[vv01f]

a thought on naming …

channel is a name for a dedicated XML element in the feed already. so that naming is not helpful.

a bunch of channels would e. g. be an aggregation. this would also clarify the difference to recommendations.

any better wording or thoughts on that maybe?

[daveajones]

a thought on naming …

channel is a name for a dedicated XML element in the feed already. so that naming is not helpful.

a bunch of channels would e. g. be an aggregation. this would also clarify the difference to recommendations.

any better wording or thoughts on that maybe?

What about <podcast:related> since that was part of Tom’s initial wording?

@tomrossi7 Do you want to write up what a tag structure would look like that you can see implementing? If you don’t have time I can take a crack at it and submit here for comments.

[theDanielJLewis]

"bundle" could be another word to use.

But I'm still having trouble understanding what's different about this compared to recommendations/related.

[chiragnd]

But I'm still having trouble understanding what's different about this compared to recommendations/related.

I’m thinking the difference between these are our shows, ie the same network or producer vs these are things we recommend, which could be anyone’s shows? This is not to say that we can’t have it under one tag and have a field to identify things that are ‘Internal’ vs ‘external’ if that matters.

From an app perspective, I think the difference becomes how it might be shown. It’d be nice to have the option to showcase our Network shows together (similar to the channel idea or a brand page), and our recommendations to be more of a blog roll type list maybe.

[saerdnaer]

@theDanielJLewis recommendations refer to specific episodes, whereas related refers to other shows/podcasts

[douglaskastle]

I am struggling with this too. Is this meant to be a RSS way of showing podcasts that are all part of a podcast network? Or would you use it as an episode level where one might be doing a cross promo? Are there any good existing examples of where this might be used? Is it per podcast or per episode? or both?

[theDanielJLewis]

I’m thinking the difference between these are our shows, ie the same network or producer vs these are things we recommend, which could be anyone’s shows? This is not to say that we can’t have it under one tag and have a field to identify things that are ‘Internal’ vs ‘external’ if that matters.

I like this idea. Whether is a recommended or related tag, let it have some kind of grouping and order. On the channel level, this could replace both "more by this artist" and also provide a more personalized "other shows you might like" list.

Having some control over the labeling and order can help differentiate these things, too. There could be standard tags, like recommended for the related recommended shows, and withhost or something like that for grouping other podcasts hosted or cohosted by the hosts, even if not their own.

For example, my own show would obviously list my other shows (unless I didn't want a show connected in this context), but I could also list Podcasters' Roundtable, of which I'm an official cohost but it's not my own show.

Then on the item level, the recommendations/related could be to other relevant episodes or entire shows as well. For example, if I do an episode about writing, I could link to a couple other "writing for podcasters" kinds of episodes, as well as entire shows all about writing.

[daveajones]

EDIT: Updated with a newer proposal below.

cc: @tomrossi7 @KieranMcKeefery @eteubert @cio-blubrry @PofMagicfingers @dan

[eteubert]

In a perfect world each podcast would have a guid. Then we could use this guid as reference instead of a URL, which may change. But the feed URL seems like a close second choice because the podcaster has a high interest in keeping that stable or at least redirecting to the current URL.

I do like the draft. Simple enough and provides enough data for the usual display of such lists.

[daveajones]

Agreed on the UUID thing. We’re brainstorming possible solutions to that here. It’s a tough one. ☹️

Would having a thumbnail url attribute included next to the feed url attribute in podcast:relatedFeed be wise? To give apps what they need for a nice UI presentation?

cc: @MartinMouritzen @dellagustin @mitchdowney

[MartinMouritzen]

At this part of the user journey, I would most likely just look up the podcasts through the API, so at least for my purposes a thumbnail url is not necessary here.

• If we think that would open up for too many API calls, then yes a thumbnail would make great sense :)

[tomrossi7]

Its not that big of a deal, but I do like <podcast:channel> better or possibly <podcast:network>. If an XML parser can't properly parse namespace tags, they are bound to run into collisions even now. Related sounds more loose a definition e.g. I mentioned Joe Rogan in one of my episodes so now I'm going to say I'm related to his RSS feed.

I like the idea of a podcast having the option of belonging to one and only one channel or network. I don't know how we could enforce integrity, but we can at least make it part of the spec and allow aggregators the ability to invalidate feeds.

Just my 2 cents!

[MartinMouritzen]

As far as I understood then "Channels" in the new Apple Podcasts is curated content. This would more be a way for podcasters themselves to say "I want to be associated with these other podcasts" right? (and possibly have those podcasts do the same thing)

If that's the case, then I do like podcast:network better for that use case.

[daveajones]

I'm really good either way on the naming. If it comes down to it, "channel" is probably a better word than "network", since large podcast networks may want to sub-categorize their shows into channels.

We could do this instead:

<podcast:channel>

<podcast:channel 
    title="[title of this channel(string)]"
    description="[a short description of the channel(string)]"
>
[one or more <podcast:channelMember> elements]
</podcast:channel>

Parent: <rss><channel>
(optional | single)

• title (required) - This is the title of the channel.
• description (optional) - This is a short (600 characters or less) description of what this channel contains.

<podcast:channelMember>

<podcast:channelMember
    url="[feed url of a related podcast(string)]"
    image="[url of a thumbnail image for this podcast(string)]"
    private="[true|false]"
/>
[Title of Podcast(string)]
</podcast:channelMember>

Parent: <podcast:channel>
(required | multiple)

The node value of this element is the title of the podcast being referenced. It is required and cannot be blank.

• url (required) - This is the url of a podcast feed.
• image (optional) - If this attribute is present, it should be the url of an image to use for this podcast to ease the burden of querying for show art urls when an app wants to display a full channel of shows to the listener.
• private (optional) - If this attribute is present, and set to "true" it tells a podcast application that this feed requires some kind of membership in order to access. If this attribute is not present or is set to "false" the feed is public.

Examples

<podcast:channel title="Daniel J. Lewis">
    <podcast:channelMember url="https://theaudacitytopodcast.com/sitefeed/">The Audacity to Podcast</podcast:channelMember>
    <podcast:channelMember url="https://podcastersroundtable.libsyn.com/rss">Podcaster's Roundtable</podcast:channelMember>
    <podcast:channelMember url="https://anchor.fm/s/a42af4/podcast/rss">Inside the Podcasting Business</podcast:channelMember>
<podcast:channel>

<podcast:channel title="Nothing But Dan" description="All the Dan Benjamin you could ever want in one place.">
    <podcast:channelMember url="https://feeds.5by5.tv/b2w" image="http://icebox.5by5.tv/images/broadcasts/19/cover.jpg">Back to Work</podcast:channelMember>
    <podcast:channelMember url="http://feeds.5by5.tv/roadwork" image="http://icebox.5by5.tv/images/broadcasts/89/cover.jpg">Road Work</podcast:channelMember>
    <podcast:channelMember url="https://feeds.fireside.fm/podcastmethod/rss" image="https://assets.fireside.fm/file/fireside-images/podcasts/images/6/63cb6a26-1daa-48af-98a7-285e89e0f62b/cover.jpg?v=2">Podcast Method</podcast:channelMember>
<podcast:channel>

cc: @staceygoers

[tomrossi7]

@daveajones I wonder if we need to duplicate any of those attributes since they can be found within the RSS feed itself. It could be as simple as below. Maybe we could have an image for the channel since that wouldn't be in any of the feeds?

<podcast:channel title="Daniel J. Lewis" image="http://icebox.5by5.tv/images/broadcasts/19/cover.jpg">
    <podcast:channelMember>https://theaudacitytopodcast.com/sitefeed/</podcast:channelMember>
    <podcast:channelMember>https://podcastersroundtable.libsyn.com/rss</podcast:channelMember>
    <podcast:channelMember>https://anchor.fm/s/a42af4/podcast/rss</podcast:channelMember>
<podcast:channel>

[theDanielJLewis]

As far as I understood then "Channels" in the new Apple Podcasts is curated content. This would more be a way for podcasters themselves to say "I want to be associated with these other podcasts" right? (and possibly have those podcasts do the same thing)

Not quite. That was my initial misunderstanding, too. But now, it's more about how a creator can create their own channels with their own shows, but a show can be in only one channel at a time.

For example, ESPN could bundle all their soccer podcasts in a channel, all their baseball podcasts in another channel, etc.

I apologize that I'm starting to get a little lost with some of the details. But what I see "related" as being is a podcaster-curated "you might also like" list, similar to what's in Apple Podcasts now. But with enough flexibility in the tag, the groupings could be based on whatever I want: whether my own other podcasts, podcasts that are similar to mine, or shows I recommend often that fit the interests of my audience.

I'm not so sure channel is a better tag. What about group or collection?

[daveajones]

@daveajones I wonder if we need to duplicate any of those attributes since they can be found within the RSS feed itself. It could be as simple as below. Maybe we could have an image for the channel since that wouldn't be in any of the feeds?

If we make image optional then it can be safely left out by the hosts. API's like us could then dynamically put it back in at run time to help the apps that don't have their own infrastructure, like PWA's.

Would that work?

I like the channel image. I'll add it.

[dellagustin]

Would having a thumbnail url attribute included next to the feed url attribute in podcast:relatedFeed be wise? To give apps what they need for a nice UI presentation?

I like the idea of having the thumbnail enclosed here, it would make it simpler from the app side if the app decide to show it.

In general I like the feeds to be as self contained as possible, without depending on external APIs (of course, observing that we don't want to have a gigantic feed...).

[tomrossi7]

I like the idea of having the thumbnail enclosed here, it would make it simpler from the app side if the app decide to show it.

This is a dangerous path because we are duplicating content in anticipation of how it may be used. In other words, we think the aggregator will want the title and artwork of the channel member, so we fatten up the RSS feed with information. I would rather err on the side of anticipating less and letting the aggregator decide what they want to load. The ultimate source of truth should be the channel member's RSS feed.

Not a biggie since we can make it optional, but just my 2 cents on a general "what we should and should not include in the RSS feed?".

[PofMagicfingers]

we are duplicating content

Yeah I agree with you. If we include titles, thumbnail url, and even members, we'll have many times either broken links or out-of-date informations.

Actually, maybe it's better to move the "channel" members into it's own "channel file", using something like OPML. The RSS feeds only reference this file, and the channel data would be inside this always up-to-date file.

The tag could be :
<podcast:channel href="http://ourpodcastnetwork.com/podcast_channel.opml" />

And the clients and aggregator would check the URL to get the up-to-date podcasts links and channel infos.

[daveajones]

Actually, maybe it's better to move the "channel" members into it's own "channel file", using something like OPML. The RSS feeds only reference this file, and the channel data would be inside this always up-to-date file.

I love OPML and have written tons of software that uses it, but I'm not sure it's the right tool for this job. It can be much more "clumsy" than RSS. I would lean toward JSON since we've already established a standard with that on the chapters side. If we're going to introduce another external file I would keep it consistent.

I can see the wisdom in an external file. It makes sense. It is, however, yet another external file to track and keep in sync. For example, what if a feed references an external channel file, but that feed itself isn't listed in the external file as being a channel member? It does become more complicated.

I would rather err on the side of anticipating less and letting the aggregator decide what they want to load. The ultimate source of truth should be the channel member's RSS feed.

I agree. We can just let the aggregators/api's take care of assembling the meta-data. Let's leave it out.

[daveajones]

So, I guess before we refine this more, we need to make a decision about external channel file vs internal to the RSS. There are trade-offs, as always. What do we think on this? I can see wisdom in either direction.

[PofMagicfingers]

yet another external file to track and keep in sync
Well yeah, but it's not meant to change very often.

For example, what if a feed references an external channel file, but that feed itself isn't listed in the external file as being a channel member? It does become more complicated.

Here are my thoughts on it :

Of course, linking should be done on both side to be confirmed :
the RSS feed links to the channel file and it is considered part of this channel, only if the channel file include the canonical link of the feed.

Other advantage of this method is that updating and adding feeds to catalogs become almost organic :

• Channels file could lead to feed discovery. If the client app or podcast indexes/directories load a podcast it will discover other feeds from the channel for inclusion in catalog.
• If you have feed A and B from channel X, after updating feed B, you update the linked channel X, and discover before updating feed A, that feed A has been removed from channel X. (also meaning you should probably update feed A because something has changed)
• Directories and platforms can keep track of channel files and update them periodically on their own.

In the end I also think an external file is better because it's an ultimate source of truth. If we include the whole network list on each feeds, what do we do when the list isn't the same on each feed ?

If the list isn't meant to be consistent between members of the channel, it's true it's more of a recommended feeds tags.

[tomrossi7]

To me, an external file seems like overkill since all we are listing are the channel members RSS feeds. Even for a large channel, you aren't talking about adding too many lines. If the feed were an object, the other channel members would be an array attribute of RSS feeds. Its definitely not an easy black-and-white and I could go either way!

[daveajones]

imagine you're thinking about changing hosting provider, you go and try importing your feed on two other services, but you don't really have time, and postpone the move. Or you move to one of them, but forget to delete the test feed from the other one.

@PofMagicfingers @tomrossi7 @cio-blubrry @eteubert Any thoughts here?

[PofMagicfingers]

Protocol prefix and trailing slashes can be removed to fix the https/http issue. It works quite well on the Podcast Index.

I was thinking about the relative protocol adresses : //mydomain.com/rss
But it seems it is less used nowadays, because the majority of people now use HTTPS.
Maybe we should not worry about it too much as HTTP is starting to be seriously deprecated and will mostly disappear in the following years (Browsers are already alerting users etc)

For those dynamic feeds that aren’t meant for the general public this can let directories know not to publicly display it in their search.

IMHO, this is more a job for #179 : <podcast:block>yes</podcast:block>

Any thoughts here?

Unfortunately, I see the issue, but can´t imagine a simple and efficient solution to this problem. The best I can think of would be to leave a trail. When you move a feed to another address, you specify which feed it does replace in one of its tags, and that feed should either redirect to the new one, or specify the new url with the tag. I think this was discussed on another issue here.

But that doesn´t protect us from abuse, human errors, or multiple feeds claiming to be the new version of an offline feed.

In fact even with decentralized systems, there is always a central authority of some kind to ensure you trust the right persons. I don´t know what we could do about it without over-engineering this.

[daveajones]

Maybe we're thinking too hard on this. Maybe the answer is "just drop the packet". Let me explain.

When it came to packet switched networks, the big revelation was to just stop giving monumental effort to trying to deliver every single packet. If the router is too busy, just drop the packet and let the sender try again. Sometimes the answer to a complex decentralization problem is to just let the perceived problems manifest themselves. It might not be as bad as we think.

Let's take @PofMagicfingers example:

And this question is relevant even in the specific use case of the proposal : imagine you're thinking about changing hosting provider, you go and try importing your feed on two other services, but you don't really have time, and postpone the move. Or you move to one of them, but forget to delete the test feed from the other one. How does a podcast directory knows which RSS feed is the one?

Look at the system we have now. If that scenario played out there would be 3 feeds (one of them is "canonical") with absolutely no linkage between them except for the podcast title and maybe the author tag. Good luck even finding those duplicates. If we had a <podcast:guid> we could at least see that those 3 feeds are attempting to be the same thing and provide portals to help fix it and/or signal to the author that they need to go clean up their mess.

Now take fraud feeds. If someone really wants to impersonate a successful podcast, they would want to clone their <podcast:guid>. But, here again, that makes it really easy for directories to find the frauds and zap them.

Basically, what I'm saying is that perhaps letting the collisions happen is actually better than what we have now, which is all just human effort to find and interpret a haystack of feed urls and metadata.

[PofMagicfingers]

That's really smart. You're right, human errors should involve human handling. The standard should not handle all possible mistakes but only specify : if there is a configuration issue, an human should correct the issue.

[daveajones]

I started an official proposal thread for the GUID tag: #251 . We can continue that discussion over there. I'm pretty sure @saerdnaer , @agates and others will have some input.

We can just use placeholders here for whatever value that ultimately takes, and that will let us push forward with an actual JSON channel spec. I'll start working on a framework for that today.

[daveajones]

@daveajones you want me to use @snookfin's proposal and propose the tags?

Sure. If you want to propose the tags as an edit to your original posting up top I will write the JSON spec.

[daveajones]

Now that phase 3 is shipped, I'll turn focus to writing up a proper channel json spec. We need podcast:guid though. So, I'll formalize that first.

[Tombarr]

Out of curiosity, what happened to <podcast:network /> or something similar? I recently came across this from both the Acast (https://schema.acast.com/1.0/) and BBC (http://bbc.co.uk/2009/01/ppgRss) namespaces. Here's some examples:

<ppg:network id="worldserviceradio" name="BBC World Service"/>

<acast:network id="102959f3-c3f2-58be-4119-38e6d4415a15" slug=""><![CDATA[Immediate Media Radio Times]]></acast:network>

I'm not a fan of "channel" because that's already in use as the parent <channel> element to podcast RSS feeds, but I do like the idea of having some combination of human-readable names & GUIDs to link podcasts made by the same producer/ network. The use case I'm thinking about is, "More from this author/ publisher/ network," which predominantly relies on string matching <itunes:author>. That said, a GUID is susceptible to pirated feeds since there's nothing to stop someone from publishing an RSS feed and copying the GUID of another well-known network.

[ttepasse]

Prior art: Atom enables feeds which are aggregations of items which originate in other feeds. It does that by simply extending the aggregated atom:item with an atom:source element which carries the copied metadata of the original feed.

<item>
  ...
  <source>
    <id>http://example.org/</id>
    <title>…</title>
    <updated>...</updated>
    <rights>…</rights>
   <link rel="self" href="..."/>
   ...
  </source>
</item>

[daveajones]

@Tombarr Good find on the network terminology. Thanks for that.

We discussed the potential for GUID conflicts (maybe here, I’m not sure) and ultimately decided it was a benefit and not a problem since people intentionally cloning GUID’s would actually reveal them as collisions and make the spammers easy to identify and remove. That’s how I’m doing it now in the podcast index database. It’s one of the criteria for deduplicating.

If I’m misunderstanding your meaning please let me know though.

[theDanielJLewis]

I think there are multiple uses we can consider and thus might want to have a more inclusive tag name.

Yes, this could be used for an actual network/affiliation. It could also be used for related podcasts, recommended podcasts.

So I keep thinking ally kinds of references to a different podcast should should use the same tag. It could be <podcast:featured> or <podcast:link> an then a rel attribute to indicate its relationship. Potential starting attribute values could be “network” and “recommended.”

[mitchdowney]

I'd vote for "network" since it implies a "group" of some kind, whereas "channel" sounds like just one thing. Also because "channel" is already the name for the top-level RSS feed item. Otherwise maybe "channels"?

[mitchdowney]

Podverse is close to adding support for podcast:medium for music, but before we do that, ideally this tag would be formalized.

I was chatting with @agates about "how do we group music albums under a single artist, if each album or single is its own RSS feed?" and he said he envisioned the channel could support this use case. Since channels seem like basically a group of RSS feeds, I think this makes sense.

What do we need to do to get this namespace over the finish line?

[thomasrynne]

I've been thinking about this since @agates linked to it on podcastindex.social
I'd like to propose an alternative which I believe is simpler. Instead of creating a new channel json spec an rss feed can be used to represent the network/channel.

The child feed would only include the tag:
<podcast:belongsTo url="http://example.org/network.rss" guid="e0eac5f3-209f-4a38-b8a8-3291905c317f" />

And the 'network'/parent feed would list the children:
<podcast:child url="http://example.org/feed1.rss" guid="7bf2aef7-f1ba-4f29-b2a0-d043aefcf325" />
<podcast:child url="http://example.org/feed2.rss" guid="8a3e2ca9-e668-435f-b457-ae25513e7e73" />

Perhaps the network feed could also have a new medium of 'collection'.

When a podcast app sees the belongsTo tag it would lookup the parent feed and see whether this feed does belong to that feed. If the feed is not listed the tag is ignored. If the feed is found the title & image of the network feed could be shown next to the feed. Clicking on the network feed would list the children.

I think the benefits of this approach are:

• I suspect it is less work for hosts and app developers because It's just two new tags
• Subscribing to the network list (to see new shows from the network) is just subscribing to an rss feed
• Notifying apps of changes to the network list can be published with a normal podping
• It doesn't define a new 'top level' entity.
• It's compatible with podcasting 1.0 apps because it's just an rss feed which means there is more value in creating a network rss feed. The feed could include short audio items announcing any changes that users subscribed with an old app can see that there is a new podcast in the network (they would then need to manually search & subscribe)

However this is implemented it needs more feedback, especially from hosts

I would really like to see this to find new shows, but as mentioned above I think it could be used to link Artist's albums too.

[agates]

@thomasrynne I think that could work by just using OPML instead of a sort of "collection" oriented RSS feed, which would keep the implementation even simpler. I'll mull over the idea and see if I can think of any major drawbacks.

[genebean]

FWIW, I like the idea of this but dislike the idea of calling it channel. Podcasters talk about their podcast network already so I think podcast:network makes sense as a name and more clearly conveys the intent.

[agates]

FWIW, I like the idea of this but dislike the idea of calling it channel. Podcasters talk about their podcast network already so I think podcast:network makes sense as a name and more clearly conveys the intent.

I would agree with you if it were meant for only podcasting, but I could make the same argument and call it something like podcast:artist for music too. If anything, something like podcast:group would cover the most ground.

[genebean]

I would agree with you if it were meant for only podcasting, but I could make the same argument and call it something like podcast:artist for music too. If anything, something like podcast:group would cover the most ground.

I kinda like podcast:group. My intent was simply to encourage unambiguous naming.

[samsethi]

I had planned to create a dedicated page of podcasts based on the producer. The podcast:author tag is confusing and would be better labelled as podcast: producer. Then when you aggregate podcasts based on the producer e.g Wondery they would be on a dedicated page. I agree calling it would be confusing. But I do agree that import/export to this group via OPML would be a good idea.

[theDanielJLewis]

I like "group" or "family."

We just need to ensure this wouldn't be confused with something like <podcast:recommended> as a way to merely indicate similar or recommended podcasts. Instead, it needs to indicate podcasts in the same "family," as if it's a network.

[ryan-lp]

This discussion reminds me of the difference between normalisation and denormalisation in database design.

Whichever way we design it, there is going to be some duplication of redundant data, but I think the goal should be to reduce the maintenance burden. If a new file is created to give a list of feeds by the same author (which in any podcast directory could have been queried anyway from the list of feeds that share the same author tag), it represents an additional maintenance burden, whether that be for the podcast creator or the podcast host who now needs to write additional software to handle the authoring of a new type of file.

Examples of directories that show you a catalogue of works by the same author, without the additional maintenance of a separate catalogue file:

• Apple's podcast directory
• Google's Play Store directory
• Apple's App Store
• Etc. etc.
• (If you could find an exception to this practice, it would be the exception rather than the norm.)

So I would be in favour of just querying based on the shared author key, either the existing itunes:author key, or the newly proposed podcast:author key: #453

[theDanielJLewis]

Or the <podcast:person> tag.