NIP-F4: Podcasts
NIP-F4 proposes Nostr-native podcast metadata and episode events so podcast clients can fetch shows from relays, link individual episodes, discover authors and connect comments, zaps and listening activity without depending only on RSS.
RSS is open, but not built like a social protocol
Podcast RSS is one of the web's great open formats, but it has weak spots for modern client behavior. A feed is a URL. It is usually loaded as a full document. Individual episodes are awkward to reference. Interaction, comments, likes, payments and listening signals live outside the feed or inside centralized platforms.
NIP-F4 proposes a Nostr-native podcast model. Each podcast can be its own Nostr keypair. Show metadata lives in a replaceable event. Episodes are individual events. Authors can counter-claim which podcasts they work on.
The goal is not to erase RSS overnight. It is to make podcast data behave like Nostr: signed, relay-discoverable, individually addressable and interactive.
Show metadata, author claims and episode events
Podcast metadata uses kind 10154, with title, image, description, website and optional people tags for host, cohost or editor roles. Authored podcast lists use kind 10064, allowing authors to list podcast pubkeys they actually author so clients do not blindly trust a show claiming any person.
Podcast episodes use kind 54, authored by the podcast pubkey. The episode object can carry title, description, media URL, publication time, duration and other podcast-specific information.
This structure lets a podcast client fetch a show through relays, page episodes and link a single episode as its own event.
fiatjaf added the podcast NIP in May 2026
NIP-F4 is new. fiatjaf added Podcasts in May 2026 through PR #1093. That recency matters: the design may change as podcast apps experiment with import, hosting, payments and RSS compatibility.
The surrounding podcast conversation is already bigger than F4. Fountain has written about using NIP-57 zaps and NIP-73 external content IDs to share podcast payment metadata across apps. Podcastindex discussions explored NIP-32 labels for podcast GUIDs. Podstr is another example of projects tying Nostr to Podcasting 2.0 ideas.
F4 belongs in that wider lane: open podcasting plus Nostr identity, payments, comments and episode-level discovery.
Podcast clients need import, fallback and payment context
A useful F4 client should import existing RSS feeds, preserve GUIDs where possible, publish NIP-73 identifiers for cross-app references and keep media URLs resilient through NIP-92, NIP-94 or Blossom-style metadata.
Payments and comments should attach to episodes cleanly. NIP-57 zaps can carry podcast GUID metadata, while normal comments or notes can reference the episode event. The reader should be able to share one episode without routing everyone through one platform.
The migration path matters. Podcasting has decades of RSS infrastructure; NIP-F4 is strongest when it complements that world instead of pretending it starts from zero.
Podcast identity and media hosting are easy to get wrong
If anyone can publish a podcast key claiming famous hosts, clients need counter-claims and verification. NIP-F4 includes an author-list mechanism for that reason.
Large media files also need serious hosting. A signed episode event does not make audio cheap to store or fast to stream. Storage, CDN, fallback and rights issues remain real.
Direct sources
Use the official file first, then the commit history, implementation references and adjacent standards. NIPs move, and product guidance gets weaker when those source trails are hidden.





