Proposal: `<podcast:gateway>` item-level tag

hellosteadman commented 3 years ago

Hi gang. Great to see such activity going on with the namespace of late.

I've written about "gateway episodes" before, as something podcasters can do on their websites to give new listeners a starting point into a long-running podcast. While we're all trying to make each episode better than the last, our 100th might not be as welcoming to new listeners as our first, so I was thinking it'd be great to be able to pin an episode to the top of a feed list, and indicate in the UI that this episode might not be the latest, much like a pinned tweet. I don't see why multiple episodes can't be pinned, but app UI developers should make their own decision as to how many is too many. I'd say a soft limit of 3.

Anyway, I think the ability to interrupt a chronological list and mark certain episodes as good starting points could be really helpful. A simple item-level <podcast:pinned> tag with the text value of yes would be simple enough. However, it could go a little further:

<podcast:pinned>
    <podcast:pinnedLabel lang="en">Start here</podcast:pinnedLabel>
    <podcast:pinnedLabel lang="es">Empieza aqui</podcast:pinnedLabel>
</podcast:pinned>

So the contents of the tag could either be

yes in which case the player app makes its own decision (perhaps we agree simply on "Pinned episode" to prevent any unintended meaning being drawn from it... we don't want to make an assumption as to why an episode is "pinned"), or
a list of labels in different languages that explicitly state what "pinning" means to this particular podcast. To avoid duplication, perhaps <podcast:pinnedLabel> could be channel-wide.

Would love your thoughts. I feel like I've kept abreast of developments but I don't use Mastodon so if this is something I've missed, and you already have a competing/better spec for this, obviously feel free to close this as a dupe. But I hope it's worth considering for phase 4.

Thanks so much.

daveajones commented 3 years ago

This is a really interesting idea. It seems to share qualities with and , but also is unique to its own purpose.

We’ve had this issue on our own show. Yes, the first show had a lot of value for new people. But, over time it became dated as the project evolved. And now I’d say that one of the episodes in the 20’s probably made more sense as an entry point.

I like this a lot. It could be that the UI of the podcast app suggests this episode to the listener when they first follow/subscribe. Maybe there is a pop up or something.

hellosteadman commented 3 years ago

Thanks @daveajones, that's great to read. Your idea of the popup makes me think we could expand this a little to have a reason attribute to the <podcast:pinned> tag, so you can say "this one is pinned because it's a good one to start with", vs "this one is pinned because we had a stellar guest". If we limit the reason attribute to a few keywords, the app can make a safe inference as to why an episode is being pinned, and then if it's, say reason="gateway", the app can safely pop up a dialog saying "Do you want to start with this episode?" Then any other pinned episode can just be shown with a highlight and the pinned label.

daveajones commented 3 years ago

Yes, with a proper reason code, the UI could really be adapted to fit a lot of different uses.

the app can safely pop up a dialog saying "Do you want to start with this episode?"

Yes, this is exactly the experience I would want as a listener. I really love this idea. It would also be great for discovery. I can see services popping up that extract all of the gateway episodes from different podcasts into lists.

adamc199 commented 3 years ago

The No Agenda Show has several 'dot five' episodes that are perfect for this. 100.5, 200.5 would be our pins (if multiple are valid)

johnchidgey commented 3 years ago

Think this is a fantastic idea and subtly different from Trailer in a good way. I think we should have an index value to order them so that if you have 3 pinned episodes, the client will show them in the same order (not just alphabetical or order they're entered in the feed). Or, we could just enforce the coding order in the feed from top to bottom should be the display order. Either works.

daveajones commented 3 years ago

Yes, an index is a fine idea.

cqr commented 3 years ago

RadioPublic implements gateway episodes via RSS, which are presented at the top of the list. The latest (or first, for serially ordered shows) episode is presented in that spot when the gateway episode tag is not present.

The specific structure of gateway episodes falls outside of the tags, because we wanted them to be able to be strictly ordered. Thus, the structure is

...
<channel>
  ...
  <rp:gateway-episodes>
    <rp:episode-reference>[guid-1]</rp:episode-reference>
    ...
    <rp:episode-reference>[guid-n]</rp:episode-reference>    
  </rp:gateway-episodes>
  ...
</channel>
</rss>

There's a lot to be said for allowing the categories / labels to be defined at the feed level, but I am wary of leaving ui localization to podcast publishers. I'm also wary of losing the defined semantic value of pinning, which I think is necessary for app makers to be comfortable building an analog in the absence of explicit values in the feed. At least from my perspective at RadioPublic, being able to backfill algorithmically was often a requirement before we built support for reading a new kind of value from the feed, because otherwise it generally wasn't worth supporting the very small number of podcasts which would proactively support an emerging standard.

To be clear, this is from our first version of the spec I wrote back in 2016, and there are definitely things I would do differently about it today. That said, I don't prefer index attribute based ordering because it can lead to confusing and undefined behavior when e.g. multiple entries share an index or some are present and some are missing.

daveajones commented 3 years ago

@cqr, thanks very much for this info. How widely used is ''? Do you know of any apps ingesting/acting upon it? If so, would it be possible to adopt this tag into the podcast namespace in a way that is backwards compatible with what you guys have? We did something similar with . Buzzsprout was using it and Podcast Addict was the only app ingesting it. We adopted it in a way that kept compatibility and just changed the prefix.

Just wondering how we can advance what you guys have done and give it wider use in the industry. Lots of hosting companies have the "podcast" xmlns declared now. So, the barrier to adoption is getting lower.

cqr commented 3 years ago

Aside from the RadioPublic apps (including the native apps, website, embed, and podsites) I don't think any clients implemented it. Libsyn implemented it on the publishing side, and there were some boutique deals with smaller hosts.

I think we have the space to invent something new here based on that adoption, but I defer to you on that. The chicken and egg problem is one I am very familiar with. Our solution at RadioPublic is to try to play both roles any chance we got, which is tricky because (until recently) we were not connected to any podcast publishing.

daveajones commented 3 years ago

Thanks @cqr .

Since the specific episode needs to live in the feed pretty much forever, even when others may roll off, there is also the option to wrap a standard episode in a tag that will obscure it from players that don't support it, like this:

<podcast:gatewayItem>
  <title>Episode 50: Max Boost Time</title>
  <description>Adam & Dave discuss the week's developments on podcastindex.org with free software entrepreneur Max Hillebrand. We go deep on how all this bitcoin lightning stuff works. An outstanding board meeting!</description>
  <link>http://adam.curry.com/html/PC205020210813Podcas-n6KRZ4qb827P30PgBqfRCtG1BHk0kP.html</link>
  <guid isPermaLink="false">PC2050</guid>
  <pubDate>Fri, 13 Aug 2021 20:27:20 GMT</pubDate>
  <podcast:chapters url="http://34.117.70.159/http%3Amp3s.nashownotes.compc20rss.xml/PC2050" type="application/json"/>
  <podcast:transcript url="https://mp3s.nashownotes.com/PC20-50-Captions.srt" type="application/srt"/>
  <itunes:subtitle>Episode 50: Max Boost Time</itunes:subtitle>
  <itunes:author>Podcast Index LLC</itunes:author>
  <author>Podcast Index LLC</author>
  <itunes:image href="https://noagendaassets.com/enc/1601061118.678_pciavatar.jpg"/>
  <itunes:explicit>no</itunes:explicit>
  <itunes:keywords>podcasting,curry,podfather,technology,deverlopers</itunes:keywords>
  <enclosure url="https://mp3s.nashownotes.com/PC20-50-2021-08-13-Final.mp3" length="97606680" type="audio/mpeg"/>
</podcast:gatewayItem>

I'm just thinking it keeps all the normal semantics we're used to, and doesn't need indexing against others because the date is already there as the normal sorting device.

Am I crazy with this?

daveajones commented 3 years ago

I'm thinking wrapping may be just too messy. You'd have to resolve GUID collisions and such. Giving this some thought...

hellosteadman commented 3 years ago

I think the idea behind it is sensible, as it does allow for separation of episodes, but could be complex for apps to have to integrate, so maybe for phase 4 it could be worth sticking with the <item> element, and look further down-the-line at what's possible?

hellosteadman commented 3 years ago

On the point-of-view of episodes dropping off feeds, for hosts that are implementing this feature at a native level – ie: they have a UI for it, and are not just relying on users being able to alter the feed themselves – I feel like it would be trivial to pick out the episodes from the feed that are marked as gateways, so that they always come up in the page 1 of a paginated list.

If I were still running Podiant – ah, those were the days 😉 – I might do something like this:

Query for all published episodes
Order the query by -isGateway and then pubDate, so that episodes where isGateway=true are always first in the list
Limit the query to 100 items
Optionally re-order the queryset results in Python, so that they're in reverse-chronological order
Render the list

Step 4 really shouldn't matter, but we're being good citizens by putting the episodes back in the expected order.

jamescridland commented 3 years ago

... it's also no different to the trailer episode in the iTunes spec, so podcast hosts should be used to it.

daveajones commented 3 years ago

so maybe for phase 4 it could be worth sticking with the <item> element

Ok, I’ll write it up like I think you intend and then we can all hammer on it and shape it to what we’re comfortable with.

RocksteadyTC commented 3 years ago

@daveajones Thanks for the invite to comment via Mastodon, I like where this is going. I have some questions/remarks:

@amarksteadman Server side, this appears perfectly doable, it's just adding an extra field and attributes to the feed.

The translations seem like a conversation that supersedes how pinning is handled, but I'll add my thoughts on that anyway while I'm here:

I'm curious how the translations would play out, surely there's a better way to do this than exponentially increasing the size of the fetch by putting it all in one file. Perhaps this could link to a child feed that follows a common convention *_en_US.rss to allow for players/UIs that honor translations to also know to follow any subfeeds with the correct locale string in the name.

@amarksteadman If you had to explain to someone programmatically how this feed is structured, with what criteria would you explain the difference between a 'pinning reason' from an 'episode description' in a way that could be translated to code?

@daveajones Though this is tangential to the discussion of a protocol, and it seems like more of a UI/UX concern, I like this idea, and would probably enjoy that or find it helpful.

@daveajones I've only just arrived, but from what I know of GUID's or UUID's in general, a collision would be unlikely. Is the term being used differently in this context? However, what I see in the field in the example is also not what I'd recognize as a GUID traditionally. In the interest of being concise, is there a better term we can use for this, or a better way we can specify what value is valid here?

@amarksteadman While reading this I'm reminded of two things, versioned protocols, and RFC's. A versioned protocol defines the mandatory elements from the supplemental elements, and RFC's define a way to comply with specificity to peripheral standards that have not yet made it to the protocol level.

jamescridland commented 3 years ago

I'm curious how the translations would play out, surely there's a better way to do this than exponentially increasing the size of the fetch by putting it all in one file

I'm curious too. We don't have translations for anything else, and I'd like to suggest that we remove translations here. The language of the RSS feed - the title, descriptions, and of the podcast itself, is already defined in the RSS's <language> element. Why would you have a label saying "Empieza aqui" when the podcast itself is only available in English?

versioned protocols, and RFC's

In the podcast namespace, we're confined by not being able to do this sort of thing. Everything we do has to be backwards-compatible, and not break current podcast apps. The good news is that the RSS specification works this way.

RocksteadyTC commented 3 years ago

Why would you have a label saying "Empieza aqui" when the podcast itself is only available in English?

I agree, however, allow me to play devil's advocate: When English isn't your first language, a translation is helpful to clarify the bits you might not understand in the English translation.

In the podcast namespace, we're confined by not being able to do this sort of thing. Everything we do has to be backwards-compatible, and not break current podcast apps. The good news is that the RSS specification works this way.

I can appreciate this goal, it is the most inclusive path and poses a fun challenge while also respecting the parting wishes of the RSS devs

cqr commented 3 years ago

I'll reiterate my concern with localizing in an RSS feed. This label for a pinned section ultimately feels to me like a piece of UI that should be consistent, and localization is a solved problem in the world of mobile apps and web apps.

The simplest thing to do in this case would be to pick a single purpose (I would advocate the abstract "pinned" case, or "Start Here" or similar) which podcasters can interpret however they want and not to worry about labels in the feed. Leave it to the app.

If you want to add arbitrary labels to items, the rss <category> tag seems like a great fit.

cqr commented 3 years ago

@daveajones I've only just arrived, but from what I know of GUID's or UUID's in general, a collision would be unlikely. Is the term being used differently in this context? However, what I see in the field in the example is also not what I'd recognize as a GUID traditionally. In the interest of being concise, is there a better term we can use for this, or a better way we can specify what value is valid here?

While RSS GUIDs are not GUIDs in the sense that the fit the commonly used definition, that's what they're called in RSS. It may not be an ideal situation, but there's no putting that particular genie back in the bottle.

theDanielJLewis commented 3 years ago

Please forgive me for having to skim this (so I might be saying something someone already said), but I suggest what I think would be a better term than "pinned" or "gateway": "feature."

Also, I suggest there be as little redundancy as possible. If this is a channel-level tag, it should reference the episodes by GUID with an optional title for each.

If it's item-level, I still recommend a separate title. For example, "Start here," or "Our most popular episode."

theDanielJLewis commented 3 years ago

Actually, maybe even instead of a gateway/featured tag, it should be a more extensible <podcast:episodeType> tag. We already know "trailer," "bonus," and "normal." We could add "featured" as a type or attribute.

daveajones commented 2 years ago

Moving this forward to another phase and posting this here as a placeholder to begin work on the combined tag.

\ - Discuss

<podcast:gateway order="[(number)]" > [free form message to listeners(string)] </podcast:gateway>

Item

(optional | multiple)

This tag, when present in an <item> indicates that this episode is a so-called "gateway episode". Gateway episodes are episodes that the podcaster (or maybe crowd sourced) thinks represent the best entry point into a long running show. If a podcast has 300 episodes, it might be a good idea to designate 1 or more older episodes as the best place to start.

The order attribute is an unsigned integer that is meant as an ascending listening order. The episode with order="1" should be played first, then order="2" and so on.

When podcast apps encounter gateway episodes, it is suggested that they present these episodes (in some form of UI) to the user when the user subscribes or follows the podcast.

Example of a single gateway:

<item>
    <title>Podcasting 2.0 - How it all Began</title>
    <description>A look into the future of podcasting and how we get to Podcasting 2.0!</description>
    <link>https://example.com/pc20/ep1</link>
    <guid isPermaLink="true">https://example.com/pc20/ep1</guid>
    <author>John Doe (john@example.com)</author>
    <podcast:images srcset="https://example.com/images/ep1/pci_avatar-massive.jpg 1500w,
        https://example.com/images/ep1/pci_avatar-middle.jpg 600w,
        https://example.com/images/ep1/pci_avatar-small.jpg 300w,
        https://example.com/images/ep1/pci_avatar-tiny.jpg 150w"
    />
    <podcast:person href="https://www.podchaser.com/creators/adam-curry-107ZzmWE5f" img="https://example.com/images/adamcurry.jpg">Adam Curry</podcast:person>
    <podcast:person role="guest" href="https://github.com/daveajones/" img="https://example.com/images/davejones.jpg">Dave Jones</podcast:person>
    <podcast:person group="visuals" role="cover art designer" href="https://example.com/artist/beckysmith">Becky Smith</podcast:person>
    <enclosure url="https://live.example.com/live.mp3" type="audio/mpeg" />
    <podcast:gateway>Start here!</podcast:gateway>
</item>

Example of a gateway series:

<item>
    <title>Podcasting 2.0 - How it all Began</title>
    <description>A look into the future of podcasting and how we get to Podcasting 2.0!</description>
    <link>https://example.com/pc20/ep1</link>
    <guid isPermaLink="true">https://example.com/pc20/ep1</guid>
    <author>John Doe (john@example.com)</author>
    <podcast:images srcset="https://example.com/images/ep1/pci_avatar-massive.jpg 1500w,
        https://example.com/images/ep1/pci_avatar-middle.jpg 600w,
        https://example.com/images/ep1/pci_avatar-small.jpg 300w,
        https://example.com/images/ep1/pci_avatar-tiny.jpg 150w"
    />
    <podcast:person href="https://www.podchaser.com/creators/adam-curry-107ZzmWE5f" img="https://example.com/images/adamcurry.jpg">Adam Curry</podcast:person>
    <podcast:person role="guest" href="https://github.com/daveajones/" img="https://example.com/images/davejones.jpg">Dave Jones</podcast:person>
    <podcast:person group="visuals" role="cover art designer" href="https://example.com/artist/beckysmith">Becky Smith</podcast:person>
    <enclosure url="https://live.example.com/pc20_ep1.mp3" type="audio/mpeg" />
    <pubDate>Fri, 11 Sep 2020 18:51:09 GMT</pubDate>
    <podcast:episode>1</podcast:episode>
    <itunes:episode>1</itunes:episode>
    <podcast:gateway order="1">Start here!</podcast:gateway>
</item>

<item>
    <title>Podcasting 2.0 - The tide has turned</title>
    <description>What a big week.  So many important things happened this week.  We dive into it all and what it means!</description>
    <link>https://example.com/pc20/ep45</link>
    <guid isPermaLink="true">https://example.com/pc20/ep45</guid>
    <author>John Doe (john@example.com)</author>
    <podcast:images srcset="https://example.com/images/ep1/pci_avatar-massive.jpg 1500w,
        https://example.com/images/ep1/pci_avatar-middle.jpg 600w,
        https://example.com/images/ep1/pci_avatar-small.jpg 300w,
        https://example.com/images/ep1/pci_avatar-tiny.jpg 150w"
    />
    <podcast:person href="https://www.podchaser.com/creators/adam-curry-107ZzmWE5f" img="https://example.com/images/adamcurry.jpg">Adam Curry</podcast:person>
    <podcast:person role="guest" href="https://github.com/daveajones/" img="https://example.com/images/davejones.jpg">Dave Jones</podcast:person>
    <podcast:person group="visuals" role="cover art designer" href="https://example.com/artist/beckysmith">Becky Smith</podcast:person>
    <enclosure url="https://live.example.com/pc20_ep45.mp3" type="audio/mpeg" />
    <pubDate>Fri, 20 Aug 2021 20:23:55 GMT</pubDate>
    <podcast:episode>45</podcast:episode>
    <itunes:episode>45</itunes:episode>
    <podcast:gateway order="2">We reached a milestone here!</podcast:gateway>
</item>

theDanielJLewis commented 2 years ago

I still strongly urge us to use <podcast:featured> instead of <podcast:gateway> as "featured" is a friendlier word, more future-proof, and more extensible.

ericpp commented 1 year ago

I think this would be great to have for music. Artists could add a featured tag for singles in the album feed.

Dwev commented 9 months ago

I support the idea of a featured tag, with a type or reason indicator (gateway,popular,event etc).

This way, players can aggregate tags of a particular type in a list (as mentioned in somewhere) so they can present a list of "Great Gateway Episodes" or similar.

Event could be an attribute that is linked to an actual event (that has a date) so it is automatically featured around the date of the event (different to the live tag, as this is intended for a real life event, like a trade show or keynote or something. Combined with the live tag, it could be used to help highlight an upcoming live episode from the event. Think of a music podcaster, promoting their performance at NAMM or a tech reviewer doing a stream for a product announcement).

The podcast players can then also have lists of upcoming event episodes. "All the episodes relating to the Apple Vision pro launch event" or "SXSW event episodes" or similar.

(I initially liked Daniel's idea of extending the existing episodeType attribute, but now think that this is slightly different. Maybe you want to feature a bonus episode, it would mean having an additional value for the attribute like "bonus,featured" which may not be backwards compatible. That tag is also in the iTunes namespace, so not sure how that would work.)

Podcastindex-org / podcast-namespace

Proposal: `<podcast:gateway>` item-level tag #281

\ - Discuss