The Xanadu Network & the Docuverse

How independent Xudanu servers form a connected literature — the tumbler address space, content sharing, transclusion across boundaries, server operator responsibilities, and inherent risks.

1. The Vision: A Connected Literature

Ted Nelson's original Xanadu vision, conceived in 1960, was of a docuverse — a universe of documents where every quotation maintains its bond to the original, every reference is permanent, and every reuse carries its full provenance. This is not the web, where links break and copies diverge. In the docuverse, connections are unbreakable and attribution is cryptographic.

Xudanu implements this vision as a network of independent servers, each owning its own content, each signing its own provenance, connected by tumbler addresses — a global hierarchical addressing scheme that lets any server reference any other server's content without replicating it.

The docuverse: independent servers connected by tumbler references. Each server stores only its own content plus small cached excerpts of what it references.

2. Do All Nodes Run the Same Code?

Yes. Every Xudanu server runs the same Rust binary (xudanu-server). There is no "master" or "worker" role. There is no "coordinator" or "follower." Every server is an equal peer.

However, each server operator configures their instance independently:

3. The Tumbler Address Space

Every piece of content in the docuverse has a globally unique address called a tumbler. The tumbler is hierarchical:

server . work . edition . position . element
   2   .   5  .    3    .    10    .    7

The tumbler namespace. Each level is owned by the level above. Server 2 owns all 2.* addresses. Work 5 owns all 2.5.* addresses.

4. How Content Is Shared

Content is never replicated across servers. Instead, servers reference each other's content. There are three mechanisms:

4.1 Transclusion (read-only reference)

When Alice on Server 1 wants to quote a passage from Bob's work on Server 2:

1. Alice's client fetches the passage from Server 2's public API
2. Client computes the BLAKE3 hash of the passage
3. Client stores a reference manifest on Server 1:
   • Tumbler address (2.5.3.10.7)
   • BLAKE3 content hash
   • The excerpt text (permanent cache)
   • Author and server identity
4. Server 1 signs the reference with its own key

Server 1 stores a few hundred bytes of metadata + the excerpt text. It does not store Bob's entire library.

4.2 Content caching (BLAKE3-addressed)

When Alice's document is opened and the transclusion needs to render, the resolution order is:

1. Check blob store cache — keyed by BLAKE3 hash. If cached, render immediately.
2. Fetch from origin server — hit the public API on Server 2, verify BLAKE3 hash, cache in blob store, render.
3. Fall back to excerpt — if Server 2 is offline, render the stored excerpt text with an "offline" indicator.

Three-tier resolution: cache → fetch → excerpt fallback. Content is always available at some level.

4.3 Binary content (images, datasets, videos)

Binary content uses the same tumbler + hash reference model, but with caching policies:

5. The Three Layers of Reference

When Alice on Server 1 quotes Bob's content on Server 2, three independent layers of verification apply:

Three independent layers of verification. Removing or changing any one layer is detectable.

These three layers compose to provide end-to-end provenance:

• Where — tumbler address resolves to a specific server
• What — BLAKE3 hash verifies the content hasn't changed
• Who — Ed25519 signature proves which server vouches for it

6. Server Operator Responsibilities

Running a Xudanu server is like running a website — you are responsible for your own content, your own users, and your own uptime. But unlike a website, your content can be referenced by other servers even when you're offline.

Minimum viable server

# Start a personal server for $5/month
xudanu-server run 0.0.0.0:8080 /data --server-name "My Server"

# That's it. Other servers can now reference your public content.
# You can also reference theirs by adding them to your directory.

7. What Each Server Stores

A server's storage is proportional to its own users' activity, not to the total size of the network:

Storage is proportional to your own activity, not the network size. The cluster model (bottom) replicates everything everywhere.

8. Cryptographic Guarantees

Every reference in the docuverse carries three cryptographic properties:

Content integrity (BLAKE3)

Every piece of content is fingerprinted with BLAKE3. If anyone modifies a single byte, the hash changes completely. This means:

• Cached content can be verified against its hash
• Fetched content is rejected if the hash doesn't match
• The same content always produces the same hash (deterministic)

Author attribution (Ed25519)

Every span of text is signed with the author's Ed25519 key. The signature covers the content hash + timestamp + server identity. This means:

• Anyone can verify who wrote what without trusting the server
• Signatures are 64 bytes — compact and fast to verify
• The signing key is encrypted at rest (AES-256-GCM + Argon2id)

Tamper-evident audit trail (SHA-256 chain)

Every attribution event is appended to a chained log where each entry's hash incorporates the previous entry's hash. This means:

• Modifying any past entry invalidates all subsequent entries
• Deleting entries is detectable (chain breaks)
• The log can be verified offline with xudanu-cli verify-report

9. Risks and Mitigations

What can go wrong

10. Comparison: Linked Servers vs Cluster vs The Web

11. Scaling to Hundreds of Servers

Each server only knows about servers it has referenced or been referred by. No server needs a global view.

Why this scales

• No central bottleneck — there is no registry, coordinator, or consensus node
• No all-to-all communication — a server with 10 references only contacts those 10 origin servers
• Storage is local — your $5 VPS doesn't store the network's 500 GB of content
• Trust is local — each operator curates their own trusted server list
• Discovery is organic — you find new servers by following reference chains, like the web

12. The Docuverse in Practice

A day in the life of a reference

1. Alice writes on Server 1: "As Bob argues in his analysis of Moby Dick..."
2. She selects Bob's passage on Server 2 and creates a transclusion
3. Server 1 stores: tumbler 2.5.3.10.7, BLAKE3 hash, excerpt text, Bob's public key, Server 2's signature
4. The reference is now permanent. Even if Server 2 changes the content, Alice's reference points to the original
5. Carol on Server 3 reads Alice's document. The transclusion renders from cache or fetches from Server 2.
6. Server 2 goes offline. Carol sees the excerpt with an "offline" indicator. The text is still readable.
7. Server 2 comes back. Next time Carol opens the document, the transclusion re-fetches and verifies.
8. Years later, someone verifies the reference with xudanu-cli verify-report. The Ed25519 signature still checks out. The BLAKE3 hash still matches the excerpt. The tumbler address still resolves (or the cached excerpt is permanent proof).