Flag a feed for DELETION

[thebells1111]

Have we considered a way to automate feed deletion as opposed to asking one of the Index custodians to remove a feed? Something as simple as <podcast:txt>DELETE</podcast:txt> in the feed could be read by the parser and trigger the feed for deletion.

[theDanielJLewis]

While I can appreciate the concept, I think it might be unnecessary. If someone wants their feed completely unavailable, they can "delete" the feed URL and the apps can remove the feed after some number or time of repeated failures.

That's how many of the feeds get removed/deactivated from Apple Podcasts every day.

[picard102]

Returning a 410 response would probably be the least complex route.

[Kolomona]

That does make sense from the aggregator's point of view but there are other players in this space as well.

Least complex from one POV, very complex from another.

[picard102]

Who would this be for other than an aggregator, who would not be in any way forced to honour the tag.

[thebells1111]

I think what you're failing to realize is this suggestion has nothing to do with how all aggregators do things. It's about removing things from the Podcast Index. I'm only concerned with how the Podcast Index does things. As long as it doesn't break an aggregator (and this wouldn't), then it could be put into a feed, and the Aggregators that are concerned with staying up to date with how things are being done in the Podcast Index and staying in sync with the Index would be updated to take the new method into account. It doesn't take anything away from the other way of doing it, it's simply an alternative for those feeds that aren't able to do it the legacy way. Any of the apps doing the cutting edge stuff are relying on and are very in sync with how the Index does things, so if they did use this suggestion, the aggregators and apps concerned would know about it very quickly.

[picard102]

I think creating a tag for a single service is not a good use of the project.

[thebells1111]

It's not creating a tag. It's using a tag that already exists. It's called podcast:txt. The purpose of that tag is to allow for usages that might be niche or otherwise not rise to the level of needing a dedicated tag. This is exactly what this suggestion is for, a niche use case for a very specific purpose for a very specific Index.

[daveajones]

What would the DELETE be expected to do? Just remove from directories or more complete than that?

[theDanielJLewis]

If people are leaving their feeds on CDNs, then they're not going to add any kind of "delete" tag.

Apple cleans up their catalog by removing podcasts that have no episodes in the feed, the feed fails repeatedly, or sometimes when all the episodes fail to download (though I have yet to document that for sure).

[thebells1111]

I don't really care how Apple does anything. I'm just trying to save some hassle for the Podcast Index guys that get asked to remove feeds from the Podcast Index when someone double posts their feed in two locations and wants one of them removed. This is simply an idea to save those guys a bit of time and effort.

[picard102]

I've seen several musicians hosting their own feeds that don't want a duplicate album in the Index when they change hosting solutions

They should be redirecting the feed.

[thebells1111]

They sometimes can't. If they host their feeds on something like Digital Oceans Spaces they don't have the ability to control redirects. There's absolutely no reason for them to need to host a separate server just to handle a redirect when we can easily add something in the feed to indicate that this is a now a dead feed.

I think what everyone is failing to realize is this is a problem that pops up 2 or 3 times a month for the Podcast Index team where someone asks them to go in and delete a feed manually. All the solutions being offered aren't working 2 or 3 times a month. I'm not asking for a new tag, I'm asking if the Index wants to use an existing tag that saves their maintenance team from doing manually something that could be done automatically.

[picard102]

That doesn't seem like a significant amount of requests to necessitate this, especially on a single platform. There seems to be a number of ways to deal with this already that have been outlined here.

[thebells1111]

I thought of another use case. Say I'm a music app, and I'm letting users create playlists to share songs using something like podcast:medium=musicL, and I want to be able to let the user delete the play list. I want it to be as quick as possible, not waiting for a bunch of redirects and failed downloads and stuff. I want to add a DELETE flag to the feed, podping the Index, query the Index 90 seconds later, verify the feed is removed, then delete the feed from my database. Now all the music apps also have the feed deleted, just as the user intended, and I'm not getting tech support questions the next day asking why the playlist is still showing up in a different app.

[jamescridland]

I want to add a DELETE flag to the feed, podping the Index, query the Index 90 seconds later, verify the feed is removed, then delete the feed from my database.

• Delete the feed (ensuring it gives an HTTP 404 error)
• podping the index
• I would expect that to remove your show (potentially after a safety period of a few tries, just in case you didn't mean to remove it).

I would also suspect that were you to podping the index a few times in quick succession, that would ensure that it was fully removed almost instantly, given typically the safety period would be a total number of errors.

What might make sense is if HTTP 410 Gone responses were treated as instant, whereas HTTP 404 Not Found were treated as failed (and thus subject to the usual safety checks) - but that's up to @daveajones

[thebells1111]

I don't know if this will work, but I'm going to experiment with it to see if it does.

Sadly for some of the feeds, controlling the HTTP response isn't so easy because they're simply hosting a file on a CDN, and I'm not sure how easy it is to set the response code when not running an actual server.

Again, this is really just to cut down on Delete From the Index requests to the Podcast Index Maintenance team. How it's done isn't that important to me, as long as it's possible for all of the feeds in the Index, not just ones hosted on a traditional server. So if this works, then that's great.

[picard102]

this is really just to cut down on Delete From the Index requests to the Podcast Index Maintenance team.

Have they requested this at all?

[jamescridland]

Sadly for some of the feeds, controlling the HTTP response isn't so easy because they're simply hosting a file on a CDN, and I'm not sure how easy it is to set the response code when not running an actual server.

CDNs still need hosts (a CDN is essentially a mirror of a file that exists on a server somewhere, even if that server is a static file host like Amazon S3). CDNs can all set HTTP responses. Here's a 404 on a CDN (via a PHP server); here's another 404 on Amazon S3.

this is really just to cut down on Delete From the Index requests to the Podcast Index Maintenance team

Do we know how many they have? Podnews has about one every six months, which is why I've not bothered making a system to deal with them.