Wikistr

Apps18 min readNIP-54 wiki client

Wikistr

Wikistr is a small Svelte client for Nostr wiki events. Its important idea is not a glossy home page. It is a horizontal card workspace for topics, authors, relays and editor sessions.

A wiki client that thinks in cards

Wikistr does not behave like Wikipedia with a purple logo. It behaves like a Nostr debugging surface that happens to be pleasant enough to read. The live site at `wikistr.com` has almost no conventional landing page. The HTML metadata says simply, "A wiki built on Nostr," and the JavaScript app does the real work. Open a topic route such as `/bitcoin` and the product appears: an account card, a recent-articles card, a topic search card, relay pills, result cards, and a small input that can add another card to the horizontal workspace.

That card model is the product. A URL path is not just a route; it is a stack of work surfaces. The Svelte route handler turns each path segment into a card. A segment beginning with `edit:` becomes an editor. An `npub1...` segment becomes a user card. A domain name, `wss://` URL or `ws://` URL becomes a relay card. A string shaped like `dtag*pubkey` becomes an article card. Everything else becomes a search card. In practice, that means a reader can start with a topic, jump to a relay, open an author, inspect another version and keep those pieces side by side.

This makes Wikistr feel more like a workbench than a publication. That is a compliment and a warning. It is excellent for understanding how Nostr wiki data moves. It is less gentle for a reader who expects a single clean article and a single search box. The interface assumes you are willing to notice relays, authors and versions. If you do not want to know those things, Wikistr can look unfinished. If you do want to know them, the app is refreshingly direct.

NostrApps describes Wikistr as a NIP-54 wiki client with a multi-article view. Its highlights are accurate: side-by-side articles, relay selection influenced by Web of Trust and recommendations, outbox behavior, rabbit-hole suggestions and a plain-text editor. The important word is "multi." Wikistr is built around the fact that NIP-54 does not create one page per topic. It creates many signed entries for the same normalized topic, written by different pubkeys, found on different relays, with clients responsible for deciding which versions deserve attention.

That is why Wikistr belongs beside Wikifreedia in this archive but should not be collapsed into it. Wikifreedia is a rhetorical and product attempt to make a public encyclopedia out of NIP-54. Wikistr is closer to a client and inspector. It asks: what if a wiki reader could see the database seams on purpose? What if the article, author, relay and editor were separate cards, and the reader could move between them without pretending that one server owns the page?

NIP-54 is the spine

The protocol underneath Wikistr is NIP-54, the draft Nostr wiki specification. NIP-54 defines `kind:30818` as an addressable event for descriptions or encyclopedia entries about particular subjects. Articles are identified by lowercase, normalized `d` tags. That one design choice changes the whole mental model. A page called Bitcoin is not a row in a database. It is a coordinate such as `30818::bitcoin`, and several pubkeys can publish their own `bitcoin` article at the same time.

Wikistr's code uses exactly that spine. In `src/lib/nostr.ts`, `wikiKind` is `30818` and `reactionKind` is `7`. Search cards query `kinds: [wikiKind]` and `#d` when looking for exact topic matches. Article cards identify an article by `[dTag, pubkey]`. The editor publishes an event with `kind: wikiKind`, a normalized `d` tag, optional `title` and optional `summary`, and the text content the user wrote. The client does not need Wikistr's server to own the article because the article is an event.

NIP-54 also defines merge requests as `kind:818`, redirects as `kind:30819`, reactions as one possible trust signal, and `defer` markers for authors who want to point their weight toward another version. Wikistr's current visible code focuses more on search, reading, writing, forking and reactions than on a full merge-request workflow. That distinction matters. The app is a strong NIP-54 reader and writer, but it is not yet the whole governance layer of a wiki.

One technical tension is worth saying plainly. The current NIP-54 text says wiki content should be Djot. Wikistr renders and previews with `svelte-asciidoc`, and NostrApps still describes it as a plain-text editor that renders Asciidoc. The code also has a compatibility flag called `supportMarkdownTransition` for older events before a September 2024 timestamp. This tells you something about the history of Nostr wiki experiments: the spec and the clients have moved. Wikistr is useful, but a reader should not assume every formatting choice in Wikistr is the final shape of NIP-54.

That formatting mismatch is not merely academic. A wiki needs stable links, tables, footnotes, media embeds and predictable rendering across clients. If one client treats content as Asciidoc and another expects Djot, the same event can feel different. Wikistr mitigates this by converting its own `[[wikilinks]]` into Asciidoc links and by offering article views for formatted output, Asciidoc source and raw event JSON. That transparency helps. It also shows why decentralized wiki clients need to be conservative about markup.

Search, relays and the outbox model

Wikistr is unusually explicit about relays. The defaults are separated into categories. Metadata and relay-list lookups use `wss://purplepag.es`, `wss://relay.nos.social` and `wss://user.kindpag.es`. Arbitrary identifiers use `wss://cache2.primal.net/v1`, `wss://relay.damus.io` and `wss://relay.nostr.band`. The wiki relay defaults are `wss://relay.wikifreedia.xyz`, `wss://nostr.wine`, `wss://nostr21.com` and `wss://relay.nostr.band`. Search defaults are `wss://relay.wikifreedia.xyz` and `wss://custom.fiatjaf.com`.

That separation is good engineering. A client should not assume every relay is good at every job. Some relays are better for profile metadata, some for search, some for author relay lists, some for a topic-specific corpus. Wikistr's UI reflects that: the live `/bitcoin` route shows the wiki-relay pills directly in the Recent Articles card. A reader can see where the app is looking instead of being told that the network magically works.

The search flow combines exact NIP-54 topic lookup with relay search. A search card normalizes the query using `normalizeIdentifier`, asks user wiki relays and preferred-author relays for exact `#d` matches, and also sends a NIP-50-style `search` filter to the default search relays. It sorts exact `d` matches above weaker matches and then uses the local Web-of-Trust score map as a ranking signal. That is the right kind of product opinion for a decentralized wiki: first find the topic, then decide whose version is worth reading.

Wikistr also uses outbox ideas. For a single author, it loads that pubkey's relay list and subscribes to up to four write relays. For many authors, it uses `outboxFilterRelayBatch` from `@nostr/gadgets/outbox`. This is the practical answer to a boring but fatal question: where do you fetch someone's article? A decentralized wiki cannot work if every client hammers the same global relays. It has to learn where authors publish.

The live check on June 7, 2026 matched the code. After a few seconds, `https://wikistr.com/bitcoin` showed Recent Articles from the default wiki relays and several `bitcoin` versions by different authors. A direct relay count found 393 `kind 30818` wiki events and 10 `bitcoin` entries on `wss://relay.wikifreedia.xyz`; `wss://nostr21.com` returned 334 wiki events and 2 `bitcoin` entries. `wss://nostr.wine` and `wss://relay.nostr.band` timed out for that simple count check, which should not be overread, but it is a useful reminder: relay availability is part of the user experience.

The app even republishes articles it has loaded back to up to three of the author's write relays after a delay. The comment in the code says this is to help Nostr stay by publishing articles from others into their write relays. That is a very Nostr-specific behavior. It can improve availability if an article was discovered from one relay but missing from the author's usual relays. It also means a reader should understand that clients can affect propagation, not just consume data passively.

Writing, forking and reader signals

Wikistr's editor is deliberately plain. It asks for a title, article content and an optional summary. Preview toggles the same rendering path used for article display. Save signs a NIP-54 event through `window.nostr` and publishes it to the logged-in user's write relays plus the default wiki relays. The publish report shows each relay target and whether it succeeded or failed. That is the kind of UX that teaches the protocol without stopping to explain it.

The signer path is browser-based. The live HTML includes `window.nostr.js`, and the code calls `window.nostr.getPublicKey()` and `window.nostr.signEvent()`. That is safer than asking the user to paste an `nsec` into the page. It also means the app depends on a NIP-07-capable signing environment or a helper that exposes the same `window.nostr` interface. For a wiki client, this matters because editing is not a throwaway action. A signed wiki article attaches a public identity to a claim.

The fork behavior is simple and revealing. If you open someone else's article, the action label becomes Fork; if it is your own, it becomes Edit. The editor pre-fills title, summary and content from the current event. Saving publishes a new event under your pubkey. That is closer to Git than to Wikipedia. You do not overwrite the other author's page. You create your version. If the original author wants to adopt it, NIP-54 has room for merge requests and deference, even if Wikistr's visible UI does not yet make that a complete social workflow.

Reader signals are present through reactions. The article card can create a `kind 7` event with an `a` tag pointing to the addressable wiki coordinate and an `e` tag pointing to the concrete event. The UI calls these like and dislike, with `+` and `-` content. NIP-54 treats reactions as one possible recommendation signal rather than raw popularity. That is important. In a wiki, a plus from someone you trust is very different from a thousand pluses from unknown accounts.

Wikilinks are also product behavior, not decoration. Wikistr turns `[[Target]]` or `[[Target|Display]]` into an internal search card for the normalized target. When the article renderer sees a wiki link, clicking it creates a new search card with preferred authors inherited from the current author and the author's wiki-author list. That means a link inside an article can carry a trust path. You are not just jumping to a word; you are jumping through a reader and author context.

External Nostr links get special handling too. The Nostr link component decodes `npub` and `nprofile` references and can turn them into user labels. Other `nostr:` links fall back to external links. The app shares articles as `naddr` links through `njump.me`, encoding kind, identifier, pubkey and relay hints. Again, the client keeps showing the underlying Nostr shape: addressable event, author, relays, shareable coordinate.

Who built it and how mature it feels

The public project trail is clearer than Wikistr's own homepage. `stuff.fiatjaf.com` lists `wikistr` under the fiatjaf organization's Nostr tools and calls it a Nostr client for wiki events. The source link points to `fiatjaf/wikistr`, a public GitHub repository described as a "wikipedia" client for Nostr. The repository is a fork of `github-tijlxyz/wikinostr`, which was created on August 31, 2023. Fiatjaf's fork was created on September 1, 2023.

As of this check, the GitHub API shows `fiatjaf/wikistr` with Svelte as the primary language, 17 stars, 4 forks, 0 open issues, no detected license, default branch `master`, and latest push on May 1, 2025. The latest visible commit message is "fix double wikilink." Contributors listed by the API include `fiatjaf`, the original `github-tijlxyz` account, and others. This looks like a real small open-source tool, not a company product.

The dependency list reinforces that impression. Wikistr uses SvelteKit, Svelte 5, Tailwind, `@nostr/tools`, `@nostr/gadgets`, `idb-keyval`, `debounce` and `svelte-asciidoc`. It uses `@sveltejs/adapter-static`, so the public app can be served as static files while the real state lives in relays, IndexedDB and the user's signer. That is a very clean fit for Nostr: the web host delivers a client, but the content system is not the web host.

There are also signs of unfinished edges. The Settings card contains a Save and Reload button but no real save behavior in the current source. The homepage can appear empty until you open a topic or wait for cards to populate. Some important NIP-54 features, especially merge-request handling, are not as complete in the UI as the protocol suggests. The repository has no license file, which makes reuse legally ambiguous despite the code being public. These are not fatal flaws, but they should stop anyone from describing Wikistr as a polished encyclopedia platform.

The better description is narrower: Wikistr is a real, working, inspectable NIP-54 client with strong ideas about cards, relays and trust. It is especially useful for builders, protocol readers, wiki experimenters and people who want to see how Nostr wiki articles behave in the wild. It is not yet a consumer-grade public knowledge site. That is fine. The ecosystem needs sharp tools before it gets beautiful tools.

The risks are the product

The first risk is formatting drift. Current NIP-54 favors Djot; Wikistr currently renders Asciidoc. Existing live wiki events include Asciidoc-style pages, imported encyclopedia-looking material, Markdown-like content and plain notes. A reader may see something that looks correct in Wikistr but less correct in another NIP-54 client. The article corpus is portable at the event layer, but presentation may not be portable yet.

The second risk is ranking. Wikistr uses exact matches, Web-of-Trust scores, relay lists and author preferences. That is far better than pretending all entries are the same. But ranking is still a product decision. If your trust graph is weak, empty or captured by a narrow group, the wiki you see may be thin or distorted. Wikistr exposes some of this machinery, yet it does not solve the social problem by itself.

The third risk is relay dependence. The app is decentralized only if useful wiki events are discoverable across relays. During the live test, two default relays answered simple count requests and two timed out. The UI still loaded rich results because subscriptions and relay behavior are more nuanced than one count probe, but the lesson holds: a Nostr wiki is only as readable as its relay strategy. Paid relays, search relays, author write relays and topic relays will all shape what readers can find.

The fourth risk is content safety. A forkable, signed, relay-backed wiki can carry health claims, biographies, accusations, copyrighted imports, propaganda, spam and sincere research in the same event kind. Wikistr makes provenance more visible than a central wiki does, but provenance is not truth. A signed bad claim is still a bad claim. A client for public knowledge needs citation culture, trust tools and moderation surfaces that match the seriousness of the material.

The fifth risk is key hygiene. Wikistr uses `window.nostr`, which is the right direction, but users still need to understand what they are signing. A wiki edit is public and durable. A reaction can become a recommendation signal. A fork attaches your pubkey to another person's content. The app should be used with a signer you trust and, for experiments, a key you are comfortable linking to unfinished public work.

How to test Wikistr

Start with a topic route, not the home page. Open `https://wikistr.com/bitcoin`, wait a few seconds, and watch the workspace populate. Look for the account card, the default wiki relays, the topic search card and multiple versions of the same topic. Click a version and use the formatted, source and raw-event views. The raw event view is the quickest way to verify that you are looking at a real `kind 30818` event with a `d` tag, title and pubkey.

Then test relay thinking. Open a relay card by adding a `wss://` relay segment or clicking one of the relay pills. Does it return wiki events? Does it time out? Does it show a different slice of the corpus? Compare `relay.wikifreedia.xyz` with `nostr21.com` and a general relay. The point is not to memorize relay names. The point is to feel how much a wiki client depends on relay choice.

Next, test author context. Open a user card from an article author. Notice whether their profile and relay information helps you understand why this version appears. If you are logged in, compare Recent Articles from your relays with Articles from Contacts. That switch is Wikistr's most honest lesson: the same Nostr wiki can look different depending on who you trust and where your network publishes.

Finally, test writing with a disposable topic and a signer you understand. Create a harmless article, preview it, publish it, and inspect the relay publish report. Then open the raw event. Confirm the `kind`, `d` tag, `title`, `summary` if present, content, pubkey and relay hints. Try opening the same article through another client or through an `naddr` link. If the event survives that journey, Wikistr has done the Nostr part correctly.

Sources worth opening

This article uses the live app, the public GitHub repository, the original Wikinostr fork trail, NostrApps, fiatjaf's project index, current NIPs and the libraries Wikistr actually imports.

• Wikistr live app
• fiatjaf project index with Wikistr
• Wikistr on NostrApps
• fiatjaf/wikistr repository
• GitHub API metadata for fiatjaf/wikistr
• Wikistr package.json
• Wikistr default relay configuration
• Wikistr Nostr state and signer code
• Wikistr outbox subscription helper
• Wikistr card type definitions
• Wikistr utility functions and wikilink conversion
• Wikistr path-to-card route
• Wikistr search card
• Wikistr article card
• Wikistr editor card
• Wikistr welcome and recent articles card
• Wikistr relay card
• Wikistr article renderer
• Wikistr wikilink component
• Wikistr Nostr link component
• Original github-tijlxyz/wikinostr repository
• NIP-54 wiki events
• NIP-50 search capability
• NIP-19 bech32 identifiers and naddr
• NIP-21 nostr URI scheme
• NIP-25 reactions
• NIP-51 lists
• NIP-65 relay list metadata
• NIP-07 browser signer capability
• NIP-02 contact lists
• @nostr/gadgets on JSR
• @nostr/tools on JSR
• svelte-asciidoc npm registry metadata
• Wikifreedia relay used by Wikistr defaults
• Nostr Web of Trust reference