The namespace adoption problem, and a solution

[ryan-lp]

The namespace adoption chicken-and-egg problem

1. What would lead to more podcasts using the new namespace? Answer: podcast hosting companies adding these tags to their authoring tools.
2. What would lead more podcast hosting companies to add these tags to their authoring tools? Answer: more demand from podcast creators and/or market pressure from the competition.
3. What would lead to more demand from podcast creators? Answer: generally, more demand from podcast listeners (with some exceptions).
4. What would lead to more demand from listeners? Exciting app features leveraging these tags that offer real value.
5. What would lead app developers to implement features leveraging these tags? Answer: support from hosting companies. Oh. Wait.

The key point is that "most" podcast creators will not be able to add these tags to their podcasts via their hosting providers, and it will be a long time (if ever) before they can.

An interim solution

What if we have an alternative (and "standard") way to embed this same metadata into plain old HTML in the channel and item descriptions, as a fallback option for hosts that don't support these tags. Now keep in mind that Spotify supports only a limited subset of HTML. Within these limitations, one way it could be done is to have a specially-named heading, followed by an unordered list of specially-formatted metadata. In the case of chapters and transcripts, the list item could simply be a hyperlink with the label indicating chapters or transcript. For simple key/value metadata, it could be represented by key: value. If the value is a list, that list can be represented as value1, value2, value3.

Another potential way to handle chapters and transcripts is to just allow a hyperlink to the chapters or transcript file to occur anywhere within the episode description, but require the hyperlink label to be formatted in a special way that can be recognised by the apps.

I think with the second approach, there's certainly the appeal that all a podcast creator needs to do to publish their transcript or chapters for an episode is to simply add a link to it in the description. Certainly podcast creators I've spoken with have been happy to publish their transcripts that way given that they aren't currently able to implement the namespace tags. And indeed, some were already doing it that way before the advent of this namespace. If people are in fact doing that, it would be nice to standardise it.

My hope is that this can help to speed up the adoption of this podcast metadata in a way that doesn't depend on the hosting companies, because if the feedback loop is shorter, the effects should iterate faster.

[ryan-lp]

Just to experiment with the idea, below is an example of how we might embed podcast namespace tags in the plain old description when using hosts that don't directly support thee podcast namespace tags. If we can standardise this, then more podcasters will be able to start using podcast namespace tags without having to wait for the hosts to catch up.

Approach 1

---

Podcasting 2.0 for April 29th 2022 Episode 83: "Pushin' Paper"

Download the mp3

Podcast Feed

PodcastIndex.org

Preservepodcasting.com

Check out the podcasting 2.0 apps and services newpodcastapps.com

Support us with your Time Talent and Treasure

Positioning

Boost Bait

ShowNotes

Put us in your value split

03ae9f91a0cb8ff43840e3c322c4c61f019d8c1c3cea15a25cfc425ac605e61a4a

Two very tired men

Live item fuck ups

Boostbot

TOS hell

Sovereign feeds kicking ass

Hypecatcher studio ramping up

Maps.fm email

Podcast Standard conversation

The Zen TV Experiment - adam.nz

Amusing Ourselves to Death: Public Discourse in the Age of Show Business: Postman, Neil, Postman, Andrew

Elon Twitter authentication

AVB & fire

Spotify launches new fund to support independent open source projects | TechCrunch

Torcon VII

Announcing the Spotify FOSS Fund : Spotify Engineering

Agora project

Podcast namespace tags

• Chapters
• Transcript (application/x-subrip)
• Person: Adam Curry. Role: host. Group: cast. Image.
• Person: Dave Jones. Role: host. Group: cast. Image.

---

Approach 2

Embedding links anywhere in the description with recognisable keywords as the hypertext:

• In this episode we interview XYZ from abc, and chat about p, q and r. Download the episode transcript and chapters in your favourite podcast app.

[theDanielJLewis]

It's an interesting idea, but I think it creates more problems than it solves. Podcast "show notes" are already a mess with wasted space, unhelpful information, and redundancies. I think this would only increase that.

Plus, I think it would only slow down adoption. Hosting providers could easily think, "Why should we support that new tag when we could do nothing any let our users insert the HTML?"

[ryan-lp]

I think it would only slow down adoption.

On the contrary, I think there are many variables we want to consider rather than only one. We want:

• More hosts supporting the tags
• More podcasts publishing the tags and associated chapter and transcript artifacts
• More features in more apps that use these tags
• More listeners to enjoy the features that use these tags
• More service providers to produce the chapters, transcripts, etc. pointed to by these tags

We should measure success by the totality of these. Indeed, a machine with this many cogs will operate at peak capacity only if there are no blockages or bottlenecks in any part of the machine, and we currently have a serious bottleneck in the hosts.

• Not enough hosts support the tags
• Podcasts can't adopt the tags because their hosts don't support them
• More listeners aren't enjoying these tags because not enough podcasts are publishing them
• More service providers aren't entering the market, because the total serviceable market isn't large enough

There is a clear bottleneck here, so just think about the impact on the total efficiency of the machine if you provide a fallback mechanism for those hosts that don't support the tags, and indeed those hosts that may never support the tags for their own strategic or philosophical reasons (which some hosts have the luxury to do because of their market power). I see it growing to the point where podcasters can at least get an initial taste of what these tags are like on their legacy hosts, and then after a while they might have more motivation to go shopping for an alternative host that directly supports the XML namespace tags because that will make their authoring process less time consuming. So in the long term, I think we will arrive in the same place, but with this there will benefits in the short term as well.

But I think even independently of the growth curve, providing a fallback option is the-right-thing-to-do (TM) simply out of fairness to those podcasters who are stuck with no other options. I spoke to one podcaster who is on a hosting provider that doesn't support these tags, and that provides no option to even export an RSS feed of any episodes beyond the most recent 100 episodes. Since the other hosting companies just provide a way to import your podcast from the RSS feed, this makes migrating from his current host impractical.

Of course if only we could convince the hosts to support the XML namespace here and now, but if you have ever tried to actively spread the word (I have), it is not that easy. These companies have a lot on their plates, and it is much harder for them to build authoring tools for the tags than it is for a podcast player app to simply display what is in the tags. And as mentioned earlier, some of these larger companies may end up never supporting these tags for their own strategic or philosophical reasons. Larger companies also tend to be the hardest to reach because of their scale and bureaucracy, while smaller companies may be more eager to adopt features and be competitive. If there is something inherent in large companies that makes them difficult targets, that is also a problem for adoption because that is where most podcasters are hosting their podcasts.

[picard102]

I agree that this will only muddy the waters and make show notes even more of a mess. I can only imagine the formatting would be wildly inconsistent.

[ryan-lp]

I agree that this will only muddy the waters and make show notes even more of a mess.

Well that was a fully fledged example with approach 1, but approach 2 allows chapters and transcript links anywhere in the description, with recognisable keywords as hypertext. e.g.:

• In this episode we interview XYZ from abc, and chat about p, q and r. Download the episode transcript and chapters in your favourite podcast app.

I can only imagine the formatting would be wildly inconsistent.

This is a self-correcting problem, because this legacy option is specifically for people who really want to publish transcripts and chapters but are hampered by their hosts. Just as with anyone who publishes a website and finds that it doesn't render properly in the web browser, or doesn't show up in the search engines, the kind of person who REALLY wants to publish a transcript and chapters will be self-motivated to fix a broken link so that it gets picked up by the apps and search engines.

In general, yes of course the fallback option is not as elegant as the native namespace tags, but remember who this option is for:

• For podcasters who really want to publish the tags and are asking for a way to do it that works on legacy hosts.
• For the listeners themselves who need the transcripts. They are primarily the ones who lose out the most. How long must they wait before the world catches up and makes podcasts accessible for them? Can we really deny them accessibility because on principle we want to permit only the most elegant solution and have no legacy fallback?
• For news and other organisations who publish their podcasts using an in-house CMS, and are genuinely interested in publishing these tags but don't have the resources to prioritise engineering of these new features. (That is a common experience when I've contacted local news organisations in my country - they showed genuine interest but still no developments more than a year later).

True, it is easy to notice that the fallback option is not as elegant as the native tags, but there is still a problem to solve. If you have a better solution to the problem, let's brainstorm on it and help to prevent the listeners waiting years for it to happen.

[picard102]

How does this increase adoption though? You can already link to those things in your feed.

As someone who builds applications that ingests RSS feeds, nothing would do more to push me away from a standards group than it advocating for non-standard methods of implementing new tags. It certainly wouldn't encourage me to implement their "fallback" standards, let alone their new tags.

[ryan-lp]

advocating for non-standard methods

I am proposing this to be included as part of the standard. I did say that up front in the original proposal.

How does this increase adoption though? You can already link to those things in your feed.

If at least one podcast app supports the legacy standard, that's a win for adoption because now those podcasters who really want to offer transcripts and chapters to their audiences but were previously hampered by their legacy hosts, will now be able to do that. Without such an option, these podcasts may not be able to publish transcripts and chapters for years yet, if ever, and that hurts the listeners.

Of course simply adding links to things in a description in a non-standard way is not going to increase adoption because no app will ever be able to pick up and then display them to the user. If it's non-standard, though podcasters publish chapters and transcripts, the listeners won't actually benefit from them showing up in their podcast player. A standard is necessary to make that possible, and all it takes is one app to support the legacy option for the listeners who, for example, really need the transcripts, to be served.

It is also not unusual to have fallback options. I see them all over the place, and they are offered for good, practical reasons. I suspect we are going to end up doing the same thing for feed ownership verification, where an entirely new system of verification is currently being proposed. Now because legacy hosts will be very slow to adopt this new standard, we would still need to have an option for them, in the form of verifying the email address publicly listed in the feed, because that's something that the rest of the hosts will support. You don't want to be so strict about "only" supporting the brand new, one ideal way, if 95% of podcast feeds can't support that new way. There is nothing wrong with having a new recommended way for the 5% and growing, AND also having a legacy way for the other 95% and shrinking.

(Speaking of fallback options, my local supermarket also has a ramp for people who use a wheelchair or otherwise have difficulty using stairs. Although in an ideal world, it would of course be great if we could make stairs work for all people, perhaps free spinal cord or hip surgery for all. But until then, we provide multiple ways of accessing the supermarket so that all users are served fairly.)

[theDanielJLewis]

When I bring back The Audacity to Podcast in September, one of my first return episodes will be about Podcasting 2.0. And I plan to push it as the new litmus test for podcast-hosting providers, alongside IAB v2 measurement compliance.

The reason to move hosting providers seems to be to get features that your current provider doesn't offer. And I wonder if the legacy providers who aren't already working on Podcasting 2.0 support are so legacy that they wouldn't even allow this kind of fallback.

I really appreciate your idea and motive behind it, I just can't see this working well or helping further the standard.

[ryan-lp]

The reason to move hosting providers seems to be to get features that your current provider doesn't offer.

Creators will find the best deal for the features they need. The problem is that transcripts are not a feature that creators need, they are a feature that listeners need. In my mind, transcripts are something that creators will generally not be motivated to offer unless:

1. required to by law, or
2. it comes at no cost, or
3. there's something in it for them, or
4. the creator really cares for listeners who need transcripts.

If, hypothetically, you were to make it your mission to serve the listeners by maximising the availability of podcast transcripts as quickly as possible, and in the climate we have, how would you go about it? (I am personally taking up challenge number 2, and this proposal would go a long way in helping make it possible to leverage existing free platforms like Anchor where, incidentally, most of my favourite podcasts are hosted, and from which the creators won't budge. I hope someone also takes up challenge number 3.)