what _not_ to do in a podcast:alternateEnclosure

what _not_ to do in a podcast:alternateEnclosure

@js a while back wasn't someone talking about putting YouTube links in? Can't remember details but I feel like it was talked about on the podcast.

@js I think this is fine, with the exception of the content type maybe. Chucking a YouTube link in there should be just fine. But that's not in the specification; and perhaps it should be.

@james link to a web page is not an enclosure, apps have no (legal) access to the media

should be atom:link or podcast:contentLink

podcast-namespace/docs/tags/content-link.md at main · Podcastindex-org/podcast-namespace

A wholistic rss namespace for podcasting. Contribute to Podcastindex-org/podcast-namespace development by creating an account on GitHub.

GitHub (github.com)

@js I believe an exception here - with a faux content-type - should be considered. Agree, it isn’t an “enclosure” and is a horrible kludge; but it is an “alternate place to get this media”.

@james thankfully no kludge is necessary here, there is a structured way of expressing "here is this episode on another platform": contentLink

podcast-namespace/docs/tags/content-link.md at main · Podcastindex-org/podcast-namespace

A wholistic rss namespace for podcasting. Contribute to Podcastindex-org/podcast-namespace development by creating an account on GitHub.

GitHub (github.com)

still usable by apps and @nathan

if nothing means anything, why not use the image tag? it also has a url and a content-type

what is the argument _for_ putting youtube links in alternateEnclosure? Budget for rss tags exhausted? "I just kind of learned about this concept, incompletely, and it's sort of close"? I don't get it

@js @james And to chime in before a certain talking point rears its head: There's a persistent mischaracterization that `contentLink` would require apps to display outbound links that send users away from the app. This is false and needs to be corrected. Supporting `contentLink` doesn't mean showing outbound links. It means parsing URLs that describe where content exists and each app choosing for itself how to present them, if at all.

@js @james And to chime in before a certain talking point rears its head: There's a persistent mischaracterization that `contentLink` would require apps to display outbound links that send users away from the app. This is false and needs to be corrected. Supporting `contentLink` doesn't mean showing outbound links. It means parsing URLs that describe where content exists and each app choosing for itself how to present them, if at all.

@nathan @js I've stepped on a landmine, clearly.

What I *love* about Podcasting 2.0 is the capacity everyone has of saying "Oh, no, there must be a way to make this *MORE* complicated and harder to develop for."

Followed three years later with "Why is nobody supporting this tag?"