CraysWikifreedia
Wikifreedia turns the wiki problem into a Nostr problem: many signed entries for the same topic, no single canonical version, public forks, merge requests, and reader-side trust filters.
The wiki that refuses the final page
Wikifreedia has one sharp idea: an encyclopedia should not have to pretend that one article has settled a subject forever. The official page calls it "the encyclopedia that can't pick a side." That line is not just branding. It is the whole product thesis. Wikipedia tries to turn conflict into one edited page. Wikifreedia tries to keep the conflict visible by letting different authors publish different signed versions of the same topic.
That makes Wikifreedia one of the more interesting Nostr apps because it is not another microblogging skin. It takes a familiar institution, the public wiki, and asks what changes when authorship is a cryptographic fact. A normal wiki page is a shared document with edit history and moderation rules. A Wikifreedia entry is a Nostr event. It has an author pubkey, a signature, tags, relay locations, and an addressable coordinate. Other people can fork it or ask for a merge, but they cannot quietly become you.
The landing page is deliberately aggressive about Wikipedia. It uses examples such as ivermectin, capitalism, free speech and journalism to show multiple competing perspectives side by side. It says Wikipedia flattens subjects into a single line, while Wikifreedia keeps clusters of disagreement visible. You do not have to accept every rhetorical punch on that page to understand why the app matters. The useful question is narrower and more practical: can Nostr make a wiki where disagreement is stored as first-class data instead of treated as editorial debris?
NostrApps captures the product in four bullets: anyone can edit, anyone can fork, there is no canonical entry for any topic, and Web of Trust should help make sense of it. That is a good compressed summary. Wikifreedia is not saying every entry is equally good. It is saying the platform should not be the final judge. The reader's trust graph, the author's reputation, reactions, deference, relay selection and visible forks become the judging machinery.
That is exciting, but it also raises the bar. A non-canonical encyclopedia cannot hide behind neutral furniture. If it is going to show conflict, it needs excellent provenance, careful UI, useful ranking, and honest warnings. Otherwise it becomes a pile of hot takes with footnotes. Wikifreedia is worth taking seriously because its architecture is tied to an actual NIP, an actual relay and live events. It is also worth reading skeptically because a wiki is high-stakes software: bad knowledge travels faster than many people can correct it.
NIP-54 is the product spec
The technical center of Wikifreedia is NIP-54, the Nostr wiki proposal. NIP-54 defines `kind:30818` as an addressable event for descriptions or encyclopedia entries about particular subjects. That phrase matters. Addressable events use a `d` tag, so a topic is not only an event ID; it is a normalized subject coordinate. The spec expects multiple people to write about the exact same subjects, either with small variations or completely independent content. That is Wikifreedia's social model expressed as protocol.
NIP-54 also explains how topic names are normalized. Uppercase letters become lowercase, whitespace becomes hyphens, many punctuation marks are removed, repeated hyphens collapse, and non-ASCII letters are preserved as UTF-8. That is why a wiki client can turn a human title into a stable `d` tag such as `proof-of-work` or preserve a Japanese, Chinese, Arabic or Cyrillic title without forcing everything into English. For a global knowledge base, that is not a detail. It decides what a link means.
The content format in the NIP is Djot, not plain Markdown. Djot was designed by John MacFarlane, the Pandoc author, and NIP-54 chooses it because encyclopedia pages need more than lightweight chat formatting: footnotes, tables, definition lists, math, stable parsing and wiki links matter. The NIP also says NIP-21 `nostr:` links can point to profiles or arbitrary Nostr events, and unresolved reference-style links can behave as wikilinks to other wiki topics. In other words, a Wikifreedia article can be both a document and a map of Nostr references.
Forks and merge requests are not bolted on as a social feature after the fact. NIP-54 defines `kind:818` as a wiki merge request. A merge request points to the target article with an `a` tag, can name the version it was based on with an `e` tag, points to the author with a `p` tag, and includes the forked event to be merged. The destination author can react to that merge request using NIP-25 reactions. The spec also defines `kind:30819` for wiki redirects, so a topic like BTC can point toward Bitcoin without duplicating content.
The trust machinery is equally important. NIP-54 does not say every client must rank entries the same way. It suggests reactions, relay lists, contact lists, wiki-related author lists, forks and `defer` markers as signals. A `defer` marker is stronger than a simple plus reaction: it lets one author say another author's version is better, effectively putting that pubkey's weight behind someone else. That is the protocol version of "I am not maintaining my fork; read theirs."
This is why Wikifreedia should be read as a NIP-54 product, not merely a politics page. The app's promise only becomes interesting because Nostr gives it portable primitives: signed events, addressable coordinates, relay discovery, reactions, lists and bech32 identifiers. If another client can understand `kind 30818` and `kind 818`, then Wikifreedia's work does not have to die inside Wikifreedia.
What the live app is doing
The live app is a SvelteKit web client at `wikifreedia.xyz`. Its public HTML describes the product as a place to search, compare and publish decentralized encyclopedia entries on Nostr. The routes exposed by the built app tell you a lot about the product shape: `/explore`, `/new`, `/drafts`, `/comments`, `/fund`, `/welcome`, `/a/[naddr]`, `/[topic]`, `/[topic]/compare`, `/[topic]/[pubkey]` and merge-request routes under `/pr/[naddr]/[pr]`. That is not a static demo. It is a web app for browsing topics, writing entries, comparing versions and following author-level views.
The `/explore` route currently emphasizes recommended wiki authors, active authors and recent topics. During this check, the server-rendered page showed no public wiki-author recommendations, no active authors and no matching recent topics in that view, but the client also shows a wiki cache sync panel pointed at `wss://relay.wikifreedia.xyz`. That is a good sign and a caution at once. The app is trying to sync a Nostr corpus locally, but some views may still look empty depending on hydration, relay state, trust filters and cache progress.
The `/new` route exposes the writer side. The server-rendered controls include a rich editor, category field, Save draft and Publish buttons. The status text says sign-in is required to save drafts and publish. The bundled code creates a NIP-54 wiki event with title, category, content and a normalized topic tag, sets `published_at`, adds an `alt` description pointing readers back to `https://wikifreedia.xyz/a/...`, and publishes the replaceable event. In Nostr terms, the app is not asking a central database to save an article. It is creating a signed event that relays can store.
Article routes use `naddr` for direct addressable-event links. NIP-19 defines `naddr` as a bech32 coordinate that can carry the identifier, author pubkey, kind and relay hints for addressable events. Wikifreedia uses that exactly where you would expect: `/a/[naddr]` for a specific wiki entry and `/[topic]/[pubkey]` for the author's version of a topic. That distinction is central to the product. A topic is not a page. A topic is a neighborhood of signed entries.
The compare route is one of the product's strongest ideas. The app gathers entries for a topic and can call `/api/event-comparisons` with selected event IDs. The landing page describes AI comparison as a way to surface fault lines between entries instead of forcing a fake consensus. That feature is powerful if used carefully. A good comparison can tell readers, "these authors disagree about evidence standards, incentives and institutional trust." A bad comparison can launder weak claims into symmetry. The article reader should treat AI comparison as a guide to inspect, not an authority to obey.
Comments and funding are present too. `/comments` is framed as live discussion from across wiki entries and, during this check, showed zero comments. `/fund` introduces a Wikifreedia Fund: patronage for writers who bring declared perspectives, with a Geyser donation link and a pitch path back to `/new`. That funding language is unusually honest about bias. It does not pretend writers have no perspective. It says the perspective should be declared, funded and attached to the author.
The relay is part of the product
Wikifreedia is not only a website. It also has a dedicated relay at `wss://relay.wikifreedia.xyz`. With the correct NIP-11 `Accept: application/nostr+json` header, that relay identifies itself as "Wikifreedia relay," describes itself as a relay for wiki events with search, and advertises a pubkey of `fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52`. If you request it like an ordinary web page, it returns a plain 404. That is not necessarily a failure; many relays only speak their real metadata when asked like a Nostr client.
The relay repository is public under `pablof7z/wikifreedia-relay`. It is a small Go relay built with Khatru, `go-nostr`, Fiatjaf's eventstore layer and SQLite. The README says it accepts only wiki-related event kinds: `30818`, `30819`, `818` and `819`. The `main.go` file confirms the allowlist and rejects everything else with the message "only wiki events are allowed here." That narrowness is good product design. A wiki relay should not become a general feed relay by accident.
The relay also enables Negentropy, the set reconciliation protocol now specified as NIP-77. That matters for a wiki because a client may need to warm or sync a local cache of many events without blindly downloading the same data again and again. The relay's public NIP-11 metadata advertises NIP-77 support, and the live app exposes a "Wiki cache sync" panel with need, have, warmed and bytes counters. The relay is not decorative infrastructure. It is how the app tries to make a distributed wiki feel browsable.
A direct Nostr check during this review found live data. A `COUNT` request against `wss://relay.wikifreedia.xyz` returned 393 `kind 30818` wiki events, 0 `kind 30819` redirects, 30 `kind 818` merge requests and 7 `kind 819` merge-answer-style events. Sample `30818` entries included topics such as Mangatsu, Serine and Pokemon Red, Blue, and Yellow. Some entries looked like imported or converted encyclopedia material; others looked like Nostr-native project profiles. The point is simple: the relay is not empty.
The counts should not be overread. They are a timestamped observation from June 7, 2026, not a permanent guarantee. Relays can prune, import, republish and change policy. Still, those numbers are useful because they move the article from "this app claims to be a wiki" to "this app is already publishing and relaying NIP-54 wiki events."
Trust, funding and the team trail
The public team trail is thinner than the product trail. The official site does not present a formal company page or a tidy list of founders. The current relay repository belongs to Pablo Fernandez's GitHub account, `pablof7z`, and the MIT license in that repo names Pablo Fernandez. A second public repository, `bquast/wikifreedia-web`, exists under another account and appears to be an older or separate prototype called "Nostipedia - Wikipedia on Nostr" rather than the current SvelteKit site. It is worth citing, but not worth pretending it proves current ownership.
That means the honest reading avoids a founder myth. Wikifreedia has public operatorship clues: the domain, the live app, the relay repo, the relay pubkey, the Geyser project link and the code-level dependency trail. It does not yet have the sort of about page that lets a reader confidently map the full team. For a public knowledge system that asks readers to care about author accountability, that gap matters. The app's own philosophy says named authors are important; the project should be held to the same standard.
Identity in the app is Nostr-first. The `/welcome` route says your identity lives on Nostr and includes a username field ending in `@wikifreedia.xyz`. The sign-in path is also supported by outside signer flows. Nsec.app has a dedicated guide showing Wikifreedia login: copy your `name@nsec.app`, click Connect with Nostr or the avatar in Wikifreedia, paste the username and confirm in Nsec.app. That is the safer pattern for a web app. You want a signer to approve events rather than pasting a private key into every site that wants to publish.
The fund route is part of the trust story too. Wikifreedia asks donors to fund perspectives, not a fake view from nowhere. It links to Geyser and frames the fund as Bitcoin patronage for writers who declare their viewpoint and do research. That is culturally very Nostr: identity, publishing and money are close together. It is also risky. Paid perspective writing can produce excellent pluralism, or it can produce bounty-driven advocacy wearing an encyclopedia costume. The difference will depend on author disclosure, reader tools and the quality of the trust layer.
Where this can go wrong
The first risk is epistemic theater. Wikifreedia's landing page is right that consensus can be captured. But "no canonical page" does not automatically produce truth. It can produce a better map of disagreement, or it can produce a museum of confident nonsense. A reader needs provenance, citations, author history, reactions from trusted people, forks, deference markers and visible counterarguments. If the interface hides those signals, the architecture alone will not save it.
The second risk is spam and scale. NIP-54 leans on Web of Trust, reactions, lists and relay selection, but it does not standardize one ranking algorithm. That is both a feature and a burden. A reader with a strong follow graph may get useful recommendations. A new reader with no trust graph may see an empty interface or a noisy one. The app says no one is silenced and no one is banned, but relays still have policies. The Wikifreedia relay itself only allows wiki event kinds. Other relays can index, ignore or reject different subsets of the corpus.
The third risk is legal and safety exposure. A forkable public wiki can carry health claims, biographies, accusations, copyrighted imports and defamatory edits. Signed authorship helps accountability, but it does not make content safe. The official demo uses explosive subjects precisely because they show why conflict matters. That also means Wikifreedia has to be careful not to turn "many perspectives" into "all claims deserve equal weight." Showing disagreement is useful. Pretending every disagreement is equally evidenced is not.
The fourth risk is transparency. The relay repo is public, but the current web app's full source repository is not obvious from the public search trail. The built SvelteKit bundles are visible in the browser, and they reveal useful product mechanics, but built bundles are not the same thing as a maintained source repository with issues, tests and review history. For a project about accountable knowledge, open development would strengthen the case.
The fifth risk is data permanence. Wikifreedia's own pitch says no admin can delete your entry because entries live on Nostr. That is partly true in the architectural sense: once an event is published to relays, the app cannot globally unpublish it. But Nostr deletion is always relay-dependent, and discoverability is not the same as existence. If an author loses keys, if relays prune data, if a relay stops serving search, or if a client ranks an entry out of view, the user experience changes. Durable public knowledge needs many relays, backups and interoperable clients.
How to test Wikifreedia
Start as a reader. Open `/explore`, then search or open a known topic route. Do not judge the whole idea by the landing page. Look for the author, the title tag, the topic slug, the published date, alternate versions and the link to the specific `naddr`. If there are several entries for a topic, compare them. Ask whether the app helps you see disagreement more clearly or simply puts several essays near each other.
Then test the relay layer. Query `wss://relay.wikifreedia.xyz` for `kind 30818` with a small limit. Confirm that events have `d` and `title` tags. Try a `COUNT` request. Request NIP-11 metadata with `Accept: application/nostr+json`. This sounds technical, but it is the quickest way to know whether the product is actually using Nostr or merely saying it does. Wikifreedia passes that basic test.
Next, test writing with a disposable key or a signer you understand. NIP-07 browser signers and Nsec.app-style flows are better than pasting secrets into a web form. Publish a harmless test topic. Look at the event kind, tags and content. Does the `d` tag normalize as expected? Can the article be found again from another client or via direct relay query? Can you fork it? Can you make a merge request? Can you find the result without relying only on Wikifreedia's own UI?
Finally, test the social layer. Follow or recommend authors you actually trust. React to an entry. Try to understand what the app does with wiki-author lists and Web of Trust. If your trust graph is empty, notice what disappears. If your graph is strong, notice whether the app becomes more useful. The whole system stands or falls on that reader-side filtering layer. Without it, Wikifreedia is just a loud wiki. With it, it could become a genuinely new way to navigate contested knowledge.
Sources worth opening
This article keeps claims close to primary project sources, live relay behavior and the NIPs that Wikifreedia is built around. Start here if you want to verify the product yourself.
- Wikifreedia official site
- Wikifreedia explore route
- Wikifreedia new-entry route
- Wikifreedia welcome and profile setup route
- Wikifreedia comments route
- Wikifreedia fund route
- Wikifreedia on NostrApps
- Nsec.app guide for signing into Wikifreedia
- Wikifreedia relay NIP-11 endpoint
- pablof7z/wikifreedia-relay repository
- Wikifreedia relay README
- Wikifreedia relay main.go
- Wikifreedia relay Go module
- Khatru relay framework
- Fiatjaf eventstore
- go-nostr library
- bquast/wikifreedia-web older web prototype
- Nostipedia prototype index
- Nostipedia prototype app script
- NIP-54 wiki events
- NIP-77 Negentropy syncing
- NIP-19 bech32 identifiers and naddr
- NIP-21 nostr URI scheme
- NIP-07 browser signer capability
- NIP-05 identifier mapping
- NIP-25 reactions
- NIP-51 lists
- NIP-02 contact lists
- Djot markup language
- Nostr Web of Trust extension
- Nostr Compass on Web of Trust
- Wikifreedia Geyser project
- Geyser product features documentation
