Proposal: <podcast:embed>

[stpp2]

<podcast:embed><iframe src="https://podcast-embed-url.com/episode1234" height="100"></iframe></podcast:embed>

Most podcast hosts provide their own embeddable audio/video players. In most cases, it's either a pain to get those programmatically or you'll need a separate API call with some hosts to get the generated embed code.

This can be a simple solution, some hosting companies already do that within their own namespace.

[PofMagicfingers]

Hey! That's an interesting idea. Why not using link tags and Oembed ?

As a podcast host, you most likely either already have an oembed endpoint, or will be better with one : compatibily with many blog platforms, patreon through embedly etc.

[stpp2]

I agree - I expect all hosts to use oEmbed, but that's unfortunately not the case for many (if not most) podcast hosts.

[daveajones]

Any host input on this? @tomrossi7 @cio-blubrry @KieranMcKeefery

[cio-blubrry]

Pre oembed we made the same tag in the rawvoice namespace: https://rawvoice.com/services/tools-and-resources/rawvoice-rss-2-0-module-xmlns-namespace-rss2/ .

We also encouraged Podcasters to provide a embed (video or anything) with every episode. Todd Cochrane our CEO uses this with every episode on his website https://geeknewscentral.com You can see we provide the embed in his feed for the audio episodes. At some point Todd used YouTube but now he hosts the video himself and uses the video embed built into PowerPress.

We ingest the info in the Blubrry podcast directory. Years ago we would display the embed, but we had someone inject other HTML there in the past, which lead us not to be able to trust this syndicated information. Beyond this, we discovered the hard way that when you use other embeds, one episode page has one look and another looks different (some youtube and vimeo video player embeds, random audio players, etc...) Right away this confused people who visited our website. In our last redesign we stopped using the embed data.

I would want to see what the new goal is for this tag. The goal before was for the directory to use the player of choice by the podcaster, but as I mentioned that is problematic for UX/UI reasons. It also opens up the possibility of spreading malicious code into other websites. The bigger issue today (that was not there 10 years ago) was all of the mobile devices, the embed is less critical as it was in years past.

Good idea, but in practice it wasn't practical. oEmbed is an alternative, but again a directory today wants to make the UX/UI easy, they will not use the embed. The question comes where would you use it other than on your own website. oEmbed is good at letting you quickly insert the player on your site/blog which is cool, but not necessarily useful being syndicated.

[PofMagicfingers]

I agree on this with @cio-blubrry, I do not see a common use case for embed through the RSS feed, and if you really want it, as I said on my previous message, I guess you could use oembed discovery link tag, like we do on html pages.

[stpp2]

@cio-blubrry - I see your point, but as a clarification - I wasn't referring to "extra" content like video or anything like that - just an iframe/endpoint to get the audio embed code for each episode provided by the podcast host.

I know oEmbed is ideal, but as mentioned above, it's not supported within many of the hosting platforms.

The main use-case for that (IMHO) would be either for aggregators/apps who want to display separate players for each podcast (depending on its source) or when importing a feed to any existing website or anything like that.

[PofMagicfingers]

As podCloud, which is both a hosting platform AND a directory (and web app), here is my take on this :

• as a podcast directory, I would rather not include foreign iframe or limit it to the minimum. If I can use my own player I'll do it. In our case we are a webplayer, so of course we prefer to use our own player. However, if I wanted to include an embed for an external podcast, I think I would prefer using oembed and/or embedly if available, because I would find documentation and library allowing us to do it in a few lines of code anyway. But that's just my opinion

• As a hosting provider, I already have implemented an oembed endpoint on my service for people using WordPress, patreon and so on. I would rather add 1 link tag I already added to my web pages to the RSS feed, than adding a new tag adding more size to the already pretty large feed.

• As a developer, I'd rather use something existing and compatible than inventing something that serves the same purpose.

That's my opinion, but maybe some others here will see things differently

[stpp2]

Just wanted to throw something out there (well, it's 2+ years since this issue was initially opened but this could be nice anyways) - Could be really cool to have several embeds for every episode. For example, an episode can have multiple embeds for each episode (from Spotify/Apple Podcasts/YouTube or even custom ones) -

<podcast:embed type="video" source="youtube"><iframe src="https://youtube-embed-url.com/episode1234"></iframe></podcast:embed>

<podcast:embed type="audio" source="spotify"><iframe src="https://spotify-embed-url.com/episode1234"></iframe></podcast:embed>

<podcast:embed type="audio" source="apple"><iframe src="https://spotify-embed-url.com/episode1234"></iframe></podcast:embed>

<podcast:embed type="audio" source="custom"><iframe src="https://custom-app-embed-url.com/episode1234"></iframe></podcast:embed>

This can work regardless of if it's using oEmbed or not, it doesn't necessarily need be an iframe I guess

[theDanielJLewis]

~@stpp2, what would you think of putting this in chapters instead of in the RSS feed? I have a separate proposal (#469) for extending what chapters can do, including rich text formatting, image galleries, videos, and more.~

[stpp2]

@theDanielJLewis - love the idea, but I'm not sure "Chapters" is the right answer here. This may imply that those links are necessarily a part of a specific chapter or segment, but this doesn't have to be the case.

I guess these links (embeds / galleries / etc.) need to live under their own tag/name, but those references could definitely be included within the chapters perhaps at some point?

[theDanielJLewis]

Doh! You're right, @stpp2. I misread this and was thinking you meant supplemental, I'll strike my previous comment.

How might you foresee indicating the default. For example, if I built a script that would automatically embed the latest episode with your preferred player on a landing page. Would the absence of source be seen as the default? Or should we make source="custom" be the assumed default? Or maybe simply whatever is listed first (although I'm not a fan of requiring an order within the <item> tag)?

[stpp2]

I guess source could be optional, so default value isn't required? Maybe I'm missing something here but it seems fine to omit the source too.

Is there a suggestion that deals with item-specific external platform links? (Spotify/Apple...) Maybe this could be a better fit over there after all

[ericpp]

Technical note: Keep in mind that embed code is usually in HTML5 format and not always compatible with the XML format used for RSS. You would need to add CDATA tags around the embed code to avoid XML parsing errors when parsing the RSS feed: <podcast:embed type="video" source="youtube"><![CDATA[<iframe src="https://youtube-embed-url.com/episode1234"></iframe>]]></podcast:embed>