After hearing people’s concerns, I’ve elected to change the URI format a little, making it a little more verbose but much more flexible. The new pattern for podto URIs looks like this:
urlis the fully-qualified URL of the podcast feed
type(optional) is the type of feed. Possible types include:
Everything after the
podto: part needs to be ISO encoded, so the URI can be easily parsed.
Instead of just replacing the “http” part of a URL with “podto”, I’m now suggesting we ISO-encode the entire URL of the RSS feed. That way, we can support HTTP and HTTPS feeds without apps needing to do any extra work.
type parameter is specified, we should always assume it’ll be
This gives apps the option to support JSON Feeds if they want.
This is a feed format set out by the DotPodcast project (there will likely be more on that story at a later date).
I’m suggesting we allow the
type parameters to be repeated so that multiple formats of a feed can be specified, and the receiving app can choose which format it prefers (for example, going forward we might want to prefer JSON Feed content, as it’s much easier to parse, but fall back to RSS if JSON isn’t available on a particular feed).
When doubling or tripling up on parameters, the order matters. The tope should not be inferred by the URL, so the
url parameters need to be in the same order as the
We can’t currently add
podto: as a URI scheme on the web for desktops, as that would require people to install apps that can receive the URI. That’s fine on mobile - and is, in fact, the entire point - but on the web in desktops, we’re going to use
web+podto: for now.
web+podto: can’t be handled by iOS (there’s no mechanism for registering custom namespaces on mobile Safari).
There’s a testing dingus available for you to try, which will ask if you want to register the tool to accept podTo links. If registration succeeds, you should move on to the next step where you can test a specific RSS URL. When you click the “Subscribe” button, your browser should take you to step three. From there on - even if you get an error message - the process works, and you’ve proven that your browser is able to accept links using the podTo URI scheme.
This won’t work on mobile yet, because of the reasons I listed above, so our next goal is to get some mobile app support around the
podto: URI scheme.
Subscribing to podcasts is hard. To prove it, try explaining it to someone with a new smartphone, who doesn’t know what an RSS feed is. Even if you have the default podcasting app on your phone (which is Apple Podcasts on iOS, and Google Play Music on Android, but only in America? Weird) you might not know that. What we need is a mailto: equivalent for podcasting. Which is why my friend and colleague Brendan Hutchins came up with the podto: scheme, and I’m helping work out the technical stuff.
Right now, there are a few options: you can just assume people are going to use iTunes (or Apple Podcasts) to subscribe. This is problematic as not everyone uses iTunes (not by a long chalk... yes, “long chalk” is a thing; leave me alone, I’m British).
Another option is to have a page which shows as many different podcast app icons as can comfortably fit on-screen. This makes it much harder for smaller or newer podcast apps to gain traction, as the easiest pathways are the already established ones. And as the overall listenership to podcasts increases, the app space is only going to get more fragmented. It’s also not a good user experience.
You could do some kind of smart device detection, where you try to sniff out what operating system the listener might be using, and best direct them to the right app. This is also a problem as those systems can’t tell what podcast apps you have in place, so for iOS they might default to Apple’s default podcast app, which many experienced podcast listeners don’t prefer.
The most democratic way of doing this is to provide an RSS URL. But that presupposes people know what one of those is, or how to get their podcast player to use one (assuming the podcast player is legitimate, and accepts RSS URLs... we’ll get onto that later).
Subscribing to a podcast should be as easy as sending an email, if not easier. In an ideal world, you find a podcast you like, somewhere on the web, click “Subscribe” and are redirected to your podcast app of choice, which shows the artwork, description and list of episodes (just as if you’d tapped a search result within the app). You tap the “Subscribe” button in your app, and you’re done.
It seems sensible to have a layer of confirmation in-between tapping the initial link and then subscribing, in case you tapped the link by accident and weren’t sure what would happen. Alternatively, for feeds that require a username and password, this prompt can potentially be given when the user hits the Subscribe button in-app.
At its heart, a podto: URI is just an RSS feed URL with the http: or https: portion replaced with podto:. So, for the Platform podcast I record with Brendan, our RSS URL is http://feeds.podiant.co/platform/rss.xml, so our podTo URI would be podto://feeds.podiant.co/platform/rss.xml
Our proposal is that app developers build podto: support into their software. This isn’t all that complex; both Android and iOS support custom URI schemes, and there’s no inherent restriction regarding multiple apps using the same URI scheme (a little on that later, also).
We envisage podto: links working just like normal, everyday links to email addresses and other things on the Web. A user clicks a Subscribe link, their device prompts them if they want to open the link in their installed podcast client, they say “yes” and are redirected to the app to subscribe. Couldn’t be simpler.
Implementing this is a technically trivial task. Its difficulty lies in asking everyone with a stake in the industry to come together for its betterment. If we all support it, we make the podcast experience better for everyone. The easier it becomes to subscribe to podcasts, the more people will.
While it would be great to have Apple adopt the podto: standard, their current model precludes anyone else from using a “built-in” URI scheme if Apple already provides support for it. This would present Apple with a grossly unfair advantage over third-party podcast app developers, as no other iOS apps would be able to respond to the URI scheme, so we’d be keen to work with Apple on waiving the built-in URI scheme lockdown for this case (if the Apple Podcasts app is hidden from the home screen).
We also have a tricky chicken-and-egg problem to negotiate. App developers need to know that it’s worth building support for this URI scheme into their apps, which means web developers need to add support in, but if not enough apps support it, the experience for the user will be a scary error message.
A podcast is only a podcast if it has an RSS feed. Otherwise it’s just some audio on the Internet. Still as engaging, entertaining and worthwhile as a podcast, but /not/ a podcast. So this scheme is only reserved for podcasts (audio or video programs that syndicate their content using the open RSS), which currently excludes services like Spotify and Audible, but does include private feeds provided by the likes of Patreon.
In the future, we should look at allowing JSON Feed URLs to be specified in the same way. This involves a little more work on the part of the app developer (as the podto: URI won’t communicate whether an app uses XML or JSON), but it could be a worthwhile exercise.
If you build apps, websites or services around podcasting, if you run the website for your own podcast, or you just love the open web, get in touch. [email protected] is the best place to start. We’d love to have you on board so we can make podcasting as easy for listeners as it should be.