Proposal: <podcast:expire> to automatically hide episodes after a date

[theDanielJLewis]

In thinking of a new "promotion" episode type for #398, I had the idea of being able to make episodes expire with a <podcast:expire> tag.

This would follow the same format as <pubDate>, but we might think up some helpful attributes.

For example, I publish an episode to promote an upcoming meetup on December 16 at 6:00 pm (EST). So I give the episode the "promotion" (or "promo") type, and include:

<podcast:expire force="true">Sun, 17 Dec 2023 05:00:00 +0000</podcast:expire>

When midnight Sunday hits, the episode is considered expired and the podcast app can dim it or hide it all together—maybe even removing/hiding it from already-downloaded episodes (if the force attribute is true).

[jamescridland]

Isn't this best done at the podcast host?

[theDanielJLewis]

That's a fair question, and I would love to see more publishing tools support expirations.

I think this is better because it doesn't actually need the RSS feed to change, and with the force attribute, it could even remove an already-downloaded episode. Imagine this for something like "offer expires at midnight!" and then you don't want anyone confused by the continued presence of the promotion when the thing is already over.

[keunes]

it could even remove an already-downloaded episode

I don't think AntennaPod would ever implement this, and to be honest I personally hope no other app would either. Public broadcasters like Radio France only keep their less-recent episodes in their proprietary app and that's already horrible. Let alone they would be allowed to actively remove content from my phone.

Apart from hiding a 'trailer' episode which is no longer relevant (I see the use-case here), as you explained in #398, can we think of other situations where this might be useful?

[samsethi]

I like the idea of this where episodes have a time limit that can automatically be removed from a feed. This has to be a UI provided by hosts. As an app developer it would not be hard to implement. We already do something similar with LIT. We injest a pending feed and then using podping we change the status to live. This expire tag feels like the reverse. An episode is live until the expire date. A podping update would change the status of the feed and we could hide/remove it.

This idea inspired us. So today we added an option to Podfans in our user settings. So now after you finish an episode (or mark as played) you can choose to have it hidden from the list of available episodes on any podcast. This is not a host or RSS option. Listeners consume episodes on their client apps and this has nothing to do with hosts or podcasters.

So we have added this feature today for users on Podfans but it was inspired by this proposed tag.

[keunes]

I like the idea of this where episodes have a time limit that can automatically be removed from a feed.

Right. But the proposal of this tag is not (only) to remove it from the feed on the host side, but to expect a client to hide an item (episode) or even to remove it from the database, based on this tag.

[samsethi]

I like the idea of this where episodes have a time limit that can automatically be removed from a feed.

Right. But the proposal of this tag is not (only) to remove it from the feed on the host side, but to expect a client to hide an item (episode) or even to remove it from the database, based on this tag.

Indeed but hosts are being slow to implement (m)any of these new tags. So if/when a host supports a tag like this with instructions to 'force' a podcast episode to expire, I will support it 100%. But to break the chicken and egg problem of who should implement this first host or app. As an app developer I have implemented a solution to remove those episodes that are finished. The next stage is simply to have a TTL for an episode and we will make it as played/complete on the app side.

[theDanielJLewis]

I appreciate @keunes's thoughts! Maybe this "expire" feature should work on only "promotion" episode types.

However, even for a regular episode, I thought of another good use): fixing catastrophic mistakes.

In short, you could set the faulty episode to expire in the past and republish the fixed version. But this seems to be a rather clunky method, and it leaves the feed cluttered, so I'll propose a replaces tag (#449).