NIP-PO: podcast episodes

[dhalsim]

A new kind 30025 to have metadata like audio file URL, episode number, transcript file URL, chapters file URL etc. that would help discover podcast content and create specific podcast clients native to nostr.

[vitorpamplona]

Very cool

[kehiy]

Nice NIP. I think 2 important things can be added to this or maybe in other independent NIPs:

1. A podcast have multiple episodes, we need an event to show us all of them.
2. Musics can have a similar event so we can publish musics Nostr Native.

[kehiy]

Also playlists can be cool too.

[dhalsim]

1. A podcast have multiple episodes, we need an event to show us all of them.

What do you think of searching kind 30025 events of that author to fetch all the available episodes? Assuming the author have only one podcast/show, and if you want to publish another podcast/show you better publish that under a new pubkey to distinguish.

[kehiy]

@dhalsim Your idea can basically WORK, but it's not how people defined NIPs until now. The common practice in my opinion is defining a new addressable event kind that contains a list of events that are podcast/music/music video/image/video events and then we can call it a playlist/collection or anything like that.

[vitorpamplona]

Does it need to be replaceable? Why not just a regular event, like shorts, pictures and posts?

[dhalsim]

I think especially show notes (content) needs to be edited once first published. One scenario could be I got a new sponsor for the show and I need to add links to the show notes. Or simply I made a mistake and need to fix it, since it can be a long note.

[rabble]

I think most things like this that are normally editable should be replaceable. Podcasts often even replace the MP3 for the episode as things change and they update it. So they'll definitely want to be able to update the episode metadata.

[derekross]

Does it need to be replaceable? Why not just a regular event, like shorts, pictures and posts?

yes it does. originally i had my kind:30054 as not replaceable kind:54, following the original unmerged NIP, and talked to @fiatjaf about it, but i came to the realization that it has to be replaceable just like blog posts, because people edit episodes. i realized this after i published two episodes and needed to go back and edit something with them. it just makes sense to be replaceable.

[vitorpamplona]

May need to add the waveform, like on NIP-A0

[derekross]

Here's the NIP that I've been using for Podcasts for the last 2 months or so.

https://nostrhub.io/naddr1qvzqqqrcvypzq0mhp4ja8fmy48zuk5p6uy37vtk8tx9dqdwcxm32sy8nsaa8gkeyqyt8wumn8ghj7un9d3shjtnwdaehgu3wvfskueqqr4cx7errv9ehgtt9wp5hxmmyv4ej6ctwvskhgunpd9kx2unngpswcu

We should combine and merge efforts so these aren't competing kinds.

I chose kind 30054 because of the old kind 54 that never was merged.

[dhalsim]

Here's the NIP that I've been using for Podcasts for the last 2 months or so.

https://nostrhub.io/naddr1qvzqqqrcvypzq0mhp4ja8fmy48zuk5p6uy37vtk8tx9dqdwcxm32sy8nsaa8gkeyqyt8wumn8ghj7un9d3shjtnwdaehgu3wvfskueqqr4cx7errv9ehgtt9wp5hxmmyv4ej6ctwvskhgunpd9kx2unngpswcu

We should combine and merge efforts so these aren't competing kinds.

I chose kind 30054 because of the old kind 54 that never was merged.

Great work Derek. I totally agree we should merge efforts and it's indeed similar. You have more kinds for podcast/show metadata (which @kehiy asked before). I was using the author kind 0 for that purpose but I agree a special event is even better. There are small differences on other aspects like:

["pubdate", "Thu, 04 Nov 2023 12:00:00 GMT"],

IMO not ok, timestamp in seconds (Unix time) would be better. We can check them later. I'm still looking them through.

• I'll check your NIP more thoroughly and probably ask you a bunch of questions later.
• I'm ok whatever you've chosen for the kinds.

[derekross]

podcast metada just seemed to fit with NIP-78 and kind:30078 as external storage over kind:0.

agree, using unix time is better. ill update my custom NIP to start using those.

[derekross]

Nice NIP. I think 2 important things can be added to this or maybe in other independent NIPs:

1. A podcast have multiple episodes, we need an event to show us all of them.
2. Musics can have a similar event so we can publish musics Nostr Native.

my plan for this was a simple NIP-51 list. no need to re-invent the same solution here.

[dhalsim]

my plan for this was a simple NIP-51 list. no need to re-invent the same solution here.

Maybe we can propose a new named Set (meaning you can have more than one list of that kind with a d tag) like this one from NIP-51:

name	kind	description	expected tag items
Curation sets	30005	groups of videos picked by users as interesting and/or belonging to the same category	"a" (kind:21 videos)

So specialized podcast clients can fetch these sets with the specific kind podcasts. Creating "playlists" from different podcasts by others can be possible this way, too. Like I'm collecting a set of episodes related to health in one "playlist" or curation.

If you ask me having both a kind for "Podcast Metadata" and podcast curations makes sense, as they can be useful for different purposes. "Podcast Metadata" can be the "official" publication of the show/podcast while sets can be user created playlists. "Podcast Metadata" can have more specialized data etc.

Problems with "Podcast Metadata" from your NIP that I see:

• Reusing NIP-78 - Arbitrary custom app data - for this purpose is wrong.

The goal of this NIP is to enable remoteStorage-like capabilities for custom applications that do not care about interoperability.

We need a more specific kind just for the podcast clients. I think the purpose of NIP-78 is to share arbitrary data between same clients but on different platforms, like I'm using coracle from both my phone and desktop and I want to use the the same theme and this doesn't needs to be interoperable between other clients.

• Having a fixed "d" tag, "podcast-metadata". It means one pubkey can only have one 30078. What if I want to create multiple of podcast/shows. This could be solved automatically if we create a new kind just for the "Podcast Metadata" event.