Xanadu tried to make links work in both directions
Most web links are one-way: a page points to another page, but the destination usually has no built-in record of who linked to it. Project Xanadu proposed a different arrangement. A link would be recorded at both ends, so a document could identify not only what it refers to but also what refers to it. The idea was to make connections more durable and traceable, even as documents changed.
Xanadu also proposed transclusion: displaying a piece of another document inside your own while keeping track of where that passage came from. Instead of copying text and losing its provenance—the record of its origin—a reader could follow the embedded passage back to its source. Built-in micropayments were meant to let creators be paid when their material was reused.
Why the promise took so long to build
These features depended on more than adding a link button. The system had to keep track of documents, passages, connections, and reuse as material was revised and moved. That made Xanadu an ambitious attempt to design a whole publishing infrastructure, not simply a new way to browse pages. Its plans and implementations evolved over decades, while the simpler web model spread widely: ordinary links were easy to create, but they did not provide Xanadu’s built-in two-way connections or payment machinery.
The result was a long gap between the project’s vision and a working prototype. The delay reflects the difficulty of turning an expansive document system into functioning software—not proof that every feature was impossible. Xanadu’s central tradeoff remains easy to see: the web made linking lightweight and widespread; Xanadu sought richer links that could preserve context and attach value to reused text.
