NIP-24: Extra metadata fields and tags
The profile layer grew faster than NIP-01
NIP-24 is where Nostr admits a practical truth: clients invent small metadata fields before every detail deserves a full standard. NIP-01 defines the basic kind 0 profile object with name, about and picture. Real clients quickly needed more: display names with richer characters, websites, profile banners, bot disclosure and birthdays.
The NIP is not a glamorous protocol feature. It is a registry for things that became common enough to coordinate. Without it, one client might write displayName, another display_name, another username, and profile pages would become a pile of near-duplicates.
That makes NIP-24 important for people building an archive, directory or profile-heavy product. Profile metadata is the first thing users see. Small inconsistencies in field names turn into missing banners, wrong names, invisible bot labels and broken topic search.
A registry for small fields that still shape product trust
For kind 0 metadata, NIP-24 records display_name, website, banner, bot and birthday. It also marks displayName and username as deprecated. The text keeps name as the fallback field, which matters for older clients and compact displays.
For kind 3 follow lists, the old relay read/write map in the event content is deprecated in favor of NIP-65 relay list metadata. That is a migration story hidden in a small paragraph: relay preferences moved out of follows because relay strategy became important enough to stand on its own.
The shared tag registry is equally useful. r can point at a web URL. i can point at an external ID using NIP-73. title is shared by sets, calendar events, live events and listings. t is a lowercase hashtag. These are tiny fields, but they give product teams a common language for profile pages, search, topic pages and external references.
A living cleanup file for conventions that escaped one app
Fiatjaf added NIP-24 in September 2023, including banner metadata and deprecated naming variants. Asai Toshiya added the old kind 3 relay-list deprecation through PR #795, and fiatjaf softened the wording around that migration a few days later.
The file kept absorbing small ecosystem realities. Terry Yiu moved calendar title convention into shared tags. Silberengel added the bot field. Oscar Merry's work connected external content IDs to NIP-73. Alex Gleason defined the t tag and clarified its lowercase behavior. Later commits clarified the NIP's purpose and fixed heading structure.
One bit of history is visible only if you read the commit log: a pronouns addition was merged in November 2024 and then reverted the same day as an improperly merged joke. That is a useful reminder that NIP-24 is intentionally conservative. It is not a place to dump every profile idea. It is for fields that have enough real usage and enough cross-client value to deserve coordination.
Every profile renderer quietly depends on these fields
NIP-24 shows up in SDKs and profile renderers because metadata is everywhere. The Nostr Lib metadata module documents NIP-24 fields including display_name, bot and birthday. The nostr-sdk-ios metadata event exposes website, banner and bot parsing with comments pointing back to NIP-24. Rust Nostr's support table lists NIP-24 as implemented.
A product implementation has to decide fallback order. A profile page may show display_name when present, fall back to name, display website only after validating it as a URL, show banner with safe image loading and label bot without turning it into a stigma or a trust guarantee.
Birthday is more delicate. The format permits year, month and day to be omitted. That gives users partial disclosure, but it also means clients have to avoid inventing missing precision. A month-and-day birthday is not a full birth date. A year-only value is not a birthday celebration date.
Optional metadata can look more authoritative than it is
The main risk is over-reading profile fields. A website URL is not verified ownership. A bot flag is self-disclosure, not enforcement. A banner image can disappear or point at tracking-heavy media. A birthday can be partial, playful or sensitive.
Another risk is client bloat. If NIP-24 becomes a dumping ground, every profile renderer has to support a long tail of fields that only one app uses. The file works best when it stays boring: common enough to reduce fragmentation, restrained enough to avoid becoming a parallel profile schema.
Read NIP-24 in the wild
NIP-24 collects extra metadata fields and tags that make profiles and events richer without requiring every client to invent its own private conventions. It is the messy practical layer where real products need names, images, website hints and social context.
The danger is profile bloat. Metadata can help recognition, but it can also leak personal information or create compatibility noise. Use it when it clarifies identity, not as a junk drawer.
What changes when you actually use it
For you, NIP-24: Extra metadata fields and tags is felt when an app either behaves predictably or suddenly loses context. The visible symptom may be a missing reply, a broken link, a strange reaction count, an empty result or a relay error that looks like the whole network failed. The official terms kind 0, kind 3, draft, display_name, name, website are where that visible behavior begins, so the source is not background material; it is the place where the product promise gets its limits.
What changes for builders and operators
For builders, NIP-24: Extra metadata fields and tags is compatibility discipline. Implement kind 0, kind 3, draft, display_name, name, website against more than one relay and more than one library, then test malformed, missing and duplicated data. Core standards fail most painfully when the happy path looks fine and the second client exposes the shortcut.
What the official file makes concrete
The official file is organized around kind 0, kind 3, tags. Inspect kind 0, kind 3, draft, display_name, name, website, bot, displayName because these are the pieces most likely to surface as product behavior. Read it beside NIP-01, NIP-02, NIP-65, NIP-73, NIP-51, NIP-52 before treating it as isolated.
NIP-24: Extra metadata fields and tags is a shared contract between independent software. The smallest field can become user-visible when two clients disagree about it.
Where it breaks
The failure mode in NIP-24: Extra metadata fields and tags is often indirect. Nobody complains about kind 0, kind 3, draft, display_name, name, website; they complain that the feed is wrong, the reply vanished or the relay behaved strangely. Use the official file to diagnose the hidden cause instead of patching only the visual symptom.
Where this appears outside the markdown
In the ecosystem, NIP-24: Extra metadata fields and tags is not something most people choose directly. It is the invisible grammar behind clients, relays, crawlers, search tools and archives. When a product team treats kind 0, kind 3, draft, display_name, name, website as implementation detail only, the mistake eventually reaches the surface as missing history, bad threading or state that cannot be reconstructed after a client switch.
The nearby-standard trap
The nearby-standard trap in NIP-24: Extra metadata fields and tags is assuming the base layer solves the higher-level feature. This NIP may define the common grammar, but publishing, wallets, moderation, media or groups still need their own constraints. Read NIP-01, NIP-02, NIP-65, NIP-73, NIP-51 to see where the base contract ends and the product-specific promise begins.
Language that keeps the feature honest
Good product copy for NIP-24: Extra metadata fields and tags does not say "the protocol handles it" and move on. It explains the visible consequence: what was sent, what was accepted, what was rejected, what is still loading and what another relay or client may show differently.
What this page does not promise
NIP-24: Extra metadata fields and tags does not promise a finished social product. It gives software a shared grammar. Feed design, moderation, ranking, notifications, storage duration and recovery remain separate product decisions. That distinction matters because a client can be technically compatible and still give you a weak experience if it hides relay errors, drops context or treats optional fields as if every app understood them.
Read it as a field test
Start NIP-24: Extra metadata fields and tags with the visible product symptom, then trace it back to kind 0, kind 3, draft, display_name, name, website. That order keeps the article grounded: you see why the field exists, which relay or client behavior depends on it, and where adjacent standards change the story. A core NIP is strong only when it explains both the normal path and the awkward edge case.
Where the standard earns trust
The source links give you places to test the interpretation in public: nips.nostr.com NIP-24 mirror, NIP-01 metadata base, NIP-65 relay list metadata, NIP-73 external IDs. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-24 source is the anchor for exact wording, and NIP-24 commit history shows how that wording moved over time. The strongest secondary clues here are nips.nostr.com NIP-24 mirror, NIP-01 metadata base, NIP-65 relay list metadata. 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-24: Extra metadata fields and tags: first the human promise, then kind 0, kind 3, draft, display_name, name, website, then the implementation record, then the real-world failure case. That order keeps NIP-24 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Can two independent clients read the same
kind 0,kind 3,draft,display_namewithout a hidden compatibility rule? - Does the UI explain relay rejection, missing context or state replacement without blaming the whole network?
- Which adjacent standard, especially NIP-01, NIP-02, NIP-65, NIP-73, NIP-51, changes the behavior once the base event leaves the happy path?
What to verify before you rely on it
- Find
kind 0,kind 3,draft,display_name,namein the official file and check where the UI exposes the same concept. - Read NIP-01, NIP-02, NIP-65, NIP-73, NIP-51 as context before treating NIP-24 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-24: Extra metadata fields and tags in that order: Official NIP-24 source for the current wording; NIP-24 commit history for the change record; nips.nostr.com NIP-24 mirror, NIP-01 metadata base, NIP-65 relay list metadata 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.
