Xudanu Technical Architecture

A deep dive into the data structures, algorithms, and performance characteristics of the Udanax-Gold hypertext engine, reimplemented in Rust.

1. Introduction

Xudanu is a Rust implementation of the Udanax-Gold hypertext document store — a system originally designed by Ted Nelson's team in the 1980s and mechanically translated from Smalltalk to C++ in 1989. The original ~200,000-line C++ codebase was a faithful but disconnected port: every component existed, but the paths between them were dead code. Transclusion queries never executed. H-tree canopy flags were allocated but never checked. The BackfollowEngine had no callers.

Xudanu reconnects these components into a working system and optimizes the critical paths. The result is a server that stores documents as content-addressed trees, tracks which documents share which text (transclusion), and answers queries like “find every document that contains this paragraph” in O(log n) instead of O(n).

Who This Document Is For

This document is written for the engineering team. Whether you're a junior developer onboarding to the codebase or a senior architect evaluating the system's design, you'll find:

• Concrete examples with real data — not abstract descriptions
• Worked walkthroughs of every major data structure and algorithm
• SVG diagrams showing how components connect
• Big-O analysis with the naive baseline for comparison
• Source file references so you can jump straight to the code

The Core Idea

Everything in Xudanu comes back to one principle: content identity. When two documents contain the same text, that text gets the same BLAKE3 fingerprint. This fingerprint becomes a universal key that enables:

If you understand BLAKE3 fingerprints, you understand 80% of Xudanu's performance story.

Source Code Map

All source is in the xudanu crate. The most important files:

2. Three-Layer Architecture

Xudanu organizes its data structures into three layers, each building on the one below. The layers are connected by a single mechanism: BLAKE3 content fingerprints. Every piece of content gets a 256-bit hash, and that hash flows downward through the stack to enable indexing, deduplication, and query pruning.

How Data Flows

A document lives in the O-tree layer as an Edition wrapping a Loaf tree. Each text element gets a BLAKE3 fingerprint. Those fingerprints flow into two places:

1. GrandMap — fingerprints become BeIds. Same text always maps to the same ID. This is the deduplication layer.
2. TransclusionIndex — fingerprints become keys in a HashMap mapping to the set of works (documents) that contain them. This is the query acceleration layer.

The H-tree tracks version ancestry. Each node (HUpperCrumData) carries a CanopyCrumData with flag bits summarizing what types of content exist in its subtree. The BackfollowEngine orchestrates the query flow: hash the query text, look up the TransclusionIndex, walk the H-tree with canopy pruning, and collect results via TrailBlazer.

The Persistence and Federation Axes

Two cross-cutting concerns span all three layers:

• Persistence (right side of diagram) — a small manifest.json holds metadata and references, while document content is stored as BLAKE3-content-addressed chunks in a dedicated chunk store. Atomic writes, versioned migration, and crash safety are built in. See the Storage System documentation for the full design.
• Federation (left side of diagram) — CRDTs (OrSet, LwwRegister) handle multi-server content replication with eventual consistency. PBFT governance coordinates trust decisions.

Both are covered in detail in Section 11 and Section 12.

3. O-Tree: Documents as Trees

Every document in Xudanu is an O-tree — an ordered tree of RangeElements. The tree is represented by the Loaf enum, which has three variants:

pub enum Loaf {
    Leaf {
        region: XnRegion,
        entries: Vec<(i64, Arc<Carrier>)>,
        default: Option<Arc<Carrier>>,
    },
    Split {
        split: XnRegion,
        in_child: Box<Loaf>,
        out_child: Box<Loaf>,
    },
    Dsp {
        offset: i64,
        child: Box<Loaf>,
    },
}

How Splitting Works

When a Leaf grows beyond MAX_LEAF_SIZE (16,384 entries), it splits in half. The median position becomes the split point. Everything below goes into in_child, everything above into out_child. This keeps the tree balanced — depth grows as O(log n).

The Dsp Node: O(1) Position Transforms

The Dsp variant is the most interesting optimization. Instead of rewriting every position when content is inserted or deleted, the O-tree wraps the affected subtree in a Dsp node that just adds an offset:

Split {
  split: below(50),
  in_child: Leaf [0:"Hello", 1:"World"],      // unchanged
  out_child: Dsp {
    offset: +3,                                 // shift everything by 3
    child: Leaf [50:"Old", 51:"Text"]           // original positions preserved!
  }
}
  

Worked Example: Building an O-Tree

Let's trace what happens when a user creates a document with the text "The quick brown fox" and saves it:

1. Client sends work_save_and_release with 4 text elements
2. Server creates a new Edition with a Loaf::Leaf containing:

entries: [
  (0, Carrier { element: Text("The "),   fp: 0x7a2f... }),
  (1, Carrier { element: Text("quick "), fp: 0xb4c1... }),
  (2, Carrier { element: Text("brown "), fp: 0xe8d3... }),
  (3, Carrier { element: Text("fox"),    fp: 0x1f9a... }),
]
region: XnRegion [0, 4)
  

4 entries is well under MAX_LEAF_SIZE (16,384), so it stays as a single Leaf. When the user adds more text and the leaf grows past the threshold, it will split. The tree grows deeper only as needed.

RangeElement: The 9 Element Types

An O-tree isn't limited to text. The RangeElement enum supports 9 types, and any Edition can mix them freely:

Structural Sharing Between Editions

When you edit a document, the O-tree doesn't copy the entire tree. It creates a new version that shares unchanged subtrees with the old one. This is the same technique used by immutable data structures in Clojure and Haskell.

In this example, editing "quick fox" to "slow dog" allocates exactly one new Arc<Carrier>. The other two elements are shared between revisions via Arc reference counting. For a document with 1,000 elements where you change 3, you allocate 3 new elements and share 997. This is why O-tree edits are memory-efficient.

4. GrandMap: Content-Addressed Deduplication

The GrandMap is the server's global content store. Every element from every document passes through it. Its job is simple but powerful: ensure that identical content always maps to the same backend ID.

How It Works

When a document is saved, each RangeElement is passed to ContentAddressIndex::intern(). This function:

1. Computes the BLAKE3 fingerprint (256-bit hash) of the element's content
2. Checks if that fingerprint already exists in fingerprint_to_be_id
3. If yes → returns the existing BeId (deduplication hit)
4. If no → allocates a new sequential BeId, stores the mapping

pub struct ContentAddressIndex {
    fingerprint_to_be_id: HashMap<[u8; 32], BeId>,
    be_id_to_fingerprint: HashMap<BeId, [u8; 32]>,
    next_be_id: BeId,
}

Worked Example: Two Documents with Shared Content

intern(Text("The "))       → BLAKE3 → 0x7a2f → new BeId(1001)
intern(Text("quick brown")) → BLAKE3 → 0xa3f7 → new BeId(1002)
intern(Text(" fox jumped")) → BLAKE3 → 0x1b4e → new BeId(1003)
  

intern(Text("I saw a"))    → BLAKE3 → 0x5c92 → new BeId(1004)
intern(Text("quick brown")) → BLAKE3 → 0xa3f7 → existing BeId(1002)  ← dedup hit!
intern(Text(" yesterday"))  → BLAKE3 → 0xd861 → new BeId(1005)
  

The GrandMap Structure

Beyond the ContentAddressIndex, the GrandMap also manages:

Why This Matters for Performance

The GrandMap's deduplication is the foundation for everything else:

• TransclusionIndex uses the same BeIds as keys — so deduplicated content automatically appears in the right query results
• Shared region detection compares fingerprints, not strings — O(1) per element instead of O(n) substring matching
• Canopy flags are tied to endorsement types, which are tied to content types, which are tracked per-BeId
• Storage grows with unique content, not total content. Documents that share lots of text use proportionally less disk

5. Canopy: Flag-Bit Pruning

The Canopy is the mechanism that makes H-tree traversal O(log n) instead of O(n). Without it, finding transclusion matches would require visiting every node in the version history. With it, entire subtrees are skipped in a single comparison.

The Problem

An H-tree node represents a version of a document. To answer “which editions contain this text?”, you need to walk the tree checking each node. With 10,000 editions, that's 10,000 checks. The canopy avoids this by annotating each node with a bitmap of what types of content exist in its subtree.

How Flag Bits Work

Each endorsement type (Text, Link, Blob, etc.) gets a bit position in a u32. The current allocation:

Endorsement flags are allocated dynamically via use_endorsement_flag() (up to 23 bits, from position 3 to 25). Each distinct endorsement type gets its own bit. The flags are then merged upward through the H-tree using bitwise OR.

Two Canopy Types

Xudanu implements two canopy variants that serve different purposes:

The Pruning Math

For a balanced H-tree with depth d:

• Without canopy: visit all 2^d nodes
• With canopy: visit only nodes whose flags include your query type. If the flag has a 50% chance of being set, you visit roughly 2^d/2 nodes — the square root
• In practice, with sparse endorsement types, the pruning is far more aggressive — often visiting only O(log n) nodes

6. H-Tree: Version Ancestry

While the O-tree stores what a document contains, the H-tree stores how versions relate. It's a directed acyclic graph (DAG) where each node — called a crum — represents a version snapshot, and edges point from child to parent (newer to older).

Structure of an H-Tree Node

pub struct HUpperCrumData {
    hcut: TracePosition,                       // where this node was split
    o_parents: Vec<Arc<Mutex<dyn HPart>>>,    // parent references (DAG edges)
    bert_crum: Arc<Mutex<CanopyCrumData>>,    // canopy flags for this subtree
    base: HistoryCrumBase,                      // unique hash for identity
    _bert_canopy: BertCanopy,                   // reference to owning canopy
}

Each crum knows its parents (multiple parents = merged branches). Each carries a CanopyCrumData that summarizes the endorsement types present in its entire subtree. This is the data the canopy pruning algorithm uses.

How the H-Tree Grows

When a new edition is created:

1. A new HUpperCrumData is allocated
2. Its parent(s) are set to the previous edition's crum(s)
3. A CanopyCrumData is created with this edition's endorsement flags
4. Flags are propagated upward through the propagate_flags() function — each ancestor's flags become the bitwise OR of all descendants

Rev 0 (initial)     → crum hash=0x001, flags=[T]
    ↓ parent
Rev 1 (typo fix)    → crum hash=0x002, flags=[T]
    ↓ parent
Rev 2 (add links)   → crum hash=0x003, flags=[T, L]
    ↓ parent
Rev 3 (add image)   → crum hash=0x004, flags=[T, L, I]

After propagation:
  Rev 3 canopy: [T, L, I]         (own + all ancestors)
  Rev 2 canopy: [T, L]            (own + Rev 0, Rev 1)
  Rev 1 canopy: [T]               (own + Rev 0)
  Rev 0 canopy: [T]               (own only)

Query: "find Link transclusions"
  → Rev 3 has L → ✓ descend
  → Rev 2 has L → ✓ descend
  → Rev 1 no L  → ✗ skip Rev 1 and Rev 0 (pruned 50%)
  

Branching and Merging

The H-tree is a DAG, not a simple chain. If two users edit the same document concurrently, the H-tree branches. When those branches are reconciled (via DagWood, Section 8), a merge node gets two parents.

     Rev 0
      ↓
     Rev 1
    ↙    ↘           ← concurrent edits
  Rev 2a  Rev 2b
    ↘    ↙           ← merge
     Rev 3            → o_parents: [Rev 2a, Rev 2b]

The canopy correctly handles merge nodes: the merge crum's flags are the bitwise OR of both branches, so no matching content is lost.

Delayed Backfollow

The H-tree supports a concept called delayed backfollow — the ability to lazily discover transclusion relationships by walking the version chain backward. Instead of maintaining a complete index of every version's content, the system can traverse parent links on demand, using canopy flags to skip irrelevant branches.

This is particularly useful for:

• Historical queries — "did version 5 contain this text?" without loading all versions
• Version diffing — walking between two crums to find what changed
• Age tracking — determining when each piece of content was first introduced

7. Transclusion Queries at O(log n)

This is where everything comes together. A transclusion query asks: "which documents contain this text?" The naive approach scans every document. Xudanu answers it in O(log n) by combining content fingerprints, inverted indexes, canopy pruning, and H-tree traversal.

The Full Query Pipeline

Step-by-Step Trace

BLAKE3("quick brown fox") → [0xa3, 0xf7, 0x1b, ..., 0xc1]  (32 bytes)

TransclusionIndex.get(0xa3f7...) → {work_42, work_107, work_891}

work_42 H-tree:
  Root flags [T,L,I] & TextFlag → match → descend
  Left child [T] & TextFlag → match → descend → found at Rev 3
  Right child [L,I] & TextFlag → no match → pruned

work_107 H-tree:
  Root flags [T] & TextFlag → match → descend → found at Rev 1

work_891 H-tree:
  Root flags [L,B] & TextFlag → no match → entire tree pruned

TrailBlazer.record(Text("quick brown fox"), work_42_rev3)  → true
TrailBlazer.record(Text("quick brown fox"), work_107_rev1)  → true

[
  TransclusionResult { element: Text("quick brown fox"), is_direct: true,  work: 42 },
  TransclusionResult { element: Text("quick brown fox"), is_direct: true,  work: 107 },
]

The TransclusionIndex

The TransclusionIndex is the core inverted index. It maps each BLAKE3 fingerprint to the set of work IDs that contain an element with that fingerprint:

pub struct TransclusionIndex {
    // fingerprint → set of work IDs containing this content
    index: HashMap<[u8; 32], HashSet<u64>>,
}

It's populated during BackfollowEngine::register_edition(): when a new edition is saved, each of its content-addressable elements is indexed. The index is also used by content_shared_region() to find overlapping content between two specific documents.

Range-Scoped Queries

The RangeTransclusionQuery in src/edition/range_transclusion.rs extends basic transclusion queries with position constraints:

• With region — only find transcluders within a specific position range of the source document
• Direct only — skip indirect transclusions (content transcluded through intermediate documents)
• Local present only — only include content that still exists in the current version (not deleted)

8. DagWood: Concurrent Edits

When two users edit the same document at the same time, both save successfully, and neither sees the other's changes until later. The DagWood is the data structure that handles this. It defines a partial ordering of edit positions and provides operations to create new positions, detect concurrency, and reconcile conflicts.

What Is a DagWood?

A DagWood is a tree of TracePositions. Each position represents a point in the edit timeline. The tree structure encodes ordering: positions on the same branch are ordered (sequential edits), while positions on different branches are concurrent.

pub struct DagWood {
    branches: BranchStore,                          // all branches
    root: TracePosition,                            // the root position
    trunk: HashMap<TracePosition, BranchId>,       // main line positions
    cached_position: Option<TracePosition>,        // last known position
    nav_cache: HashMap<BranchId, u32>,              // navigation cache
}

Concurrent Edit Scenario

How Positions Are Created

The DagWood provides two key operations:

// User A saves after pos 2
let pos_a = dagwood.new_position_after(pos_2);
// → pos_2a on same branch (first successor)

// User B also saves after pos 2 (concurrent!)
let pos_b = dagwood.new_position_after(pos_2);
// → pos_2b on a NEW branch (second successor)
// → pos_a and pos_b are now concurrent, not ordered
  

Partial Ordering and Navigation

The DagWood's nav_cache enables fast ordering comparisons. Given two positions, the system can determine:

• Ordered — position A happened before position B (same branch, A < B)
• Concurrent — neither happened before the other (different branches)
• Same — identical positions

This is used by the TraceView to present a coherent ordering to clients even when the underlying history is a DAG.

Reconciliation Strategy

When concurrent edits need to be reconciled, Xudanu's current strategy is last-writer-wins at the element level. Both edits are preserved in the history; the H-tree stores both branches. The "current" version shown to users is determined by the reconciliation logic:

1. Elements unique to one branch are kept
2. Elements present in both branches use the later timestamp
3. The merge creates a new H-tree node with both branches as parents

9. Big-O Performance Summary

This section consolidates the performance characteristics of every major operation. The "naive" column shows what the C++ Udanax-Gold code would have done if the disconnected components had been wired together with simple loops. The "Xudanu" column shows what the optimized Rust implementation achieves.

W = total works, L = text length, U = unique fingerprints, A = avg works per fingerprint, n/m = document lengths, r = shared regions, t = text

Key Takeaway

10. Labels, Paths, and Deep Linking

Xudanu doesn't just store flat text. It supports a rich addressing model that lets you name, link to, and navigate into specific positions within documents — even across documents via transclusion.

The Label System

A Label is a named anchor attached to a position in an O-tree. Labels are stored as RangeElement::Label entries, so they participate in the same structural sharing and versioning as text. When you create a new revision, labels from the previous version are automatically inherited.

Edition for "Getting Started Guide":
  pos 0: Text("# Getting Started")
  pos 1: Label("intro")            ← anchor named "intro"
  pos 2: Text("Welcome to Xudanu...")
  pos 3: Text("First, install the server.")
  pos 4: Label("install")          ← anchor named "install"
  pos 5: Text("Run `xudanu-server`...")
  

Paths and Tumblers

The Udanax-Gold addressing model uses tumblers — hierarchical numeric paths that identify a position within a document, within a work, within the global namespace. Xudanu implements this via:

• Id — a pair of (IdSpaceId, i64) identifying any entity
• IdSpace — a namespace that allocates sequential IDs
• IdentityMap — resolves labels to IDs and back

A full path to a label looks like:

work:42 / edition:7 / label:"intro"

This resolves through three lookups: work ID → current edition → label position. Each step is O(1) via HashMap.

Deep Linking

Because labels are stored as O-tree elements, they support the same operations as text:

• Versioned — a label created in Rev 3 is visible in Rev 4 (structural sharing), and can be tracked back to its origin
• Transcluded — if Document A transcludes a section from Document B, the labels come with it
• Compared — the Compare view shows label positions alongside shared regions

HyperLinks

Xudanu implements bidirectional hyperlinks via the HyperLink and HyperRef types:

• HyperLink — stores source position, destination path, and link type
• HyperRef — a reference from a link to a target edition/position
• Links are stored server-side and serialized in snapshots
• Every link is bidirectional — you can always find "what links here"

11. Persistence: Snapshots and Crash Safety

Xudanu uses a two-layer persistence architecture: a small manifest.json file holds metadata and chunk references, while document content is stored as BLAKE3-content-addressed chunks in a dedicated chunk store (ChunkStore). This keeps writes proportional to changes, not total data size. The persistence layer handles versioning, checksums, atomic writes, migration, and backup management.

For the full design rationale, chunk format, and performance analysis, see the Storage System documentation.

The Manifest and Chunk Store

On checkpoint, the server separates metadata from content:

• Manifest (manifest.json) — a small JSON file containing server metadata, counters, system clubs, and references (chunk hashes) pointing to where works, editions, and clubs are stored in the chunk store.
• Chunk store (chunks/ directory) — document content is serialized into individual chunks, each addressed by its BLAKE3 hash. Chunks are stored as .xchunk files in a sharded directory layout (chunks/<prefix>/<hash>.xchunk). Only changed chunks are written on each checkpoint.

data/
├── manifest.json          # small metadata + chunk references
├── manifest.json.v2.bak   # backup from version migration
├── key_history.json       # server keypair history
├── chunks/                # content-addressed chunk store
│   ├── a4/
│   │   └── a4f7c2e8....xchunk
│   ├── 3b/
│   │   └── 3b91d0fe....xchunk
│   └── ...
├── blobs/                 # large binary objects
└── attribution/           # attribution records
  

Write Process: Chunked Checkpoint

When the server checkpoints (triggered automatically after mutations), the following steps occur:

1. Serialize works to chunks — each work's content is serialized into content-addressed chunks via work_to_chunks(). Only changed chunks are written.
2. Serialize clubs to chunks — club data (including their work trees) is similarly chunked.
3. Serialize standalone editions — editions not attached to a work are chunked individually.
4. Build manifest — collect all chunk references into a Manifest struct with metadata, counters, links, blob references, and federation state.
5. Write manifest — the manifest JSON is written atomically (temp file + rename) to manifest.json.

1. work_to_chunks()      → write changed .xchunk files for each work
2. edition_to_chunks()   → write changed .xchunk files for standalone editions
3. Build Manifest {
     format_version: 3,
     works: [(be_id, WorkChunkRef { root_hash, ... }), ...],
     clubs: [ClubChunkRef { work_root: WorkChunkRef, ... }, ...],
     links: [...], blob_metas: [...], ...
   }
4. BLAKE3(manifest_data) → checksum
5. write("manifest.json.tmp") → atomic rename to manifest.json
  

Read Process: Restore and Migrate

On startup, the server restores from the manifest and chunk store with full validation:

1. Read manifest — load manifest.json with fallback to backups if corrupted (tries up to 3 backups)
2. Verify checksum — BLAKE3 of the manifest data must match the stored checksum
3. Validate version — check format_version matches expected version (currently 3). Apply migration chain if older.
4. Verify chunks — cross-reference manifest entries against the chunk store to detect missing or corrupt chunks
5. Restore works — for each work, load chunks via work_from_chunks() and reconstruct the in-memory work tree
6. Restore clubs, editions, links — similarly reconstruct from chunk references
7. Restore federation, blobs, keys — load remaining state from manifest fields

What Gets Persisted

Backup Management

When a manifest version migration occurs, the system automatically:

• Creates a backup with the version suffix: manifest.json.v2.bak
• Keeps at least 2 backup versions
• Prunes older backups automatically via cleanup_old_backups()

Error Handling

The persistence layer defines comprehensive error types for both the manifest and chunk store:

pub enum ManifestError {
    Io(std::io::Error),
    Json(serde_json::Error),
    ChecksumMismatch { expected: String, actual: String },
    InvalidVersion { found: u32, expected: u32 },
}

pub enum ChunkError {
    Io(String),
    HashMismatch { expected: String, actual: String },
    CorruptData(String),
}

The most critical errors:

• ChecksumMismatch — data corruption detected. The server refuses to start. Restore from backup.
• InsufficientDiskSpace — not enough room for the write. Checkpoint fails gracefully; the in-memory state is unaffected.
• Validation — missing or malformed fields. Warnings are logged but non-fatal; errors prevent restore.

Crash Safety Guarantees

12. Federation: CRDTs and PBFT

Xudanu supports multi-server content replication. A federated deployment lets documents and their transclusion relationships span multiple Xudanu servers, with eventual consistency guaranteed by CRDTs (Conflict-free Replicated Data Types) and coordinated trust decisions handled by PBFT (Practical Byzantine Fault Tolerance).

Federation Model

Each Xudanu server is identified by a server_id string. Servers know about their peers via a FederationConfig:

pub struct FederationConfig {
    pub enabled: bool,
    pub peers: Vec<PeerAddress>,        // host:port of known peers
    pub mode: FederationMode,             // Closed, Open, or Community
    pub min_endorsements: u32,            // trust threshold (default: 2)
}

pub enum FederationMode {
    Closed,      // only listed peers may connect
    Open,        // any server may join
    Community,   // peers vouch for new members (endorsement-based)
}

CRDT Building Blocks

Federation uses three CRDT primitives to handle different aspects of distributed state:

// Two servers add and remove concurrently
Server A: add("doc_42")   → events: {("doc_42", a1)}
Server B: remove("doc_42") → events: {("doc_42", b1)}

// Merge: "doc_42" is present because
// Server B's remove hasn't seen
// Server A's add (concurrent)
    

pub struct LwwRegister<T> {
    value: T,
    timestamp: u64,
    server_id: String,
}

// Server A sets value at t=100
// Server B sets value at t=105
// Merge → Server B's value wins (higher t)
    

Federation Merge Diagram

Content Origin Tracking

When content crosses server boundaries, it carries its origin:

pub struct FederatedId {
    pub server_id: String,    // which server created this
    pub local_id: u64,        // the BeId on that server
}

This allows the system to:

• Trace where content originated (attribution)
• Avoid infinite sync loops (only forward content that's new to the recipient)
• Calculate cross-server royalties in the micropayment model

Membership and Governance

The FederationState manages three aspects of distributed coordination:

PBFT for Trust Decisions

Not all federation operations can use CRDTs. Some decisions — like accepting a new peer into a closed federation — require explicit agreement from existing members. Xudanu uses a simplified PBFT protocol for these:

1. Propose — a server proposes a trust change (e.g., "add server gamma")
2. Vote — each member server votes yes/no
3. Decide — once min_endorsements votes are collected, the decision is committed
4. Propagate — the decision is replicated to all members via OrSet

13. Comparison with Other Systems

Xudanu's design draws on ideas from several systems. Here's how it compares:

Feature Comparison Table

What Xudanu Borrows

• From Git: content-addressed storage, immutable snapshots, DAG-based versioning. But Xudanu operates at the element level (a word, a paragraph) rather than the file level.
• From IPFS: content fingerprints as universal identifiers, deduplication by hash. But Xudanu adds transclusion (tracking which documents reference which content) and query acceleration (canopy pruning).
• From CRDTs: conflict-free merging for federation. But Xudanu's content-addressing means most conflicts are already resolved — identical content always maps to the same ID.

14. Future Directions

v0.1.2 (Near Term)

v0.2 (Medium Term)

Longer Term

• Micropayment integration — Lightning Network (LDK) behind a feature flag. The accounting engine (StorageCost, CostMethod) already exists.
• Rust SDK — wrap the WebSocket protocol for programmatic access. Embed the engine directly for single-user tools.
• Content marketplace — publisher dashboards, reader paywalls, royalty reports per transclusion event.

15. References

Primary Sources

• Udanax-Gold Source Code — the original C++ codebase (~200k LOC), mechanically translated from Smalltalk-80 in 1989. Available at original-code/xanadugold/ in the workspace repository.
• Ted Nelson, "Literary Machines" (1981, 1993) — the original specification of the Xanadu hypertext system, including transclusion, tumblers, and micropayments.
• Ted Nelson, "The Xanadu 17 Rules" — the design constraints that define Xanadu-compatible systems. Summarized in docs/xanadu-17-rules.md.

Technical Concepts

• BLAKE3 — the cryptographic hash function used for content fingerprinting. github.com/BLAKE3-team/BLAKE3
• CRDTs — Conflict-free Replicated Data Types. Shapiro et al., "A comprehensive study of Convergent and Commutative Replicated Data Types" (2011).
• PBFT — Practical Byzantine Fault Tolerance. Castro and Liskov, OSDI 1999.
• B-trees — the underlying data structure for O-tree leaves. Bayer and McCreight, "Organization and Maintenance of Large Ordered Indices" (1972).
• Content-addressed storage — the same concept used by Git, IPFS, and Nix. Xudanu applies it at the element level rather than the file level.

Internal Documentation

• README.md — Quick Start guide, CLI reference, security notes
• docs/diagram.html — Content + Performance Architecture diagram (companion to this document)
• docs/slides.html — Presentation slides for Show & Tell
• docs/tls-setup.md — TLS configuration guide
• docs/manual.md — Full user manual
• docs/protocol-and-audit.md — WebSocket protocol specification
• TODO.md — Development roadmap
• tests/integration.rs — 199 integration tests covering all documented behaviors
• tests/tls.rs — 7 TLS integration tests