diff --git a/54.md b/54.md new file mode 100644 index 0000000..81b3a06 --- /dev/null +++ b/54.md @@ -0,0 +1,80 @@ +NIP-54 +====== + +Podcasts +-------- + +`draft` `optional` + +This NIP defines how podcast episodes can be fetched from relays. It's intended to fit easily into existing podcast players. + +## Rationale + +RSS feeds are great, but they have some problems that are solved by moving feeds from RSS URLs to multiple Nostr events, one for each episode: + +- they depend on a URL and that is hard for most people, so podcasters tend to use service providers that can + - charge money -- which isn't a bad thing per se but it turns out that with a Nostr-native podcast feed protocol it would be much simpler to host feeds and infinitely cheaper to host the media, so the ecosystem could be more decentralized + - seal them into their walled gardens (like Spotify has been doing), slowly turning a previously open ecosystem into a centralized system captured by big corporations + - censor podcasters and prevent them from migrating (on Nostr this wouldn't be a problem even if a relay banned someone as moving to other relays would be trivial as long as the podcaster held their key and podcast clients could easily discover the new relay URLs) +- they can only be loaded in full, with no pagination or filtering of any kind, which means that + - the sync process in normal RSS clients is slow and cumbersome (which also nudges people into using centralized solutions) + - this has also led to the creation of broken schemes like [Podping](https://podping.org/), which wouldn't be necessary in a Nostr-native podcast feed + - It's impossible to reference a single episode directly (since it only exists as a member in the full RSS list of episodes), this means there is no way to share a podcast episode with friends or on social media, so people tend to share links to centralized platforms or to YouTube videos of the same podcast content, which is an antipattern +- they cannot be interacted with in any way: listeners cannot "like" or comment or signal that they have listened to the episode, which is also another factor in the push towards centralized closed platforms: better analytics and insights and possibilities of engagement with the public + +## Event definitions + +### Podcast Profile + +Podcasts have their own key and their own [NIP-01](01.md) `kind:0` profile, but with a tag `["type", "podcast"]` that can be used to signal that they have podcast episodes published. + +### Podcast Episodes + +Podcast episodes are `kind:54` with some tags: + +```jsonc +{ + "id": "55807e7d5cd90d0303d7dce7397f996fdbaed8697903f326c7cf8ad999b9de3d", + "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798", + "kind": 54, + "created_at": 1700682555, + "tags": [ + ["title", ""], + ["image", ""], + ["description", ""], + ["audio", "https://.../", ""], // can be specified multiple times + ["t", ""], // can be specified multiple times + ["alt", ""] + ], + "content": "", + "sig": "...", +} +``` + +### Podcast Comments + +These are normal text comments like `kind:1`, but specific for podcast episodes. + +```jsonc +{ + "id": "606f6c703f04c70806a5c2830e3853bd83c44985b1f282a070ba894add3724b0", + "pubkey": "b2c5d5bf69d14d35c25fa47d5c67896b13394136734065a371c5bf2c62f905d2", + "kind": 55, + "created_at": 1700682556, + "tags": [ + ["e", "55807e7d5cd90d0303d7dce7397f996fdbaed8697903f326c7cf8ad999b9de3d"], + ], + "content": "", + "sig": "...", +} +``` + +(It's unclear if it's best to use this or a generic kind for commenting on stuff that isn't `kind:1`.) + +### Reactions (likes), zaps and reposts + +These work normally according to their own NIPs. + +### To be added: + +- "read" events, signaling that a user has listened to a given podcast, perhaps just use https://github.com/nostr-protocol/nips/pull/933