Proposal: contentLink Enhancement (Revised)

[nathangathright]

Purpose

contentLink was initially proposed in the context of liveItem to allow podcasters to provide external destinations where the same livestream can be consumed. Expanding that to include support for on-demand episodes would enable podcasters to link to alternate versions of the same episode, such as a video version on YouTube or an extended, ad-free version on Patreon. Apps that support this tag could treat it like an external version of alternateEnclosure.

Parent

<item> or <podcast:liveItem>

Count

Multiple

Node Value

The node value is a free-form string meant to explain to the user where this content link points and/or the nature of its purpose.

Attributes

• href: (required) A URL pointing to an external platform representing the same content as the parent tag.

Examples

Item-level contentLink

<podcast:contentLink href="https://patreon.com/posts/public-episode-83079838">Listen on Patreon</podcast:contentLink>
<podcast:contentLink href="https://youtube.com/watch?v=RWPmCpKVPS8&list=PLKLAQeES5doHtEgyGyAInyDDlG-MljkMX">Watch on YouTube</podcast:contentLink>

[daveajones]

This seems like a simple change that would add a lot of flexibility.

[geeknews]

If this can be approved and put in a release stack this would help fix the pending clash of the Alternate Enclousre

[nathangathright]

An alternateEnclosure is a link to a media file that plays the same (or similar) audio/video. It is absolutely suitable for TrueFans to ingest.

@jamescridland I 100% agree with this, which is why I’m confused that we’re claiming that a YouTube link is a media file. Adding them to an alternateEnclosure with type=mp4 isn’t appropriate for these links. Please help me understand.

A contentLink is a tool for directories and search engines to help link a visitor to the platform of their choice. It is absolutely not suitable for TrueFans to use - why would you link away from your platform?

I’ve been very clear that I don’t expect players to link out to competing players.

If players want to embed YouTube content in their app and we agree that a YouTube link is not a media file, then I’m open to any suggestions for the best way for feeds to provide these YouTube URLs that doesn’t break existing implementations of alternateEnclosure.

[jamescridland]

A YouTube link isn't a media file. It's also incorrect to add a mimeType of "video/mp4" to it, because you're not linking to a media file. It's not an alternateEnclosure, to my mind.

But it could be a special case - if you see "youtube.com" in an alternateEnclosure (with a v attribute), then you know how to deal with it. I'd suggest it simply doesn't have a mimeType because it isn't a file. (Or, text/html if you must). Right now, the mimeType ought to be parsed by a player and it should know which mimeTypes it can play and which it can't. I'd hope no iOS device is using my audio/opus alternateEnclosure, as one example, because it won't play it.

So it might be simply that: "If an alternateEnclosure does not have a mimeType selected, then the player should make a decision on how to deal with that URL by itself".

There is, of course, the <link> tag, which could, I guess, have a rel="youtube" attribute?

The media namespace allows links to embedded players. It's a namespace used by YouTube for different-sized episode images. It's supported by Omny Studio and others. But, this is an audio player and not a video one, so... I don't really know what to suggest.

<media:content url="https://traffic.omny.fm/d/clips/ad4ac715-121e-4de7-98e9-a5da0072a7a0/8d94b967-a751-481f-a663-a5da0082be6b/18de2768-6648-4b6e-acd7-b14e014806e4/audio.mp3?utm_source=Podcast&in_playlist=07a7a7f4-0393-4915-8753-a5da0086dece" type="audio/mpeg">
<media:player url="https://omny.fm/shows/game-changers-radio/the-more-the-ferrier/embed"/>
</media:content>

[samsethi]

Oh well don’t worry. Lets not bother. Let’s give YouTube a free run. No traditional host wants to actually support video. It’s too expensive is the common response.

So instead many podcasts have a dual strategy of audio podcast and then a separate video podcast on YouTube. Eventually podcasters will not bother to have a separate audio podcast on traditional hosts as they can have both on one channel in YouTube. Spotify already offer a proprietary Alt Enclosure switch between audio/video and I am sure Apple can easily offer a proprietary Alt Enclosure when they want.

Trying to get hosts to support the Alt Enclosure tag is like pulling hen’s teeth. The solution I offered (and will now remove from TrueFans) allowed podcasters to maintain there dual strategy but would also allow any P2.0 app to display the YouTube Video inside their apps with YouTube baring the hosting cost.

Instead we want users to click an external content link ( which no sensible P2.0 app will support) leave the P2.0 app to watch the YouTube video. Oh well YouTube wins again. :-(

[nathangathright]

@samsethi For the last time, no one is asking apps to link out to competitors.

I hope TrueFans moves away from requiring feeds to use type="video/mp4" to enable this feature cause I think it’d be a shame to break existing implementations of alternateEnclosure. Either adopt something like type="text/html", propose a new attribute, or ignore attributes altogether and parse the URL for YouTube URLs.

[jamescridland]

Instead we want users to click an external content link

No, we don't. But we do want to help app developers understand that this YouTube link is not a link to a video/mp4.