Project Xanadu: Nog meer retrospectief

In december 2024, tijdens een bezoek aan San Francisco, werd ik op het laatste moment uitgenodigd voor een feest dat alleen daar had kunnen plaatsvinden: een viering van het 50-jarig jubileum van het manifest Computer Lib/Dream Machines uit 1974 van de hypermedia-visionair Ted Nelson, waarin de visie van Project Xanadu-hypertext werd geprezen. Ik draag al 20 jaar bij aan de Engelstalige Wikipedia en werk al 15 jaar aan Gwern.net, dus ik kon het onmogelijk missen om een heel feest bij te wonen met mensen met sterke meningen over hypertext.

Onze gastheer, James, had een verrassend uitgebreide collectie Nelson-memorabilia verzameld: niet alleen exemplaren van dat boek (dat in het echt veel groter en indrukwekkender is dan ik besefte, vergelijkbaar met een Compact OED waarbij een vergrootglas nodig is, dat ook werd meegeleverd), of Nelsons boek The Future of Information uit 1997, maar ook kopieën van zijn mimeograaf-tijdschriften van het Swarthmore College, en het meest indrukwekkende van alles: verschillende vintage computers waarop kopieën van diverse Xanadu-implementaties draaiden.

Ted Nelson was op 87-jarige leeftijd nog in leven, maar kon helaas niet aanwezig zijn. Gelukkig was een van de aanwezigen een voormalig Xanadu-programmeur uit het Autodesk-tijdperk (ca. 1988–1993), en we konden naar enkele van zijn verhalen luisteren.

Deze verhalen waren een herinnering aan het feit dat, hoewel we eerdere tijdperken van computing romantiseren, de hardwarebeperkingen destijds echt zeer ernstig waren, wat productieve ontwikkeling bemoeilijkte. Ik denk dat sommige teleurstellingen in software-systemen uit het verleden begrijpelijker worden wanneer we ons herinneren hoeveel tijd en vindingrijkheid er is besteed aan het omzeilen van beperkingen. Zo is McIlroy (1982) terecht trots op de maanden van slim algoritme-ontwerp en optimalisatie die hij deed om een bruikbare spellchecker in minder dan 1MB RAM te laten passen—iets wat we vandaag de dag in een paar regels JavaScript zouden schrijven (en wat door een LLM zou worden gedaan).

Hij beschreef bijvoorbeeld hoe ze Xanadu prototypeden in Smalltalk (wat logisch was, aangezien dit een zeer productieve, prettige taal/OS is wiens objectgeoriënteerde model prachtig aansluit bij hypermedia), maar dat ze het vervolgens moesten cross-compileren naar C++ en dat moesten compileren... wat ongeveer een week duurde om te compileren. Niet een minuut, of een uur, of zelfs een dag, maar een week. (En ik dacht dat de compile-tijden van meerdere uren voor Gwern.net slecht waren voor mijn ontwikkelingssnelheid!) Hij moest ook veel tijd verspillen aan C++-onzin en compileerproblemen.

Het was een uitdaging om dit überhaupt werkend te krijgen op de pc's die we zagen, en dat was een van de redenen voor het feest. Ik moet toegeven dat ik me soms had afgevraagd hoe de Xanadu-jaren bij Autodesk zo weinig resultaat konden opleveren na meerdere man-jaren fulltime werk, terwijl het implementeren van de verschillende client-side transclusie- of popup-functies op Gwern.net gewoonlijk een paar dagen werk was voor Said Achmiz. Maar het horen van deze verhalen rechtstreeks van de bron hielp om de zaken in het juiste perspectief te plaatsen en herinnerde me eraan hoe ongelooflijk arm mensen destijds waren op het gebied van rekenkracht. (Misschien was de opslag nog erger dan de CPU: ik neem het voor lief dat ik elke PDF-, PostScript- of HTML-bestand dat ik nodig heb kan hosten, maar een aanzienlijk deel van mijn gehoste documenten overschrijdt de totale hardeschijfruimte van een gemiddelde pc uit 1990, die misschien een harde schijf van 50 MB had. Ondertussen zijn de Markdown-bronbestanden van de Gwern.net-essays zelf ongeveer 40 MB, de annotaties twee keer zoveel, en de uiteindelijke site 221.438 MB!)

De college-tijdschriften waren een verrassing en leuk om doorheen te bladeren: de jonge Ted hield al van schrijven, heel veel, en gaf graag advies. Iemand noemde dat Nelson ervan had gedroomd een Hollywood-regisseur te worden en er spijt van had dat hij in de technologie was gegaan; ik vond dat logisch en het verklaarde sommige dingen over zijn auteur-benadering van softwareontwikkeling (zoals zijn volharding dat hij 50 jaar later nog steeds "geen programmeur" is) of zijn gebruik van film-montage-metaforen zoals "edit decision lists".

Ook had ik Computer Lib/Dream Machines nog nooit echt goed gelezen en bladerde ik door een paar pagina's. Het was interessant om zo'n groot boek te zien, in meerdere kolommen om zoveel mogelijk informatie te proppen: Nelson kan er niet vanuit gaan dat de lezer iets over computers weet en moet vanaf nul beginnen met het uitleggen van basisconcepten zoals bytes of bestanden. (Je zou echt een vergrootglas nodig hebben als je ouder was.) Het latere (en veel minder bekende) boek Future of Information was ook interessant vanwege een ongebruikelijke hoofdstukstructuur, waarbij je in meerdere volgordes kon lezen, met een centraal samenvattingshoofdstuk.

Yuxi Liu merkt op dat Xanadu lijkt op een ander beroemd, langlopend "boil-the-ocean"-project met nauwe connecties met databases en AI, een charismatische leider die nooit van gedachte veranderde, aversie tegen open-source had en vergelijkbare tekenen vertoonde van 'pathologische wetenschap': Douglas Lenats Cyc. Na erover na te denken en Xanadu-materialen opnieuw te lezen, ben ik het daarmee eens.

Ik heb kortstondig op de Xanadu-pc's gekeken, onder de indruk dat ze überhaupt draaiden, maar ik en de meeste feestgangers raakten snel gedesillusioneerd. De UI was te vreemd. We hadden echt een demo van James nodig, of iets dergelijks: hypertext-systemen lenen zich niet voor onmiddellijke exploratie, vooral wanneer ze draaien op OS-en op computers die niemand daar in 25 jaar heeft gebruikt, indien überhaupt ooit.

Maar ik hoefde ze niet veel te gebruiken om naar het scherm te kijken dat de stereotiepe Project Xanadu-demo toonde—de opening van het boek Genesis met zijn beroemde lijnen die in zigzag naar rechts lopen om transclusies of commentaren op passages aan te geven—en een plotseling besef te krijgen:

"Oh mijn god—het is compleet onleesbaar."

De lijnen waren verwarrende rommel, vooral omdat ze elkaar kruisten (een hardnekkig probleem bij de lay-out van sidenotes, dat door de outlines veel erger werd gemaakt). Geen van de 'sidenotes' was leesbaar omdat het scherm zo klein was. Zelfs als je gewoon scrollde, kon je door de lijnen op veel mogelijke posities niets lezen! Hoe kon een document-UI waarbij je vaak niets kon lezen, ooit als een goed idee zijn verschenen? De UI was simpelweg verschrikkelijk—het had nooit kunnen werken. Zelfs op een groot scherm zoals mijn 4k-monitor zou ik dat niet willen.

En toen dacht ik na over de keuze van de tekst, en ik besefte dat de UI niet het echte probleem was; en het probleem was al die decennia niet het team. Het hele concept van side-by-side range-transclusies is een oplossing op zoek naar een probleem.

De range-specifieke transclusie en commentaren waren logisch voor het boek Genesis, waar gedetailleerde commentaren op elke regel staan en veel Bijbelse kritiek is die probeert te sorteren hoe het is samengesteld uit meerdere tegenstrijdige teksten. Maar terwijl ik bij mezelf dacht: "Hé, we kunnen sidenotes en range-transclusies/commentaren met bidirectionele backlinks op Gwern.net ook doen, en dat doen we in mijn analyse van het korte verhaal 'Suzanne Delage'!", besefte ik plotseling: we kunnen het, maar we doen het meestal niet, omdat niemand dat echt nodig heeft. Dit is vooral waar als we kijken naar de "Voorbeelden van Parallelle Documenten" van Ted Nelson: tekstkritiek (de Bijbel, Hamlet, "Rashomon" versus de film Rashomon), het vergezocht voorbeeld van de Virginia Declaration of Rights die de United States Bill of Rights beïnvloedde, en vervolgens zeer twijfelachtige voorbeelden—lijsten van heiligen, telefoonge gesprekken binnen een organisatie, en comedy-tv-afleveringen...?

Hampenaast geen enkele tekst in de wereld moet echt worden 'gefisked', of specifieke regels of paragrafen getranscludeerd hebben; bijna niemand schrijft Talmoed-commentaren, laag over laag genest. De meeste echte instanties van citaties zijn citaties naar het doel als geheel. En zelfs bij die zouden we 99% ervan niet willen zien, en we zouden de goede 1% sowieso niet weten te organiseren omdat ze elk een ander doel kunnen hebben. (Kijk maar eens naar online reacties: sorteren we ze op datum, populariteit, karma of 'page rank', lengte, of op basis van of de auteur van de pagina direct heeft gereageerd...?)

Met terugwerkende kracht denk ik dat het veelzeggend is dat ik in noch Lib/Dream noch Future কোনো instanties van 'transclusie' op papier heb gezien. Nelson had elke hoeveelheid side-by-side lay-out of range-transclusie in zijn boeken kunnen gebruiken, want software is geen obstakel: hij stelde ze met de hand samen en kon alles tekenen, illustreren of kopiëren in elke gewenste opstelling. Maar hij deed het niet, omdat... het gewoon niet zo nuttig is voor boeken. Zelfs niet voor die van hem. (Je hebt geen transclusies nodig als je gewoon naar een eerdere passage kunt verwijzen.)

Let op dat zelfs in film, waar het triviaal is om twee bronnen van beeld naast elkaar te zetten en de één 'commentaar' te laten geven op de ander, dit zelden gebeurt; in plaats van te vertrouwen op horizontale of verticale juxtapositie, gebruikt film de derde dimensie van tijd, met een rijke woordenschat van montage en andere trucs voor overgangen, die hetzelfde doen. Ruimtelijke juxtapositie wordt in diverse omstandigheden gebruikt, maar is nergens de standaard. Alleen in zeldzame gevallen is iets als een picture-in-picture lay-out conventioneel. Een belangrijke niche zijn live-uitzendingen waarbij het ondoenlijk is om vanuit meerdere hoeken te filmen en coherent te monteren. Bij een live-interview is het gebruikelijk om twee sprekende hoofden gelijktijdig te zien, maar wanneer het later wordt gemonteerd, wordt dit vaak omgezet in een sequentie van cuts.

En dat is waarom we die specifieke transclusie-mogelijkheid pas rond 2023 aan Gwern.net hebben toegevoegd, gemotiveerd door mijn literaire analyse van een kort verhaal. Ik heb het niet nodig, de Engelstalse Wikipedia heeft het niet nodig, Reddit heeft het niet nodig, Twitter heeft het niet nodig, ~100% van de persoonlijke blogs hebben het niet nodig... Het is gewoon niet zo nuttig—tenzij je literaire kritiek of commentaar op een tekst schrijft, wat ongeveer 0% van het World Wide Web beschrijft (in 2025 of 1989). Al die lijnen zien er cool en futuristisch uit, maar op het moment dat ik denk aan hoe ik ze zou gebruiken in een echt Gwern.net-essay en hoe het zou zijn om dat te lezen, krijg ik hoofdpijn.

De beroemde Project Xanadu UI/UX is een "sciencefiction-interface", zoals de 3D-gebaar-interfaces in de film Minority Report of de virtual reality van Snow Crash: iedereen kijkt ernaar en is verblind door hoe cool het eruitziet, behalve dat het een verschrikkelijk idee is dat een ellende zou zijn om te gebruiken en je "gorilla-arm" zou geven. Je probeert een prototype of mockup uit, en bijna zodra je ze begint te gebruiken, besef je dat nee, dit is niet werkbaar en je moet het volledig weggooien.

Dit herinnerde me aan de opmerking over de Hollywood-regisseur: je zou kunnen zeggen dat Project Xanadu het idee van een Hollywood-regisseur is van wat een World Wide Web zou moeten zijn. Je kunt er alleen in geloven als je het nooit echt probeert te gebruiken voor een echt project. Als Ted Nelson minder charismatisch was geweest, en een minder meeslepende schrijver, of minder geloof had gehad in zijn eigen visie, zou dit eerder duidelijk zijn geworden. Omdat dat niet zo was, geniet Nelson—net als Douglas Engelbart—de eer om de levende belichaming te zijn van de wet van Cunningham: een van die historische figuren wiens belang eraan was dat ze zo ongelijk hadden over zo'n belangrijk onderwerp dat ze anderen inspireerden om het juist te doen.

Sterker nog, dat verklaart ook iets over Xanadu dat me altijd heeft verward: de nadruk op auteursrecht. Het is moeilijk om in de moderne wereld iets te bedenken dat schadelijker is en meer tegenover een nuttig hypertext-systeem staat dan ons huidige maximalistische auteursrecht, maar de 17 principes van Xanadu besteden meer tijd aan het veilig maken van het web voor auteursrechthebbenden dan aan kleine zaken als "transclusie". Het moet micropayments ondersteunen op willekeurige niveaus van transclusie, moet standaardlicenties hebben, Net Neutrality vermijden, toestemmingsloze transclusie van willekeurige bronnen toestaan, etc.:

De 17 Xanadu Principes (Wikipedia-versie)

1. Elke Xanadu-server wordt uniek en veilig geïdentificeerd.
2. Elke Xanadu-server kan onafhankelijk of in een netwerk worden bedreven.
3. Elke gebruiker wordt uniek en veilig geïdentificeerd.
4. Elke gebruiker kan documenten zoeken, ophalen, maken en opslaan.
5. Elk document kan uit een willekeurig aantal delen bestaan, waarvan elk van een willekeurig datatype kan zijn.
6. Elk document kan links van elk type bevatten, inclusief virtuele kopieën (“transclusies”) naar elk ander document in het systeem dat toegankelijk is voor de eigenaar.
7. Links zijn zichtbaar en kunnen vanaf alle eindpunten worden gevolgd.
8. Toestemming om naar een document te linken wordt expliciet verleend door de handeling van publicatie.
9. Elk document kan een royalty-mechanisme bevatten op elk gewenst detailniveau om betaling te garanderen voor elk ontsloten deel, inclusief virtuele kopieën (“transclusies”) van geheel of deel van het document.
10. Elk document wordt uniek en veilig geïdentificeerd.
11. Elk document kan veilige toegangscontroles hebben.
12. Elk document kan snel worden gezocht, opgeslagen en opgehaald zonder dat de gebruiker weet waar het fysiek is opgeslagen.
13. Elk document wordt automatisch verplaatst naar fysieke opslag die passend is voor de frequentie van toegang vanaf een gegeven locatie.
14. Elk document wordt automatisch redundant opgeslagen om beschikbaarheid te garanderen, zelfs in geval van een ramp.
15. Elke Xanadu-dienstverlener kan zijn gebruikers een tarief naar keuze in rekening brengen voor de opslag, het ophalen en het publiceren van documenten.
16. Elke transactie is veilig en controleerbaar, uitsluitend door de partijen bij die transactie.
17. Het Xanadu client-server communicatieprotocol is een openbaar gepubliceerd standaardprotocol.

• Ontwikkeling en integratie van software door derden wordt aangemoedigd.

Ik had me altijd afgevraagd hoe iemand kon geloven dat dit mogelijk of wenselijk was: natuurlijk zouden auteursrechthebbenden weigeren hieraan mee te werken, en zouden ze elke Xanadu met afschuw en walging verwerpen, omdat het talloze businessmodellen en IP-regimes omverwerpt. Maar natuurlijk, als je jezelf in je hart als een Hollywood-regisseur zag, zou je sterke gevoelens hebben over de heiligheid van het auteursrecht, zou je fel tegenstaan tegen het volgen van de logica van transclusie naar vrije software/open source, en zou je geloven in een soort semantisch web waarbij je verwacht... dat alles gewoon werkt.

Tegenover de realiteit van wat er gebeurt wanneer je 8 miljard mensen online brengt en een groot deel van de wereld laat draaien op het internet: een nachtmerrieachtig donker bos waar alles wat fout kan gaan, willekeurig vaak per dag fout gaat; elke invariant waar je in geloofde blijkt ergens ter wereld kapot te zijn; en elke mooie functie—zoals bidirectionele trackback-links—zal genadeloos worden misbruikt door spammers, dwazen en schurken, actoren van natiestaten, opduikende bugs of hackers...

De meeste van die principes zijn alleen logisch als je ze nooit in de echte wereld probeert, waar je zult ontdekken dat velen van hen niet alleen van twijfelachtige waarde zijn, of fel zouden worden bestreden door vele entiteiten, maar simpelweg illegaal zijn.

Dus, voor mij is Project Xanadu een casestudy in waarom ontwerpers hun ontwerpen moeten mock-uppen en prototypen voordat er te veel in wordt geïnvesteerd. Xanadu was niet het slachtoffer van "Worse is Better"; het was gewoon een oplossing op zoek naar een probleem. (Iets soortgelijks lijkt waar te zijn voor Arbital: het had één echte gebruiker, Eliezer Yudkowsky, die het had bedacht, maar worstelde om de visie te communiceren of een duidelijk prototype en set use-cases te creëren).

Waar waren de Xanadu-demo's en use-cases die op papier waren uitgewerkt met scharen en lijm, indien nodig? Waarom waren ze altijd gewoon een wild onrepresentatieve use-case zoals "Het boek Genesis"? Als je zou gaan zitten en zou proberen om een gewone technische documentatie of het dichtstbijzijnde tijdschrift om je heen te veranderen in een reeks range-transclusies... hoe goed zou dat werken?

Ik denk dat als je dit deed, het antwoord snel zou worden: "Ja, ik heb hyperlinks nodig, die zijn doodnuttig; ik moet kunnen linken naar willekeurige mediatypes zoals afbeeldingen, audio, video, of specifieke pagina's in een boek; ik heb links nodig die niet gaan rotten; ik heb een scripttaal nodig, maar... ik heb de meeste van deze andere dingen niet echt nodig."

En voor mij, toen ik begon aan Gwern.net, werd bijna elke functie gedreven door een use-case die ik had (vooral omdat ik lui ben). Voor hypertext vraag ik mezelf af: "Wat heb ik nodig dat een basis blog-achtige HTML-pagina of een English Wikipedia-pagina niet biedt?", en het antwoord is: "Ik hoef niet zomaar een reeks willekeurige paragrafen van een URL te transcluderen. Wat ik nodig heb is een soort samenvatting of abstract. Ik heb ervoor nodig dat een lezer zo snel en wrijvingsloos mogelijk kan browsen, en snel referenties kan scannen of interessante citaties kan volgen."

Ik zou zeggen dat de fout van de Xanadu-UI was dat transclusie als 'horizontaal' en side-by-side werd behandeld, en ervan werd uitgegaan dat al het lezen/schrijven op het laagste ruwe niveau van tekst moest gebeuren. In plaats daarvan had het 'verticaal' moeten zijn met popups, en 'inzoomen' en 'uitzoomen' op verschillende abstractieniveaus van de tekst (link-icoon → titel → abstract → sectie etc.).

Zodra je popups hebt die naadloze navigatie bieden, gebruik je in feite overal transclusie—maar dan binnen de popups. Dit leidt tot elegante Gwern.net UI/UX-ontwerppatronen, zoals: de disclosure/collapses om in-place zoomen mogelijk te maken van alles, van secties tot zinnen in paragrafen, of de tag-directories, of de backlinks die veel verbeteren over die van Xanadu of Wikipedia door een 'omgekeerde' transclusie te tonen om de context van de link in de andere pagina's te laten zien.

Dit illustreert dat een probleem met Nelsons nadruk op byte-ranges—misschien voortkomend uit zijn oude metafoor van het aan elkaar splicing van gespecificeerde frames van filmrollen—is dat het semantiek negeert. Ik wil niet 'bytes 123–456' van een HTML-bestand transcluderen; ik wil een specifiek, betekenisvol element XYZ transcluderen, dat toevallig nu op bytes 123–456 is opgeslagen, maar van lengte kan veranderen, kan worden verplaatst, of kan worden herschreven. Tekst is niet semantisch onveranderlijk.

Dus moet je vertrouwen op toegang tot de volledige bewerkingsgeschiedenis van alles zodat je uit oude versies kunt transcluderen, wat het begin van een doodlopende weg is; en als je dat wilt doen, kun je gewoon je eigen kopie hosten!

Ik denk dat een van de redenen waarom outliner-benaderingen voor hypertext in het algemeen niet zijn doorgebroken, is dat ze, hoewel nuttig, te veel werk bij de auteur leggen. Echter, LLM's openen veel nieuwe ontwerpconcurrenties voor het automatisch samenvatten/uitbreiden om een volledige hiërarchie op te bouwen terwijl de menselijke auteur alleen schrijft wat noodzakelijk is, wat volgens mij veel oude 'tools for thought'-ideeën kan doen herleven en ze eindelijk bruikbaar kan maken.