Subscription URLs
farski opened this issue · comments
It'd be nice if there were a way to list subscription URLs to various places that have such a thing (like iTunes), so when an aggregator is looking at a feed it can be aware of those without having to hit each API.
I think this alternative feeds spec covers what you're talking about?
@Cj-Malone I think alternative feeds always points to another feed. I'm talking about app-specific URLs that represent a show. Eg, Alice has an aggregator that ingests some new feed. It might be nice if the feed included the iTunes Store URL, so her aggregator front end can display that link, without having to go hit the iTunes API to find the URL.
Then archives?
<link rel="archives" type="text/html" href="https://itunes.apple.com/us/podcast/the-joe-rogan-experience/id360084272" title="iTunes"/>
<link rel="archives" type="text/html" href="http://pca.st/joerogan" title="Pocket Casts"/>
I just don't think a spec is needed to do this, it should be possible with a standard rel.
There's already a link element in the RSS spec, and it can only appear once per channel, so that doesn't really work here.
That was for Atom, in RSS it would just use the Atom namespace just like self links do more commonly.
<?xml version="1.0" encoding="UTF-8"?>
<rss
xmlns:atom="http://www.w3.org/2005/Atom" version="2.0">
<channel>
<atom:link
rel="self" type="application/rss+xml"
href="http://joeroganexp.joerogan.libsynpro.com/rss"/>
<atom:link
rel="archives" type="text/html"
href="https://itunes.apple.com/us/podcast/the-joe-rogan-experience/id360084272"
title="iTunes"/>
<atom:link
rel="archives" type="text/html"
href="http://pca.st/joerogan" title="Pocket Casts"/>
<title>The Joe Rogan Experience</title>
Look at how RawVoice does this with feeds from PowerPress:
<rawvoice:subscribe feed="https://theaudacitytopodcast.com/feed/podcast/?redirect=no" itunes="https://TheAudacitytoPodcast.com/itunes" googleplay="https://goo.gl/app/playmusic?ibi=com.google.PlayMusic&isi=691797987&ius=googleplaymusic&link=https://play.google.com/music/m/Iidwj7r73rzw7rof54wfwnagfgu?t%3DThe_Audacity_to_Podcast_-_how_to_launch_and_improve_your_podcast" stitcher="https://theaudacitytopodcast.com/stitcher" />
If there are other destination URLs which should be included please let me know.
We did not include subscribeonandroid.com or subscribebyemail.com in the list becuase those subscription links can be re-created simply by knowing the RSS feed URL.
The "link element in the RSS spec" is not always appropriate by the way since it may be pointing to a feed that is now using the itunes:new-feed-url attribute to point to another detestation.
Agreed on not using the link element.
Yeah, I'm not sure the best way for this to be used, so I'm a little torn on what should go in the feed vs. in the app or page the feed links to.
Like the subscribeon*.com, it's also interesting to see what podlove has done with their subscribe button, which derives (desktop and mobile) OS default urls such as using pcast: scheme, but also a bunch of different app specific links it supports, and only shows the appropriate ones after user agent/OS detection.
https://github.com/podlove/podlove-subscribe-button/blob/master/src/coffee/clients.coffee
I cite their huge list of supported apps and OS as a kind of reductio ad absurdum - does it make sense for every feed to include all of these dozens of options, when a single page/app/button could be maintained and present them universally? I'm assuming this is similar to the thinking that went into the highly useful subscribeon*.com sites.
Does it make more sense to have a single subscribe url, which can then redirect the user to an appropriate url by user agent/os - and similarly to a single page that presents the appropriate options for the OS, or perhaps features certain options? Or does it make more sense to have many urls/links in the feed in an attempt to cover them all in the feed?
I think podcasters want this to "just work", so I favor a solution where a podcast feed needs only a single or few urls to direct a user like the blubrry subscribeon*.com url(s), so perhaps I am interested in both a new element to support this, and expecting services that make efficient use of it.
A podcaster might also want to specify on override even for an easily derivable link, such as a specific itunes link rather than a pcast: url, or with an affiliate link or tracking redirect / short url, so I am not insinuating we only let people have one url, more thinking that what we put in the spec also serves as a suggestion for how podcasters and app makers can and should use this. Heck, many a successful podcaster may have their own subscribe page on their site which upsells buying a subscription or donating as well as promoting the actual rss subscription action.
For the podcast episode players I work on, a single url I can link a subscribe button to makes sense to me. For a podcaster, being able to specify a page I maintain or use a service I trust as a single url seems easier to manage as well.
The biggest problem with the pcast:// and other non http / https links is that if there is no app installed that can process the schema, then the end user is left with a link that does absolutely nothing or worse, displays an error sometimes implying they did something wrong. A simple friendly standardized link like subscribe*.com or what iTunes provides is ideal in that if the app is not on the device the website will load, which presents a friendly message with the options how to install the app for their platform.
Apps and directories coming up with their own subscribe links is problematic at some point as it then creates confusion in the market place. Providing the most recognized services is key though, think in terms of someone seeing a subscribe page like this one (http://www.powerpresspodcast.com/subscribe-to-podcast/) and they are already love using their "TuneIn" app, that will be the option they then click. The end goal is to get them subscribed as easily as possible.
We made SubscribeOnAndroid.com completely open. It supports http or https feed URLs, we did not put advertising on the pages, and we allow any application that implements the protocol to be listed on all subscribe pages. Best thing is once a user installs one of the supported apps, they never visit the website anyway. Only goal is to help convert Android users to podcast subscribers.
@theDanielJLewis @cio-blubrry I support using the existing RawVoice instead of re inventing it. But I don't like that it's using defined attributes, so if a new destination is wanted a updated spec is required.
@Cj-Malone the folks from the RSS Advisory Board frowned down upon the metamarks we created which allowed for such flexibility. Otherwise we would have created the following:
<rawvoice:subscribe>
<rawvoice:subscribe-url type="itunes" value="..." />
<rawvoice:subscribe-url type="blubrry" value="..." />
<rawvoice:subscribe-url type="googleplay" value="..." />
...
</rawvoice:subscribe>
This method the types could be endless and added as they grow.
I will gladly change how we have sometime implemented for the greater good of the community, but we also need to get the blessing of the RSS Advisory Board, well if they still exist.