Podcasting 2.0 August 28th 2026 Episode 269 - "Verbal Pollution"

  Adam & Dave blame everything on Alby and Poddybot is resurrected!
  The week the value-for-value system of the podcasting 2.0 movement could not take fifteen dollars off a man who was actively trying to give it away.
  On the docket: database surgery and the third emergency of the month, our own Alby hub going dark mid-boost, the location tag landing inside real products, the person tag gets an endpoint, and human speech as the last thing nobody can fake.
  <b>The only board meeting where we always blame Alby!
  I'm Adam Curry in the Heart of the Texas Hill Country
  And in Alabama, the man who performed database surgery this week and reports the butt is intact -- <i>Say hello to my Friend on the other End — Dave Jones!</i>
  Download the mp3
  Podcast Feed
  PodcastIndex.org
  Preservepodcasting.com
  Check out the podcasting 2.0 apps and services newpodcastapps.com
  <i>Support us with your Time Talent and Treasure</i>
Positioning
  The Podcast Index is here to preserve, protect and extend the open, independent podcasting ecosystem.
  We do this by enabling developers to have access to an open, categorized index that will always be available for free, for any use.
  Try a new podcast app today and see how much better the experience can be.
  What is <b>Value4Value</b>? - Read all about it at Value4Value.info
  V4V Stats
Shownotes
  -------------------------------------------------------------------------------------------------------------------------------------
  00 - DATABASE SURGERY WEEK — AND THE THIRD EMERGENCY OF THE MONTH
    <b>The lead, and it's Dave's:</b> Saturday 22 Aug — "#api I'm in the middle of a <b>big refactor with the Podcast Index database schema</b>. If I do my job right, nobody will notice it. But, the side effect will be an overall <b>huge increase in the consistency of the data</b> (duplicates, url change lag, etc)."
    @dave — the big schema refactor (22 Aug)
    <b>Wednesday night:</b> "<b>Podcast Index database surgery will begin in the morning.</b>" Thursday: "Step 1. Expect a brief api outage. It should last just a few minutes." — then "Done" — then "#api <b>Adding a very large table index...</b>" — and finally, Thursday evening: "<b>Finished. Butt is intact.</b>" (6 favourites. The board's favourite status update of the month.)
    <b>What Adam should ask:</b> what actually changed under the hood, what does "consistency" buy an app developer in practice, and is there anything a host or an app should do differently now that duplicates and url-change lag are being cleaned up?
    <b>🔥 The other half of the week — the third emergency.</b> Tuesday 25 Aug: "#api <b>Linode emergency maintenance on our db host. API is down.</b>" Then: "No update as of yet. <b>Just hard down.</b>" Then the line that is really the story: "<b>This is the third 'emergency maintenance' event that has affected us this month. Getting kind of old.</b>" And, dryly: "I guess a reboot every few years isn't too much to ask."
    @dave — Linode emergency maintenance, API is down (25 Aug)
    <b>Board question:</b> three unplanned outages in one month on the host that carries the Index. Is it time to talk publicly about where the database lives, and what the fallback is? The Index is infrastructure now — other people's products go down when it does.
    <b>Podping shipped twice.</b> v0.13.0 across gossip writer, watcher and monitor — "<b>a dynamic memory cap to address the Iroh bug</b>" (that is last week's memory leak, now capped). Then v0.14.0 the same day — "<b>cpu architecture in the mesh announcement messages</b> to make determining what hardware a node is running on easier." Monitor updated too: ppmonitor.podcastindex.org.
    @dave — podping v0.13.0, dynamic memory cap for the Iroh bug
    Podping monitor
    Podcast Index API docs
  -------------------------------------------------------------------------------------------------------------------------------------
  04 - 📌 PODCASTING'S GOLDEN OPPORTUNITY: HUMAN SPEECH
    <b>Your PREP note, verbatim:</b> "<b>For PC2.0 - Podcasting's Golden opportunity! Human speech!</b>" — filed against a piece on how to spot AI writing.
    Can you learn how to detect AI writing? Here are some clues
    <b>The argument:</b> text is now cheap to fake, images are cheap to fake, and as of this year so is a voice. What is <b>not</b> cheap to fake is <b>a specific human, speaking unscripted, for three hours, with a transcript and a signature chain attached.</b> Podcasting is the only medium that ships that by default — and the namespace already carries the provenance parts.
    <b>🔥 Evidence from this week, and it is stacked:</b>
    <b>1. Apple Music is about to start labelling.</b> @js: "<b>more than a third of the music Apple receives monthly is '100% AI'</b> + usage — presumably what other humanoids would call 'listening' — of AI music on Apple Music is <b>below 0.5%</b>. = yes they are going to have to do something about it, starting with labelling." Read that ratio again: a third of the supply, half a percent of the demand.
    Billboard — Apple Music to label AI-generated music
    <b>2. Nobody can hear the difference in podcasting either.</b> @jaybrunet, 22 Aug: "I listened to a <b>voice clone podcast</b> last night ('Stark Reflections') and it was <b>surprisingly more concise and easier to follow</b> than his previous episodes that tend to meander off in too many directions. <b>If he hadn't said it was ElevenLabs, I wouldn't have cared or noticed the difference.</b>"
    <b>3. The scale of the flood, measured.</b> Marco Arment said Overcast <b>transcribes about 30,000 hours of audio per day</b>. @js checked it against his own index: "taking a look at my 'all new episodes published' internal db for last month, <b>the world published at least 1.4m hours of new mp3 episodes for the month, or about 46k hours a day</b>... so if your 30k hours are unduplicated then you have excellent coverage — <b>the long tail is very long and, these days, full of generated audio.</b>"
    @js — 1.4m hours of new mp3 in July, full of generated audio
    <b>4. The shame is gone.</b> Stanley Druckenmiller, on his WSJ op-ed: "<b>I'm not embarrassed by it... I write everything using AI now for the same reason I use a calculator when I do math problems. I don't know why this is relevant. My name is on the piece. It's my message.</b>"
    Notus — Druckenmiller's WSJ op-ed
    <b>5. And somebody is already building the counter-stack.</b> Japanese publishers' <b>Originator Profile</b>: "OP uses <b>cryptographic digital signature technology to create tamper-proof credentials for websites</b>. Each ID card confirms <b>who published the content</b>, whether professional organizations vouch for that publisher, and information about the publisher's <b>editorial and ethical standards</b>." — that is a person tag with a signature on it.
    Nieman Lab — Japanese publishers and Originator Profile
    <b>⭐ The namespace question this asks:</b> we have <b>person</b> (who), <b>location</b> (where), <b>transcript</b> (what was said, word-level, timestamped). That is three quarters of a provenance stack that no AI feed can forge cheaply. <b>Do we need a fourth — a signed claim of human origin — or is the honest move the opposite: an AI-disclosure tag, because the liars won't use either one and the honest shows will?</b>
    <b>The V4V angle:</b> if a third of the supply is synthetic and gets half a percent of the listening, then <b>attention is already voting for humans</b>. Value-for-value is the only monetisation model that pays for that directly — you cannot boost a bot you don't believe in.
  -------------------------------------------------------------------------------------------------------------------------------------
  02 - THE LOCATION TAG, WEEK TWO — IT IS INSIDE PRODUCTS NOW
    <b>Last week we watched a dataset become a globe in 48 hours. This week the apps shipped it.</b>
    <b>Podhome, this morning:</b> "New feature: <b>Add a location to your show and to your episodes</b>, and modern podcast apps can put your podcast on the map. You can also see your show on @alberto's fantastic radar.rss.io." — note <b>show AND episode level</b>, which is exactly the gap James flagged on the globe.
    @podhome — location on shows and episodes (28 Aug)
    Podhome location docs
    <b>😊 The demand was already there — @rgblack316, 26 Aug:</b> "@podhome I was just about to send you a feature request to add the Location tag and <b>logged in this morning to find it already there.</b> 😁"
    <b>TrueFans shipped search off it — @samsethi, this morning:</b> "<b>New location search for discovery based on @alberto radar now added to TrueFans.</b> truefans.fm/search/"
    TrueFans location search
    <b>😏 And @silas had it first and said nothing — 22 Aug:</b> "Listening to the episode and hearing them talk about radar. <b>I have had a map thing showing podcast locations for actually like two months.</b> Both on web and on mobile. Not yet on tv. Would be cool if I were happy with it and not still a perfectionist. <b>I'm in the car and I actually pulled over to write this.</b>"
    <b>...and he already solved the flaw everyone else is about to hit:</b> "I ran into that shitty browser location thing and I solved it by, on the web version, <b>just not giving you a search near me button. Only on the phone app because that is guaranteed to have gps and an actual location</b> — not just wherever the heck a desktop computer seemingly randomly guesses where it might be located."
    @silas — two months of a podcast location map
    <b>The granularity problem, now with the definitive example — James Cridland on PNWR this week:</b> "You can put a building in there, a business in there, you can put <b>everything from the state of Queensland to Brisbane City Post Office</b>. If you do a podcast with a pastor — as you know, somebody who used to be on MTV with big hair does — <b>then don't just put the city where you are, put</b>..." (← that is you and Pastor Jimmy, on air, in Australia.)
    <b>⭐ Sam Sethi's line, and it is the best summary of the project anyone gave this week:</b> "What we're beginning to see is <b>all the hard work from the people in the podcast 2.0 community is beginning to bear fruit now, because I see them as building blocks. The person tag, the location tag, the transcript.</b> All of these were fundamental building blocks that now you can start to build services around, which is what we've been waiting for. And of course, <b>the lag was waiting for the data to be filled in once the tags were available.</b>"
    <b>Board question:</b> the globe is channel-level. Podhome now writes episode-level. Does Radar (and the dataset behind it) pick up item-level locations next — and does the Index want a <b>recommended granularity</b> in the spec, so we stop getting podcasts located in an area 2.6x the size of Texas?
    radar.rss.io — the globe
    Podcast Index — public datasets
  -------------------------------------------------------------------------------------------------------------------------------------
  03 - THE PERSON TAG GETS AN ENDPOINT
    <b>Dave, 22 Aug:</b> "#api The new <b>episodes by person endpoint: /api/1.0/episodes/byperson?q=James+Cridland&max=5</b>. It reports directly what the [item] level [person] tags dictate."
    @dave — the episodes/byperson endpoint (22 Aug)
    <b>James wired it into Pod News, and said so on this week's PNWR:</b> "a very simple, possibly too simple, but a very simple person tag search, which is now <b>integrated into the Pod News website</b>. The first time I integrated it I didn't do it very well, but it's much better now, because <b>I've actually followed the spec</b>."
    <b>😄 And he name-dropped you on purpose:</b> "if you're listening to <b>Adam Curry</b> — let's just say Adam Curry, <b>just so that his AI bot gets him to listen to this bit</b> — you can click the search next to Adam Curry and it will query the podcast index person endpoint and find all the other shows Adam Curry has been marked down as a person on." (Confirmed: the bot got you to this bit.)
    <b>The drawback he found:</b> "<b>there is more than one person in the world called Dave Jones</b>" — no disambiguation. A person tag is a string, not an identity.
    <b>Dave's own proposed fix, 25 Aug:</b> "I think adding a <b>toggle to the person search to switch it from extracted text to person tag only</b> would be good. Then, on the person-tag-only option, there would be a way to <b>filter for certain attributes like the href, image</b>, etc." — the href IS the disambiguator. Wikidata/website URL as identity.
    @dave — toggle for person-tag-only plus attribute filters
    <b>Sam Sethi, on PNWR, gently claiming priority:</b> "We've included this as a feature for two years, it's called <b>My Podcast Work</b>... If the <b>item level supersedes the channel</b>, and in podcast:person there is a <b>guest tag</b>, then if we pick up that you are a guest we'll label that as a guest rather than the host."
    <b>🎯 Board bait, straight from James on PNWR:</b> "I would have expected <b>Dave Jones to have done an MCP directly with the Podcast Index by now</b>. And who knows, <b>maybe even to have stuck that behind some form of a paywall</b>. Given that Dave is working so much with AI tools in his day job these days, I would imagine he'll be pretty good at making it all work. <b>So I'm kind of surprised why they haven't done that yet.</b>" — Dave, answer that one on air.
    <b>Related, same week:</b> @csb on <b>WebMCP</b> — "an emerging browser standard that lets a website explicitly declare its features as structured, callable tools for AI agents. Instead of forcing an AI agent to guess page layouts, read complex DOM trees, or parse scripts." — the question underneath both: <b>does an open index expose itself to agents, or does it get scraped anyway?</b>
  -------------------------------------------------------------------------------------------------------------------------------------
  01 - 🔥 V4V FAILED ON OUR OWN SHOW — THE ALBY / KEYSEND MESS
    <b>The post of the week, and it is a gut-punch. @csb, Friday morning:</b> "@dave @adam bros, I tried, oh I tried, to send you <b>$15.10 via bitcoin lightning but 4 splits failing including the main one</b>, please fix it as it's embarrassing: <b>if podcasting 2.0 value for value system fails for the main podcast of the podcasting 2.0 movement then it will fail for non-celebrity podcasters too</b>, looky:"
    @csb — 4 splits failing including the main one (28 Aug)
    <b>Dave, same morning, and he does not dodge it:</b> "<b>Ugh. I opened a new public channel yesterday with LNServer and our AlbyHub says it's offline.</b> Idk why. I guess I'll have to open another one. [sigh]" Then: "I did test yesterday and it was working. <b>Looks like it went offline overnight.</b>" Then: "New channel is opening now and the other one just came back online." And, at 11:39: "<b>Ok, both public channels are online now.</b>"
    @dave — our AlbyHub says it's offline (28 Aug)
    @dave — both public channels are online now
    <b>🔥 But this is not a one-morning outage — it is the third independent report of the same class of failure this week, and the other two are older:</b>
    <b>1. @algrid, 25 Aug — the specific technical finding:</b> "I recently did some V4V testing and noticed that <b>podcastindex@getalby.com receives bolt11 payments successfully, but keysend payments to it fail</b>. You probably should check your channels configuration there or <b>remove the getalby.com/.well-known/keysend/podcastindex data to disable keysend completely</b> if Alby allows that."
    @algrid — bolt11 works, keysend fails (25 Aug)
    <b>2. @ChadF, 22 Aug — found it independently from the app side:</b> "I also don't think the <b>PI Alby address in the feed accepts keysend</b> and is causing failures every time I send a boost in boostmebitch.com. Which is strange since <b>every other Alby address is fine</b>. I do the well known lookup and do keysend if it's available for Alby addresses."
    @ChadF — PI Alby address and keysend failures (22 Aug)
    <b>3. @podcastguru, 21 Aug — the monitoring gap, stated plainly:</b> "<b>Looks like our Albyhub was down for a month and I had no idea.</b> 😫 Had to update the hub, re-open channels, I assume payments still worked. Just kind of annoyed <b>how the hub can go offline and we don't get any type of notification.</b>"
    @podcastguru — our Albyhub was down for a month (21 Aug)
    <b>⭐ The board question, and it is the show:</b> we run a <b>podping monitor</b> that tells the world when notifications stop. We run an <b>API status</b> nobody has to guess at. <b>We do not monitor our own money endpoint.</b> Should the Index publish a V4V health check — a small bot that sends itself one sat an hour to every address in the value block and screams when one fails? Every app developer in the community would use it.
    <b>The channel side of the story:</b> @ericpp opened a channel to the Index this week — Dave: "03011dfdeeb31113db15620fbc0bc102f23e7d09f952b60615642ae2107e7db594 is the public key." Then the LNServer dance: "It says I can only have <b>either all public or all private channels</b> so I guess I'll have to close our existing one first." → "the new public LNServer channel is open now with <b>2,000,000 sat capacity</b>." → and this morning, after it went dark: "<b>Well, at least we know why it's cheap now. Lol</b>"
    @dave — well, at least we know why it's cheap now (28 Aug)
    <b>💡 And the standing idea this all feeds — @ChadF on your single-QR ask:</b> "Adam mentioned having a single QR for boosts but that requires something like <b>The Split Box</b> that StevenB made. Easy if you run a node as a backend, <b>but then you're taking a user's payments, splitting it and sending the split payments out, which is in the money transmitter area so I'm not touching it.</b>" His alternative: "when we update the [value] tag we add an entry for a <b>single lightning address</b> then apps like mine can offer a QR option and just make an invoice for that one address. That removes splits but it's no different than having a PayPal donation to a single account."
    @ChadF — the single-lightning-address idea in the value tag
    <b>Namespace question that falls straight out of it:</b> does the value block want an optional <b>fallback address</b> — one that an app can use for a QR, and that a sender can retry against when the split fails? Today, when a split fails, the money simply does not arrive and nobody is told.