Xanadu and the rejected ideas
The story of Xanadu is the story most people associate, when they think about it at all, with hypermedia’s failure. It is the example reached for when somebody wants to argue that visionary computing projects produce visionary documents and not visionary software. Wired magazine ran a cover story in June 1995 called “The Curse of Xanadu,” by Gary Wolf, that is the most-cited piece of writing on the project and that frames it as the longest-running vaporware in history. The framing has stuck. It is also, as a way of understanding what Xanadu is and was, almost entirely wrong. Xanadu shipped working code more than once. Some of its ideas have been implemented elsewhere. Some have not, and the parts that have not are not vaporware — they are unsolved engineering problems that several systems have since attempted with mixed results. Ted Nelson has been working on the project, in various forms, for sixty-five years. The chapter below is about what he was actually proposing, why what he was proposing turned out to be hard, what the web specifically chose not to take from him, and what the present state of the recovered ideas looks like.
Nelson, and what Xanadu was supposed to do
Theodor Holm Nelson was born in 1937, the son of two figures in mid-century American entertainment (his mother Celeste Holm an Oscar-winning actress, his father Ralph Nelson a television and film director). He did graduate work at Harvard in sociology, where in 1960 he took a computer course and began thinking about how the structure of computation might let a writer escape the linear constraints of the printed page. The project he named Xanadu, after Coleridge’s Kubla Khan, dates from that moment. The word “hypertext” comes a few years later. Nelson coined it in 1963 and first published it in print in 1965 in a paper titled “A File Structure for the Complex, the Changing, and the Indeterminate,” presented at the Association for Computing Machinery’s national conference. “Hypermedia” followed shortly after. Both terms were Nelson’s, and both spread quickly into the small community that was beginning to take the problem seriously.
Nelson’s proposal — held with remarkable consistency across six decades of writing, interviews, and demonstrations — was that the natural form of writing is nonlinear and that the natural form of reading is the assembly of quotations from other writing into new writing. He treated the linear sequence of pages in a printed book as a historical accident imposed by the constraints of bound paper, not as an essential property of writing. A computer system, freed from those constraints, should let an author produce documents that branched, that referenced other documents directly rather than through copy-pasted quotation, that maintained the connection between a quoted passage and its source forever, and that let a reader move between the original and the citing context with a single gesture. The system should also, Nelson insisted, let the original authors of quoted material receive a small payment each time their words were used. The economics and the engineering were not separable in his proposal; the rights model and the technical model were features of the same system.
The project’s published list of features — Nelson has formalized it variously over the years, most famously as a “17-rule” specification in the 1980s — contains items that vary in their technical strangeness from the obvious to the unprecedented. Some are now familiar: that the system should be open to any user, that any user should be able to publish, that documents should be addressable by reference. Others are now alien: that every byte of every document is permanently addressable for the life of the system; that quoted passages should always be quoted by reference and never by copy; that the original author should always be findable from a quotation; that revisions of a document should not destroy previous versions but live alongside them; that links between documents should be visible from both ends. The list runs to seventeen items in the version most often cited and to more or fewer in other versions. The number is not the point. The point is that Nelson proposed a coherent set of properties that together constitute a serious answer to the question “what should a hypermedia system do,” and that the answer is structurally different from the answer the web gave.
Transclusion and the rights model
The single most important Xanadu idea is transclusion. The word is Nelson’s coinage, and it names a precise operation: the inclusion of a passage from one document inside another document by reference, in such a way that the passage is not copied. The included passage is shown, in the citing document, but it is the original passage, retrieved from the source. If the source changes — though in Xanadu the source does not change in the destructive sense, because version permanence keeps the old version available — the citation can be made to follow the change or to remain pinned. The included passage carries its origin with it. Click on a transcluded paragraph and you are taken to the document it was quoted from, in the place it appeared. The reverse pointer is also live: in the source document, you can see which other documents have transcluded which of its passages and follow the citations back.
Transclusion is not difficult to describe and is not impossible to implement. It is implemented, in approximate forms, in several systems alive today. What Xanadu proposed that no major working system has implemented is universal transclusion: the rule that every quotation in the system, of every kind, is a transclusion, and that copying-by-value is something the system does not do. This is the engineering claim that makes Xanadu both interesting and hard. If every quotation is by reference, then the original document must remain available forever, at a stable address, for as long as any citing document survives. If documents are written by independent authors on independent machines, the system must reconcile the durability requirement with the autonomy of the authors. Authors must not be able to break other people’s documents by editing or deleting their own. The system must therefore maintain version permanence: old versions of edited documents are preserved alongside new versions, and citations point to specific versions, not to “the current version” in a mutable sense.
Universal transclusion plus version permanence yields the basis of the rights model. Because every quotation is a reference and not a copy, the system always knows which authors are being read whenever any document is read. A reader pulling up a derivative document is, automatically, pulling up the original work of every author whose words are transcluded into it. Nelson proposed that the system bill the reader (a small amount, perhaps fractions of a cent) for each access, and divide the payment among the authors whose work was being read in proportion to how much of their work was being read. This was not micropayments in the recent sense of subscription substitutes; it was a built-in royalty system that ran whenever anyone read anything. The rights model was not bolted onto the technical model. It was the same model, viewed differently.
It is worth being honest about what is and is not original here. The idea of paying authors per use of their work was old; it underlay the music licensing system that ASCAP had been administering since 1914 and the various photocopying-rights organizations that emerged in the postwar period. What was original in Nelson’s proposal was the integration of the rights system with the storage system, such that the bookkeeping was a side effect of the storage, not a separate accounting. This integration is what universal transclusion buys you. It is also what makes the system hard to ship, because you have to get the storage and the rights and the version control and the addressing all right at the same time before you can show anyone how it would work.
Tumblers and the addressing scheme
The other Xanadu idea that has not made it into the web is the addressing scheme that Nelson called “tumblers.” A tumbler is an address that identifies, with arbitrary precision, a specific span of bytes inside a specific version of a specific document by a specific author. The address is hierarchical and infinite-precision: a publisher number, a user number, a document number, a version number, a byte range within the version. Tumblers compose: you can point to a passage inside a transclusion inside a document inside a publisher’s catalog. Any span at any level of nesting has a unique, stable address.
The web’s addressing scheme — the URL — addresses documents, not spans within documents. Recent additions (fragment identifiers, the text-fragment extension, “scroll to text fragment”) have started to add span-level addressing on top of URLs, but the addresses are second-class citizens: they are advisory hints to the rendering layer, not first-class objects the system tracks. In Xanadu the tumbler is the address. There is no separate notion of a document URL with optional fragment; every address is span-precise. This makes citations precise in a way web citations are not, and it makes the underlying database structurally aware of which parts of which documents are linked to which other parts.
Tumblers are also, like much of Xanadu, structurally expensive. To support them at the scale Nelson proposed, the system needs a global address space, allocated by some authority, with the structural properties that subordinate addresses can be issued by subordinate authorities. Nelson’s design for this — a hierarchical allocation under a global root, with each publisher controlling their own range — is technically similar in shape to DNS, but with much heavier semantic content per address. It would have worked at small scale. Whether it could have worked at internet scale is a question that has never been answered, because Xanadu has never operated at internet scale.
The institutional history
The hard part of writing about Xanadu is being honest about its institutional history, because the institutional history is mostly the story of a project that did not ship in any of its many phases. Nelson worked on the system, with various small teams, through the 1960s and 1970s, supported by a series of academic and consulting positions. The major institutional moment came in 1988, when John Walker, the founder of Autodesk, acquired the Xanadu Operating Company as a subsidiary of Autodesk and put serious money behind it. Walker had read Computer Lib/Dream Machines, Nelson’s self-published 1974 manifesto, and believed that Autodesk’s success could subsidize the completion of the system. The Autodesk Xanadu team grew to several dozen engineers and built, over four years, a series of implementations of pieces of the system: a server, addressing schemes, a transclusion engine, several front-end demos.
What the team did not produce was a coherent product. The scope kept expanding. The implementation kept being rewritten as parts of the design were rethought. Autodesk’s commercial position deteriorated and Walker stepped down from the CEO role in 1992. The new management did not share Walker’s enthusiasm for the project and spun the Xanadu Operating Company off, with little money and no clear path forward. The 1995 Wired piece by Gary Wolf was written into this period — the Autodesk relationship had ended, the spinoff was failing, and Wolf’s framing of the project as a thirty-five-year failure to ship became the public framing.
This framing is not exactly false. Xanadu, the full system Nelson had been describing since the 1960s, did not ship in 1995 and has not shipped since. What is missing from the framing is that pieces of the system have shipped. ZigZag, a multi-dimensional data structure that Nelson worked on through the 1990s, was released in 1999 and is documented and downloadable. OpenXanadu, a 2014 web-based demonstration, shows transclusion working in a browser. Various academic and amateur reimplementations exist. The system as a whole has not been built; specific subsystems have been built more than once.
It is also worth pointing out that the framing applies a standard — “did it ship a commercial product” — that comes from a different industry than the one Nelson was operating in. The systems in this book that did ship as commercial products mostly did so by drastically reducing scope and accepting compromises Nelson was unwilling to make. Whether that constitutes the right way to evaluate Xanadu depends on what you think the project’s goal was. If the goal was to ship a product, the project failed. If the goal was to articulate a coherent proposal for what hypermedia should be, the project succeeded, and the proposal has shaped sixty years of subsequent work even where the subsequent work did not credit it.
What the web specifically rejected
The web took some of Nelson’s vocabulary — “hypertext” is now web vocabulary, and “hyperlink” derives from “hypertext link” — and rejected almost all of his substantive proposals. The rejections are worth enumerating because each is a specific decision with consequences.
The web rejected two-way linking. Nelson had insisted that a link should be visible from both ends: the document being linked to should know which documents linked to it. The web’s HTTP and HTML link only forward. Tim Berners-Lee’s 1989 CERN proposal explicitly considered two-way linking and explicitly rejected it on the grounds that it would not scale — to make two-way links work, the destination document would have to be updated whenever a new link to it was created, which is impossible if the destination is owned by someone other than the linker. Nelson’s answer to this objection was that the link should not live in either document but in a third place, a central registry, which the system would consult to find all the links pointing into a given location. The web rejected this answer because a central registry is a central point of failure and a central point of control, and the web wanted neither. The cost of the rejection is that web links rot, that the relationship between a citing document and a cited one is invisible from the cited side, and that the citation network that links the web together is reconstructable only at enormous cost (this is what search engines spend their compute on, in part).
The web rejected version permanence. A web document is mutable. The publisher of a document can change it, replace it, or delete it, and the URL points to whatever the publisher has there now. There is no version history at the protocol level. The Internet Archive has, since 1996, attempted to retroactively provide version permanence by periodically saving copies of web pages, with mixed results. Nelson’s design had version permanence built in: a version, once published, was preserved, and citations always pointed to specific versions, not to mutable references. The cost of the web’s rejection of this property is the universal phenomenon of link rot, the inability to cite a web page with confidence that the reader will see what you saw, and the structural unreliability of the web as a substrate for serious citation.
The web rejected transclusion. HTML has IMG and IFRAME and various media inclusion elements, but they include resources from foreign servers as opaque blobs, not as part of a unified text-and-citation graph. There is no native way in HTML to quote a passage of another document by reference such that the original source is preserved and shown. You quote by copying. The cost is that citations on the web carry no live connection to their sources; that paraphrase and direct quotation are visually indistinguishable; and that the structural awareness of which documents quote which other documents is unavailable to the system. Recent extensions (text fragments, web annotations as a W3C standard since 2017) recover pieces of this, but in ad-hoc ways layered on top of an architecture that was specifically designed without it.
The web rejected the rights model. HTTP carries no notion of payment or authorship. The web’s economic model — when there is one — is advertising or subscription, both bolted on through external systems. Nelson’s proposal that the system itself should handle small-amount payments to authors as documents are read has never been implemented at scale. Various micropayment systems have tried (Flattr, Brave’s BAT, cryptocurrency tipping experiments); none has reached the scale where it changes the structure of online publishing. The cost is that the relationship between authorship and revenue has been mediated, online, by advertising platforms whose interests are not aligned with either authors or readers, and that the rights claim Nelson built into the system has had to be reconstructed, badly, by external institutions.
The web rejected the precise addressing of tumblers. URLs are document-level; fragment identifiers are advisory. The cost is that web citations cannot, generally, point to a specific passage; that the granularity of linking matches the granularity of pages rather than the granularity of arguments; and that the kind of fine-grained quotation Nelson treated as the default unit of intellectual work is harder on the web than on paper.
In each of these rejections, the web chose simplicity, scalability, and uncoordinated growth over a richer feature set that would have required coordination. The choices were defensible. They were also, in each case, choices, and they were made by people who knew the alternatives Nelson had proposed.
What is being recovered
Several pieces of Xanadu’s proposal have re-emerged in working systems, usually without the explicit acknowledgment.
Transclusion has returned, in narrow form, in several recent tools. Notion’s “synced blocks” provide an in-product transclusion: a block in one document can be a live reference to a block in another, and editing one updates the other. Roam Research, since 2019, has built its primary user experience around block references: every block in every page has an address, and a reference to a block displays the block’s current content in the citing context. Logseq and several other personal knowledge tools have followed Roam’s lead. These systems are smaller in scope than Xanadu — they are personal, not global — but the operational pattern matches what Nelson described. The chapter on personal knowledge tools (chapter 24) treats these recoveries.
Version permanence has returned in two distinct lineages. The first is content-addressable storage, descended from Git (2005) and now ubiquitous in software development. Git is not designed for hypertext, but its content model — every version of every file is identified by a hash, and the hash is the address — implements the underlying property Nelson had insisted on. The second lineage is the broader effort to use distributed content-addressable systems for general-purpose storage: IPFS, the InterPlanetary File System launched in 2014, makes content-addressing the primary addressing scheme. The web does not yet use these, except for narrow applications, but they exist and are reachable. The Internet Archive’s Wayback Machine, founded by Brewster Kahle in 1996, provides versioned snapshots of arbitrary web pages and has become an essential part of the web’s citation infrastructure, retrofitting version permanence onto the system the web did not build it into.
Two-way linking has been recovered, partially, by webmentions and backlinks. The webmention specification, a W3C recommendation since 2017, lets a citing page notify the cited page of the citation, and lets the cited page display a list of incoming references. This is much smaller than what Nelson proposed; webmentions are advisory and require both ends to implement them. But the property — that a page knows what links to it — is partially available, and has spread within the IndieWeb community. Wiki systems, going back to Ward Cunningham’s original WikiWikiWeb in 1995, have had backlinks since the beginning; the property is native to wikis. Roam’s backlinks, for personal knowledge graphs, do for individual notes what webmentions do for public pages.
The rights model has not been recovered at scale. Various attempts continue. None has yet produced a working system at the scale Nelson proposed.
The unified address space of tumblers has not been recovered. URLs plus fragments are what we have. There are research proposals to do better — robust anchor systems, hash-based content addressing combined with stable selectors — but no widely deployed system.
The verdict that should not be the verdict
Xanadu is treated, in the popular accounts, as a kind of monument to overreach. The verdict — that Nelson’s system was too ambitious to ship and that the web’s pragmatism won — is the verdict the industry has accepted. The verdict is half-right: the system was ambitious and did not ship, and the web’s pragmatism did win, and we are living in the world the pragmatism built. But the half that the verdict misses is that the things Xanadu was trying to do are the things that hypermedia is supposed to do. Two-way linking, version permanence, transclusion, precise addressing, an integrated rights model — these are not crank ideas. They are the rest of the feature set, the part of hypermedia we lost when we settled for the web’s reduced version. The recoveries chronicled in Part V are, in significant part, ad-hoc rediscoveries of features Nelson had specified by 1981 and demonstrated, in pieces, by 1990.
Nelson is now in his late eighties. He is still working on Xanadu. The system in its full form has not shipped and will not ship in his lifetime, and probably not at all. What survives is a vocabulary, a proposal, and a list of properties that any serious hypermedia system either has or has consciously chosen not to have. The web has consciously chosen not to have them. The chapter on the web’s technical decisions makes the case for why this was, in 1991, the right choice. The chapters in Part V make the case for why, in 2026, it is increasingly the wrong one, and why the alternatives Nelson sketched are being quietly reassembled in pieces.
The next chapter turns from the most ambitious of the hypermedia proposals to the most successful. HyperCard did almost nothing of what Nelson had specified. It did not have two-way links, it did not have transclusion, it did not have version permanence, it had no rights model, and its addressing scheme was a single linear stack. It shipped on five million Macintoshes, was used by millions of people for a decade, and produced a culture of end-user authorship that has not existed on any platform since. It is the case for shipping.