Using podcast:guid to pick up/support URL changes

Feature request
1

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

1 Like
2

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.

2 Likes
3

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

4

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.

5

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?

6

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.

7

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

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

8

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.

9

Hello. Great points on privacy.

I would like to see support for podcast:guid, however, as soon as possible.

My reasoning is a bit different, and so I am unsure if it needs a new title . . .

The tag of podcast:guid allows someone who stops listening to a podcast right before a change in the feed URL get back into the show when he or she returns a year or two later. By that time, the URL redirects are no longer valid. Our hypothetical lapsed listener has a new smartphone or Android-running device.

The same tag of podcast:guid appearing on a new fee would tell the lapsed listener that the “Big Barn” with the new URL in the feed is indeed the same “Big Barn” that he or she had enjoyed until fifteen months ago, and not one of the other five podcasts that coincidentally have the same name. (Let us assume that the title of the series is a fairly generic one.)

This persistence of the podcast’s own GUID is the reason.

N.b.: I do know that nothing stops someone from making a new podcast with a phony podcast:guid in order to mimic someone else and steal the prodigal listeners returning to the flock. The only way to stop that would be a digital signature that someone signs, but until that day—and whether we do the hierarchy of trust as with TLS and S/MIME or self-signed keys in the web of trust as with PGP or use quantum-proof algorithms—podcast:guid would be a fine step in the right direction.

Thank you for your time and progress on other fronts.

10

As a workaround for such case it is possible to edit podcast feed URL. To access it : podcast screen, info, edit feed entry in menu.
It’s an advanced option because it can mess subscription if someone is not knowing what he is doing. And there is no undo / recovery once you do. (There is a warning when you are about to apply)

11

Just how common is the issue of podcasts changing URLs? Not sure I have ever experienced it.

12

URL transitions are rare precisely because it so hard to migrate people unless you have reliable redirects.

Choosing a host for me came down to one over-riding aspect: having my own domain for the feed. I hold little trust in the vague promise that the hosting providers will never go out of business and offer reasonable terms for hosting a 401 redirect for a year after switching providers. They hold the feed hostage and can wield almost all the power.

I think we are at a chicken-and-egg situation where very few hosts implement podcast:guid and practically no programs do anything with the tag. Feed generators on hosting platforms see no reason to support the tag because no apps support it, and no apps support the tag because no hosting platforms support it.

I see supporting this as an existential matter, not a nice-to-have matter. We can have an eco-system where RSS feeds are rare and only gigantic series can move because Namey McNameface and mcnameface.com are well-known quantities, where proprietary apps and the hosting platforms hold all the power, OR we see an eco-system of RSS feeds and imperfect but easier transitions.

Literally the only reason for a hosting platform to insist on holding onto all feed URLs while seemingly allowing own domains for podcasts is to hold the feeds hostage, to make migration less likely. (Looking at you, Transistor.FM.) This state of affairs ruins the ability of customers to shop around or to bargain.

13

So how do you imagine this to work? The only scenario I could imagine would be:

  • Users notice that there are no new episodes anymore
  • They open the “add podcast” screen
  • Type the podcast name again
  • Click one of the results
  • AntennaPod notices that an existing feed has the same guid
  • AntennaPod throws together all episodes from both feeds and updates the url

This has a bunch of problems:

  • If the hosting platform doesn’t want you to migrate, why do they allow you to have a guid in the feed?
  • Users need to actively search
  • Malicious websites could MITM other feeds using a simple “subscribe” link
  • Given the number of messed-up feeds I have seen, users will end up with a complete mess of duplicate episodes because podcasters will not make sure that episode IDs match
  • Podcasters will definitely use guids like “abc”. This would then combine totally unrelated feeds together, creating an even worse mess with a mix between different feeds

For the two last points, users would blame AntennaPod even though it would be caused by the creators. And the creators will definitely mess this up. 50%-75% of the time AntennaPod needs to refresh feeds is spent on workarounds for podcast creators messing up their feeds.

I’m pretty sure most hosting services support redirects. Even if they don’t, a simple episode saying “subscribe to our new feed” would be way more reliable

14

Thank you for the attention and critical feedback.

Precisely what you outlined. Synchronizing the history of previously listened episodes is a big added value.

This has a bunch of problems:

  • If the hosting platform doesn’t want you to migrate, why do they allow you to have a guid in the feed?

Not every provider is like this. Blubrry, for example, is a for-profit business and would like you to stay, but it lets you have your own domain for the feed and also lets you set podcast:guid. That is the only American one like that. Other hosting platforms may kind of allow this, but I have only seen other successes with people self-hosting and writing their own RSS feed generators or using some open-source tool to generate the RSS feeds.

  • Users need to actively search

The users would have to, yes, but the persistence of podcast:guid would ensure that the playback history and settings would carry over.

  • Malicious websites could MITM other feeds using a simple “subscribe” link

True. Digital signatures could circumvent that, and podcast:guid would not be sufficient, but it would be a step in the right direction, methinks.

  • Given the number of messed-up feeds I have seen, users will end up with a complete mess of duplicate episodes because podcasters will not make sure that episode IDs match

Is this an argument against feed migration, period? I feel that discouraging that is beyond AntennaPod’s scope.

For the reasons I stated above, I think that discouraging feed migration is bad for the eco-system overall. Even if feed migrations are usually mishandled, if hosting platforms know that migration is more feasible, they would be less likely to engage in unethical and predatory practices.

  • Podcasters will definitely use guids like “abc”. This would then combine totally unrelated feeds together, creating an even worse mess with a mix between different feeds

Do you think so? I think most podcasters will not bother to customize the field for podcast:guid. Furthermore, bad actors who want to imitate other podcasts are already able to imitate the cover art and titles of popular series. I do not understand how adding podcast:guid support would make things worse.

For the two last points, users would blame AntennaPod even though it would be caused by the creators.

That is a very good point and a legitimate concern. To this, I would recommend hiding support for podcast:guid behind some settings option, off by default (at first or for the foreseeable future). Anyone who monkeys around with “advanced settings” is unlikely to irrationally blame AntennaPod. (I would hope!)

I also realize that this may be a bigger undertaking code-wise than I may think. So far, I think only closed-source applications have supported this. This means that there is no way, code-wise, to see what others had done.

But it is possible.

In any case, thank you for your time. (Questions and push-back are infinitely better than my being ignored!)