Nostr Event Kind

An event kind is the integer field, defined in NIP-01, that every Nostr event carries to declare what it is. Kinds tell clients how to interpret an event's content and tags, and — just as importantly — the numeric range a kind falls in tells relays how to store it. Understanding kinds is the key to reading any Nostr feature, because every NIP ultimately assigns its messages a kind number. Where HTTP has methods and MIME types, Nostr has one integer doing both jobs.

The famous low numbers

Kind 0 is user metadata: the content is a JSON profile (name, about, picture) describing the author. Kind 1 is a plain text note — the basic social-media post that most people picture when they think of Nostr. Kind 3 is the contact/follow list, kind 7 is a reaction (the "like"), and kind 4 is the legacy encrypted DM that NIP-17 has since superseded. Most other low and mid-range numbers (1–44 and 1000–9999) are "regular" events: relays store them normally, and new events never overwrite old ones.

How ranges govern storage

The high ranges encode lifecycle behaviour directly in the number. Replaceable events (kinds 0, 3, and 10000–19999) keep only the latest event per pubkey-and-kind pair; when you update your profile, relays may discard the old version. Ephemeral events (20000–29999) are not expected to be stored at all — relays broadcast them to connected subscribers and let them evaporate, which suits typing indicators and other real-time signals. Addressable (parameterized-replaceable) events (30000–39999) are stored uniquely per combination of kind, pubkey, and d tag, which is how long-form articles, product listings, and configuration documents stay editable in place: publishing a new event with the same d tag replaces the previous version at the same stable address.

Reading a protocol by its numbers

Because the range dictates persistence, you can often predict an event's entire lifecycle from its number alone. The Nostr Marketplace (NIP-15) puts stalls at kind 30017 and products at 30018 — addressable, because a merchant must be able to edit a listing in place. The Data Vending Machine ecosystem uses the 5000–5999 range for job requests and 6000–6999 for results — regular events, because a job and its result are permanent records. Zap receipts land at kind 9735, gift wraps at 1059, relay lists at 10002, DM relay lists at 10050. A client that has never heard of a NIP can still handle its events correctly at the storage level, purely from the kind number.

Why this design matters

The kind system is what lets Nostr grow without a committee. Anyone can propose a new application by picking numbers in the appropriate range and writing a NIP; relays need no upgrade, because storage semantics are already implied. For a sovereign user, that is the point — the protocol's evolution is permissionless in the same way its participation is. When you evaluate any new Nostr application, start by asking what kinds it publishes and what range they sit in; the answer usually tells you who controls the data, how long it lives, and what a relay can silently do with it.

Full open-data reference: Nostr Event Kinds Reference — CSV / JSON + REST API, CC BY 4.0.