nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-09-29 00:10:56 +00:00
Code Issues Packages Projects Releases Wiki Activity
1f1ee425b7
nips/54.md

3.9 KiB
Raw Blame History

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, 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 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:

{
  "id": "55807e7d5cd90d0303d7dce7397f996fdbaed8697903f326c7cf8ad999b9de3d",
  "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
  "kind": 54,
  "created_at": 1700682555,
  "tags": [
    ["title", "<episode title>"],
    ["image", "<optional episode image>"],
    ["description", "<a brief description>"],
    ["audio", "https://.../", "<optional_media_type>"], // can be specified multiple times
    ["t", "<optional tag>"], // can be specified multiple times
    ["alt", "<optional NIP-31 short description for displaying in incompatible clients>"]
  ],
  "content": "<markdown content (or what is supported in RSS feeds content nowadays?)>",
  "sig": "...",
}

Podcast Comments

These are normal text comments like kind:1, but specific for podcast episodes.

{
  "id": "606f6c703f04c70806a5c2830e3853bd83c44985b1f282a070ba894add3724b0",
  "pubkey": "b2c5d5bf69d14d35c25fa47d5c67896b13394136734065a371c5bf2c62f905d2",
  "kind": 55,
  "created_at": 1700682556,
  "tags": [
    ["e", "55807e7d5cd90d0303d7dce7397f996fdbaed8697903f326c7cf8ad999b9de3d"],
  ],
  "content": "<plain text 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: