NIP-53: Live Streaming and Spaces
Live rooms need more structure than a link in a post
Nostr clients can always post a streaming URL. NIP-53 asks for more: a live activity that clients can discover, display, update and join. A live show has a title, image, summary, start time, status, host, speakers, participants, streaming endpoint, recording link and chat.
That matters because live media is not just content. It is presence. People want to know what is live now, who is in the room, who is speaking, where to join, what chat belongs to the room and where the recording lands later.
NIP-53 gives that shape to audio rooms, video streams, interactive rooms, meetings and live presence. It is the standard behind a more open version of Spaces, Nests, live podcasts and streaming events.
Kind 30311, live chat and participant proof
The main object is kind 30311, an addressable live streaming event. It can carry d, title, summary, image, streaming, recording, starts, ends, status, participant counts, relay hints, pinned messages and participant p tags with role labels.
Live chat uses kind 1311 and must include the activity a tag. The activity needs to be linked with NIP-19 naddr, so it can be shared and reopened as one addressable room.
The proof-of-agreement field is the thoughtful part. A room owner can attach a signature from a participant proving agreement to be listed. Without that, a malicious room could list famous accounts as speakers to lure followers.
Live Activities grew into rooms and presence
Vitor Pamplona added the visible NIP-53 Live Activities work in July 2023. Later commits fixed event kinds and wording. In February 2025, Oscar Merry added optional pinned live chat messages, and Vitor refined live chat to remove markers and add q tags.
In June 2025, Bitkarrot added interactive rooms, meetings and live presence. That change broadened the page from simple live streaming toward shared live spaces. The June 2026 rename to Live Streaming and Spaces reflects that broader use.
This history is important because NIP-53 is not only for video platforms. It is for real-time social coordination around a room.
zap.stream and live clients make the standard visible
zap.stream is the obvious public reference point for Nostr live streaming culture. Other Nostr media clients and directories also track live and streaming applications. NIP-53 gives these products a shared room object instead of only an external stream URL.
A good implementation updates the live event while the room changes, keeps participant lists small enough to be usable, shows role labels plainly and treats old live events as ended when they have not been updated. Clients need to not assume the participant list is complete.
The room proof field deserves real UI. If a famous speaker has not provided proof, a client can show invited or unverified rather than presenting the person as confirmed.
Live social proof can be abused
A live room can borrow credibility from names, images and chat. NIP-53's proof feature exists because that abuse is obvious. Clients need to not flatten confirmed speakers and unverified tags into the same visual treatment.
There is also a safety issue around live chat. A room can attract spam or harassment quickly. NIP-53 gives the event shape; communities still need moderation, relay choices and clear room policy.
Read NIP-53 in the wild
NIP-53 models live activities such as streams, spaces and temporary rooms. It exists because a live thing is different from a normal note: discovery depends on freshness.
A stale live event is worse than no live event. Clients need active, ended and updated states that are obvious, or people will arrive late to rooms that no longer exist.
What changes when you actually use it
For you, NIP-53: Live Streaming and Spaces 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 30311, kind 1311, kind 30312, kind 30313, kind 10312, draft decide whether the object carries enough context to survive.
What changes for builders and operators
For builders, NIP-53: Live Streaming and Spaces 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 Live Streaming, Proof of Agreement to Participate, Live Chat Message, Examples, Meeting Spaces, Meeting Space Event (kind:30312), Meeting Room Events (kind:30313), Examples. Inspect kind 30311, kind 1311, kind 30312, kind 30313, kind 10312, draft, kind:30311, p because these are the pieces most likely to surface as product behavior. Read it beside NIP-19, NIP-21 before treating it as isolated.
NIP-53: Live Streaming and Spaces 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-53: Live Streaming and Spaces 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-53: Live Streaming and Spaces 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-53: Live Streaming and Spaces 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-19, NIP-21 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-53: Live Streaming and Spaces 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-53: Live Streaming and Spaces 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-53: Live Streaming and Spaces 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 30311, kind 1311, kind 30312, kind 30313, kind 10312, draft. 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: zap.stream, PR #1789, NIP-19 bech32 entities, Nostr Apps directory. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-53 source is the anchor for exact wording, and NIP-53 commit history shows how that wording moved over time. The strongest secondary clues here are zap.stream, PR #1789, NIP-19 bech32 entities. 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-53: Live Streaming and Spaces: first the human promise, then kind 30311, kind 1311, kind 30312, kind 30313, kind 10312, draft, then the implementation record, then the real-world failure case. That order keeps NIP-53 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 30311,kind 1311,kind 30312,kind 30313to render the work without private context?
What to verify before you rely on it
- Find
kind 30311,kind 1311,kind 30312,kind 30313,kind 10312in the official file and check where the UI exposes the same concept. - Read NIP-19, NIP-21 as context before treating NIP-53 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-53: Live Streaming and Spaces in that order: Official NIP-53 source for the current wording; NIP-53 commit history for the change record; zap.stream, PR #1789, NIP-19 bech32 entities 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.
