diff options
| -rw-r--r-- | 54.md | 80 |
1 files changed, 80 insertions, 0 deletions
| @@ -0,0 +1,80 @@ | |||
| 1 | NIP-54 | ||
| 2 | ====== | ||
| 3 | |||
| 4 | Podcasts | ||
| 5 | -------- | ||
| 6 | |||
| 7 | `draft` `optional` | ||
| 8 | |||
| 9 | This NIP defines how podcast episodes can be fetched from relays. It's intended to fit easily into existing podcast players. | ||
| 10 | |||
| 11 | ## Rationale | ||
| 12 | |||
| 13 | 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: | ||
| 14 | |||
| 15 | - they depend on a URL and that is hard for most people, so podcasters tend to use service providers that can | ||
| 16 | - 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 | ||
| 17 | - 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 | ||
| 18 | - 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) | ||
| 19 | - they can only be loaded in full, with no pagination or filtering of any kind, which means that | ||
| 20 | - the sync process in normal RSS clients is slow and cumbersome (which also nudges people into using centralized solutions) | ||
| 21 | - 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 | ||
| 22 | - 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 | ||
| 23 | - 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 | ||
| 24 | |||
| 25 | ## Event definitions | ||
| 26 | |||
| 27 | ### Podcast Profile | ||
| 28 | |||
| 29 | 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. | ||
| 30 | |||
| 31 | ### Podcast Episodes | ||
| 32 | |||
| 33 | Podcast episodes are `kind:54` with some tags: | ||
| 34 | |||
| 35 | ```jsonc | ||
| 36 | { | ||
| 37 | "id": "55807e7d5cd90d0303d7dce7397f996fdbaed8697903f326c7cf8ad999b9de3d", | ||
| 38 | "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798", | ||
| 39 | "kind": 54, | ||
| 40 | "created_at": 1700682555, | ||
| 41 | "tags": [ | ||
| 42 | ["title", "<episode title>"], | ||
| 43 | ["image", "<optional episode image>"], | ||
| 44 | ["description", "<a brief description>"], | ||
| 45 | ["audio", "https://.../", "<optional_media_type>"], // can be specified multiple times | ||
| 46 | ["t", "<optional tag>"], // can be specified multiple times | ||
| 47 | ["alt", "<optional NIP-31 short description for displaying in incompatible clients>"] | ||
| 48 | ], | ||
| 49 | "content": "<markdown content (or what is supported in RSS feeds content nowadays?)>", | ||
| 50 | "sig": "...", | ||
| 51 | } | ||
| 52 | ``` | ||
| 53 | |||
| 54 | ### Podcast Comments | ||
| 55 | |||
| 56 | These are normal text comments like `kind:1`, but specific for podcast episodes. | ||
| 57 | |||
| 58 | ```jsonc | ||
| 59 | { | ||
| 60 | "id": "606f6c703f04c70806a5c2830e3853bd83c44985b1f282a070ba894add3724b0", | ||
| 61 | "pubkey": "b2c5d5bf69d14d35c25fa47d5c67896b13394136734065a371c5bf2c62f905d2", | ||
| 62 | "kind": 55, | ||
| 63 | "created_at": 1700682556, | ||
| 64 | "tags": [ | ||
| 65 | ["e", "55807e7d5cd90d0303d7dce7397f996fdbaed8697903f326c7cf8ad999b9de3d"], | ||
| 66 | ], | ||
| 67 | "content": "<plain text content>", | ||
| 68 | "sig": "...", | ||
| 69 | } | ||
| 70 | ``` | ||
| 71 | |||
| 72 | (It's unclear if it's best to use this or a generic kind for commenting on stuff that isn't `kind:1`.) | ||
| 73 | |||
| 74 | ### Reactions (likes), zaps and reposts | ||
| 75 | |||
| 76 | These work normally according to their own NIPs. | ||
| 77 | |||
| 78 | ### To be added: | ||
| 79 | |||
| 80 | - "read" events, signaling that a user has listened to a given podcast, perhaps just use https://github.com/nostr-protocol/nips/pull/933 | ||