← All NIPs

NIP-F4

Podcasts

DraftEvents

Podcasts as Nostr feeds: each show has its own keypair, publishes kind 10154 show info and one kind 54 event per episode, and hosts confirm they author it with kind 10164.

At a glance

Status
In use and still allowed to change.
Kinds
Tags
  • audio
  • description
  • image
  • p
  • title
  • website
Last changed
May 28, 2026

Try it

Edit the form or the JSON: both stay in sync, the badge says whether the result is valid, and tapping any field explains it.

What to build

How the parts connect: Verified hosts

Examples
Valid 1 note

Not signed yet · Demo keys only. These personas' secret keys are public on purpose.

Form
Jan 1, 2025, 12:00 AM UTC

Content

Empty: everything is in the tags.

This kind has no content: leave it as an empty string.

Tags

  1. title Recommended

    Title.

  2. image Recommended

    Cover image.

  3. description Recommended

    Short description.

  4. website Optional

    A website of the show. Repeatable.

  5. p Optional

    A person involved in the show. Confirmed only by their own kind 10164.

  6. p Optional

    A person involved in the show. Confirmed only by their own kind 10164.

Add tag

How this NIP works

Step 1 of 5

A podcast is a keypair

Each show gets its own Nostr key. It can post normal notes too, and the key can be shared or handed over to change ownership.

In the course

No course chapter covers this NIP yet. The editor above is the quickest way in.

Builds on

See also

Specification

Specification text is quoted in English from the nostr-protocol/nips repository. Our explanations and the interface are translated. Source on GitHub at commit 0046368

Read the spec724 words, quoted from the repository at commit 0046368.

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

Concept

The idea is that each podcast is its own Nostr keypair. This is simple and allows podcasts to combine their podcasting presence with a normal kind:0/kind:1 microblogging presence.

It also allows podcasts to have shared ownership (via MuSig2 or just common agreements between friends) and to change that ownership over time (again, based on human trust over handling of key material).

Event definitions

Podcast Metadata

Podcast metadata is stored in kind:10154 replaceable events. This event contains the show-level information that podcast clients need to display the podcast.

Similar information may exist in the kind:0 profile for the podcast, but podcast-specific clients should be able to read directly from kind:10154 and ignore kind:0 entirely.

{
  "id": "...",
  "pubkey": "<podcast-pubkey>",
  "kind": 10154,
  "created_at": 1700682555,
  "tags": [
    ["title", "<podcast-title>"],
    ["image", "<podcast-cover-image-URL>"],
    ["description", "<podcast-description>"],
    ["website", "<podcast-website-URL>"], // optional, multiple
    ["p", "<podcast-author-pubkey>", "<role>"] // optional, multiple
  ],
  "content": "",
  "sig": "..."
}

<role> is optional, can be "host", "cohost" or "editor".

Authored Podcasts

The p tag in kind:10154 shouldn't be blindly trusted as implying authorship, since any podcast can falsely claim anyone to be their author, so before it is displayed as information by clients it must be checked against an equivalent counter-claim by the podcast authors themselves.

This is the kind:10164 event. Here podcast authors can list the public keys of the podcasts they author.

{
  "id": "...",
  "pubkey": "<user-pubkey>",
  "kind": 10064,
  "created_at": 1700682555,
  "tags": [
    ["p", "<podcast-pubkey-1>"],
    ["p", "<podcast-pubkey-2>"]
  ],
  "content": "",
  "sig": "..."
}

Clients can also use this to discover all podcasts authored by a given user.

Podcast Episodes

Podcast episodes are kind:54 events authored by the podcast public key directly.

{
  "id": "...",
  "pubkey": "<podcast-pubkey>",
  "kind": 54,
  "created_at": 1700682555,
  "tags": [
    ["title", "<episode title>"],
    ["image", "<optional episode image>"],
    ["description", "<a brief description>"],
    ["audio", "<audio-url>", "<optional_media_type>"], // can be specified multiple times
    // ...other important fields to be specified here later after further discovery
  ],
  "content": "<markdown content>",
  "sig": "...",
}

Favorite podcasts

See NIP-51 for the description of a kind:10054 event in which any user can list the podcasts they publicly advertise to listening to, as a soft recommendation.