Udanax Gold Heritage

Tracing the lineage: how every Gold concept lives on in Xudanu

Contents
The Lineage Architecture Map
Core Concepts
O-tree — The Document Spine Editions & Documents GrandMap — Content Is Identity Clubs & Permissions Lock Hierarchy Backfollow — Finding Transclusions Canopy Trees H-tree — Version Tracking Works & Revisions Coordinate Spaces Links
Persistence
Disk & Storage Wire Protocol
Full Mapping
Complete Concept Table Nelson’s 17 Rules

The Lineage

1960
Ted’s Vision
1988 - 1995
Udanax Gold Development
2026
Xudanu Rust Port

Udanax Gold was a C++ implementation of the Xanadu hypertext system, in active development from 1988 through 1995, and released as open source in 1999. It contained the accumulated wisdom of decades of thinking about how documents should connect: the O-tree, clubs, transclusion detection, canopy trees, the GrandMap, and the lock hierarchy.

Xudanu is a Rust based implementation of Udanax Gold, migrated from the released C++ code base. Every Gold subsystem was reviewed, mapped, and rebuilt with modern tools. This page traces each Gold concept to its Xudanu descendant, so you can see exactly what survived and what evolved.

Architecture Map

The Gold architecture was organized around the Fe/Be (Frontend/Backend) split. Xudanu preserves this conceptual separation but collapses it into a single server process with a WebSocket API.

Web Frontend
React + TypeScript, collaborative editor, transclusion overlays, document map
NEW
Wire Protocol
140+ operations, dual codec (JSON + binary), WebSocket transport, CSRF, heartbeats
ENHANCED
Server Core
Sessions, clubs, works, links, transclusion queries, security log, CRDT sync
GOLD
Edition Engine
O-tree, RangeElement, XnRegion, GrandMap, ContentPool, BackfollowEngine, Canopy
GOLD
Storage
BLAKE3 content-addressed chunks, WAL, dual manifest slots, atomic checkpoints
ENHANCED

Gold layers (amber, purple) are preserved concepts. Enhanced layers (blue, red) use modern technology. Green is entirely new.

O-tree — The Document Spine

The O-tree (orgl tree) is Gold’s persistent splay tree for storing edition content. It was the heart of the system — a structure that could represent infinitely large documents, splay arbitrary regions to the root, and share structure across versions.

Udanax Gold (C++)

OrglRoot / Loaf / InnerLoaf

orootx.hxx, loavesx.hxx

Loaves auto-split at tableSegmentMaxSize (16384). Nine-case splay transformation. DspLoaf for lazy displacement. OPartialLoaf with TrailBlazer. Splay restructures tree so any region is near the root.

Xudanu (Rust)

OrglRoot / Loaf DONE

src/edition/orgl.rs

Loaf enum: Leaf or Split. Auto-splits at 16384 (matching Gold). Full 9-case splay algorithm ported. Loaf::Dsp for lazy transforms. Infinite domains via default + tombstone entries. 22 O-tree tests passing.

OrglRoot splay(region) Split split: XnRegion Split split: XnRegion Leaf entries[N] Leaf entries[N] Leaf entries[N] Leaf entries[N] in_child out_child in_child out_child
O-tree structure: OrglRoot → Split nodes partition by XnRegion → Leaf nodes hold sorted entries

Editions & Documents

Udanax Gold (C++)

FeEdition / BeEdition

nkernelx.hxx, brange3x.hxx

Editions wrap an OrglRoot. FeRangeElement hierarchy: DataHolder, Edition, PlaceHolder, Label, IDHolder, Work. BeCarrier pairs element + optional label. Infinite-domain support via default entries.

Xudanu (Rust)

Edition DONE

src/edition/edition.rs

RangeElement enum: Data, Text, Edition, Label, PlaceHolder, Work, WorkRef, EditionRef. Carrier pairs element + optional label. Same infinite-domain semantics. fetch(), with(), without(), replace() use structural sharing via O-tree.

Gold heritage: The RangeElement hierarchy was the most faithful port. Every Gold element type has a Rust enum variant. The Carrier abstraction (element + optional label) is preserved exactly. 14 Gold test cases from nkernelt.cxx ported and passing.

GrandMap — Content Is Identity

Udanax Gold (C++)

BeGrandMap

grandmapx.hxx

Bidirectional mapping: BeId ↔ BeRangeElement. assignID() registers content. fetch() retrieves by ID. IDSpace::global() / IDSpace::unique() for ID allocation. Counter / BatchCounter for preallocating ranges.

Xudanu (Rust)

GrandMap + ContentPool ENHANCED

src/edition/grand_map.rs, src/edition/content_pool.rs

Same bidirectional mapping. Enhancement: ContentPool adds BLAKE3 content addressing — find_by_content() hashes content and returns existing ID if already stored. This means identical content is stored exactly once (Rule 8).

GrandMap BeId ↔ RangeElement assign_new_id(elem) → BeId fetch(id) → RangeElement ContentPool BLAKE3 → BeId (new!)
GrandMap: content is identity. ContentPool adds BLAKE3 hashing so identical content is stored once.

Clubs & Permissions

Udanax Gold (C++)

FeClub (extends FeWork)

nkernelx.hxx

Clubs are identity groups. Club IS a Work (inheritance). ClubDescription contained a Set of member clubs — recursive membership. sponsor(IDRegion) was separate from read/edit. historyClub controlled revision access.

Xudanu (Rust)

Club DONE

src/server/club.rs

Club contains a Work internally (composition). Personal clubs with Ed25519 keypairs. read_club, edit_club, default_read_club, default_edit_club. Enhancement: Encrypted signing keys (Argon2id + ChaCha20-Poly1305). OAuth login (GitHub, Google).

What evolved: Gold's recursive club membership (clubs containing clubs) is simplified to flat membership in Xudanu. The historyClub concept is not yet separate — anyone with read access can see history. Sponsor clubs are not yet implemented.

Lock Hierarchy

Gold’s lock system was a brilliant hierarchy of authentication mechanisms. Every lock type had a matching LockSmith that created it and a credential that opened it. Xudanu preserves the full hierarchy.

Lock Hierarchy BooLock public access WallLock no access MatchLock password (PHC) ChallengeLock Ed25519 challenge MultiLock named + any sub-lock Each lock has a matching LockSmith that creates it Each lock opens with a specific LockCredential Boo Password ChallengeResponse Named{...} KeyMaster: tracks accumulated authority
Complete lock hierarchy from Gold, preserved in Rust. KeyMaster accumulates authority across logins.

Backfollow — Finding Transclusions

The backfollow engine was Gold’s crown jewel: given a piece of content, find every document that contains it, anywhere in the system. This is what makes transclusion visible — you can trace where content has been reused.

Udanax Gold (C++)

RecorderFossil / ResultRecorder / Matcher / TrailBlazer

backfollx.hxx, recordrx.hxx

Recorder registered persistent queries. Fossil accumulated results over time. Matcher compared fingerprints. TrailBlazer resolved lazy placeholders. transcluders(), works(), rangeTranscluders().

Xudanu (Rust)

BackfollowEngine DONE

src/edition/backfollow.rs

Synchronous in-memory engine. TransclusionIndex maps BeId → works containing it. find_transcluders, find_works_for_content wire ops. BLAKE3 fingerprinting for content matching. Enhancement: Real-time WebSocket push of transclusion results.

Content (text fragment) BLAKE3 fingerprint Canopy lookup Transcluders [Work A, Work B, ...] input hash content find in index who has this?
Backfollow pipeline: content → BLAKE3 fingerprint → canopy tree lookup → list of transcluding works

Canopy Trees

Gold used canopy trees (BertCanopy and SensorCanopy) as balanced binary indices over edition content. They enabled fast filtering of transclusion queries — instead of scanning every position, the canopy pruned the search space.

Udanax Gold (C++)

BertCrum / SensorCrum / CanopyCrum

canopyx.hxx

Bert flags tracked which content fingerprints appeared in subtrees. Sensor flags tracked which positions had specific properties. Flag propagation up the tree enabled O(log n) filtering.

Xudanu (Rust)

BertCanopy / SensorCanopy DONE

src/edition/canopy.rs

Rc<RefCell<>> balanced binary tree with flag propagation. BertProp / SensorProp flag sets. Endorsement bit allocation. Flag-based filtering on transclusion queries. Fully tested with Gold scenarios.

H-tree — Version Tracking

Parallel to the O-tree, Gold maintained an H-tree (history tree) that tracked version information for every position. When content was transcluded from one document to another, the H-tree recorded the provenance. This was essential for backfollow — the H-tree is what let Gold trace content reuse backward through version history.

Udanax Gold (C++)

HistoryCrum / HUpperCrum / HBottomCrum

htreex.hxx

H-tree paralleled the O-tree. HUpperCrumData stored delayed backfollow walks. When new content was inserted, the H-tree recorded where it came from, enabling recursive transclusion tracking.

Xudanu (Rust)

HUpperCrumData DONE

src/edition/htree.rs

H-tree with delayed_store_backfollow walk. Integrated with canopy for transclusion queries. Records provenance on insert. Enables again()-style recursive transclusion chains.

Works & Revisions

Udanax Gold (C++)

FeWork

nkernelx.hxx

Work holds current edition + revision history. revise() creates new edition. history() returns past editions. Clubs for read/edit. Sponsors for vouching.

Xudanu (Rust)

Work DONE

src/server/server.rs

Same model: current edition + history. work_revise, work_fetch_edition, work_fetch_history. Enhancement: CRDT collaborative editing (multiple users, same work, real-time sync). Version genealogy API (version_is_before, version_ancestors).

Coordinate Spaces

Gold had a rich algebra of position spaces: Integer, Real, Sequence (tumblers), Cross (multi-dimensional), Filter. Each space had positions, regions, displacements, and orderings. This was the mathematical foundation for addressing within documents.

Udanax Gold (C++)

IntegerSpace, RealSpace, SequenceSpace, CrossSpace, FilterSpace, IDSpace

spacex.hxx, integerx.hxx, sequencex.hxx, crossx.hxx

Generic Position/Region/Dsp hierarchy. SequenceSpace had full tumbler addressing (variable-length integer tuples like 1.2.3.4). CrossSpace supported multi-axis coordinates for endorsements.

Xudanu (Rust)

Space Traits PARTIAL

src/space/

Circular associated types replace C++ inheritance. IntegerSpace, RealSpace, SequenceSpace, CrossSpace2, FilterSpace, SimpleMapping, CompositeMapping. 74 space tests passing.

Gap: No full tumbler addressing yet. SequenceSpace uses Vec<i64> without hierarchical prefix queries.

Udanax Gold (C++)

HyperLink / HyperRef

linkx.hxx

Bidirectional links. HyperRef::Single and MultiRef for multi-ended. Link type sets. Named ends. Endorsed wrappers. endNames() returned SequenceRegion.

Xudanu (Rust)

HyperLink / HyperRef DONE

src/edition/link.rs

Bidirectional links tracked in both directions. Single and Multi refs. Excerpt field on Single. Gap: No link type sets or named ends yet. Span-level targeting not yet exposed in protocol.

Disk & Storage

Udanax Gold (C++)

SnarfPacker / Turtle / Urdi / FlockManager

packerx.hxx, turtlex.hxx, urdix.hxx

Full disk abstraction: shepherds mapped to disk blocks (snarfs). Object-level persistence granularity. Purger evicted clean objects. Agenda persisted deferred work. Turtle was the root persistent object.

Xudanu (Rust)

Content-Addressed Chunks DIFFERENT APPROACH

src/persist/

BLAKE3 content-addressed .xchunk files in hex-sharded directories. WAL + dual manifest slots + atomic checkpoints. LRU cache. Different from Gold: Simpler, more robust, but lacks Gold’s object-level persistence granularity.

Design choice: Gold's SnarfPacker was an object database — every persistent object was a "flock" mapped to a "snarf" (disk block). Xudanu uses content-addressed storage instead, which is simpler and crash-safer but trades away Gold's fine-grained object paging. The Snarf on-disk format was faithfully implemented in src/persist/snarf.rs and tested, but the production server uses the chunk store.

Wire Protocol

Udanax Gold (C++)

Binary2 over TCP / Promise Manager

binary2.hxx, promanx.hxx

Custom binary protocol with humber encoding. 470+ numbered request handlers. Portal for bidirectional channels. Recipe for message construction. Negotiator for version negotiation. BootPlan for connection setup.

Xudanu (Rust)

WebSocket JSON + Binary ENHANCED

src/server/transport/

140+ operation codes. Dual codec: JSON (human-readable) and binary (postcard). WebSocket transport (ubiquitous). CSRF tokens. Heartbeats. Handshake response with version negotiation. Enhancement: Browser-native, no custom client needed.

Complete Concept Mapping

Every Gold type, module, and concept mapped to its Xudanu equivalent:

Udanax Gold (C++) Xudanu (Rust) Status Notes
OrglRoot / LoafOrglRoot / LoafDoneFull 9-case splay algorithm ported
FeEdition / BeEditionEditionDoneWraps OrglRoot, structural sharing
XnRegion / IntegerRegionXnRegion / IntegerRegionDoneTransition-array encoding preserved
FeRangeElement hierarchyRangeElement enumDoneData, Text, Edition, Label, PlaceHolder, Work
BeCarrierCarrierDoneElement + optional label
BeGrandMapGrandMap + ContentPoolEnhancedBLAKE3 content addressing added
FeWorkWorkEnhancedCRDT collaborative editing
FeClubClubEnhancedEd25519 keys, OAuth, encrypted at rest
FeKeyMasterKeyMasterDoneAuthority accumulation
Lock hierarchyLock trait + 5 locksDoneBoo, Wall, Match, Challenge, Multi
FeSessionSessionDoneConnection context
FeServerServerDoneAll ops as permission-checked methods
BackfollowEngineBackfollowEngineDoneBLAKE3 fingerprint matching
RecorderFossilTransclusionIndexDonePersistent transclusion index
BertCrum / SensorCrumBertCanopy / SensorCanopyDoneFlag propagation preserved
HistoryCrum / H-treeHUpperCrumData / H-treeDoneVersion tracking for backfollow
HyperLink / HyperRefHyperLink / HyperRefDoneBidirectional, Single + Multi refs
SequenceSpace (tumblers)SequenceSpacePartialNo hierarchical tumbler addressing
CrossSpaceCrossSpace2<A,B>Partial2D generic, no higher dimensions
FilterSpaceFilterSpacePartialTag-based, not region comparison
IntegerSpace / RealSpaceIntegerSpace / RealSpaceDoneTransition arrays, flip model
SimpleMapping / CompositeMappingSimpleMapping / CompositeMappingDonePosition transformations
SnarfPacker / TurtleChunk store + WALDifferentContent-addressed, simpler approach
Urdi (disk I/O)UrdiFileDoneFile-backed, guard records
Counter / BatchCounterCounter / BatchCounterDoneID pre-allocation
Abraham (persistence)Persistent traitDoneflock_id, to_bytes, type_tag
Cookbook / RecipeTypeRegistryDoneHashMap<tag, deserializer>
FeAdminerAdminStateDoneAccept/reject, shutdown, grants
FeFillDetectorDetector traitDoneCallback-based events
PlaceHolder / FillDetectorPlaceHolder variantPartialNo fill detection, no template slots
Agenda / AgendaItemNot yetPersistent task queue planned
ClubDescription recursive membershipFlat membershipNot yetClubs can't contain clubs
Work::sponsor()Not yetSponsor clubs planned
historyClubNot yetHistory access = read access
Binary2 over TCPWebSocket JSON + BinaryEnhancedBrowser-native, dual codec
XuPromise (lazy eval)Synchronous ResultSimplifiedAdequate for WebSocket model

Nelson’s 17 Rules: Status

#RuleStatus
1Every document consists of arbitrarily many portionsDONE
2Every portion can be transcludedPARTIAL
3Permission is required to transcludeDONE
4Permission is required to quoteDONE
5Tumbler addressingPARTIAL
6Bidirectional linksDONE
7Links visible from all endpointsDONE
8Identical content stored onceDONE
9Royalty at any granularityPARTIAL
10Mix of royalty-bearing and free contentDONE
11Data available from any serverPARTIAL
12Connection by any protocolDONE
13Adaptive storage tieringPARTIAL
14Redundant storagePARTIAL
15Charge users at any ratePARTIAL
16Handle any data typePARTIAL
17Portable front-endDONE

Read the full rule-by-rule assessment →