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.
NIP-F4
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.
Edit the form or the JSON: both stay in sync, the badge says whether the result is valid, and tapping any field explains it.
How the parts connect: Verified hosts
Not signed yet · Demo keys only. These personas' secret keys are public on purpose.
Select any field in the form or the JSON to see what it does.
Step 1 of 5
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.
No course chapter covers this NIP yet. The editor above is the quickest way in.
All three kinds are ordinary NIP-01 events.
NIP-51 kind 10054 lists the podcasts you recommend.
Audio files can be hosted on Blossom servers.
Listeners react to episodes like any other event.
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
This NIP defines how podcast episodes can be fetched from relays. It's intended to fit easily into existing podcast players.
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:
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).
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".
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 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": "...",
}
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.