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

[picard102]

Ah good to know. The social usage might also intersect with podcast:social. But if this is the path forward for both tags, it might be good to specify in the tag what the intention of the JSON list is if it's going to be used for both cases, ie <podcast:follow url="https://examplehost.com/feed/12345678/followlinks.json" type="socialmedia"/> or <podcast:follow url="https://examplehost.com/feed/12345678/followlinks.json" type="platforms"/>

[albertobeta]

We'd be happy to support <podcast:follow>. It's a low hanging fruit for us as we already have this information in our DB so consider us in.

[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.

[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.