An independent interpretation of the released Udanax Gold source · not Project Xanadu documentation · about this documentation

What people said killed Project Xanadu — and what happened when we built it anyway

Four objections, sixty years of hindsight, one running system.

Every few months a thread appears asking what Project Xanadu was and why the Web won instead. The answers settle into a pattern — four reasons the 1960 design was “DOA.” They're reasonable reasons. They were mostly true in 1998. They are also, it turns out, all testable — because the model runs now. This piece is about what we learned building a working xanalogical system in 2026, one objection at a time.

Project Xanadu is Ted Nelson's project. This piece is about the ideas it proposed — transclusion, two-way links, unbreakable connections — which Nelson coined terms for and championed for decades. The work described here is independent, open-source (Apache 2.0), and not affiliated with or endorsed by Project Xanadu. It stands on the shoulders of the code the Udanax teams released openly in 1999, and on the modern tooling they never had.

Objection 1 “It was never really implemented”

Mostly fair, as history. The Xanadu teams never shipped to the public in their era. But “never implemented” stopped being true on August 23, 1999, when the surviving code was released openly: Green — the design developed from 1979 by the Swarthmore team through 1988 at the Xanadu Operating Company, released as Xanadu 88.1 — and Gold — Xanadu 92.1, developed from 1988 through 1995 at Udanax.com and, briefly, under Ted Nelson's own company (Memex, now Filoli). Real enfilades, real tumblers, working systems that simply predated the web-frontend era.

That code is hard reading by modern standards; it took a later generation's tooling — test harnesses and languages alike — to make the model approachable again. And it stops being an obstacle today: our system, Xudanu, runs the model — quoting by reference, live transclusions that update when their sources edit, bidirectional links that survive edits to either end — in a Rust server with a browser frontend and a phone client. Not a paper. A URL you can type into.

Objection 2 “Backlinks become spam — everyone who linked to the Bible gets listed”

This is the strongest intuition-pump against two-way links, and it's a user-interface question, not an architecture one. The registry of inbound connections is per-document and scoped: you see what points at this passage, this document, this thread — filterable by link type, pinnable, and quiet by default. The “billion backlinks” case is a sorting problem with forty years of UI practice now available to solve it. In practice the problem is the opposite: backlinks are the feature people notice first. Quote a document; the author sees your quotation in context, from their side, forever.

Objection 3 “Micropayments make it hostile — pay-spam everywhere”

The original vision coupled transclusion to royalty plumbing, and the coupling scared people off. It was also unnecessary. Our hard design rule: the server never handles money. Rights travel as metadata — per-work licences, transcopyright-style permissions, warnings when a source forbids reuse — and settlement, if any, is somebody else's layer, plugged in at the edges. Provenance without a toll booth turns out to be the valuable half of the idea: every passage carries signed, chained authorship you can verify without trusting the server. That part works today, on a phone.

Objection 4 “Over-thought — ordinary people couldn't use it”

This one we respect the most, because it's the one the Web got spectacularly right: simple first. The lesson we took: the deep structure must be opt-in, not a prerequisite. Our system opens like a plain document editor — type, save, done. The xanalogical layer reveals itself progressively: colours under the text showing who wrote what; a quote that visibly updates when its source is edited; two-way connections discoverable when you go looking. Nobody has to understand tumblers to get value — any more than you need to understand TCP to send a link.

The comment that got it right

In one such thread, a reader cut past the noise to the real prize: links from passage to passage that stay valid while both documents change over time. Anyone who maintains a documentation set, a research corpus, or a regulation-bound archive knows link rot as a permanent tax. The Xanadu answer — addresses that survive edits, connections that migrate with their text — was dismissed as impossible-to-build complexity. It required solving document addressing, position migration, and per-span provenance together, which is why nothing attempted it. It is also, now, the part that works most reliably in our system: 3,200 backend tests hold that behaviour in place, and the demo server runs it continuously.

Where that leaves it

The honest summary of 60 years: the vision was right about what (durable connection between documents), early about provenance and rights, and wrong about how much the world would adopt at once. The Web built the adoption layer first and has been re-discovering the connection layer ever since — permalinks, DOIs, quote-tweets, embeds, canonical sources: each a partial re-implementation of something specified in 1960.

We built the whole thing because partial versions kept winning: the ideas compose. A document you can quote by reference, that credits its authors cryptographically, whose links cannot break, and that anyone can self-host in one Docker container — that is a complete, small, testable answer to the question in that thread.

Try the live demo Source (Apache 2.0) Self-hosting guide