This page lists part of the collection. The page links below work without JavaScript. With JavaScript, a filter searches everything and pages the matches.
A podcast app developer moved to the free Podcast Index after a paid API's $100/month became unaffordable at launch. Dave says pay-per-use pricing is annoying when you can't predict usage, but at the low end you aren't paying for something you don't use, which can decide whether a product launches at all.
That's always the drawback of pay per use is pay per use can get annoying, when you don't know how much use you're going to have. But it does always have it on the low end, it always does have the benefit of you're not, you're not paying for something that you're not using.
In standards work, Dave says, you spend most of your time debating features 99 percent of people will never use. Most will use a tag like location only in its most basic form, so design that root form to be dead simple to create and dead simple to consume.
your you end up spending most of your time debating about stuff that 99% of people are not going to use,
The location tag was always going to be hard, partly because everyone has an opinion and partly because many of those opinions are legitimate. When four or five approaches exist and none is obviously wrong, you just have to pick one and hope for the best.
when you have four or five different opinions on how to do something, and none of them are obviously wrong, pulled in, you just got to pick one and you know, and hope for the best.
Creating chapters for a three-and-a-half-hour show is hard. There's no way to do it without a person, and podcasters would have to re-listen to everything. Dave imagines a Mechanical Turk-style service where people are paid small Lightning payments to create chapters.
there's just not a way to do any of this stuff without a person doing it.
Dave asks everyone who has made even one comment on Podcast Index Social or GitHub to add themselves to the contributors file. Speaking up counts as contributing, and he says recognizing that is important.
everybody who has had comments and has spoken up about anything, you are a contributor, stick yourself in the file, so that you get recognized as because that's, that's important.
As Spotify pushes to monetize podcasting by cloning Apple's music-subscription model, Dave suggests it should have asked why Apple, dominant in podcasting for years, never tried to monetize it. Maybe Apple knows that monetizing podcasting is extremely difficult.
Maybe Maybe they know something we don't know, which is trying to monetize that is going to be extremely difficult.
Citing a poll in which nearly half of podcasters do it just for the fun of it, Dave sees big ramifications. Many shows are just someone talking into a phone, with no plans to sell ads or chase a deal. People who aren't obsessed with getting paid are open to any way of getting paid, like Lightning streaming.
it means that not only are people not obsessed with getting paid, but they're open to just any way of getting paid.
Developers have always had a strong strain of imposter syndrome, much of it fed by blowhard developers who shame others for not knowing things. Dave says that when an industry's culture works like that, people consistently undervalue their own worth, which matters when deciding what to ask for.
when when that's the culture, in whatever industry, you you always tend to devalue your own your own value.
Whatever fixes podcasting's problems has to touch everyone in the chain from listener to creator, and it can't be controlled by any one party. Anyone should be able to drop it onto their own system. The Index will run its piece, but if it's seen as 'just the Podcast Index thing' it won't last; only an open spec survives.
it's got to also be something that is not that is not controlled by any one person.
Against the argument that platform bans aren't a free-speech issue because Twitter, Facebook and Google are private, Dave points out, citing Taibbi and Greenwald, that tech decimated local media. Over the past decade these few companies have become the default funnel all speech is pushed through.
they've become the default funnel for all speech gets pushed through, really these three companies mainly Twitter, Facebook, Google.
Dave noticed the Mac app Chapters already output a JSON chapter format almost identical to the namespace's draft, with many of the same property names. He contacted its developer and proposed small tweaks on each side to merge them into one format. The developer agreed, so the app's users could immediately produce namespace-compatible chapter files.
I made contact with him said, Hey, your your format is so close to ours, this would be huge when if we just combined, what if we merge these two formats together?
Developers see how the pieces fit to make something function, but functioning isn't what makes great software. It also has to be enjoyable and easy, and you can't dream that up in code. You need a non-developer actually using it, breaking it, and saying 'this is awkward' or 'it took 10 minutes to load'. Developers can't fully debug their own software or see it with non-developer eyes; the back and forth is what makes it great.
just simply functioning is not what makes great software. No, it is what makes great software is is functioning it has to function at what it's supposed to do. And it's also got to do it in a way that is enjoyable, and easy.
Some in the industry feel the namespace can't work without Apple, Google and Spotify at the table. Dave says those players aren't trying to preserve independent podcasting. At best they treat it like baseball's minor leagues, scouting whom to call up to the majors.
at best, what they're trying, what they're doing is they're using it as sort of a triple A for Major League Baseball.
Value looks different for different people. Daniel J. Lewis doesn't contribute code, but he shows up on the GitHub repos with his experience and says 'you need to consider this', and Dave calls that every bit as valuable.
the way he's giving us his value is by his experience, and shit and showing up on the GitHub repos and saying, Hey, guys, I think this is something y'all need to y'all need to consider. And that is every bit as valuable
There are easily 50 times more blogs than the Index's 1.3 million podcast feeds. Dave warns independent podcasting not to sever itself from blogging. Use the same RSS that blogs use, with the enclosure tag that's there for a reason, and add a namespace for what podcasters need beyond that.
it behooves everybody to maintain podcasting, as a subset of blog, have the same thing that blogging uses to do feeds, the enclosure tag is there for a reason?
Not in the audio. unknown: the opening words 'it behooves' are on an Unknown-labelled cue that clearly continues Dave's sentence into a Dave-labelled run.
On calls to replace RSS with JSON Feed, Dave says developers chase a fantasy of one perfect spec that fixes everything. The world applies different solutions to different problems: HTML, YAML and XML coexist, and a stray curly bracket breaks JSON just like XML. RSS dominates feeds and everyone already uses it, so he puts his energy into the low-hanging fruit of an XML namespace.
I think we need to get away from this idea that there's this one perfect spec that needs to be applied to everything. The world we live in, applies different solutions to different problems.
Asked about feeds abusing a person tag with dozens of entries, Dave says there's abuse potential in everything in RSS, from keyword stuffing to 50 categories. The answer is sanity in the aggregator: the Index takes no more than eight categories and would index the first few persons. A culture of the right way to do things will develop, and hosts control their own systems.
I think that the way you get around that is just with sanity in the aggregator, you basically say, Well, nobody's gonna have 45 guests on an episode, right?
Following Winer's rules for standards-makers, Dave set a hard date to freeze phase one of the namespace. Once new ideas slow to a trickle and compatible software exists, freeze the spec, provide an outlet for new ideas, and drop anything not ready. Developers need a fixed foundation to build on.
rules for standards makers, you have to set timelines or else things never get done.
From the first episode the goal was to make podcasting base infrastructure like DNS. DNS has had domain transfer locking for 25 years, and bringing that simple idea to podcasting was easy: the podcast:locked tag. Once the major hosts honor it, those that don't, like Anchor, can be publicly shamed.
DNS has had this concept of transfer locking of a domain for 25 years. And that is a simple thing to bring to the podcasting space.
Open the namespace with a starter spec of what everyone already wants, and it turns out people want more and have really good ideas. They just need a place to write them down in public and discuss them. Dave sees his role as chaperone and tiebreaker, guided by Dave Winer's rules for standards-makers.
it also turns out that people have really good ideas, no q&a, just need a place to write them down in public and discuss them. And it's really not any more complicated than that.
Launching the namespace, Dave sensed that everyone had wanted something like it for a long time. What was missing wasn't desire but a single entity willing to pull it all together and get everyone to the same table.
everybody has wanted this to happen for a long time. But there's never been a single entity that's tried to pull it all together.
Reviewing Fireside's own namespace tags like hostname and player embed code, Dave says the podcast namespace doesn't need to absorb them. Some elements only one company wants. A feed can carry 25 namespaces, so companies can keep small namespaces of their own alongside the shared one.
we don't have to take every existing namespace that's out there and take all the tags and shove them all into this one.
Ideally, when a feed URL is submitted you'd check it isn't a 404, parse the XML, and confirm it has enclosures. But doing that synchronously blocks the call while the server pulls the feed. The Index trusts vetted key holders, accepts the submission fast, and runs the heavy checks afterward in the aggregator.
you can't really do that and make the call fast. Because you're gonna block while you're sitting here waiting on the server to pull the feed and do all these crazy checks.
Companies can spend months with a dedicated team preparing a large codebase for release. Even a modest project quickly needs documentation and comments, a line-by-line pass for static passwords and sensitive configuration, and cleanup of leftover TODO markers. Nobody will read 100,000 undocumented lines.
it doesn't have to get very big before you run into a lot of work to make something that's ready to open source, you have to go through there and make sure that everything's documented correctly. Otherwise, you're just dumping a bunch of garbage on people.
When you're deep in writing code or running a project, you get into a tunnel and stop seeing what's outside it. Someone from outside asking a simple, even simplistic question ('what about so-and-so?') often reveals something you never considered. Dave values that kind of input.
There's a lot of value to be had from anybody who's on the outside of something to come in and say, and just ask a simple sort of simplistic questions.
Huge effort goes into slicing content by category, AI and transcripts, or opening databases to machine learning. Dave says almost no time is spent on how people want content delivered, an underexplored area he credits Adam with pointing at.
there's a lot of time spent around around figuring out what content people want, and not the way they want it.
Dave remembers a developer who kept delaying his web product to add one more feature, and his conclusion that there's never a time when not having a product beats having one. That's why the Podcast Index opened to the public with warts and a crappy UI: it had to live and be out there.
He said, there's never a time when not having a product is better than having a product.
After a big push on categories, Dave planned to pause feature work for infrastructure: make sure everything is documented and backup procedures are in place. Every so often you have to stop and double-check that stuff.
I need to slow down and make sure everything's documented and make sure we all have our backup procedures and everything to make sure that all that's looking good. Just you have to stop every now and then to just double check that stuff.
Indexing whole description fields polluted the Index's search. Dave's plan: a very large stop-word list, possibly 100,000 words or more, robust enough to cut the noise so descriptions can be indexed. That brings in useful things like unique guest names.
The better the better. The search, usually, the bigger their stop word list is.
From years of tech support, Dave sees that some people find something on Google in 15 seconds while others spend hours, because search is an art form. He doesn't think he's a good judge of the Index's search, since he knows how it works. The real question is which metadata gets indexed.
I've been in the computer world so long, that I, there is an art form to searching for things
Working on Index categories, Dave admits an innate dislike of hierarchical systems like Apple's. With fast database search there's no reason for hierarchy, and he prefers flat labeling. He also checks his own urge to blow everything up for something simpler, and settled on a hybrid after James Cridland added balance.
I have this just sort of innate dislike of hierarchy of hierarchical category systems. I don't want I don't it's, it's not a digital native type process.
Asked what guarantees the Index offers, Dave says there's no SLA — but there isn't one from Apple or any other index either, and even Office 365 goes down monthly. What he can promise is that the service matters to them, and if it's down, he's working on it.
Can we guarantee 100% uptime? No, no, I'm not even going to try to guarantee that. But the thing that we, you know, that we can say is that we care about this service.
Code and general input from people are exactly what's needed, Dave says, because building in the open means building the things people need. Without hearing from them you end up building for yourself.
Otherwise, we're just going to end up building stuff that we want. But that not might not be exactly what's needed exists. So we got to know those things.
The Index's v1 API was deliberately simple rather than fully RESTful so anyone could jump in. Rather than replace it, Dave's plan was for a more robust spec to be designed next to it, with the simple one sticking around for those who just need something light.
And then the 1.0 spec will stick around for you know, forever, possibly, just to have sort of a lightweight spec, and a heavyweight spec to give each group whatever they need.
Say 'podcast index' and people picture a website where you search for shows. There's plenty of that already. What's actually missing, Dave says, is the underlying plumbing that lets anyone build on top of it — within a day someone had written a bot on the API.
what they envision immediately is a website that you go to that you search for a podcast, and it brings back results. Okay, that, like, there's some of that out there already. I mean, that's not that's not a compelling thing that the quote unquote world needs.
Even siding with Apple most of the time, Dave asks whether one company should control the directory for a supposedly open platform. No one company owns DNS; it's distributed enough that nobody can bend it to their interests. Podcasting instead had a centralized private default directory — the problem the Index was started to fix.
there's not one company that owns all of DNS, you know, it's it's fairly distributed at the top, you know, there are, obviously financial interests, but it's distributed enough to where one company can't use can't push their own interests into the way that it functions.
Building an RSS reader is a classic first project in any new language, so it seems easy. With ten sample feeds it is. At tens or hundreds of thousands of real, broken feeds, Dave says it becomes a mess immediately.
So you think, Okay, this must be easy, oh, my God, it is the most not easy thing in the world to be. So to build an RSS reader, a feed reader, when you are looking at maybe 10 example feeds. Now, that's fine.
Looking back on years of working with Adam with no pressure, Dave says what made it rewarding is that it's been fun and challenging — echoing something he'd heard: that meaningful work and meaningful relationships are the two most important things in human life.
I don't know where I heard they do meaningful work and, and meaningful relationships are like the two most important things in here in human life. And like that's, that's what this project has been like
Back in the day a sysadmin had to be a programmer to get the job done, Dave says. Not a computer-science kind of programming, just practical code held to two standards.
it's like, you know, just make it work, peer, you know, period and make it not break in the middle of the night where I had to fix it. That's, you know, those are two, those are two things.
Dave returns to Charles Taylor's A Secular Age, which he's discussed before. Its repeated point is that every new social movement carries the seed of its own demise or reversal. He applies it to AI: it'll look unstoppable and change the world, and it will also eventually be replaced by something we don't yet understand.
the main points that he makes in there repeatedly is that Whenever you have a new social movement, That movement always contains the seed for its own demise or its own reversal, whatever word you choose to put there.
Not in the audio. The book title and author ('Charles Taylor', 'a secular age') are named in the preceding cues, which voice matching labeled Unknown, so who named them isn't confirmed. Dave says 'we've talked about this before' about Taylor.