NIP-14: Subject tag in text events
Some conversations need a subject line
NIP-14 is tiny, but it captures a real product difference between a feed and a conversation list. In a timeline, the first words of a post may be enough. In a threaded list, inbox or forum-like view, a subject line can make the page scannable.
The NIP defines a subject tag for kind 1 text events. It was implemented in more-speech, and its shape is intentionally close to email: a short label that can be displayed in a list instead of guessing from the first sentence of the message.
That may sound minor until a client wants to show long conversations, support message boards or make Nostr feel less like one endless timeline. A subject gives the thread a handle. It is not identity, routing, encryption or storage. It is editorial structure.
One tag, inherited through replies
The tag is simple: ["subject", "some short subject"]. The source says clients replying to a message with a subject replicate the subject tag. They can adorn the reply subject, for example with Re:. Long subjects are likely to be trimmed, and the guidance keeps them below roughly eighty characters.
Because this is a tag on kind 1 events, it lives beside NIP-10's threading rules rather than replacing them. The subject tag can help a client label the thread, while e and p tags still describe reply structure and participants.
The important boundary is that a subject line is display metadata, not a durable permission or routing rule. A client can show it, copy it into replies, trim it or ignore it. The network still understands the event without it.
An early email-shaped idea that stayed small
Robert C. Martin proposed the early subject and discussion tag work in May 2022, then refined it into the subject tag. The final NIP-14 file was added a few days later. Later history is mostly formatting and title cleanup, including Asai Toshiya's 2023 title adjustment and fiatjaf's November 2023 author-removal pass.
That quiet history is itself a signal. NIP-14 did not become the center of Nostr social clients. It remained a small optional tool. Some products care about subjects; many feed-first clients do not. The NIP survives because the cost of the convention is low.
A 2026 nostream issue asking for NIP-14 support shows that the subject tag is still noticed at the relay/software boundary. The request was not to turn Nostr into email. It was to preserve subject tags end to end without mutation and list support accurately.
Useful in inboxes, forums and long thread lists
A client that implements NIP-14 can show subjects in a thread list, keep them when replying and avoid building titles from the first words of the message. That is especially helpful in forum-like products, mailing-list-style people or any client where a conversation is selected from a list before the full text opens.
The implementation is not difficult. The risk is product overstatement. A subject tag does not organize a community by itself. It does not decide the thread root. It does not make kind 1 a forum post. It simply gives clients a user-facing label that can sit beside NIP-10's thread structure.
For Crays, the page is useful because it explains why some Nostr notes may contain a subject and why most do not. It is one of those standards that matters only when a specific product shape needs it.
Small metadata can still create messy UX
The main risk is drift. If replies mutate subjects freely, a thread can split visually even though the underlying reply tree is intact. Clients need conservative behavior if they want subjects to help rather than add noise.
The second risk is bloat by habit. Not every short note needs a title. A subject tag is useful when the product has a thread-list surface. In a fast feed, it can become unused metadata.
Read NIP-14 in the wild
NIP-14 adds a subject tag to text events. It is small enough to ignore until you need scanability: support threads, email-like discussions, community posts, long-running topics and imported conversations all benefit when a message has a visible subject.
The boundary is important. A subject does not create a forum, a permission system or a canonical thread. It gives a label that clients can display beside the real reply structure.
What changes when you actually use it
For you, NIP-14: Subject tag in text events 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 1, draft 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-14: Subject tag in text events is compatibility discipline. Implement kind 1, draft 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
Inspect kind 1, draft because these are the pieces most likely to surface as product behavior.
NIP-14: Subject tag in text events 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-14: Subject tag in text events is often indirect. Nobody complains about kind 1, draft; 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-14: Subject tag in text events 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 1, draft 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-14: Subject tag in text events 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 and the adjacent source links to see where the base contract ends and the product-specific promise begins.
Language that keeps the feature honest
Good product copy for NIP-14: Subject tag in text events 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-14: Subject tag in text events 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-14: Subject tag in text events with the visible product symptom, then trace it back to kind 1, draft. 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 mirror: NIP-14, nostream issue #523, NIP-10 Text Notes and Threads, go-nostr NIP constants. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-14 source is the anchor for exact wording, and NIP-14 commit history shows how that wording moved over time. The strongest secondary clues here are NIPs mirror: NIP-14, nostream issue #523, NIP-10 Text Notes and Threads. 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-14: Subject tag in text events: first the human promise, then kind 1, draft, then the implementation record, then the real-world failure case. That order keeps NIP-14 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Can two independent clients read the same
kind 1,draftwithout 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 and the adjacent source links, changes the behavior once the base event leaves the happy path?
What to verify before you rely on it
- Find
kind 1,draftin the official file and check where the UI exposes the same concept. - Read NIP-01 and the adjacent source links as context before treating NIP-14 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-14: Subject tag in text events in that order: Official NIP-14 source for the current wording; NIP-14 commit history for the change record; NIPs mirror: NIP-14, nostream issue #523, NIP-10 Text Notes and Threads 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.
