Ability to list all platforms podcast is available on

[redimongo]

So the idea here would be for a full transparency of where a listener could find the podcast, I note that some podcast platforms allow a styled RSS feed to show in Chrome, Firefox, Microsoft Edge browsers.

At the moment I know PodNews and PodToo customers get a styled RSS feed that technically can allow users to listen to each episode in their browsers.

But I was thinking we should take this a step forward by introducing a tag that allows us to list all the links that a podcast can be heard on, we can than add some style to our XSL file that will show each of the platforms and allow the user to click on the icon to go to that platform.

As for what it looks like maybe something like this?

<podcast:avaliableOn>
       <avaliableOn platform="Spotify" href="SPOTIFY LINK"/>
       <avaliableOn platform="ApplePodcast" href="Apple Podcast LINK"/>
       <avaliableOn platform="GooglePodcast" href="Google Podcast LINK"/>
</podcast:avaliableOn>

technically we could even store the links to the icons in the above

<podcast:avaliableOn>
       <avaliableOn platform="Spotify" icon="LINK TO ICON" href="SPOTIFY LINK"/>
       <avaliableOn platform="ApplePodcast"  icon="LINK TO ICON" href="Apple Podcast LINK"/>
       <avaliableOn platform="GooglePodcast"  icon="LINK TO ICON" href="Google Podcast LINK"/>
</podcast:avaliableOn>

Would love feed back on this idea.

the feature is mainly only for if a user views your RSS feed in a browser that supports XSL viewing (safari does not)

Here is how a RSS feed currently looks in a "Supported" browser. This would allow us to remove the text that says "So you probably want our website" and instead allow us to add the icons of supported players with direct links.

[jamescridland]

Good afternoon, Perth!

I think this is two things:

1. XSL support for podcast RSS feeds. This is already a standard, and it's up to podcast hosts to implement. As you rightly point out, Safari (including iOS etc) doesn't support viewing of RSS feeds, even with XSL. I'd prefer not to spend time on this part.

2. Alternate links for other platforms. I agree, this would be desirable.

There is already prior art here... Blubrry proposed the rawvoice:subscribe tag a long time ago. You can see it in all Blubrry/Powerpress feeds, like this for the New Media Show

<rawvoice:subscribe
  feed="https://newmediashow.com/feed/audio/"
  html="https://newmediashow.com/subscribe-to-podcast/"
  itunes="http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=392545649"
  blubrry="https://www.blubrry.com/nms/"
  stitcher="https://www.stitcher.com/podcast/geek-news-central-podcast/the-new-media-show" 
  tunein="https://tunein.com/radio/The-New-Media-Show-p502763/" 
  spotify="https://open.spotify.com/show/5RlVyi6n3KIXaSg6huouAv"
></rawvoice:subscribe>

Now, this has been discussed before, and discarded I believe - I think the concern was not to promote Spotify. (I don't really agree with this).

Speaking personally, it's very difficult to match podcasts in places like Spotify and iHeart to existing RSS feeds. It's also almost impossible to link to a YouTube channel equivalent for a podcast (since the YouTube search API is almost impossible to query at scale - it's very expensive to do so).

The ideal way to link would be if all podcast platforms understood the podcast:guid link, of course, and we had a standard way of linking to them all. So just as podnews.net/podcast/ae38e5df-3281-5138-b120-b07cb835cac5 automatically redirects, so there's probably no reason why open.spotify.com/show/ae38e5df-3281-5138-b120-b07cb835cac5 shouldn't redirect, except of course, it doesn't (because Spotify don't use the GUIDs).

But I like the idea of slinging the URIs into the RSS feed for auto-discovery. The question is whether we want to give another reason for podcast directories not to bother implementing the GUID - the ideal would be for every podcast directory to use, or at least redirect, the existing GUID.

[ryan-lp]

Hmm, in the best case scenario, companies will continue to innovate by creating more and more new platforms inspired by Podcasting 2.0. And this introduction of new platforms is completely orthogonal to the sorts of things that typically cause changes to a feed (e.g. a new episode is added), and your podcast will also pop up in new directories due to being crawled independently and not by explicitly submitting to them. As such, I would prefer this list of platform links to be a separate mechanism from the RSS feed... ideally.

Of course, idealism doesn't work in practice, so:

Maybe the podcast:guid based approach can be spec'd as the ideal solution for the platforms that support it, and then the entry in the feed can be used as a fallback for those platforms that don't support it.

As for how the podcast:guid approach could work, we could have an XML or JSON file in git that has URL patterns for each platform's slug. New platforms can submit pull requests to get added. Everyone can import that file into their apps in order to generate the links on the fly, and then fallback to links in the feed for the legacy platforms.

the feature is mainly only for if a user views your RSS feed in a browser that supports XSL viewing (safari does not)

Looking at your example, I have a feeling you don't plan to actually list "all" platforms, maybe just the most popular platforms (and popularity contests will favour the big companies that don't actually support Podcasting 2.0 at the expense of promoting the smaller ones that do). But if you do actually want to list all platforms and you have a means to do that, it can be done without necessarily putting it in the RSS feed. For example, you could generate a unique XSL for each RSS feed that presents this list of platforms to the listener.

[nathangathright]

1. As far as I know, the only services that support the <podcast:guid> in URLs are Steno.fm and Podnews. If there’s more, I welcome any pull requests to my repo of podcast URL patterns.
2. I’m in favor of something like a <podcast:subscribe> tag. I’d love if more supported GUIDs, but practically-speaking, I don’t expect major platforms to support foreign key lookup methods, whether that’s in the URL or via something like /.well-known/webfinger. Personally, I’d love if we could elegantly handle episode URLs as well, but that may be a pipe dream.
3. I don’t think the spec should dictate the accepted platforms. Leave that open to the podcasters.
4. I don’t think RSS feed should dictate the icon. Leave presentation to the apps.
5. I’d propose that we copy/extend the <podcast:contentLink> tag:

   <podcast:contentLink href="https://youtube.com/blahblah/livestream">Live on YouTube!</podcast:contentLink>
   

   Allowing arbitrary URLs and node values makes this as future-proof as possible so we don’t need to constant revise the spec. Like always, apps can choose what information from the feed to expose to their users. They’re not obligated to show all the links provided, especially if the podcaster’s included links to social media, newsletters, etc. Apps can decided which links they want to display as icons by matching against the domain names of the URLs.

[redimongo]

@nathangathright <podcast:guid> is supported by PodToo, however I am going to be honest I don't see it catching on as we would like, the issue is some of these platforms already have indexed millions of podcasts, for them all to change it would be a technical nightmare.

I am not in favour of /.well-known/webfinger just never have liked those when managing large data. As a hosting provider we are more than willing to supporting <podcast:subscribe> but we need to have a clear understanding of what the limitations are.

The downside of the <podcast:subscribe> is that if we copy rawvoice owned by Buzzsprout we could be breaching their copyright as they own and control the rawvoice standard, and as a competing company in the space we would want to stay clear of what could be seen as a clear "copy & paste". So any suggestions on what / how ours would look?

As for point 4, we could improve on that by doing something like this.

<podcast:subscribe href="https://youtube.com/blahblah/livestream">YouTube</podcast:contentLink>

however it does not allow us to loop through them as easily when we are converting the XML to a Webpage. Therefor we would suggest. As it has a clear block and that section inside can be easily looped.

<podcast:subscribe>
       <subscribe platform="anycast" href="anycast  LINK"/>
       <subscribe platform="Apple Podcast" href="Apple Podcast LINK"/>
       <subscribe platfrom="Google Podcast" href="Google Podcast LINK"/>
</podcast:subscribe>

[nathangathright]

RawVoice is the parent company of Blubrry, not Buzzsprout, and here’s one of their cofounders proposing an evolution of their tags for the podcast namespace. I don’t expect any issues on that front.

I’m not opposed to a free-form platform attribute. My recommendation would just be to avoid defining a list of accepted platforms. Especially when it will be very difficult to get all parties in the namespace to agree on which platforms should be included.

I’m not at all familiar with the limitation of XSL templating. So I’m unclear if that’s a dealbreaker for what you’re trying to achieve.

[redimongo]

@nathangathright Thanks I knew it started with a B.. was on my mobile phone when I did my reply.

I red their idea, it's not bad and technically would or could replace a number of the tags that are already supported. however it seem the community has not yet decided on this and therefor we are stuck.

From our side, we need to start integrating something today, we can always change it later. From my experience dealing with XSL templating it could be done like this.

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:output method="xml" indent="yes" />

  <!-- Define the mapping between brand names and icon URLs -->
  <xsl:variable name="brandIcons">
    <icon brand="Apple Podcast">https://cdn.podtoo.com/icons/applepodcast.png</icon>
    <icon brand="Google Podcast">https://cdn.podtoo.com/icons/googlepodcast.png</icon>
    <icon brand="Spotify">https://cdn.podtoo.com/icons/spotify.png</icon>
    <icon brand="anycast">https://cdn.podtoo.com/icons/anycast.png</icon>
  </xsl:variable>

  <!-- Main template matching the podcast:subscribe element -->
  <xsl:template match="podcast:subscribe">
    <xsl:copy>
      <!-- Loop through each subscribe element -->
      <xsl:for-each select="subscribe">
        <xsl:variable name="platform" select="@platform" />
        <xsl:variable name="iconUrl" select="document('')//icon[@brand = $platform]" />
        <!-- Use xsl:choose to match the brand name and output the icon URL -->
        <xsl:choose>
          <!-- Match found, output the icon URL -->
          <xsl:when test="$iconUrl">
            <xsl:copy>
              <xsl:attribute name="platform">
                <xsl:value-of select="$platform" />
              </xsl:attribute>
              <xsl:attribute name="href">
                <xsl:value-of select="$iconUrl" />
              </xsl:attribute>
            </xsl:copy>
          </xsl:when>
          <!-- No match found, output the original element -->
          <xsl:otherwise>
            <xsl:copy-of select="." />
          </xsl:otherwise>
        </xsl:choose>
      </xsl:for-each>
    </xsl:copy>
  </xsl:template>
</xsl:stylesheet>

Personally I would rather make the podcast RSS feed have the icon file link but if we don't want to as a community then this would be another option. As others have said developers can choose to take what they want from an RSS feed, so this is only for those who want to style RSS this way. Personally I would rather have the icons in the RSS feed as then for our podcasts.podtoo.com webpages we can just grab the icons from there - it's more simple and less querying if all the querying has already been done.

It's truly just a developer choice.

[redimongo]

Hmm, in the best case scenario, companies will continue to innovate by creating more and more new platforms inspired by Podcasting 2.0. And this introduction of new platforms is completely orthogonal to the sorts of things that typically cause changes to a feed (e.g. a new episode is added), and your podcast will also pop up in new directories due to being crawled independently and not by explicitly submitting to them. As such, I would prefer this list of platform links to be a separate mechanism from the RSS feed... ideally.

Of course, idealism doesn't work in practice, so:

Maybe the podcast:guid based approach can be spec'd as the ideal solution for the platforms that support it, and then the entry in the feed can be used as a fallback for those platforms that don't support it.

As for how the podcast:guid approach could work, we could have an XML or JSON file in git that has URL patterns for each platform's slug. New platforms can submit pull requests to get added. Everyone can import that file into their apps in order to generate the links on the fly, and then fallback to links in the feed for the legacy platforms.

the feature is mainly only for if a user views your RSS feed in a browser that supports XSL viewing (safari does not)

Looking at your example, I have a feeling you don't plan to actually list "all" platforms, maybe just the most popular platforms (and popularity contests will favour the big companies that don't actually support Podcasting 2.0 at the expense of promoting the smaller ones that do). But if you do actually want to list all platforms and you have a means to do that, it can be done without necessarily putting it in the RSS feed. For example, you could generate a unique XSL for each RSS feed that presents this list of platforms to the listener.

Hi @ryan-lp thanks for all that information, it's really helpful. The only thing I would say is Podcast 2.0 players will be supported, however mainstream listeners the stats speak for themselves, people are listening via Spotify and Apple Music. I agree I wish we could make everyone switch to a podcast 2.0 player tomorrow, but it's not going to happen.

The industry is getting away from us, and it favouring the big players in the space.

Our commitment at PodToo is any Podcast 2.0 player that wants to work with us and get listed in our one-click directory we will put them to the top of our system. However we have to list Spotify & Apple Music as data from our platform shows that 85% come from these two players alone - that's data from January 2023 to end of June 2023 with 38 podcasts using our platform in Private beta mode.

[ryan-lp]

I would just mention that we have a list of "new podcast apps", so rather than waiting for authors of new podcast apps to contact you to get listed, it might be better to just copy the list of new podcast apps and display them.

Edit: Well actually this would not be the "new podcast apps" list, it would need to be the XML or JSON file that contains the list of URL patterns if you want to link directly to the guid on that platform.

[redimongo]

I agree, but from my conversations with a small amount of them they are scrapping their data from PodcastIndex or Apple Podcast, therefor we don't need to technically support them. If they decided that they wanted to move away from indexing or collecting data from 3rd party, then of course we would support listing them in our directory.

Note our "One Click Directory" is how podcasters submit their podcast to podcast players. So it makes no sense to support players that scrap the data from 3rd parties which we already submit to.

That does include players like Anycast - while a great player it sadly has no way for us a hosting company to send new listings to them. I have asked the developer and they said "we use apple podcast directory".

So why would we support a player/s that has no way for me to send a direct link or to fetch from them the url to listen to the podcast that we just submitted to them?

Edit: we want to show in the RSS feed of a podcast the following for example lets say anycast had a url we could call like "https://anycast.app/(PODCAST GUID)" which then sent the user to the anycast app. We as a podcast hosting company still need to know that they have (Podcast GUID) on their platform before we could start sending people to them. This is why it's important to have a API for hosting companies to check if a podcast is listed on a platform.

[redimongo]

Update 16-01-2024: As requested by a number of people in the community icons don't have to be included.

so goes from:

<podcast:avaliableOn>
       <avaliableOn platform="Spotify" icon="LINK TO ICON" href="SPOTIFY LINK"/>
       <avaliableOn platform="ApplePodcast"  icon="LINK TO ICON" href="Apple Podcast LINK"/>
       <avaliableOn platform="GooglePodcast"  icon="LINK TO ICON" href="Google Podcast LINK"/>
</podcast:avaliableOn>

to

<podcast:avaliableOn>
       <avaliableOn platform="Spotify" href="SPOTIFY LINK"/>
       <avaliableOn platform="ApplePodcast" href="Apple Podcast LINK"/>
       <avaliableOn platform="GooglePodcast"  href="Google Podcast LINK"/>
</podcast:avaliableOn>

note that allows us to link it internally as well. I think the recommended tag from contentLink would be a nice addition thoughts? as it could make all those recommended go to the top - or does that get messy?