NIP-71: Video Events
Video needs a media object, not a note with an MP4 link
A video client needs duration, variants, poster images, fallbacks, language tracks, bitrate and sometimes addressable updates. A normal kind 1 note with an attached video cannot carry that reliably enough for a YouTube- or TikTok-like experience.
NIP-71 creates dedicated video events. Normal videos and short videos get separate kinds because the viewing experience is different, even if the boundary is stylistic rather than physically strict.
The standard is especially important as Nostr media clients mature: zap.stream, Nostrube-style video surfaces, long-form video libraries and short vertical feeds need interoperable metadata.
Four video kinds and rich imeta variants
Regular normal videos use kind 21. Regular short videos use kind 22. Addressable versions use kinds 34235 and 34236 with d tags so metadata, descriptions or URLs can be corrected without losing the stable address.
The content field is a summary or description. The primary video data lives in imeta tags, following NIP-92 and NIP-94 while adding video-specific fields such as duration, bitrate and waveform. Recent work added multiple audio tracks and an ov marker for the original version.
Addressable video matters for imported content and hosting changes. A creator may need to migrate URLs or fix metadata after publication.
The video NIP moved from early experiments to serious media metadata
The file has an odd early history because video events first appeared around the old NIP-44 number in December 2023 before moving to NIP-71. Kieran added imeta work in May 2024. In January 2025, fiatjaf made video events regular. In October 2025, Kieran added duration and bitrate.
In January 2026, rabble added addressable video events. In May 2026, Leo added multiple audio tracks. That progression shows the NIP becoming more like real video infrastructure rather than a simple media URL event.
The best reading is practical: NIP-71 is how Nostr video clients avoid each inventing their own metadata object.
The client has to choose variants intelligently
A video client needs to read imeta variants, select suitable resolution, preserve audio continuity when switching tracks, show duration and thumbnails, and fall back when a host fails. It needs to also respect addressable updates when a creator migrates media.
NIP-71 sits beside NIP-96 storage, NIP-94 file metadata and NIP-92 imeta. A serious implementation needs all of those pieces, not only kind 21 and 22 parsing.
For users, the proof is simple: a video posted in one client needs to play correctly in another, with the right image, description, duration and fallbacks.
Video metadata can hide broken media
A rich event can still point at dead URLs, misleading thumbnails or unverified files. Clients need to prefer hash verification and show fallbacks clearly.
Video is also expensive. Relays carry metadata, not the media itself, but clients and storage servers still need to handle bandwidth, moderation and copyright realities.
Read NIP-71 in the wild
NIP-71 models video events. It gives video objects structure while the heavy media files usually live outside relays.
That split is healthy and messy. You need URLs, hashes, previews, duration, captions and availability signals so a video remains understandable when one host disappears.
What changes when you actually use it
For you, NIP-71: Video Events is felt when a post becomes a durable object: article, file, image, video, audio, bookmark, wiki entry or source reference. The question is whether the work still makes sense after one app, host or relay disappears. The concrete pieces kind 1, kind 6000, draft, kind:1, d, .content decide whether the object carries enough context to survive.
What changes for builders and operators
For builders, NIP-71: Video Events is context preservation. Store enough title, tag, author, hash, URL, media, preview and reference material that another interface can rebuild the object. If your feature depends on a private database to make sense, the NIP is not doing the portability work yet.
What the official file makes concrete
The official file is organized around Video Events, Addressable Video Events, Required tags for addressable events:, Other tags:, Optional tags for imported content:, Addressable Event Example, Referencing Addressable Events. Inspect kind 1, kind 6000, draft, kind:1, d, .content, imeta, bitrate because these are the pieces most likely to surface as product behavior. Read it beside NIP-92, NIP-94, NIP-96 before treating it as isolated.
NIP-71: Video Events protects context. Titles, media, hashes, source links, timestamps and references decide whether work survives beyond one app.
Where it breaks
The failure mode in NIP-71: Video Events is link rot with a nice interface. Media disappears, metadata lies, source URLs change, hashes are missing or an article loses its addressable identity. The page needs to make durability part of the feature, not an afterthought.
Where this appears outside the markdown
In the ecosystem, NIP-71: Video Events is part of the creator and archive layer. It decides whether writing, media, files, bookmarks, wiki material or source references remain understandable after the first app disappears. That is why media standards need to talk about storage, provenance and recovery, not only presentation.
The nearby-standard trap
The nearby-standard trap in NIP-71: Video Events is flattening every creative object into a note with a link. Articles, videos, files, torrents, highlights, images, wiki entries and bookmarks carry different metadata and storage pressure. Read NIP-92, NIP-94, NIP-96 so the product does not throw away the part that made the object portable.
Language that keeps the feature honest
Good product copy for NIP-71: Video Events names the object and the storage. It says article, file, image, video, bookmark, wiki page, torrent, highlight or podcast episode, then tells you where the signed metadata ends and where external hosting begins.
What this page does not promise
NIP-71: Video Events does not guarantee that published work survives forever. It can carry richer metadata, hashes, references or addressability, but files still need hosts, relays still need retention, and clients still need to render the object faithfully. Treat the NIP as the signed map of the work, then check where the actual bytes, previews and source links live.
Read it as a field test
Start NIP-71: Video Events with the object you want to keep: article, file, media, bookmark, repository, torrent, wiki entry or podcast episode. Then trace which parts are signed, which parts are hosted, and which parts another client can reconstruct from kind 1, kind 6000, draft, kind:1, d, .content. That is the difference between portable publishing and a pretty link preview.
Where the standard earns trust
The source links give you places to test the interpretation in public: PR #2072, PR #2255, NIP-92 Media Attachments, zap.stream. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-71 source is the anchor for exact wording, and NIP-71 commit history shows how that wording moved over time. The strongest secondary clues here are PR #2072, PR #2255, NIP-92 Media Attachments. Treat this evidence chain as part of the article, not as footnotes. A NIP page becomes useful when you can move from claim to source to working behavior without guessing.
Keep the chain visible for NIP-71: Video Events: first the human promise, then kind 1, kind 6000, draft, kind:1, d, .content, then the implementation record, then the real-world failure case. That order keeps NIP-71 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Where do the signed metadata and the actual media or file bytes part ways?
- Can the object still be identified by hash, address, title, author and source if the first URL breaks?
- Does a second client know enough from
kind 1,kind 6000,draft,kind:1to render the work without private context?
What to verify before you rely on it
- Find
kind 1,kind 6000,draft,kind:1,din the official file and check where the UI exposes the same concept. - Read NIP-92, NIP-94, NIP-96 as context before treating NIP-71 as a complete product story.
- Open at least one implementation, mirror, pull request or library source from the source links before trusting that the idea is mature.
- Test the unhappy path: missing relays, stale metadata, invalid signatures, blocked events, expired state, revoked permissions or unavailable media.
- Write the user-facing copy in plain language. If a standard changes authority, privacy, money, moderation or recovery, say that before the click.
Direct sources
Use these sources for NIP-71: Video Events in that order: Official NIP-71 source for the current wording; NIP-71 commit history for the change record; PR #2072, PR #2255, NIP-92 Media Attachments for public context. The article gives you the consequence in plain language, but the source trail is where exact fields, status notes, unresolved debates and implementation proof stay checkable.
