Publishing, Media and Archives: How NIPs Carry Work Beyond One Client
A deep guide to long-form content, highlights, file metadata, HTTP storage, live activities, wiki pages, calendars, picture feeds, video, podcasts and archive standards.
Why this part of the NIP map matters
Nostr is often introduced through short notes, but the more interesting publishing question is larger: can your work travel? A creator does not only need a place to post. They need titles, summaries, images, references, files, live events, highlights, calendars, video, podcasts, wiki pages, bookmarks and enough metadata that another client can understand the work without calling the first app.
Publishing standards are where Nostr becomes cultural infrastructure. A long-form article is different from a note. A calendar event is different from a live room. A file metadata event is different from the file bytes. A wiki page is different from a profile. A podcast is different from a zap. The standards let these objects exist in public, signed form instead of being trapped in one product database.
The real need is durability. Nostr has to explain how creative work survives, not only how posts move. Long-form writing, Blossom and file storage, live activities, highlights, wikis, picture-first feeds, calendars and media metadata all answer different parts of that survival question.
The central question for you is not whether an app looks like a publisher. It is whether your work, audience, links, payment context and proof can still be understood after the original app is gone.
The mental model
Long-form content gives essays addressability, metadata and a better route across clients than a stretched note.
Media standards separate the event that describes a file from the server that carries the bytes. That distinction decides what can be recovered.
Live activities have a clock. Discovery, status and freshness matter because the moment disappears if the client finds it too late.
Wiki and calendar events turn public memory into signed objects. They are powerful only when authorship, revisions and competing versions remain visible.
Publishing is where Nostr's open social graph meets copyright, archives, creator businesses and real-world attention.
Read this topic with one hand on the protocol and one hand on the product. The protocol tells you the shared format. The product tells you what a person actually sees, approves, loses, recovers or can take elsewhere. Both are necessary. One without the other creates either abstract standards talk or a pretty interface with no durable proof underneath.
Use the source links as proof, not as decoration. A useful NIP explanation gives you the mental model first, then sends you to the official markdown when exact fields, status notes, examples or implementation details matter.
The NIP pages in this topic
Long-form Content
NIP-23 turns long-form work into a portable article object with title, summary, image, tags and addressability.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch kind 30023, kind 30024, kind 1, kind 1111, kind:30023, kind:30024 because these are the terms that usually surface as product behavior. Nearby standards: NIP-37, NIP-19, NIP-27, NIP-21, NIP-22.
Custom Emoji
Custom emoji may be added to kind 0, kind 1, kind 7 (NIP-25) and kind 30315 (NIP-38) events by including one or more "emoji" tags, in the form:
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch kind 0, kind 1, kind 7, kind 30315, kind 30030, kind:pubkey:d-tag because these are the terms that usually surface as product behavior. Nearby standards: NIP-25, NIP-38, NIP-51.
git stuff
This NIP defines all the ways code collaboration using and adjacent to git can be done using Nostr.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch kind 1621, kind 1617, kind 1618, relays, <relay-hint>, <identifier> because these are the terms that usually surface as product behavior. Nearby standards: NIP-10, NIP-22, NIP-65, NIP-B7.
Torrents
In order to make torrents searchable by general category, you SHOULD include a few tags like movie, tv, HD, UHD etc.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch kind 2003, kind 2004, kind 1, kind 2003, ["i", "tcat:video,movie,4k"], kind 2004 because these are the terms that usually surface as product behavior. Nearby standards: NIP-10.
Sensitive Content
Sensitive Content / Content Warning -----------------------------------
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch content-warning because these are the terms that usually surface as product behavior. Nearby standards: NIP-32.
Draft Events
This NIP defines kind 31234 as an encrypted storage for unsigned draft events of any other kind.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch kind 1234, kind 31234, .content, expiration, kind:1234, kind:31234 because these are the terms that usually surface as product behavior. Nearby standards: NIP-40, NIP-42, NIP-65.
User Statuses
This NIP enables a way for users to share live statuses such as what music they are listening to, as well as what they are currently doing: work, play, out of office, etc.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch kind 30315, kind:30315, content because these are the terms that usually surface as product behavior. Nearby standards: NIP-30.
Calendar Events
This specification defines calendar events representing an occurrence at a specific moment or between moments. These calendar events are addressable and deletable per NIP-09.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch kind 31924, kind 31922, kind 31923, kind 31925, calendar event, event because these are the terms that usually surface as product behavior. Nearby standards: NIP-09.
Live Streaming and Spaces
This NIP introduces event kinds to advertise live spaces and the participation of pubkeys in them.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch kind 30311, kind 1311, kind 30312, kind 30313, kind 10312, kind:30311 because these are the terms that usually surface as product behavior. Nearby standards: NIP-19, NIP-21.
Wiki
This NIP defines kind:30818 (an addressable event) for descriptions (or encyclopedia entries) of particular subjects, and it's expected that multiple people will write articles about the exact same subjects, with either small variations or completely independent content.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch kind 30818, kind 818, kind 30819, kind 10102, kind:30818, content because these are the terms that usually surface as product behavior. Nearby standards: NIP-21, NIP-25, NIP-51, NIP-02.
Picture-first feeds
This NIP defines event kind 20 for picture-first clients. Images must be self-contained. They are hosted externally and referenced using imeta tags.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch imeta, .content because these are the terms that usually surface as product behavior. Nearby standards: NIP-71.
Video Events
This specification defines video events representing a dedicated post of externally hosted content.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch kind 1, kind 6000, kind:1, .content, imeta, content-warning because these are the terms that usually surface as product behavior. Nearby standards: NIP-92, NIP-94, NIP-96.
External Content IDs
There are certain established global content identifiers such as Book ISBNs, Podcast GUIDs, and Movie ISANs that are useful to reference in nostr events so that clients can query all the events associated with these ids.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch <id, without hyphens>, <id, without version part>, <id, lowercase>, <guid>, <chainId>, <txid, hex, lowercase> because these are the terms that usually surface as product behavior.
Highlights
This NIP defines kind:9802, a "highlight" event, to signal content a user finds valuable.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch kind 9802, kind 1, kind:9802, .content, <link rel="me" href="nostr:nprofile1..." /> because these are the terms that usually surface as product behavior. Nearby standards: NIP-94.
Media Attachments Metadata (imeta
Media Attachments Metadata (imeta) ------------------------------------
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch imeta because these are the terms that usually surface as product behavior.
File Metadata
The purpose of this NIP is to allow an organization and classification of shared files. So that relays can filter and organize in any way that is of interest. With that, multiple types of filesharing clients can be created. NIP-94 support is not expected to be implemented by "social" clients that deal with kind:1 notes or by.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch kind 1, kind 30023, kind:1, kind:30023, content, <width>x<height> because these are the terms that usually surface as product behavior. Nearby standards: NIP-96.
HTTP File Storage Integration
This NIP defines a REST API for HTTP file storage servers intended to be used in conjunction with the nostr network. The API will enable nostr users to upload files and later reference them by url on nostr notes. The official README carries a caution here, so use it as history or compatibility context before you build something new.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch kind 10096, Authorization, payload, expiration, content_type, filename because these are the terms that usually surface as product behavior. Nearby standards: NIP-B7, NIP-98, NIP-94.
Voice Messages
This NIP defines new events kind: 1222 for root messages and kind: 1244 for reply messages to be used for short voice messages, typically up to 60 seconds in length.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch kind 1222, kind 1244, kind: 1222, kind: 1244, content, tags because these are the terms that usually surface as product behavior. Nearby standards: NIP-22, NIP-92.
Web Bookmarks
This NIP defines kind:39701 for a URI as editable web bookmark which uses the HTTP scheme.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch kind 39701, kind 1111, kind:39701, .content, kind 39701, kind 1111 because these are the terms that usually surface as product behavior. Nearby standards: NIP-22.
Blossom
This NIP specifies how Nostr clients can use [Blossom][] for handling media.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch kind 10063, kind:10063 because these are the terms that usually surface as product behavior.
Code Snippets
This NIP defines a new event kind for sharing and storing code snippets. Unlike regular text notes (kind:1), code snippets have specialized metadata like language, extension, and other code-specific attributes that enhance discoverability, syntax highlighting, and improved user experience.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch kind 1, kind 1337, kind:1, kind:1337, .content, name because these are the terms that usually surface as product behavior. Nearby standards: NIP-34.
Podcasts
This NIP defines how podcast episodes can be fetched from relays. It's intended to fit easily into existing podcast players.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. Watch kind 0, kind 1, kind 10154, kind 10164, kind 54, kind 10054 because these are the terms that usually surface as product behavior. Nearby standards: NIP-51.
Deep reading: where the details become product behavior
NIP-23: Long-form Content
NIP-23 turns long-form work into a portable article object with title, summary, image, tags and addressability.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. In the official file, slow down around kind 30023, kind 30024, kind 1, kind 1111, kind:30023, kind:30024, kind:1, .content. It also touches NIP-37, NIP-19, NIP-27, NIP-21, NIP-22, so do not read it as an island.
The source structure points you toward Format, Metadata, Editability, Linking. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-30: Custom Emoji
Custom emoji may be added to kind 0, kind 1, kind 7 (NIP-25) and kind 30315 (NIP-38) events by including one or more "emoji" tags, in the form:
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. In the official file, slow down around kind 0, kind 1, kind 7, kind 30315, kind 30030, kind:pubkey:d-tag, name, content. It also touches NIP-25, NIP-38, NIP-51, so do not read it as an island.
The source structure points you toward Kind 0 events, Kind 1 events, Kind 7 events. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-34: git stuff
This NIP defines all the ways code collaboration using and adjacent to git can be done using Nostr.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. In the official file, slow down around kind 1621, kind 1617, kind 1618, relays, <relay-hint>, <identifier>, "relays", refs/nostr/<[PR|PR-Update]-event-id>. It also touches NIP-10, NIP-22, NIP-65, NIP-B7, so do not read it as an island.
The source structure points you toward Repository announcements, Nostr Clone URL format, Repository state announcements, Patches and Pull Requests (PRs). That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-35: Torrents
In order to make torrents searchable by general category, you SHOULD include a few tags like movie, tv, HD, UHD etc.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. In the official file, slow down around kind 2003, kind 2004, kind 1, kind 2003, ["i", "tcat:video,movie,4k"], kind 2004, kind 1. It also touches NIP-10, so do not read it as an island.
The source structure points you toward Tags, Tag prefixes, Torrent Comments, Implementations. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-36: Sensitive Content
Sensitive Content / Content Warning -----------------------------------
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. In the official file, slow down around content-warning. It also touches NIP-32, so do not read it as an island.
The source structure points you toward the event fields, examples and edge cases. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-37: Draft Events
This NIP defines kind 31234 as an encrypted storage for unsigned draft events of any other kind.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. In the official file, slow down around kind 1234, kind 31234, .content, expiration, kind:1234, kind:31234, relay. It also touches NIP-40, NIP-42, NIP-65, so do not read it as an island.
The source structure points you toward Checkpoints, Relay List for Private Content. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-38: User Statuses
This NIP enables a way for users to share live statuses such as what music they are listening to, as well as what they are currently doing: work, play, out of office, etc.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. In the official file, slow down around kind 30315, kind:30315, content. It also touches NIP-30, so do not read it as an island.
The source structure points you toward Abstract, Live Statuses, Client behavior, Use Cases. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-52: Calendar Events
This specification defines calendar events representing an occurrence at a specific moment or between moments. These calendar events are addressable and deletable per NIP-09.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. In the official file, slow down around kind 31924, kind 31922, kind 31923, kind 31925, calendar event, event, name, kind:31922. It also touches NIP-09, so do not read it as an island.
The source structure points you toward Calendar Events, Collaborative Calendar Event Requests, Date-Based Calendar Event, Time-Based Calendar Event. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-53: Live Streaming and Spaces
This NIP introduces event kinds to advertise live spaces and the participation of pubkeys in them.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. In the official file, slow down around kind 30311, kind 1311, kind 30312, kind 30313, kind 10312, kind:30311, naddr, kind:pubkey:dTag. It also touches NIP-19, NIP-21, so do not read it as an island.
The source structure points you toward Live Streaming, Proof of Agreement to Participate, Live Chat Message, Examples. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-54: Wiki
This NIP defines kind:30818 (an addressable event) for descriptions (or encyclopedia entries) of particular subjects, and it's expected that multiple people will write articles about the exact same subjects, with either small variations or completely independent content.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. In the official file, slow down around kind 30818, kind 818, kind 30819, kind 10102, kind:30818, content, [Bob](nostr:npub1...), kind:818. It also touches NIP-21, NIP-25, NIP-51, NIP-02, so do not read it as an island.
The source structure points you toward Articles, d tag normalization rules, Content, Optional extra tags. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-68: Picture-first feeds
This NIP defines event kind 20 for picture-first clients. Images must be self-contained. They are hosted externally and referenced using imeta tags.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. In the official file, slow down around imeta, .content. It also touches NIP-71, so do not read it as an island.
The source structure points you toward Picture Events. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-71: Video Events
This specification defines video events representing a dedicated post of externally hosted content.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. In the official file, slow down around kind 1, kind 6000, kind:1, .content, imeta, content-warning, kind 6000. It also touches NIP-92, NIP-94, NIP-96, so do not read it as an island.
The source structure points you toward Video Events, Addressable Video Events, Required tags for addressable events:, Other tags:. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-73: External Content IDs
There are certain established global content identifiers such as Book ISBNs, Podcast GUIDs, and Movie ISANs that are useful to reference in nostr events so that clients can query all the events associated with these ids.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. In the official file, slow down around <id, without hyphens>, <id, without version part>, <id, lowercase>, <guid>, <chainId>, <txid, hex, lowercase>, ["i", "podcast:guid:c90e609a-df1e-596a-bd5e-57bcc8aad6cc"].
The source structure points you toward Supported IDs, Examples, Webpages, Geohashes:. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-84: Highlights
This NIP defines kind:9802, a "highlight" event, to signal content a user finds valuable.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. In the official file, slow down around kind 9802, kind 1, kind:9802, .content, <link rel="me" href="nostr:nprofile1..." />. It also touches NIP-94, so do not read it as an island.
The source structure points you toward Format, References, Attribution, Context. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-92: Media Attachments Metadata (imeta
Media Attachments Metadata (imeta) ------------------------------------
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. In the official file, slow down around imeta.
The source structure points you toward Example, Recommended client behavior. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-94: File Metadata
The purpose of this NIP is to allow an organization and classification of shared files. So that relays can filter and organize in any way that is of interest. With that, multiple types of filesharing clients can be created. NIP-94 support is not expected to be implemented by "social" clients that deal with kind:1 notes or by.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. In the official file, slow down around kind 1, kind 30023, kind:1, kind:30023, content, <width>x<height>. It also touches NIP-96, so do not read it as an island.
The source structure points you toward Event format, Suggested use cases. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-96: HTTP File Storage Integration
This NIP defines a REST API for HTTP file storage servers intended to be used in conjunction with the nostr network. The API will enable nostr users to upload files and later reference them by url on nostr notes.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. In the official file, slow down around kind 10096, Authorization, payload, expiration, content_type, filename, pubkey, 200 OK. It also touches NIP-B7, NIP-98, NIP-94, so do not read it as an island.
The source structure points you toward Introduction, Server Adaptation, Relay Hints, List of Supporting File Storage Servers. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-A0: Voice Messages
This NIP defines new events kind: 1222 for root messages and kind: 1244 for reply messages to be used for short voice messages, typically up to 60 seconds in length.
Ask where the object lives, which fields describe it, where the bytes are stored and whether the archive survives outside one publishing app. In the official file, slow down around kind 1222, kind 1244, kind: 1222, kind: 1244, content, tags, imeta. It also touches NIP-22, NIP-92, so do not read it as an island.
The source structure points you toward Specification, Event Kind 1222 and Kind 1244, Visual representation with imeta (NIP-92) tag (optional), Examples. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
What to check before you trust a product claim
Start with the most concrete promise. Does the feature claim portable identity, encrypted messaging, relay discovery, zaps, wallet permissions, long-form publishing, moderation, search or application data? Name the promise before you open the source. Otherwise every NIP starts to look like background reading.
Open the official markdown next. Look for required fields, event kinds, tags, relay messages, status warnings and examples. Do not stop at the title. Many Nostr mistakes happen because a product advertises a NIP number while ignoring the boring edge case that actually protects the user.
Then test another implementation. If the event, payment, list, message, article, badge or relay behavior only works inside one product, the feature may still be useful, but it is not yet a strong portability claim. The second implementation is where the standard stops being a slogan.
Finally, check the risk class. Keys, private messages, money, storage, moderation and identity need more caution than a playful app format. A product can be young and promising, but the page should not ask you to trust it like a mature standard when the source trail is thin.
How this area usually fails
The first failure is overclaiming. A client says it supports a NIP, but it supports only the easiest happy path. That may be enough for a demo and not enough for real use.
The second failure is hidden custody. The app feels convenient because it quietly holds the key, routes the wallet, chooses relays or stores media in a way that makes leaving hard. Nostr is most interesting when those boundaries are visible.
The third failure is stale source material. A guide, blog post or old archive page may describe a version of the ecosystem that changed. The official repository and active implementations matter because Nostr standards are living documents.
The fourth failure is social flattening. Reports, badges, zaps, follows, labels and community events are not neutral numbers. They are signed social signals. You need to know who produced them, who displays them and what the product does with them.
The fifth failure is pretending the protocol solves product judgment. A NIP can define a format. It cannot force a client to explain it well, moderate fairly, store files forever or make a wallet prompt humane. Good pages keep that distinction clear.
Where to go next
The common thread is that a NIP is not a magic wand. It gives independent software a shared object, permission, message, tag, filter or social signal. The product still has to explain what it does with that shared shape.
If you are new to the topic, read the cards first and open only the NIP that matches your immediate question. If you are building, read the official markdown and test against more than one implementation. If you are evaluating a product, ask which parts travel with your key and which parts stay inside the product.
That is the difference between a useful NIP atlas and a numbered archive. The archive tells you that a document exists. The Wissenslexikon tells you why the document changes the way Nostr feels in your hands.
When a NIP touches keys, money, private messages, moderation or storage, slow down. Those are not decorative protocol topics. They decide who can sign, who can pay, who can read, who can hide, who can recover and who can leave.
The best Nostr product writing stays close to those consequences. It does not bury you in acronym soup, and it does not pretend every standard is equally mature. It tells you what you can do next, what you should verify, and where trust enters the room.
Direct sources
Use these sources to verify the text, not as decoration. The official repository is the canonical source; mirrors, guides and project pages help you see how the standard is explained or implemented elsewhere.