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

[hellosteadman]

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]

This is a really interesting idea. It seems to share qualities with podcast:soundbite and podcast:trailer, 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]

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]

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]

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]

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]

Yes, an index is a fine idea.

[cqr]

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]

@cqr, thanks very much for this info. How widely used is 'rp:gateway-episodes'? 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 podcast:transcript. 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]

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]

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]

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

[hellosteadman]

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]

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:

1. Query for all published episodes
2. Order the query by -isGateway and then pubDate, so that episodes where isGateway=true are always first in the list
3. Limit the query to 100 items
4. Optionally re-order the queryset results in Python, so that they're in reverse-chronological order
5. 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]

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