Using podcast:guid to pick up/support URL changes

tonytamsf · June 28, 2021, 6:14am

@ByteHamster what do you think of supporting the podcast:guid which would solve the issue of urls changing for those podcasts that adopt this?

github.com

Podcastindex-org/podcast-namespace/blob/main/docs/1.0.md#guid

# RSS Namespace Extension for Podcasting (Tag Specification)

A wholistic RSS namespace for podcasting that is meant to synthesize the fragmented world of podcast namespaces. As elements are canonized, they will be added to this document so developers can begin implementation. The specifications below are considered locked and the team will prioritize backward compatibility. We are operating under the [Rules for Standards-Makers](http://scripting.com/2017/05/09/rulesForStandardsmakers.html).

The namespace for this extension is `https://podcastindex.org/namespace/1.0`. Clients which recognize this namespace must also recognize `https://github.com/Podcastindex-org/podcast-namespace/blob/main/docs/1.0.md` as identical. The suggested tag prefix for use in XML is `podcast`, but clients should support alternate prefixes for this namespace. If your application generates RSS feeds and you implement one or more elements below, you will need to link this document in your XML:

```xml
<rss version="2.0" xmlns:podcast="https://podcastindex.org/namespace/1.0">
```

# Podcast Tags
Each tag below exists in the podcast namespace within the specified parent. All attributes are required unless explicitly specified as optional.

Anywhere the url of a hyper-text based resource is specified, it must be given as `https:` and not `http:`.

<br><br>


## Transcript
`<podcast:transcript>`

This file has been truncated. show original

ByteHamster · June 28, 2021, 8:06pm

If the publishers don’t manage to do a proper redirect (which was the use-case here), I doubt that they are able to set up the podcast:guid tag properly.

keunes · June 29, 2021, 6:27am

The idea is that transferring a podcast guid is much easier than setting an http redirect. A redirect needs the involvement of tech people when self-hosting as a bigger organisation, you must know how to do it yourself if you host your own feed, or you have to hope that your hoster has built a UI to set http redirects if you’re with a commercial hoster. Copy-pasting a code from your old to your new podcast hosting software, however, is evidently easier for your everage person (than setting up a redirect) and can be done independently (from tech people or your previous hosting company).

So I think that many podcasters will set this, if possible in their hoster. (At least more than there are http redirects, which already improve the situation.)

ByteHamster · June 29, 2021, 6:53pm

Both need support by the hosting software and have (from a technical perspective) pretty much the same complexity to implement. Just pasting a single code will also not make it work. The GUIDs of every single episode needs to match, too.

keunes · July 3, 2021, 4:55pm

True. The usual chicken-and-egg story. On a UX-level, much easier for podcasters than some server redirect.

Do you mean for the (technical) hoster, or for clients (podcast apps)?

Fair point, interesting. @benjaminbellamy How do you handle episodes when transferring feeds into Castopod from another place? Do you scrape all episode info or sth, including episode GUID?

ByteHamster · July 4, 2021, 6:16am

I meant the hoster.

Redirects are also easier for users. With the guid, they have to enter the new url manually and with the redirect, they don’t even have to realize that there are URLs involved - it just happens automatically.

keunes · July 4, 2021, 11:03am

Right. If the two are equally complicated for the hoster, but easier for the podcaster, GUID will probably get wider adoption

Well, that depends on the client adoption. If we implement a check against a repository (like we already have for search) and a changing mechanism (like we already have for server redirects), the user wouldn’t have to notice anything.

https://podcastindex-org.github.io/docs-api/#get-/podcasts/byguid

ByteHamster · July 4, 2021, 11:36am

That means we would basically have to regularly upload the full subscription list of all users to the podcastindex server. I would suggest to not do that for privacy reasons.