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.

[johnspurlock]

agreed, only suggestion would be to add a clear item-level example to the spec for folks wanting to associate a podcast episode with the associated youtube video watch page - for easy copy/paste

[nathangathright]

The current example YouTube URL is pointing to the watch page for a specific video: https://www.youtube.com/watch?v=RWPmCpKVPS8 + the podcast playlist the video belongs too &list=PLKLAQeES5doHtEgyGyAInyDDlG-MljkMX. Should we remove the playlist bit to clarify that item-level contentLinks shouldn’t point to "playlists"?

[johnspurlock]

yea when the time comes to draft a PR for this (maybe it's worth doing now?), I'm suggesting keeping the new item-level youtube example in the spec as simple to follow as possible, leave little to the wild imagination...

[johnspurlock]

Dave added the new parent element to the NS, here is a quick followup PR with that item-level example and other corresponding fixes: #652

[geeknews]

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

[jamescridland]

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.

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 don't see the clash here, but also see this as being (the first?) tag that TrueFans won't support, and I'd understand that entirely. Podnews would consume it.

[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>

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

[daveajones]

This change has been formalized.