NIP-52: Calendar Events
Events need to outlive the app that announced them
Communities schedule meetups, livestreams, conferences, releases, calls and local gatherings. If that data lives only in one app, it cannot be reused by a client, relay, profile, venue page or notification tool. NIP-52 turns calendar data into signed Nostr events.
The standard separates date-based events from time-based events. That sounds fussy until you try to represent a holiday, a vacation day and a video call with one model. A date-based event has no meaningful timezone. A time-based event does. NIP-52 keeps those cases separate.
It also defines calendars and RSVPs, which moves the standard from announcement to coordination. A calendar can collect events, and a user can respond with accepted, declined or tentative style state.
Addressable events, calendars and RSVP state
Date-based calendar events use kind 31922. Time-based events use kind 31923. Both share tags such as d, title, summary, image, location, g geohash, participant p tags, topic tags and references.
Calendars use kind 31924 and collect event references. RSVPs use kind 31925. The source also supports collaborative calendar event requests, where an event references a calendar and asks to be included, subject to the calendar owner's approval.
NIP-52 has accumulated careful compatibility work around title versus old name tags, required content fields, event references, participants and timehashes. That is the boring detail that makes calendar data portable.
Calendar semantics got refined around real scheduling edge cases
Terry Yiu added the visible NIP-52 calendar work in June 2023. Later edits changed terminology to addressable events, deprecated name in favor of title, restored backward-compatible references and clarified participant and RSVP fields.
In 2025, fiatjaf simplified parts of the NIP and Henrique Albuquerque fixed wording. Gil added collaborative calendar event requests in August 2025. In February 2026, hodlbod added timehashes. The history shows a standards file being shaped by the unromantic problems of calendars: identity, time, location, collaboration and edits.
That is why this page must not describe NIP-52 as just event dates. It is a calendar interoperability layer for communities.
A calendar client has to respect time, place and ownership
A serious NIP-52 client needs to understand date-only and time-specific events, show participant roles, render locations and links, manage RSVP state and avoid timezone mistakes. It also needs to handle deletion through NIP-09 and addressability through NIP-33-style rules.
Formstr's calendar work and broader Nostr app directories show how calendar data can become a feature surface rather than a standalone calendar app. The standard is also relevant for venues, conferences, livestreams and Crays-style real-world access because it gives events a portable social identity.
The product test is whether a user can create an event in one client, see it on a calendar in another, RSVP from a third and still preserve title, time, location, participants and source references.
Calendars make social availability visible
Calendar data can expose where someone will be, when they are busy and which communities they join. Clients need to not assume every calendar event needs to be public just because Nostr can publish it.
The second risk is timezone damage. A bad conversion can turn a real event into missed calls and wrong doors. NIP-52 implementers need ordinary calendar discipline, not only event-kind parsing.
Read NIP-52 in the wild
NIP-52 handles calendar events. Time sounds simple until you add time zones, updates, cancellations, locations, participants, recurring events and different clients rendering the same meetup.
Use this NIP for events that need to survive beyond one announcement post. The source of truth, last update, organizer key and location privacy all matter.
What changes when you actually use it
For you, NIP-52: Calendar 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 31924, kind 31922, kind 31923, kind 31925, draft, calendar event decide whether the object carries enough context to survive.
What changes for builders and operators
For builders, NIP-52: Calendar 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 Calendar Events, Collaborative Calendar Event Requests, Date-Based Calendar Event, Time-Based Calendar Event, Calendar, Calendar Event RSVP, Intentionally Unsupported Scenarios, Recurring Calendar Events. Inspect kind 31924, kind 31922, kind 31923, kind 31925, draft, calendar event, event, d because these are the pieces most likely to surface as product behavior. Read it beside NIP-09 before treating it as isolated.
NIP-52: Calendar 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-52: Calendar 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-52: Calendar 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-52: Calendar 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-09 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-52: Calendar 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-52: Calendar 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-52: Calendar 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 31924, kind 31922, kind 31923, kind 31925, draft, calendar event. 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: Formstr Calendar app reference, NIP-09 Event Deletion, NIP-33 Addressable Events, Geohash background. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-52 source is the anchor for exact wording, and NIP-52 commit history shows how that wording moved over time. The strongest secondary clues here are Formstr Calendar app reference, NIP-09 Event Deletion, NIP-33 Addressable Events. 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-52: Calendar Events: first the human promise, then kind 31924, kind 31922, kind 31923, kind 31925, draft, calendar event, then the implementation record, then the real-world failure case. That order keeps NIP-52 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 31924,kind 31922,kind 31923,kind 31925to render the work without private context?
What to verify before you rely on it
- Find
kind 31924,kind 31922,kind 31923,kind 31925,draftin the official file and check where the UI exposes the same concept. - Read NIP-09 as context before treating NIP-52 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-52: Calendar Events in that order: Official NIP-52 source for the current wording; NIP-52 commit history for the change record; Formstr Calendar app reference, NIP-09 Event Deletion, NIP-33 Addressable Events 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.
