Proposal: <podcast:follow> tag and JSON spec

[nathangathright]

Purpose

Matching feeds to their corresponding URLs in third-party podcast apps can be tricky. The follow tag would allow podcasters to verify their presence on various platforms by providing an array of URLs in a linked JSON file. This is particularly useful for locating shows on platforms with no public lookup methods or identifying shows with common names like “Real Talk” in platforms that only provide a search API.

This tag will be of little use for most podcast apps, but podcasters that want to take advantage of universal link services (like episodes.fm) wouldn’t need to create accounts just to fix an incorrect link or add a missing one.

Parent

<channel>

Count

Single

Attributes

• url: (required) A URL pointing to a JSON file.

Example

<podcast:follow url="https://examplehost.com/feed/12345678/followlinks.json"/>

---

JSON Format

This is the initial spec for a JSON format that can be referenced in an RSS feed using the <podcast:follow/> tag. This file can reside on any publicly accessible URL. This file should be served with a Content-Type of application/json and a Access-Control-Allow-Origin header set to *.

Permissible Link Guidelines

This spec does not restrict permissible domains or multiple links to the same domain. Keeping it flexible allows new use cases to emerge without modification to the spec. Hosts may choose to only permit familiar domains, and developers may choose to ignore unfamiliar or repeated domains. For your convenience, here’s a repo of common podcast link patterns.

JSON Keys

• version: (required - string) The version number of the format.
• links: (required - array) An array of link objects.
  • href: (required - string) A URL pointing to an external platform representing the same content as the parent tag.
  • text: (optional - string) A free-form string meant to explain where this content link points and/or its purpose to the user.

Examples

Basic Example

{
  "version": "1.0.0",
  "links": [
    {
      "href": "https://podcasts.apple.com/us/podcast/feed/id1325018583?ls=1&at=11lo6V&ct=i8xe9",
      "text": "Listen on Apple Podcasts"
    },
    {
      "href": "https://open.spotify.com/show/5s9hHFr8VJARyg0QkghSF1",
      "text": "Listen on Spotify"
    },
    {
      "href": "https://music.youtube.com/playlist?list=PLusOJN4fPK_u0dMxl_xRCTNT1GKaM6vtU",
      "text": "Listen on YouTube Music"
    },
    {
      "href": "https://music.amazon.com/podcasts/bfe17258-0f9d-43db-8a31-c7f921fd7c5f/podnews-daily---podcasting-news",
      "text": "Listen on Amazon Music"
    }
  ]
}

Multiple links to the same domain

Hosts may choose to permit only a single link per domain. However, if a feed contains multiple links to a platform, they should all point to the same "show," such as separate audio and video feeds. Developers may choose to ignore duplicate domains.

{
  "version": "1.0.0",
  "links": [
    {
      "href": "https://podcasts.apple.com/us/podcast/geek-news-central-podcast-video/id348655557",
      "text": "Apple Podcasts (video)"
    },
    {
      "href": "https://podcasts.apple.com/us/podcast/geek-news-central-podcast-video/id348655557",
      "text": "Apple Podcasts (audio)"
    }
  ]
}

Social links representing the podcast

While the intention of this tag is primarily to provide links to podcast apps where a user could "follow" the show, that technically includes social destinations as well. Developers may choose to ignore links that don’t suit their use cases.

{
  "version": "1.0.0",
  "links": [
    {
      "href": "https://mastodon.social/@atpfm",
      "text": "Mastodon"
    },
    {
      "href": "https://www.threads.net/@atp.fm",
      "text": "Threads"
    },
    {
      "href": "https://twitter.com/atpfm",
      "text": "Twitter"
    }
  ]
}

[nathangathright]

I’d really love to see this proposal make it into Phase 7, but that’s not going to happen without more hosts expressing interest in adoption. Otherwise, I’d appreciate any feedback or concerns that are dealbreakers. @snookfin @albertobeta @mijustin @bmaluijb

[nathangathright]

@picard102 I'm sorry. The way I structured my examples may have implied separate JSON files, but my intention was a single follow tag with whatever links they might want to include in a single JSON file. I don’t find the distinction meaningful, and apps are free to present some/all of the links however they want.

[samsethi]

Happy to support it as we already have social links in our user settings and if we can read them from the RSS feed it makes populating the fields easier. I think we will need to this for the new ActivityStream work. So +1 for TrueFans. I also reserve the right "Developers may choose to ignore links that don’t suit their use cases." ;-)

[picard102]

@picard102 I'm sorry. The way I structured my examples may have implied separate JSON files, but my intention was a single follow tag with whatever links they might want to include in a single JSON file. I don’t find the distinction meaningful, and apps are free to present some/all of the links however they want.

My concern would be without an indication for what it's intention is, when new services get added it could leave providers and platforms behind the 8 ball unless there was a distinction for what the links purpose was other than simply an external link.

[rpeterman-gp]

Being able to have both subscription and social media links, without an explicit distinction of the links purpose, places a large burden on developer to maintain complicated pattern matching to filter links based on the href value. If the follow link objects included a type property, filtering links would be much easier to develop and maintain.

• type: (optional string) A string describing the type of link. Valid values are subscription or socialmedia. When omitted, developers should assume subscription as the default type.

[nathangathright]

@rpeterman-gp I’m sympathetic to those concerns. I’m not opposed to adding a type attribute if people think it has merit.

For my purposes, I’d accepted the burden of filtering links because Episodes.fm will only display links from a list of pre-approved domains. That’s partially due to needing icon assets for each platform, but more importantly, displaying unfiltered arbitrary links on the web seems like an invitation for spammers to abuse a service. If you’re filtering anyway, then a "type" attribute felt redundant to me.

[bmaluijb]

Also happy to support this as we already have the info in Podhome, although the usage of this will of course be very limited. Sent from Outlook for iOS<https://aka.ms/o0ukef>

…

________________________________ From: Sam Sethi ***@***.***> Sent: Thursday, April 11, 2024 7:32:46 PM To: Podcastindex-org/podcast-namespace ***@***.***> Cc: Barry Luijbregts ***@***.***>; Mention ***@***.***> Subject: Re: [Podcastindex-org/podcast-namespace] Proposal: <podcast:follow> tag and JSON spec (Discussion #609) Happy to support it as we already have social links in our user settings and if we can read them from the RSS feed it makes populating the fields easier. I think we will need to this for the new ActivityStream work. So +1 for TrueFans. I also reserve the right "Developers may choose to ignore links that don’t suit their use cases." ;-) — Reply to this email directly, view it on GitHub<#609 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AD6C7Y2PH6GYZ5ERLHFPRJDY43CL5AVCNFSM6AAAAABDD4LF52VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TAOBXGA2DG>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[Dwev]

Castopod has this information and uses a non-official tag to publish it, I think it would be trivial to change it in the rss feed. Is the intent here to move all these links to a linked JSON file though?

Also, if a podcaster specifies 3 or 4 player apps in their feed, would services like episodes.fm prioritize those in the list of app links for that podcast? I don't care about putting what is popular or first in the alphabet high on the list, I want to promote the apps that work best for my feed and that I support the work of.

[nathangathright]

@Dwev Yes, I originally proposed a method that added these links directly to the feed, but I received pushback from hosts.

Episodes.fm will definitely be using these links to supplement missing or incorrect links, and I’m still deciding how to emphasize these links. I was considering a verification checkmark to indicate that the RSS feed has endorsed these links. (à la Mastodon verification of domains)

The OP3 integration in Episodes.fm already tailors the sort order for the existing audience of participating podcasts. So I would have to figure out a way to factor that in alongside how I’m handling the availability of different apps on different operating systems.

[theDanielJLewis]

I like this idea and I've supported past proposals for similar functionality.

But I don't see why this should be a separate JSON file.

[nathangathright]

ok

[daveajones]

Also, PodLove chapters is being included in many feeds now (recently added) and that bloats the feed a lot too. I guess each feature gets evaluated on it's own merit whether it's worth the size increase.

[daveajones]

To be clear, either way seems fine to me. Adding to the feed seems easier for a universal tag like this though. 🤔

[nathangathright]

I don't have a strong stance here—my initial proposal was to expand contentLink to the channel level, which sparked a lengthy debate. If someone wants to revisit that, they’re welcome to take up the challenge.

It might help to consider this from two angles: host adoption likelihood and app adoption likelihood. Most tags aim for high app adoption, and linking to an external file introduces unnecessary complexity for minimal bandwidth savings. However, this tag might be an exception: it’s aiming for high host adoption but may be ignored by most players. (It’s more useful to niche clients like Episodes.fm, Podnews, Podpage, etc.) I can’t speak for the hosts and apps bearing the burden of this type of tag, but I’d be interested in hearing their perspectives on the matter.

[jamescridland]

@nathangathright I would prefer, because I'm incredibly lazy, to have it within the feed. Having it outside the feed appears to add complexity to podcast hosts as well as those consuming the data. It's likely that I'll not implement it as quickly if it's a separate file. But I'm - to be fair - relatively unlikely to implement it unless there's a strong amount of adoption.

[jamescridland]

My suggestion would be not to achieve this within the RSS feed at all.

Every RSS feed comes with a to a website. It's mandatory for Apple Podcasts, incidentally, to have this link. (They don't actually police that; but there we are).

It makes sense for us to encourage the use of structured data within that linked website, rather than an additional set of structured data which is not useful for anything other than a podcast app. There are hundreds of articles on structured data, generators to produce it, and libraries to consume it.

This testing tool uncovers the schema information held within Podnews's homepage. You'll note that the "Organization" bits include links to Podnews's social media presence. There's no particular reason why you wouldn't want to make this information available to any consumer of structured data - like Google, Bing or Facebook.

There are two different ways to put Schema structured data into documents. The easiest is to simply use microdata and mark links as "sameAs", like this:

<div itemscope itemtype="http://schema.org/Organization">
  <link itemprop="url" href="http://www.your-company-site.com"> 
  <a itemprop="sameAs" href="http://www.facebook.com/your-company">FB</a>
  <a itemprop="sameAs" href="http://www.twitter.com/YourCompany">Twitter</a>
</div>

or use JSON-LD, which is what I use - like this (I've chopped this down a little):

<script type="application/ld+json">
{
    "@context": "https:\/\/schema.org",
    "@type": "NewsArticle",
    "headline": "Podnews podcasting news",
    "datePublished": "2024-10-31T10:59:00+00:00",
    "dateModified": "2024-10-31T11:07:02+00:00",
    "publisher": {
        "@type": "Organization",
        "name": "Podnews",
        "url": "https:\/\/podnews.net",
        "foundingDate": "2017",
        "sameAs": [
            "https:\/\/www.linkedin.com\/company\/podnews",
            "https:\/\/x.com\/podnews",
            "podnews"
        ]
    },
    "copyrightNotice": "\u00a9 2017-2024 Podnews LLC",
    "copyrightYear": "2017"
}
  </script>

In the above cases, I'd link to my presence on Spotify, Amazon Music, etc, just as a sameAs.

Benefits are - better SEO for everyone; an existing standard; existing libraries to scrape it; and everything. Every podcast has (or should have) an associated HTML website anyway. Podcast hosts can automatically enable this for hundreds of thousands of customers with one code change. All podcasters can use this, irrespective of where their RSS is hosted.

Downsides - there's no doubt that fetching the full HTML for https://podnews.net (in this case) is more than fetching a teeny-tiny JSON file.

[jamescridland]

...and, just to add to that...

Buzzsprout hasn't added structured data to https://weekly.podnews.net/ - but a scraper could easily already see the Spotify link directly from this page.

Podpage - https://www.boostagramball.com uses it - appears to have implemented two pieces already: "site navigation element", and "PodcastSeries", which is interesting, because guess who else supports PodcastSeries: Podnews does. Oh, and Spotify does. (Typically, Apple Podcasts have gone their own way).

[kookster]

this is a similar approach to open graph, relying on the site rather than the feed, I'm not against it, but require coordination between the two, where having a podcast host provide both the rss feed and info on following it is a bit simpler.
Maybe both is an answer? link either to a json file, or a site with schema on it?

[nathangathright]

If hosts prefer to organize around structured data, I’ll gladly support that. However, if they haven’t already implemented structured data just to improve their SEO rankings, I’d be very pessimistic about them adopting it now for a niche feature.

The feed is the source of truth for the podcast. For better or worse, that makes it the API for talking to third parties. Moving a tag’s data elsewhere is tantamount to killing it. Since several hosts have already expressed interest, I’d love to hear more chime in.