NIP-54: Wiki
A wiki must not need one central editor
NIP-54 is one of the more philosophically Nostr-shaped standards. It does not try to create one canonical encyclopedia. It defines a way for many people to write wiki-style articles about the same subject, with clients and people deciding which version to read.
That makes sense for Nostr. Public keys are authors, relays are distribution, and addressable events are stable subjects. A wiki article becomes kind 30818 with a normalized d tag, title and content. Multiple authors can publish different articles with the same subject tag.
The goal is not to beat Wikipedia at its own governance model. The goal is to make knowledge pages portable, forkable and linkable inside Nostr.
Normalized subjects, Djot content and wikilinks
NIP-54 identifies articles by lowercase, normalized d tags. Whitespace becomes hyphens, punctuation is removed, repeated hyphens collapse and non-ASCII letters are preserved. That makes subjects predictable while still allowing Japanese, Chinese, Arabic, Cyrillic and other scripts.
The content format is Djot, with two Nostr-specific behaviors. Links can use NIP-21 nostr: URIs, and unresolved reference-style links become wikilinks to another normalized article. That gives authors familiar wiki writing without forcing one website's URL scheme.
Merge requests use kind 818. A writer can request that a forked article be merged into a source article. Again, the protocol gives the shape, not a central editorial court.
Format arguments became part of the standard's story
fiatjaf added the visible decentralized wiki work in May 2024. The file quickly gained normalization rules, wikilink clarifications and content-format changes. In June 2024 it moved to Asciidoc, then in March 2026 Vincenzo Imperati switched it from Asciidoc to Djot.
The non-Latin script normalization fix in December 2025 is another important detail. A global wiki cannot assume ASCII subject names. NIP-54's examples now preserve non-Latin scripts and lowercase where appropriate.
The history tells people that NIP-54 is not only an event-kind table. It is an argument about writing formats, article identity and multilingual knowledge.
Wiki clients must help people compare, not just render
A NIP-54 client needs Djot rendering, wikilink resolution, subject normalization and a way to compare multiple articles for the same subject. The interesting UI is not one article page. It is the fork map, author trust, merge requests and you choice.
Wikistr and other Nostr wiki experiments are the natural product territory. The standard also fits Crays' own Nostr archive because it treats knowledge as portable public objects rather than static site pages only.
You need to be able to open a subject, see who wrote each version, follow references to Nostr profiles or events, inspect forks and decide whose article is worth reading.
Forkability can become confusion
A decentralized wiki lets many versions exist. That is powerful, but a casual you can be lost if a client does not show author, date, source quality and fork lineage. The protocol avoids central control; the UI must supply orientation.
There is also a spam risk. Wiki subjects are attractive targets for junk, impersonation and low-quality rewrites. Clients need ranking and trust tools without pretending there is one universal editor.
Read NIP-54 in the wild
NIP-54 gives wiki-like knowledge a Nostr event shape. That makes it possible to publish topics, revisions and shared explanations without one central wiki owning the record.
The hard part is authority. A signed wiki page proves authorship, not truth. Show versions, authors, competing pages and update history so knowledge remains inspectable.
What changes when you actually use it
For you, NIP-54: Wiki 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 30818, kind 818, kind 30819, kind 10102, draft, kind:30818 decide whether the object carries enough context to survive.
What changes for builders and operators
For builders, NIP-54: Wiki 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 Articles, d tag normalization rules, Content, Optional extra tags, Merge Requests, Redirects, How to decide what article to display, Reactions. Inspect kind 30818, kind 818, kind 30819, kind 10102, draft, kind:30818, d, content because these are the pieces most likely to surface as product behavior. Read it beside NIP-21, NIP-25, NIP-51, NIP-02 before treating it as isolated.
NIP-54: Wiki 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-54: Wiki 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-54: Wiki 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-54: Wiki 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-21, NIP-25, NIP-51, NIP-02 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-54: Wiki 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-54: Wiki 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-54: Wiki 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 30818, kind 818, kind 30819, kind 10102, draft, kind:30818. 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: Djot, Wikistr, NIP-21 nostr URI scheme, PR #2242. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-54 source is the anchor for exact wording, and NIP-54 commit history shows how that wording moved over time. The strongest secondary clues here are Djot, Wikistr, NIP-21 nostr URI scheme. 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-54: Wiki: first the human promise, then kind 30818, kind 818, kind 30819, kind 10102, draft, kind:30818, then the implementation record, then the real-world failure case. That order keeps NIP-54 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 30818,kind 818,kind 30819,kind 10102to render the work without private context?
What to verify before you rely on it
- Find
kind 30818,kind 818,kind 30819,kind 10102,draftin the official file and check where the UI exposes the same concept. - Read NIP-21, NIP-25, NIP-51, NIP-02 as context before treating NIP-54 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-54: Wiki in that order: Official NIP-54 source for the current wording; NIP-54 commit history for the change record; Djot, Wikistr, NIP-21 nostr URI scheme 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.
