True could be a relay per show. Or maybe there are podcast-only relays that host any shows. Then your podcast account connects to those relay and writes to them. Nostr podcast apps connect only to those relays and display shows and episodes based on info published there.

regardless of relay; it should not misuse currently well-known event kinds, this is an entirely different use case than 30023 and there's a specific event kind for exactly audio tracks

Where can I find any info about kind 31337? Not seeing it in the NIPs and not seeing zapstr.live code on your github.

I’m in the chat now, sweet. I’ll engage some of the peeps there as well.

The podcast namespace stuff as well as the podcast:guid concept is the right way to approach this. Nostr isn’t re-inventing podcasting. The idea is to move the source of truth toward self-sovereignty and decentralization. Buzzwords! Your keys, your podcast.

Nostr’s role here could take different shapes.

1. The babiest of steps would be to add a tag to the namespace that contained the author’s nostr npub. This could unlock functionality on Podcastindex.org, in the chat, in Podcasting 2.0 apps, and even Podcasting 2.0 hosts like RSS Blue.

2. Next step, relays syndicate the existing rss.xml for shows. It serves as a backup that can’t be taken down. It also becomes a place for Nostr-native podcast apps to begin developing. They can build functionality for talking to podcast relays, honoring author npubs, zapping based on the value splits, and fetching show content from info contained in the note (which is the contents of the rss.xml file created elsewhere at this point).

3. Long term, I think Nostr notes become the source of truth for podcast information. Adhering to the namespace and Podcasting 2.0 docs, info gets published in Nostr notes, signed by the author(s) key. Again, your keys, your podcast. All of the tag information outlined in namespace for the show is there in the note. Does it live as XML in the Nostr note? TBD. There would be nostr notes for the show’s general info and others for individual episodes.

Podcastindex.org could parse the notes and serve up show info to apps and services through the Podcast Index API. (Adam, like you said on the episode with Marty, the Podcast Index might be the largest nostr relay operator in this long term view.) Nostr-native podcasting apps could parse the notes directly if they want, or still get the info through the Index API. I think many apps would go to the Podcast Index still, while allowing users to add individual relays that are unknown to the Index.

XML has served podcasting well for two decades, and I might be pulling the pin on a grenade right now, but Nostr might not need it. It would stay around during a transition phase spanning years as platforms migrate. Eventually apps look to nostr relays and notes for the data.

Those are some additional thoughts :)