The Xanadu Network

A docuverse of independent servers, connected by permanent, cryptographically verified, attribution-preserving references — the vision Ted Nelson had in 1960, working today.

The Vision What We Proved Tumbler Addressing Setting Up a Server Connecting Two Servers Security Model Operating a Server Safely Gold Heritage History: From 1960 to Today

The Vision

In 1960, Ted Nelson envisioned a universe of documents — a docuverse — where content could be connected, reused, and traced across independent servers. Not a web of pages, but a network of connections at the character level. Every quotation would maintain its bond to the original. Every reuse would carry its full provenance.

The World Wide Web (1989) gave us one-way links between pages. Nelson's Xanadu was different: bidirectional, typed, permanent connections between passages — with content staying on its origin server, never copied, always verified.

Xudanu implements this vision.

ALICE'S SERVER alice.xudanu.com "Hello from alice" Published + BLAKE3 hash ← Backlink: "Referenced by Bob" BOB'S SERVER bob.xudanu.com [cross-server link] Click → fetch → verify → display Cached in blob store TUMBLER BACKLINK THREE-LAYER VERIFICATION Tumbler (WHERE) BLAKE3 (WHAT) Ed25519 TOFU (WHO) "alice.com".03ed b6e5e023... pinned key No central registry. No federation. No shared database.

Two independent Xudanu servers connected by a tumbler reference. Content stays on its origin server; references travel between them.

What We Proved

On July 10, 2026, we verified the full cross-server pipeline end-to-end with two independent Xudanu servers running on separate ports with separate data directories:

Verified Flow

  1. Alice's Server (Node 1) publishes a work: "Hello from alice"
  2. Bob's Server (Node 2) creates a cross-server link using a tumbler: "127.0.0.1:8081".03ed.1.0.0
  3. Bob's Server automatically notifies Alice's Server of the incoming reference
  4. Alice's Server displays: "← Referenced by Bob's Server" in the Connections panel
  5. Clicking the link marker on Bob's Server fetches "Hello from alice" from Alice's Server
  6. BLAKE3 hash verified — content cached locally with a green checkmark

No central registry was consulted. No shared database was synchronized. No federation protocol was used. Two sovereign servers discovered each other, exchanged a permanent reference, and shared verified content — exactly as Ted Nelson designed.

Tumbler Addressing

Every piece of content in the Xudanu network has a permanent, globally unique address called a tumbler. This is Nelson's innovation from the 1970s — a hierarchical, dotted notation that identifies content across servers.

"alice.xudanu.com".03ed.1.0.0 Server DNS-routable Work Hex ID Edition Revision Position Char offset Element Sub-element

A domain-based tumbler. The domain replaces Gold's numeric server IDs, enabling DNS self-routing.

The domain format ("alice.xudanu.com".03ed.1.0.0) is Xudanu's enhancement over Gold's original numeric format (1.03ed.1.0.0). DNS provides self-routing — no central registry needed.

Setting Up a Server

Any Xudanu server can join the network by publishing its identity and content.

1 Start the server
./xudanu-server run 0.0.0.0:8080 data \
  --server-name "Alice's Literature Server" \
  --server-description "Essays and annotations" \
  --public-address alice.xudanu.com
2 Publish content

Create a document, write text, and click Published. Published works become available via the public content API at /api/public/work/{id}.

3 Verify discovery
curl https://alice.xudanu.com/.well-known/xudanu-server.json

Returns the server's identity, verifying key, name, description, and stats.

4 Verify content API
curl https://alice.xudanu.com/api/public/work/03ed

Returns the work text, BLAKE3 content hash, span provenance, and server identity.

Connecting Two Servers

Once two servers are running and have published content, users can create cross-server links:

1 On Server B, select text and click Link

Choose "Link to a remote server" in the Link Creator wizard.

2 Enter the tumbler and hash

Enter the tumbler from Server A (e.g., "alice.xudanu.com".03ed.1.0.0) and the BLAKE3 content hash from the public API.

3 Create the link

The link is stored on Server B with the CrossServerRef payload (tumbler + hash + author info). Server B automatically notifies Server A of the incoming reference.

4 Click to resolve

Clicking the link marker on Server B triggers cross-server resolution: fetch from Server A → verify BLAKE3 hash → cache locally → display content.

Automatic backlinks: When Server B links to Server A, Server A automatically sees the incoming reference in its Connections panel. This bidirectional visibility is the Xanalogical principle — every connection visible from both ends.

Security Model

Cross-server content sharing uses three independent layers of verification:

LayerWhat it answersHowEven over HTTP?
TumblerWHERE does content live?Domain-based global addressYes
BLAKE3WHAT is the content?256-bit hash verified on every fetchYes — mathematically impossible to forge
Ed25519 TOFUWHO is the server?Key pinned on first connection (like SSH)Yes (after first pin)
Tumbler WHERE BLAKE3 WHAT Ed25519 WHO

Why HTTP is safe for content fetches

A man-in-the-middle cannot substitute different content because they would need to produce content with the exact same BLAKE3 hash — which would take 1022 years (longer than the age of the universe). The hash is stored at link creation time and verified on every fetch.

HTTPS is still preferred for privacy (hiding what you're fetching) and availability (preventing request blocking). Xudanu tries HTTPS first, and if successful, pins it — refusing HTTP downgrade for that server in the future.

Additional protections

ProtectionStatus
SSRF protection (reject loopback/private IPs, IPv6-aware)Done
5MB byte cap on fetchesDone
Trust gate (untrusted servers rejected)Done
Ed25519 TOFU (pin on first use, warn on change)Done
HTTPS pinning (refuse downgrade)Done
Byte tracking (RoyaltyEntry per fetch)Done
Structure validation on peer content (invariant gate)Done (v1.6.0)
Signed identity responses (verified against directory keys)Done (v1.6.0)
Rate limiting on public endpointsPlanned (#105)

Adversarial resilience (v1.6.0)

Every document arriving from a peer passes a structure validation gate before it can touch server state: positions, spans, transclusion ranges, and provenance are checked against strict invariants, with size caps against resource exhaustion. Malformed entries are rejected individually and logged — the sync continues, the attacker's data does not. Identity responses are Ed25519-signed by the serving server and verified against the key registered in your directory, with a freshness window against replay. See Adversarial Resilience for the full method and findings.

Governance

Federation membership decisions (admit, expel, key rotation) are made by a PBFT consensus among 3–10 member servers: total ordering, Byzantine fault tolerance (f faulty members tolerated in 3f+1), no forks. A single compromised server cannot corrupt governance or rotate another server's keys — the quorum is required.

Operating a Server Safely

Server operators control the trust posture with run flags. The defaults are safe; the flags let you relax them deliberately.

Flag / envDefaultWhat it does
--edit-policy owner-only
XUDANU_EDIT_POLICY
owner-onlyOnly signed-in identities can create or edit works. public-sandbox enables wiki-style anonymous editing (demo servers).
--admin-passphrase
XUDANU_ADMIN_PASSPHRASE
noneSets the admin club's password (break-glass: archive orphans, manage grants). Without it the admin club has no credential by design.
--allowed-origin(must set)WebSocket/API origin allowlist — set exactly your site origins.
--tls-cert / --tls-keyoffNative TLS; or terminate at a reverse proxy (Caddy/nginx).
Confidentiality note. The network is an open sharing platform: published works are meant to be found and quoted, so peer traffic needs integrity and authenticity (which signatures provide) rather than secrecy. TLS remains recommended for reader privacy, and private works stay within their read clubs.

Gold Heritage

This implementation inherits directly from the Udanax-Gold hypertext model (open-sourced 1999), with modern adaptations:

Gold conceptXudanu implementationEnhancement
Numeric tumblersDomain-based tumblersDNS replaces central registry
Enfilade content storageO-tree CRDT + chunk storeCollaborative editing
Push-based syncPull-based resolutionServer stays sovereign
Custom binary protocolHTTPS + JSONStandard web protocols
Royalties (Rule 9)RoyaltyEntry ledgerByte tracking, no payments yet
Bidirectional linksCross-server backlinksAutomatic notification
"This is what Xanadu was always meant to be." A docuverse of independent servers connected by permanent, cryptographically verified, attribution-preserving references. Not a web of pages, but a network of connections — every quotation maintaining its bond to the original, every reuse carrying its full provenance.

History: From 1960 to Today

The Xanadu project spans over six decades — one of the longest-running visions in computing history. Understanding this history helps explain why the cross-server network works the way it does, and why certain design decisions (tumblers, bidirectional links, content addressing) were worth the wait.

1960 Ted Nelson envisions the docuverse at Harvard. "A connected literature where every quotation maintains its bond to the original." 1965 "Zippered lists" paper at ACM — the origin of transclusion. Documents assembled from pieces of other documents, not copies. 1972 xu72 — Model T enfilade (Nelson, Ridgway, Cal Daniels). 1978 "Swarthmore summer" — General Enfilade Theory. Mark Miller, Roger Gregory, K. Eric Drexler. The Ent data structure. Tumblers. 1983 Autodesk backs the project (John Walker). 1988 Udanax Green (xu88) — C implementation. First working demo. Transpointing windows demo by John Walker. Ka-Ping Yee's PYXI. 1992 Udanax Gold (xu92) — Smalltalk rewrite by Mark Miller. The Ent, PlaceHolder/FillDetector/Agenda, tumblers, royalties. Never shipped. 1995 Wired: "The Curse of Xanadu." The WWW dominates. 1999 Open-sourced at O'Reilly Open Source Convention. Enfilades and the Ent disclosed as prior art.

The Xanadu timeline: 39 years from vision to open source (1960–1999).

The Key Innovations (and who built them)

ConceptOriginYearWhat it does
TransclusionNelson1965Content referenced, not copied — live links to the original
EnfiladeMiller, Gregory1978Data structure for efficient versioned content access
The EntDrexler1978Tree structure managing complex versioning with low overhead
TumblersGregory, Miller1978Globally unique, hierarchical addresses for every passage
Bidirectional linksNelson1965Both ends of a connection are always visible
PlaceHolder / FillDetectorMiller1992Lazy template slots that auto-fill when content appears
Royalties (Rule 9)Nelson1960sMicropayments to original authors when content is transcluded

What Happened to Xanadu?

The Xanadu project faced many challenges over the decades:

But the ideas were sound. Ted Nelson's 1965 paper introduced concepts that the web still hasn't fully adopted 60 years later: bidirectional links, transclusion, and content addressing. The open-sourcing in 1999 allowed these ideas to survive and influence new implementations.

How Xudanu Carries the Torch

Xudanu is not a port of Udanax-Gold. It is a reimagining of Nelson's vision using modern technology, informed by the Gold codebase and its innovations:

UDANAX-GOLD (1992) Smalltalk/C++ · Never shipped ● Enfilade / Ent data structure ● Side-table compound storage ● Numeric tumblers (1.5.3.10.7) ● Push-based content sync ● Custom binary protocol ● Single-user terminal UI ● PlaceHolder / FillDetector ● Royalty micropayments Trade secret until 1999 Never tested at scale Side-table could drift inherits + modernizes XUDANU (2026) Rust + React · Working · Open source ● O-tree CRDT (replaces Ent) ● Inline transclusion (no side-table) ● Domain tumblers ("alice.com".5...) ● Pull-based resolution (server sovereign) ● HTTPS + JSON (standard protocols) ● Collaborative real-time web UI ● BLAKE3 content addressing ● Ed25519 signed attribution ● Cross-server backlinks (verified!) Verified end-to-end July 2026 Two servers sharing content

Udanax-Gold vs. Xudanu: same vision, modern implementation.

The People

The Xanadu project involved many brilliant minds over the decades:

Standing on their shoulders. Xudanu would not exist without the decades of work by Nelson, Miller, Gregory, Drexler, and the entire Xanadu team. Their ideas — tumblers, transclusion, bidirectional links, content addressing — were decades ahead of their time. We are finally building the infrastructure to make their vision real.