Retracted contentLink Proposal #589
Replies: 9 comments 73 replies
-
|
Sure technically you could do it that way, but realistically what we have found is that podcast apps don't read this data. We are PodToo use availableOn as it is integrated into our UI design for podcast websites that we generate at PodToo. We also use it in our soon to be released iOS app. While I agree a unified approach would be great, we needed away to go this link equal that logo and that's why we went with our version. While we technically could do that with your version, it's a little harder. Also if let's be honest these links are designed to be viewed inside a podcast player, I don't think many podcast apps would do that. The idea is keep people inside my app doesn't matter if it's a P2.0 app for not. I think we what we truly need is a global search API that lists back all podcast apps that have a podcast and then generate these links automatically. Mainly because Spotify and Apple now don't have public API for hosting companies to submit podcasts. Well at least they not sharing it with us. Oh one last thing, I do like your live idea for multiple liveItem links. But I thought the liveItem links were so podcast apps could play live streams in their app. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, for items, there’s definitely a chicken-and-egg problem. But just like feeds don’t know their channel-level URLs before publishing their first episode, the feed can be updated after the fact when it serves the podcaster to do so. Addressing the bloat comment too, this spec isn’t requiring feeds to provide links to all platforms for all episodes. It merely provides a standardized way to do so. Hosts will balance the tradeoffs of including tags as they see fit. Even just including the show-level Apple Podcasts URL would ensure that sites like Podlink and Podnews could generate 15 show links correctly without additional API lookups. In my opinion, all podcast apps should provide a lookup method that accepts foreign keys, whether that’s a URL, a In general, this crowd is averse to single points of failure like a centralized database. I’m going to build one anyway, but that’ll rely on fragile scraping methods, liable to break at the whims of each platform. I have no expectation that I could convince any significant number of podcasters to create accounts, verify ownership of their feeds, and manually provide their episode links. So, advocating for an in-feed method to point to platform URLs seems like a necessary fallback, fitting with the original intention of the contentLink tag, and this method feels like the cause most likely to find traction. |
Beta Was this translation helpful? Give feedback.
-
I've done similar, as you know - scraping a number of additional sources. While we use our own ID numbers, like https://podnews.net/podcast/i5hv2, you can also programmatically use the following to link here (they’ll redirect):
Now, a little feedback... This proposal uses very fragile names - "Apple Podcasts" - and I'd be keen for the proposal to have a master set of valid values for the directories. I'd also prefer not to have mixed parameters and values, and would push for: |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the feedback @jamescridland! I was just copying the existing contentLink spec which included values like "Live on YouTube!" So I wasn’t expecting the values to be reliable for programmatic parsing. For instance, I could imagine a podcaster including two YouTube links: That said, we do have serviceslugs.txt if we really need a list of permissible destinations, but I wasn’t convinced that was necessary to restrict as part of the spec itself. Some of the prior art included links to social media profiles, newsletters, merch, etc. Leaving it up to the discretion of podcasters and/or their hosts doesn’t imply that services like yours and mine must display all links. Certainly for my own uses, I was expecting to filter them against a list of acceptable domains. |
Beta Was this translation helpful? Give feedback.
-
Putting my idealistic pipe dream hat on:
But I think the database idea suffices in the meantime because it's workable, and I see bloat as a major issue to keep in mind for any proposed addition to the feed, particularly if it is per item. It would be very easy for the costs of crawling and injesting RSS feeds to double as a consequence of this proposal being widely adopted.
I have a similar issue with the podcast index API, and I think it would be nice to look at ways to facilitate easier replication and syncing as is done with, say, Linux distros. |
Beta Was this translation helpful? Give feedback.
-
|
@ryan-lp Ha! Maybe I shouldn’t have offered to advocate for "any" suggestion! |
Beta Was this translation helpful? Give feedback.
-
We do. I'm always a fan of something that's programmatic, rather than free text. It allows icons and other clever things, as well as validation.
Indeed. In fact, I'd suggest services like ours would use these as overriding values - and that we'd still need to scrape iHeart/Global etc if they're not listed here. |
Beta Was this translation helpful? Give feedback.
-
Exactly how I was intending to use this tag!
I’m not opposed to an |
Beta Was this translation helpful? Give feedback.
-
|
I forgot that I’d already made my own list of apps that might have podcast URLs for my podcast-badges repo. |
Beta Was this translation helpful? Give feedback.
-
These are great, Nathan. We should use these for Podnews. Any reason why you don't have an "issues" tab in Github? I'd suggest removing Stitcher, and changing Podfans to TrueFans (the icon is the same). You might also want a logo specifically for YouTube Music. |
Beta Was this translation helpful? Give feedback.
-
You might want to be cautious doing that, as this might violate trademark law. I won't track down the individual terms for each of the logos you're using, but just to take Google's trademark: https://about.google/brand-resource-center/rules/
|
Beta Was this translation helpful? Give feedback.
-
|
I’ve collated a few of my lists to produce a non-comprehensive list of podcast platform slugs and domains, which this tag might link to. To be clear, I wouldn’t expect feeds to include the vast majority of these. With almost 60 domains on the list, I just wanted to explore the challenge of maintaining a list of valid values for an |
Beta Was this translation helpful? Give feedback.
-
|
One suggestion - an additional (optional) value in the RSS, marked This should appear ONCE in the list of contentLinks, and should link to the podcast app that the podcaster recommends. If it does not appear, no recommendation is given. (If it appears more than once, that's a broken specification: and the directory might choose the first one in the list.) This allows a podcaster to recommend a specific platform that they might wish you to use. As examples, Adam is currently promoting Podcast Guru on his podcast, and by adding the Podnews would support this, I think, if we saw it in a feed - either as the only main link we give a user, or we'd ensure that it's one of the highlighted links at the top of the page. This has obvious benefits for value4value apps, but also for apps that respect the creator. |
Beta Was this translation helpful? Give feedback.
-
|
In the interest of persuading hosts to adopt this tag, I’d prefer to keep it as simple as possible. For hosts that want to be spec-compliant, any new podcaster-facing setting (optional or not) dramatically increases the scope of work. They have to add it to their UI, explain why podcasters should care, and answer support queries about where it’s implemented. As the spec is currently written, though, hosts that already show badges on their websites could start supporting the contentLink tag in their feeds without any new UI. The Venn diagram of “listeners willing to switch podcast apps for a specific show,” “recommended app is available on the listener’s device,” and “services that will take advantage of this attribute” has a very small intersection. In my opinion, that doesn’t provide enough value to justify the additional burden to hosts. |
Beta Was this translation helpful? Give feedback.
-
|
I like the idea of highlighting particular platforms over others. "featured" could be another term. Or if we want to carry over a different resurrected idea, "pinned." That might be more understandable because the whole list is essentially recommended apps. But which ones should be featured above the others? |
Beta Was this translation helpful? Give feedback.
-
<channel>
<podcast:contentLink href="https://podcasts.apple.com/podcast/id1584274529">Listen on Apple Podcasts</podcast:contentLink>
<podcast:contentLink recommended href="https://truefans.fm/podcasting-20">Listen on TrueFans</podcast:contentLink>
...
</channel>Maybe you mean |
Beta Was this translation helpful? Give feedback.
-
|
You can achieve that by using @nathangathright 's podcast badge lookups, looking for the domain that the link is for. Better not to let the user select an icon; it'll be all kinds of ugly incompatible nonsense. Does this link contain "open.spotify.com"? Excellent - here's the Spotify icon in the format I want to use in my website/app. You only have to visit twenty podcast websites to see twenty variants of the Apple Podcasts logo! :) |
Beta Was this translation helpful? Give feedback.
-
|
@redimongo Is there another use case for the icon attribute besides a host’s own XSL templates? Is there anything stopping PodToo from putting icons in their feeds/XSL templates today? I don’t see why it needs to be a part of the spec to achieve your goals. |
Beta Was this translation helpful? Give feedback.
-
|
@nathangathright this is a nonnegotiable requirement for us, as we use the XML data to show on whitelabel client websites, our oEmbed frame and also our iOS and Android apps (when ever is applicable). Note this is the advantage of the We won't be supporting any new tag that replaces that tag without this requirement. |
Beta Was this translation helpful? Give feedback.
-
|
@redimongo Looks like you won't be supporting this tag then. It's madness to get a podcaster to add an icon, when icons are a) up to the platform to display, not the podcaster; b) should be consistent throughout an entire platform, not up to the podcaster themselves; c) trivial to parse a URL and work out which icon to display. Just to illustrate this, and put this idea to bed - here are "the Apple Podcasts icon" from the podcast websites I promoted yesterday in Podnews. Every one is a different size and shape. You want THIS? Really? 
|
Beta Was this translation helpful? Give feedback.
-
|
That is a bad website design, and if you see my other comment that is exactly why we went in the direction of listing the icons in our xml as we want a set UI/UX experience which each of our templates have. We are not just another podcast provider we provide a whole suite of tools for our clients who may not have website UI/UX or app UI/UX experience. |
Beta Was this translation helpful? Give feedback.
-
Yes I agree you can, however we have a set design UI that we have built from the ground up, and our system controls every aspect for radio stations, radio show content providers to podcast creators, so for us it is a standard UI experience we are bringing to our clients. For us our system is built, and replacing availableOn with ContentLink would be easy as long as it has the icon href as that corresponds with the icon filename in the system be it a podcast website, radio station website or our many plugins (coming soon). |
Beta Was this translation helpful? Give feedback.
-
|
@nathangathright what service are you building that would utilise this feature?
@ryan-lp I agree :) |
Beta Was this translation helpful? Give feedback.
-
I appreciate your insights on this specification. To enhance our understanding, could you please provide some guidance on how you envision it being utilized? A practical example of its application in a real-world scenario would be very helpful. Additionally, I'm trying to grasp the advantages of this specification over the 'availableOn' tag. Could you clarify the guidelines for what links are appropriate for the 'contentLink'? Are there specific boundaries or is it flexible to include any URL? Your clarification would greatly aid in resolving some of the confusion I'm experiencing. Thank you for your time and effort in addressing these questions. |
Beta Was this translation helpful? Give feedback.
-
|
@jamescridland Apologies if my previous comment came across as rude—that was certainly not my intention. I was simply requesting a demonstration on how to use the specifications again. My comment about 'no one follows rules anyway' was meant in a lighthearted manner, not to offend. I understand that text-based communication can sometimes lead to misinterpretations, as it lacks the nuances of spoken language. If my comment was perceived negatively, I assure you it was a misunderstanding. I respect that everyone has their own style of communication and interpretation. However, if my words have offended you, I apologize. It was not my intention to come across as disrespectful. |
Beta Was this translation helpful? Give feedback.
-
|
Clearly @redimongo has (1) missed some points that have already been raised and answered, and (2) feels passionately about something, and (3) depending on one's perspective might be perceived as rude. This makes people feel (1) frustrated, (2) anxious and (3) offended. But hey, I've done that. @jamescridland has done that. Adam and Dave have done that. Many people have done that. Of course it's easy to be frustrated when SOMEONE ELSE exhibits these 3 qualities, but just remember that you (by which I mean all of us) have also probably exhibited those same qualities through someone else's eyes in these discussions at some point. In my books, misunderstandings are acceptable because they are resolvable if you just point out where the misunderstanding was. Being passionate is acceptable, it's the fire that keeps many of us motivated to improve podcasting. Name calling is not acceptable because these are words designed to shut people down and prevent discussion. But remember, other examples of what might be taken as offense are often not intended to be, and so they fall into the misunderstandings category. I don't like it when other people misconstrue my point or put words in my mouth, sure, but that would be just an example of a misunderstanding, and it can be resolved by just pointing out, "that's not what I meant/said - here's what I actually meant/said". But if someone uses name calling, there is no room for even misunderstandings to be cleared up because you have shut the person down. Although not everyone who name calls is a bully, it can feel like you're being bullied when you're being name called. I know I'll take heat for this, but I stopped listening to the PC2.0 podcast a long time ago because of all of the name calling (and the politics). I still listen to Podnews even though James also resorts to name calling (and politics) once every so often, but it's just below my threshold. Since the PC2.0 podcast is referred to as a board meeting, I have requested that they publish minutes which I assume will focus on only the best of what they do and leave out what derogatory names they have decided on to label the people or products that the don't align with their own mission or views. (There, I've said it! XD ... And just to point this out, I am happy to work with everyone here. Misunderstandings can and will happen. We are going to unintentionally miss points that were said, we are going to unintentionally misunderstand what someone said or meant, and we can resolve those misunderstandings. I don't think we can unintentionally use derogatory words, so that's something we could do without.) |
Beta Was this translation helpful? Give feedback.
-
|
@ryan-lp thank you, and yes my reading and writing Level is definitely not at a quality that I would like, but I am trying. |
Beta Was this translation helpful? Give feedback.
-
|
Just posting this here in case anyone else started having this thought. Whether this or a different tag, I was about to suggest we opt for IDs instead of full URLs for this simple reason: URLs change and are sometimes not redirected. For example, Apple Podcasts URLs changed from But then I remembered how this tag is going to be used: by websites, feed readers, and non-podcast apps. So it will be more important for the full URL to be there because a non-podcast app will be far less likely to maintain the base URL patterns than a podcast app would. But a podcast app would also not have any need to link to the same podcast in a different app. |
Beta Was this translation helpful? Give feedback.
-
|
As a potential consumer of this tag - one of the benefits is that I know that a URL with Interestingly, the Apple Podcasts URLs often include |
Beta Was this translation helpful? Give feedback.
-
|
Also the Apple has gone back and forth with a |
Beta Was this translation helpful? Give feedback.
-
@jamescridland couldn't you take the country code from the podcast? Is there not a tag stating which country the podcast is made in?
Does that help? This is how we do country pricing on PodToo, so I assume it can work for XML to HTML where you are processing the HTML first. |
Beta Was this translation helpful? Give feedback.
-
|
I see your point about the challenges with caching and privacy concerns. How about this alternative:
Would this approach work better in terms of balancing functionality, privacy, and server efficiency? |
Beta Was this translation helpful? Give feedback.
-
Sure, maybe that would help clear the air. This will not be an exhaustive list of ways to use this tag. Like all tags, hosts will pick and choose the ways that make sense for their platform to implement. Here are a few major use cases I’m envisioning. Example 1: Automatic & manual channel linksHosts like Buzzsprout already display podcast platform links on their webpages. In some cases, Buzzsprout manages the podcast’s relationship with a given directory and knows the show URL automatically. In other cases, the podcaster has to manually provide the URL to Buzzsprout. Buzzsprout decides what links are permissible, no spec dictates that for them. Buzzsprout could support the These links would serve as self-verification of their presence on those platforms. It would be easy enough to scrape these links from a Buzzsprout webpage, but not all hosts provide webpages for their shows. So including this is the feed may be the only way for them to self-verify. This is particularly useful for locating shows on platforms with no lookup method or identifying shows with very common names like “Real Talk” in platforms that only provide a search API.
Example 2: Automatic host-managed episode linksHosts like Transistor can publish episodes to YouTube on behalf of the podcast and might be the only party to have programmatic access to that episode URL. Transistor could support the
Example 3: Manual episode linksPodcasters could be willing to manually provide episode links when they see receive value. Hosts like Acast and Transistor have integrated with Patreon to some extent. Podcasters could provide a link to an extended version of the same episode on Patreon.
In my opinion, the advantage of this tag over What would happen if a podcaster somehow includes their blog, newsletter, social links, Calendly link, and merch store in their A The only remaining difference is the name. |
Beta Was this translation helpful? Give feedback.
-
|
First let me say amazing love the examples - example 1 is my fav. Just a really small thing, and I know I am not alone in this area, as a hosting provider we have spent thousands of hours (and lots of money) to code our system from analytics to publishing, to our content delivery network etc. While I love the idea of apps being able to switch to the YouTube, Rumble, Twitch versions (for example), that would require us to then get an API to all those services, get users to sign into their account just so we can read the view count (yes technically we don't need an API we could scrape). NOTE: As a hosting provider that does support video, I understand the bandwidth issue very closely. I can't speak for other providers but I know we don't compress any video that its hosted on our system we use Google CDN to deliver it to viewers and have a video embed player that people can put on their website. The only limit we have is a 2GB file limit per upload. However us making / supporting apps to be able to auto switch to YouTube, Rumble, Twitch video over serving our own video link from our own system defeats the purpose of "open standard" and only helps Google, Amazon and others get richer. Just recently a Youtuber got a content strike by YouTube for promoting an android app that was designed to follow your fav creator no matter if they stream on twitch, YouTube or Kick (https://www.reddit.com/r/youtube/comments/17l9zrv/youtube_removes_louis_rossman_video_promoting_his/). it was like FriendFeed (back in the old day) but for video. Anyway that is off topic, I have no issue with supporting an open community and open standards but I am in the business to allow creators to unlock their content from platforms that removes or scores their content low because it doesn't sit well with their algorithm, and bypass the YouTubes' of the worlds. Being open and having full control of your content is why I love our industry, giving up control of your content and how it is viewed, who can view it, and being at the mercy of large companies to take it down or hide it bugs me hugely. As you have said in the past, and this is where I think we can agree on, it's about giving choice to our customers (podcasters), we differently want to support the P2.0 apps, but at the same time features like this can cause confusion of "what is a podcast". We don't want to support the Google's of the world, but at the same time understand that video is watch on Youtube.
I would like more information about this, as if a rss feed has the video enclosure in it, why would you switch to YouTube or any other video platform, which may have ads that play which don't pay the publisher in some cases. NOTE: Your not wrong tho as technically we could host the videos with YouTube, have a mp4 scrapper that gets the YouTube mp4 url and stores that in the RSS feed as the video enclosure this bypassing the need to link to YouTube directly but would allow full access to the video file - the same way YouTube downloaders work. Which then reduces bandwidth (smart) Also part of a hosting provider is to make sure that they generate enough revenue to handle the bandwidth, many including us use Google CDN for video or even better we cache the video on edge networks for 24 hours from the last time they where requested which reduces bandwidth cost from a cloud perspective (note you have to own the servers and network for this to really save money) In summary: I can see where you are coming from, and it's a very interesting view point. |
Beta Was this translation helpful? Give feedback.
-
See #589 (reply in thread) for the gist of an approach to allow services such as podnews to crawl YouTube episode links without relying on the podcast to publish content links. I think everything else is actually settled for me, I think your reasons for the tag name, the icon attribute and the platform attribute are very convincing and probably something we can easily reach consensus on. The only thing I'm unconvinced of is item level content links. I've previously done a lot of work with crawlers and never really encountered an insurmountable problem before, and so I don't find Example 2 convincing. Example 3 might be an interesting use case, although perhaps it could even be a separate tag with its own specific attributes or child elements. Perhaps someone needs to do a requirements analysis for that to uncover any differences that might warrant a separate tag.
Can you point me to the discussion? Hopefully this doesn't lead to a common practice of using YouTube as a podcast hosting service. I think that would be a bad thing for open podcasting and traditional podcast apps that may have invested heavily into their own audio playing engine, e.g. to implement things like dynamics processing, silence skipping, and various other things that require access to the raw audio data before passing it through its processing pipeline. These are things that are only possible when the system is truly open, where the app can see everything in the RSS feed, and can see everything in the audio file, without having to rely on any proprietary system to decode and play the audio for you. I think that openness aspect is one of the things that is included in the mission statement (i.e. to preserve and protect an open podcasting ecosystem). The one thing that any podcast app should expect, above all else, is access to the raw audio data so that it can process and render it. |
Beta Was this translation helpful? Give feedback.
-
|
Watching and thinking...thought I would share my 2 cents. Large hosts are always concerned about bandwidth. Adding 15+ lines to 100K+ feeds that get requested thousands of times everyday is a big deal. I'm not sure the value is there; I would be concerned about adoption. Still keeping an open mind. Just thought I would share. ✌️ |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @snookfin! If it was a single tag pointing to a linked JSON file, would that be more viable for you? |
Beta Was this translation helpful? Give feedback.
-
|
@nathangathright 100% |
Beta Was this translation helpful? Give feedback.
-
|
@snookfin I took a stab at adding a JSON alternative to this proposal, but I’m not happy with the result. I would prefer a JSON-only approach rather than this Frankensteined mess. And in that case, using the existing Important Based on the feedback provided here, I’ve split this into two smaller proposals: |
Beta Was this translation helpful? Give feedback.
-
|
I like the :follow idea. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Important
Based on the feedback provided here, I’ve split this into two smaller proposals:
<podcast:follow>tag and JSON speccontentLinkEnhancement (Revised)Purpose
For services like Podlink, Podnews, etc, it can be tricky to match feeds and episodes to their corresponding URLs in third-party podcast apps. I maintain a repo of known podcast URL patterns, but many apps don’t support foreign key lookup methods, especially for episodes. The intent of this proposal is to consolidate prior efforts and extend
<podcast:contentLink>to cover all show and episode links.Prior Art
<rawvoice:subscribe>tag<podcast:id>tag (Dec 30, 2020)<podcast:contentLink>proposal (Jan 14, 2022)<podcast:avaliableOn>proposal (Jul 10, 2023)Open Questions for Discussion
<podcast:contentLink>per domain per parent tag? (e.g. restricting feeds to one show-level Apple Podcasts URL at the channel-level, one episode-level Apple Podcasts URL at the item-level, etc.)<podcast:contentLinks>parent tag?typeandslugwere suggested in prior proposals. Given the limited scope I’m proposing, I didn’t see the need for them at this stage, but I’m open to changing that.Parent
<channel>or<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.
Attributes
Examples
Feed-level contentLink
Item-level contentLink
liveItem contentLink
Beta Was this translation helpful? Give feedback.
All reactions