<podcast:id> feedback

[cio-blubrry]

Currently the proposed method is to create multiple tags for each service. This is problematic as it is possible then for someone to enter the same service 2 or more times. Since you want a show to have 1 listing for each service.

Based on the current list of ID's found here: https://github.com/Podcastindex-org/podcast-namespace/blob/main/serviceslugs.txt (which look more like slug names than numeric IDs, I propose the slug name is the tag attribute name and the attribute value is the URL where the podcast is found in that said directory.

e.g.

<podcast:id apple="https://itunes.apple.com/us/podcast/geek-news-central-audio/id73331167" spotify="https://open.spotify.com/show/1CZaaddm3cjzb0EPVVQcVn" google="https://www.google.com/podcasts?feed=aHR0cHM6Ly9nZWVrbmV3c2NlbnRyYWwuY29tL3BvZGNhc3QueG1s" blubrry="https://www.blubrry.com/geeknewscentral/" android="https://subscribeonandroid.com/geeknewscentral.com/podcast.xml" email="https://subscribebyemail.com/geeknewscentral.com/podcast.xml" />

One thing though, this would mean that all slugs must start with a letter and be made of up only ascii letters and numbers, no spaces or other special characters. This would mean that podcasts.com and rss.com would need to be renamed to podcastscom and rsscom OR podcastsdotcom and rssdotcom.

Another benefit is that this is much stricter, the slug names have to be in the list defined by this RSS spec otherwise it cannot be used. Otherwise you run the risk of someone just throwing in what they want and then its not documented in this RSS spec it never gets used.

Further, I do not think the actual tag name "ID" is correct term. When we added this to the rawvoice namespace, we called it "rawvoice:subscribe", though maybe the term does not make as much since today. Perhaps the name "destination" or "platform" may be better?

The tag in the spec page does not state clearly what the goal is of the id tag, perhaps that needs hashed out first? If the goal is to provide links for a directory to show where you can subscribe to the podcast, perhaps we had it right in calling it the subscribe tag, but I see someone went out of there way to call it ID instead of subscribe most likely so it didn't look like it was copying Blubrry/RawVoice. It's ok, copy I give you permission. Again whom ever proposed this may want to explain the goal of the tag first which will flush out a better name for it.

ref: https://rawvoice.com/services/tools-and-resources/rawvoice-rss-2-0-module-xmlns-namespace-rss2/

[jamescridland]

I like this idea because the tags have to be defined before use. That shouldn't hold anyone back, but keeps things much less likely to fragment. This is a good plan.

This does lose the ID for each platform - but I wonder how important that is, or whether the consumer could parse the URL given to discover IDs if it's really important for them.

[daveajones]

I think it was me that proposed it originally, if I remember right. I remember calling it "id" because the goal was to be able to link a feed to it's presence in different platforms using just that platform's id. It was me thinking like a greedy programmer. :-)

For instance on Podcast Index, Podnews is identified with "227573". On Apple Podcasts Directory it's id is "1325018583". On the Blubrry directory it seems to be identified as "podnews___daily_news_about".

The idea was that if a feed declared it's identifiers on different platforms, it would cause less scraping and API calling to dig that information out.

I like the idea of just having the full link instead of just an ID. As James said, we can still parse that out. Using the slugs as attribute names feels so strange though. Maybe there is another way to do it. It's not bad. Just odd to see it like that. I can't quite put my finger on why it bothers me.

[cio-blubrry]

@jamescridland & @daveajones , What I proposed does look "odd" but it was a different attempt to support 49+ tag/values and have it be more strict that they have to be defined before using them. I am not married to the idea either but having them all at the channel level as separate tags is not helpful either. Perhaps we are trying too hard to avoid nested tags?

Nested tags may solve the problem, and also gives a XSL Template the ability to show them if the value's are set to something like...

<podcast:destinations>
    <podcast:destination type="social" slug="twitter" url="https://www.twitter.com/geeknews">Twitter</podcast:destination>
    <podcast:destination type="subscribe" slug="apple" url="https://itunes.apple.com/us/podcast/geek-news-central-audio/id73331167">Apple Podcasts</podcast:destination>
    <podcast:destination type="share" slug="facebook" url="https://www.facebook.com/share.php?u=https%3A%2F%2Fgeeknewscentral.com%2F&t=Geek+News+Central+Podcast">Facebook</podcast:destination>
    ...
</podcast:destinations>

This has the advantage of handling social, subscribe and sharing links in one XML list. A XLS Template could easily loop through and check the types and only display the subscribe links in one spot of the template and then loop through and display only the share tags in another part of the template. This could even handle "funding" as a type.

[daveajones]

Yes. That’s feels a lot better. I can get behind that for sure.

[theDanielJLewis]

I agree with @cio-blubrry on this. Using URLs instead of IDs also makes it far easier for app developers to support it by simply hyperlinking the text instead of having to maintain a list of URL patterns.

[cio-blubrry]

It could be links/link instead of destination/destinations..

<podcast:links>
  <podcast:link>...</podcast:link>
  ...
</podcast:links>

[saerdnaer]

Why not simply use the existing spec – where the URL is optional? Also you can skip the id for all services which use the feed url (android, email, etc.) or a hash of the feed url (like google podcasts) and use libraries like https://github.com/podlove/podlove-ui/tree/630c71d301b86ccc1988d951ecd96313a358e6d5/packages/clients npm to generate the concrete URLs.

Also keep in mind that apple has multiple urls for the same id, eg. for different languages etc.

In your example from the top this would compress down to:

<podcast:id platform="apple" id="73331167" />
<podcast:id platform="spotify" id="1CZaaddm3cjzb0EPVVQcVn" />
<podcast:id platform="google" />
<podcast:id platform="blubrry" id="geeknewscentral" />

Android and Email would be generated from the feed itself by the corresponding app / subscribe button.

Also keep in mind there is also an other tag for social media:

<podcast:social platform="[service slug]" url="[link to social media account]">[social media handle]</podcast:social>