Introduction

This book is about a contest that most people do not remember happening.

In the late 1980s and through the first half of the 1990s, several different ideas competed for what it would mean to put information into networked machines. The contest had technical dimensions — different protocols, different data models, different ways of naming things — but underneath the technical dimensions were different ideas about what a computer was for, what reading was, what writing was, and what the relationship between an author and a reader could be when both were sitting at terminals connected to the same wires. The web won that contest. It won so completely that within a decade the word “online” effectively meant “on the web,” and within two decades the word “computer,” for most people, effectively meant “a thing you use the web through.”

Won is the right verb. The web did not arrive in an empty room. It arrived in a room already full of working systems, some of them older than the web by twenty years, some of them younger by only a season. It beat them. It beat them for real reasons, some technical, some social, some economic, and it is worth being clear-eyed about those reasons because the alternative is to slip into a kind of grievance literature that mistakes nostalgia for analysis. This book does not want to be that. The premise of these chapters is that the systems the web displaced were proposed by serious people, were used by real users, solved real problems, and made real claims about what networked computing should be. Some of those claims were wrong. Some were right but premature. Some were right and remain right, and have been quietly buried under twenty-five years of layered abstractions that solve the same problems less well.

The through-line of the book is a single observation: the document was lost to the application, and authorship was lost with it. In every system this book treats — Bush’s Memex, Engelbart’s NLS, Nelson’s Xanadu, Atkinson’s HyperCard, the academic hypermedia tradition from Brown to Southampton, the literary hypertext canon at Eastgate, the knowledge-base lineage from PARC to Carnegie Mellon, Gopher and WAIS and Usenet and email and Plan 9 — there was a working assumption that the unit of computing was a piece of writing, that the person at the terminal was both a reader and a writer, and that the system’s job was to make that reading and writing more powerful. The web inherited some of this. The web was, in its first form, a document system. Tim Berners-Lee’s original 1989 proposal at CERN was a document system. The first browser, written on a NeXT in late 1990, was an editor as well as a reader. But the web did not stay a document system. Within a few years the document was a vehicle for an application, and within a decade the application was the point and the document was incidental scaffolding. Authorship — the ordinary act of a person making something readable that other people can read — became a specialist skill again, the way it had been before printing.

This is what was lost. Not the protocols, not the file formats, not even the specific features like two-way links or transclusion or stack scripting, though those losses are also real. What was lost was the assumption that a person sitting at a computer would naturally make things, and that the things they made would be first-class objects in the system, addressable and durable and combinable with other people’s things. That assumption was load-bearing for the systems in Parts II and III of this book. The web kept it, formally, for about five years. Then the browser ate the document, and the platform ate the browser, and what we ended up with is a world in which roughly five billion people consume software through a small number of glass rectangles, and almost none of them write anything that survives a server migration.

The book has five parts.

Part I is the frame. It argues that “won” is the right verb, sketches what hypermedia was supposed to be from Vannevar Bush forward, and sketches what the internet was supposed to be from the earliest packet-switching proposals forward. Both visions are older than most readers expect. Both were specific about the kinds of work they intended to support and the kinds of social relations they assumed. The web kept some of this and discarded a great deal.

Part II covers the hypermedia alternatives — the systems that proposed answers to the question “how should networked text behave” that were not the answer the web gave. Xanadu, the system Ted Nelson has been proposing in some form since 1960, with its insistence on two-way links, transclusion, version permanence, and a coherent rights model. HyperCard, the most-used hypermedia system in history, which made stack-based interactive media a thing ordinary Mac users built in the kitchen. NLS and Augment, Doug Engelbart’s actual proposal for augmenting human intellect, of which the world remembers the mouse and forgets almost everything else. The academic hypermedia tradition — Intermedia at Brown, Microcosm at Southampton — which took linking seriously as a research problem and produced systems that the web’s designers either knew about and rejected or did not know about and reinvented worse. The literary hypertext canon — Storyspace, Eastgate, Michael Joyce’s afternoon, Shelley Jackson’s Patchwork Girl — which proved, before the web existed, that nonlinear writing was a real literary form and not just a technical curiosity. And the knowledge-base lineage — NoteCards at Xerox PARC, KMS at Carnegie Mellon — which framed hypermedia as a tool for thought rather than a tool for publishing, and whose ideas now resurface in Roam and Obsidian and Logseq twenty-five years later.

Part III covers the internet alternatives — the protocols and architectures that proposed answers to the question “how should networked services be structured” that were not the answer the web gave. Gopher, which thought the right abstraction was a hierarchy of menus and would have given us a very different relationship to navigation. WAIS, which treated search as a peer service rather than a centralized index, and which knew in 1991 most of what the rest of us learned in 2010 about why centralized indexes are dangerous. Usenet and FidoNet, the federated-by-default community systems that distributed conversation across thousands of independent servers and worked, for two decades, without anyone being in charge. Email, which is the only one of these to have survived, and which survived in compromised form for reasons worth examining. Plan 9 from Bell Labs, which proposed that the entire network should look like a filesystem and that every operation should be a file operation, and which we mostly ignored because Unix was good enough.

Part IV is about how the web won. It is not an attempt to take the win back. It is an attempt to be specific about which choices mattered and why they mattered. The choices that gave the web its shape — statelessness, uncoordinated URLs, lossy one-way linking, view-source, a permissive layout model — were not obvious at the time, and several of them were specifically rejected by competing systems for what looked like good reasons. They turned out to matter enormously. The chapters in this part treat the technical decisions, the commercial inflection through Mosaic and Netscape, the politics of standardization across the IETF, W3C, and WHATWG, the accidental dominance of JavaScript as a runtime, and the platform decade in which a small number of companies absorbed most of what the rest of us thought we were building.

Part V is about what is being recovered, and what is not. Some of the lost ideas are coming back. Local-first software is recovering data ownership at the architectural layer, treating the user’s machine as the canonical store and the server as a cache rather than the other way around. ActivityPub and the IndieWeb are recovering federation, slowly, in a form that has to negotiate with platforms it did not design for. Markdown and static site generators and the Gemini protocol are recovering the document as a first-class object, at least for the people who want one. Roam and Obsidian and Logseq are recovering personal hypermedia at the desktop layer, with bidirectional links and block references that would have been familiar to the NoteCards team in 1985. The dynamic document tradition — Bret Victor’s explorables, Observable, Jupyter, Glamorous Toolkit — is recovering the idea that a document can also be a computation, which is older than the web. But some losses are not being recovered, and the last chapter tries to be honest about which.

A word on what this book is not.

It is not a history of the web. Several good ones already exist; Tim Berners-Lee’s own Weaving the Web, James Gillies and Robert Cailliau’s How the Web Was Born, and the more recent oral histories collected at the Computer History Museum all cover that ground better than a single book trying to cover a much wider field could. It is not a defense of any one of the alternatives. Ted Nelson has been defending Xanadu for sixty years and does not need help. It is not an attack on the web. The web has been one of the most successful pieces of public infrastructure in the history of the species, and its success is real. And it is not a roadmap for replacing the web. There is no replacement coming. What is coming is a slow accretion of recovered ideas on top of, around, and underneath the web, and the value of being clear about what was lost is that it makes that accretion legible — it lets us name what local-first is recovering, what ActivityPub is recovering, what the static renaissance is recovering, instead of describing each recovery in isolation as if it were novel.

A word on accuracy.

The systems in this book existed. The people in this book existed and most of them are still alive. The papers, the protocols, the products, the lawsuits, the licensing disputes, the funding decisions — these are matters of record, and where the record is uncertain the book says so. I have tried to avoid the temptation that haunts this material, which is to make the past more coherent than it was. The people who built NLS did not know they were building NLS until they were building it. The people who built Xanadu have, in some sense, never finished building Xanadu. The web was not designed to win; it was designed to solve a specific problem at CERN and then it kept being useful for other problems, and the people who built it were as surprised as anyone when it became the substrate for civilization. Calling any of this “designed” understates the contingency. Calling it “inevitable” insults the people who were trying, in good faith, to build something different.

The argument of the book, then, is simple. The systems that lost lost for reasons. Those reasons are worth knowing. The things they were trying to do are still worth doing, and some of them are being done again, in new clothing, by people who in many cases have no idea they are repeating an attempt. The point of recovering the history is not to relitigate the contest. It is to give the recovery somewhere to stand.

The first part begins with the verb.

Won is the right verb

The first thing to establish, before anything else, is that there was a contest. This sounds trivial. It is not. The way the history of the web is usually told — in introductions to programming books, in keynote addresses, in the official mythology that the web’s own institutions produce — presents the web as a kind of inevitable arrival, a thing that simply happened when the conditions were ripe, with no opponents worth naming and no losers worth mourning. This is wrong. The web arrived into a room full of working systems, several of which were older than it, several of which had more users than it had for the first three years of its existence, several of which had richer feature sets than it would have for another fifteen years, and several of which were specifically designed to do better the things the web was about to do worse. None of them survived as primary infrastructure. Each was beaten. This chapter is about why the verb is “won.”

The empty-room story and why it is false

The empty-room story goes like this. There were computers. They were connected by the internet. People wanted to share information. Tim Berners-Lee proposed the web. The web spread because it was useful. End of history. Inside this story, the web is not so much an invention as a recognition: the recognition that information could be linked, displayed, and shared in a uniform way. The story has a clean shape because it is a story about a single hero solving a problem nobody else had thought to solve. It is wrong on every clause. Many people had thought to solve it. Several had built working solutions. Two of them, Gopher and WAIS, were widely deployed across the academic internet by the time the web was a year old. One of them, HyperCard, had millions of users on Macintoshes. Another, the various academic hypermedia systems descended from Engelbart’s NLS, had been used in production research environments since the 1970s. And one of them, Xanadu, had been proposed in 1960 and was, by 1990, the subject of a software company funded by Autodesk with a staff of working engineers.

This matters because the empty-room story makes the web’s victory look like discovery, whereas in fact it was selection. Discovery has no losers. Selection does. To say the web won is to say that some specific properties of the web — properties chosen by specific people for specific reasons — beat specific properties of specific competitors that were chosen by other people for other reasons. Recovering the names of those competitors and the names of those properties is the first step in being able to talk seriously about what was traded away. If the web simply arrived from nowhere there is nothing to trade. If it beat real alternatives, there is.

What was actually in the room

A partial list of what was running on networked machines in 1991, the year the first web server came online at CERN:

Gopher had been released in April 1991 at the University of Minnesota and was being adopted, quickly, across the academic internet. Its model was a hierarchy of menus. You navigated by selecting items. Each item could be a document, another menu, a search interface, or a connection to a remote service. There was no markup. There were no inline links. There was a clean, almost severe abstraction: the world is a tree of things you can look at, and you look at them by walking the tree. This was understood, at the time, as a feature and not a limitation. The web’s later association of “navigation” with “following an arbitrary link inside a paragraph” was one specific choice among several plausible ones, and Gopher had made the other choice with care.

WAIS — the Wide Area Information Server — had been released in 1991 by Thinking Machines, Apple, and Dow Jones, with Brewster Kahle as its principal designer. WAIS was a federated search system built on the Z39.50 protocol. Any machine could expose its content as a WAIS index. Any client could query multiple indices in parallel and get ranked results. Search was a peer service: there was no central place. Anyone running a server contributed to the searchable universe. The current internet’s relationship to search — a small number of centralized indices, each owned by a company, each a chokepoint — was specifically not the relationship WAIS proposed.

HyperCard had shipped on every Macintosh since 1987. By 1991 it had been used to build commercial software, educational stacks, games (including the original Myst), reference works, business tools, and personal note-taking systems. Its scripting language, HyperTalk, was natural-language enough that schoolteachers used it. The cultural fact of HyperCard — that ordinary computer users routinely made interactive media for themselves and each other — has no direct equivalent on the web. We rebuilt some of its surface in the web. We have not rebuilt the underlying cultural pattern.

Usenet, the federated discussion system using NNTP, had been operational since 1980. By 1991 it carried tens of thousands of newsgroups, was the locus of most online community life, and had a working governance model based on group creation votes and a hierarchy of moderators. FidoNet, its dial-up cousin, had been founded by Tom Jennings in 1984 and connected tens of thousands of bulletin board systems through store-and-forward messaging. Both worked. Neither had a single owner. The current web’s relationship to community — a small number of platforms, each operating its own walled garden — was specifically not the relationship Usenet and FidoNet proposed.

Behind these were older and stranger things. The Memex, Vannevar Bush’s 1945 thought experiment, was the founding image of hypermedia and had remained a touchstone for forty-five years. Engelbart’s NLS, demonstrated in the 1968 “Mother of All Demos,” had been a working system for two decades. Xanadu had been in development since the early 1960s under various sponsors. Brown University’s hypermedia work, beginning with Andries van Dam’s Hypertext Editing System in 1967, had produced Intermedia by 1985 and was being used to teach undergraduate literature courses. Southampton’s Microcosm system, built by Wendy Hall’s group, was being used for industrial documentation. NoteCards at Xerox PARC, KMS at Carnegie Mellon, Storyspace at Eastgate Systems, Guide on the Macintosh — each was a serious, deployed hypermedia system with users, papers, and a roadmap.

The room was not empty. It was crowded.

The decisive years, 1991 to 1995

In the four years between the first web server at CERN and the Netscape IPO, all of this was decided. It is worth being specific about the timing because the legend foreshortens it. The web was not “released” in any one moment. It became, in stages, the dominant system.

In 1991, the web existed as a single server, info.cern.ch, accessible mostly to physicists. Berners-Lee’s first browser ran only on NeXT machines. The total number of web pages in the world was small enough to enumerate. Gopher had more users that year than the web did. So did WAIS. So did HyperCard, by orders of magnitude.

In 1992, ViolaWWW, Erwise, and MidasWWW gave the web cross-platform browsers. The number of web servers grew from one to about fifty. Gopher’s user base also grew, faster, and Gopher’s developers introduced Gopher+ to add features that addressed early criticisms. The competition was live.

In 1993, two things happened that mattered more than anything else. The University of Minnesota announced in March that it would charge licensing fees for Gopher in commercial settings. The fees were modest and applied only to commercial use, but they were enough to spook institutions and developers, who had been operating under the assumption that internet protocols were free in the sense of unencumbered. CERN, that same year, announced that the web’s specifications would remain public-domain and royalty-free. The shift in momentum was immediate. The other thing that happened in 1993 was Mosaic. Released by NCSA in late January, Mosaic was a graphical browser that ran on Unix, then on Mac and Windows, and that displayed inline images. Marc Andreessen and Eric Bina, the principal authors, made the web look like a magazine where Gopher looked like a card catalog. The number of web servers rose from fifty to about five hundred over the course of the year.

In 1994, Andreessen co-founded what became Netscape Communications. The web servers crossed ten thousand. The W3C was founded at MIT under Berners-Lee. HotWired and the first commercial web banner ads appeared in October. Gopher’s growth flattened and reversed. The hypermedia academic conferences began to absorb the fact that the web was not, technically, a serious hypermedia system, but that it was nevertheless the system that was going to win.

In 1995, Netscape went public on August 9th, valuing the company at $2.9 billion on its first day despite never having shown a profit. The IPO is the conventional marker for the moment the contest ended. By the end of 1995 the web had more than twenty thousand servers, more users than Gopher had ever had, and a commercial gravity that made it the obvious target for any new investment in networked services. Gopher continued to exist; it still does, in a small archival way. WAIS continued to exist for several more years before being absorbed into commercial search products. HyperCard continued to ship with Macintoshes until 1998 and was formally discontinued in 2004. Xanadu’s first public release, ZigZag, came in 1999, after the contest was already over. The academic hypermedia community redirected its work toward the web, often grudgingly.

Four years is a short time. The standard narrative tends to compress them further, into a kind of single instant in which the web simply was, but the people who lived through those years remember the contest as live. Andreessen remembers it. Berners-Lee remembers it. The Gopher team at Minnesota remembers it with particular sharpness, because they had reason to think they were going to win until they weren’t.

What winning looked like at the protocol level

The web’s protocol-level victories were specific and worth naming.

HTTP was stateless. Each request stood alone; the server kept no per-client memory between requests. This was, by the standards of the systems it competed with, almost shockingly thin. Gopher was also stateless, but most of the hypermedia systems were not — Intermedia, NoteCards, KMS, and others all maintained rich session state about who was reading what and where. Statelessness was a feature for scale and a liability for almost everything else. The features the hypermedia systems had — robust two-way linking, version tracking, awareness of other readers — depended on state the web threw away. The web traded those features for the ability to handle, eventually, billions of clients on commodity hardware.

URLs were uncoordinated. Anyone could mint one without asking anyone. This was a deliberate rejection of the rich addressing systems that Xanadu and the academic hypermedia systems had proposed, in which a link was a two-way relationship registered with some authority. The cost of uncoordinated URLs is link rot: the web’s links break, constantly, because nobody promised to keep them working. The benefit is that the system has no chokepoint and can grow without permission. The bet was that the cost of broken links was lower than the cost of a permission system, and over a span of decades the bet has mostly paid off, though it has also been the cause of nearly every recovery effort discussed in Part V.

Links were one-way and lossy. You could link to a page without that page knowing. The linked page could move, change, or vanish, and the link would silently rot. Xanadu had specifically proposed two-way linking and had built parts of the machinery to support it. The academic hypermedia systems had proposed the same. The web rejected both, partly because two-way linking does not scale without coordination and partly because the people building the web found the engineering of one-way links easier to ship. The cost of lossy linking is the loss of citation structure: a link no longer reliably means “this thing exists and says this.” The benefit is that you can link to anything without asking and without negotiation.

HTML was permissive. The original specification was small; browsers were forgiving of malformed input; the layout model was forgiving of authors who did not know what they were doing. This permissiveness was the opposite of what most hypermedia systems had offered. NoteCards, KMS, and Intermedia were strict; their authoring tools enforced structure; you could not produce malformed content because the tools would not let you. HTML let anyone produce anything that vaguely looked like HTML, and the browser would do its best. This was a major reason for the web’s growth. It was also the seed of the layered complexity that would become CSS, then JavaScript, then the modern browser-as-operating-system.

View-source. This was a feature, not a protocol, but it shaped the social pattern more than any single protocol decision. A web page’s source was visible to any reader; the View Source menu let anyone open any page’s HTML and read it. The hypermedia systems mostly did not do this. They presented content; they did not invite you to inspect its construction. View-source meant that the early web was a school. People learned HTML by reading other people’s HTML, then changing it, then publishing. This was the recovery of a teaching pattern that had been familiar from BASIC programs in computer magazines a decade earlier, and it shaped a generation of authors.

What winning looked like at the social level

The protocol-level story is half the story. The other half is social. The web won, at the social level, for reasons that have less to do with technology than with how the technology was governed.

It was royalty-free, definitively, from 1993 onward. CERN’s release of the web specifications into the public domain that year was a specific governance decision and an answer to the Gopher licensing scare. The promise that no one would ever owe money for using HTTP or HTML was a precondition for institutional adoption. The institutions adopting the web were universities, government agencies, and early commercial publishers — entities with lawyers who needed to know whether they were taking on a liability. The web’s answer was no.

It was permissionless. There was no central registry of web servers, no application to fill out, no naming authority other than DNS, which already existed. If you had a machine with a public IP, you could be on the web in an afternoon. None of the hypermedia systems had this property. Xanadu by design required participation in its docuverse, which implied coordination. Intermedia required institutional infrastructure. HyperCard was permissionless to author but had no native network distribution; sharing a stack meant copying a file. The web’s setup cost for a publisher was very nearly zero and that mattered enormously.

It was rendered, badly, on cheap machines. This is sometimes treated as a minor technical detail, but it was load-bearing. Mosaic and the browsers that followed it ran on consumer hardware over consumer modem connections and produced something legible. The hypermedia systems were mostly built on workstation-class machines or required specific operating systems. The web, by contrast, ran wherever there was a TCP/IP stack and a screen. This let it grow into the consumer internet of the mid-1990s, where Gopher and the hypermedia systems would have remained academic curiosities.

It was promiscuous about content. You could put anything on a web page. The hypermedia systems mostly had stronger opinions about what hypermedia was for, and stronger structural commitments — links between propositions, links between argument structures, links between annotations and source. The web treated content as opaque. This was a real loss in the hypermedia sense; it was also, in retrospect, a precondition for adoption. The web did not care what you were saying. It only required that you say it in HTML.

The honest accounting

The chapters that follow do not pretend the web won by accident or by malign luck. The web won because it picked a set of trade-offs that turned out to be correct for the scale it was going to need to reach. The cost of those trade-offs is the subject of the rest of this book, but the trade-offs themselves were not foolish. The people who made them — Berners-Lee at CERN, Andreessen and Bina at NCSA, the early IETF working groups — were not unaware that they were trading away features the competing systems had. They were aware. They made the trade anyway because they correctly understood that the systems they were building had to be lighter, more permissive, and less coordinated than the alternatives if they were going to scale across a decentralized network of millions of independent operators.

But “won” still implies losers. The systems in Parts II and III lost things they were specifically designed to do well. Linking, in the rich sense of two-way addressable persistent connection between named pieces of writing, lost. Authorship, in the sense that the system’s job is to make a reader into a writer, lost. Federation, in the sense that the unit of community is a peer rather than a tenant, lost. Hierarchy, in the sense that information has a place and you find it by following the structure, lost. Search-as-peer-service lost. Stack-based interactive media as a popular form lost. Literary nonlinear writing as a recognized form lost.

Each of those losses is the subject of a chapter. Each is real. Each happened because the web took a different set of trade-offs and the world chose the web.

This is the frame for everything that follows. The web won. It is the right verb because there was a contest, and the things on the other side of the contest were not vapor — they were systems that worked, that had users, that proposed coherent answers, and that, in many specific ways, did things better than what replaced them. Naming what those things were, and what they did, and why they lost, is the work of the next twenty-four chapters.

The contest had a starting point. To see it clearly we have to go back to 1945, to an essay in The Atlantic, written by an engineer who had run American science through the Second World War and was thinking, in the months after the war ended, about what was going to happen to the documents.

What hypermedia was supposed to be — Bush, the Memex, and the founding claim

The founding document of hypermedia is an essay published in July 1945, three months before the war it was a response to had formally ended. The essay was Vannevar Bush’s “As We May Think,” and it appeared in The Atlantic Monthly under a title supplied by the editors that gave no hint of what it contained. Bush did not invent the word “hypermedia.” Ted Nelson would coin “hypertext” eighteen years later, in 1963. The Atlantic essay does not propose a computer; it proposes a desk. But every working hypermedia system that has existed since — Xanadu, NLS, HyperCard, NoteCards, Intermedia, Storyspace, Roam, every wiki, and the web — has cited Bush as the source of its founding claim. The claim was that the way human beings move through ideas is associative rather than hierarchical, that the machines we use for thinking should match the way we think, and that information becomes useful only when it can be linked to other information by the person who reads it. This chapter is about what Bush actually said, what he did not say, and how the essay landed in the men who built the systems that followed.

Who Bush was, and why anyone listened

Vannevar Bush was, by the summer of 1945, one of the most powerful figures in American science. He had been Dean of Engineering at MIT, then Vice President of MIT, then president of the Carnegie Institution in Washington. In 1940 he had persuaded Franklin Roosevelt to create the National Defense Research Committee, and in 1941 he had become Director of the Office of Scientific Research and Development, the agency that ran the American war effort in science and engineering. The Manhattan Project ran under Bush’s general oversight. The proximity fuze, radar at MIT’s Rad Lab, penicillin’s mass production, the first analog computers used in ballistics — these came out of organizations Bush either ran or had set up. When the war ended he was about to deliver a report to Roosevelt, Science, the Endless Frontier, that would propose the structure of postwar American science and lead, three years later, to the National Science Foundation.

“As We May Think” was not a side project. It was Bush thinking about what the scientists he had spent five years organizing were going to do after they stopped building weapons. He had a specific worry. The volume of scientific publication was growing past the point where any human could keep up with the literature of their field. Cross-disciplinary work, which the war had shown was where the breakthroughs came from, was made hopeless by the impossibility of reading across multiple specialties. The bibliographic infrastructure — card catalogs, indices, abstracts — was an accumulated mass of nineteenth-century technology that no longer fit the volume of twentieth-century knowledge. Bush thought this was the problem postwar science would have to solve before it could solve anything else. The essay is his answer.

The essay was first read by scientists, but it spread fast. Life magazine published an illustrated abridgment on September 10, 1945, with drawings by Alfred D. Crimi that visualized the device Bush had described. The Life version reached an audience orders of magnitude larger than The Atlantic’s, and it is the version that several of the people who later built hypermedia systems first encountered. Bush had a national platform. The essay was treated, in 1945, as a serious proposal from a serious figure. It is worth keeping this in mind, because the essay is sometimes presented now as a visionary speculation by a single thinker. It was that, but it was also a policy document by the man who had run American science, and it was read that way.

The Memex

The device Bush described he called the Memex. The name combined “memory” and “extender,” and was Bush’s coinage. The Memex was a desk. The desk had two slanted translucent screens at the user’s working height. Behind the screens was a microfilm storage system that could hold, in Bush’s estimate, what would now be called millions of pages. A keyboard let the user enter commands. A set of levers and pedals controlled the projection of microfilm pages onto the screens. A dry photography process let the user take notes that were merged back into the same microfilm store. The Memex was, in short, a workstation, designed before the word existed for a kind of work nobody had yet done.

Bush had not invented the Memex out of nothing. He had spent the 1930s working on what he called the Rapid Selector, a microfilm system that used photoelectric scanning to retrieve documents indexed by binary codes punched into the film. The Rapid Selector was a real machine. Versions of it had been built; one was used during the war for cryptographic indexing. The Memex was the Rapid Selector extended into a model of how a person might actually use such a machine for sustained intellectual work. The microfilm storage and the binary indexing were extrapolations of technology Bush had already built. The two screens, the dry photography, and the pedal-and-lever interface were extrapolations of contemporary office equipment. None of this was fantasy in the science-fictional sense. It was an engineering proposal, expressed at the level of mechanism, by an engineer who had been involved in building related machines for a decade.

Bush did not propose to build the Memex. He proposed it as a thing that could be built and that ought to be built. The essay’s claim is not “I have built this” but “this is what the next generation of scientists’ equipment should look like, and here are the reasons why.”

The reasons why — associative indexing

The reasons were specific. The bibliographic infrastructure Bush wanted to replace was hierarchical: a document had a place in a classification, a subject was filed under a heading, and to find a document you walked the hierarchy. This worked when the hierarchy fit the structure of human knowledge. It stopped working when the structure of human knowledge stopped being hierarchical, which Bush argued had already happened. The breakthroughs in science were being made at the joints between fields, and the bibliographic infrastructure had no good way to register joints. A paper on the structure of hemoglobin and a paper on cryptographic codebreaking might have a method in common — a kind of statistical inference, say — but the cataloging system would file them under different headings and the person who needed to see them together would have to know in advance that they were together.

Bush proposed that the right structure was associative rather than hierarchical. The human mind, he argued, works by association: one thought leads to another through a connection the thinker recognizes, not through a connection the cataloger has pre-registered. A machine designed to support human thinking should support that mode of operation directly. The Memex did so by letting the user create what Bush called “trails.” A trail was a sequence of documents that the user had linked together by their own act of linking. Once two documents had been put on a trail, a button on the Memex took you from one to the other in either direction. Multiple trails could pass through the same document. Trails could be named, saved, recalled, and — this is the crucial step — given to other people.

The trail is the founding object of hypermedia. It is not the document; it is the relation between documents, registered by a reader’s act of registering it. The Memex’s value was not the documents it stored — those were just microfilm — but the structure the user accumulated on top of them. Bush understood that this structure was the thing of value. He proposed that a scientist’s Memex, over the course of their career, would accumulate trails that constituted a record of how they had thought. The trails could be inherited. A senior scholar’s trails through the literature would be a kind of intellectual capital, transmissible to students and successors, more useful in many ways than the publications themselves because they would show not just what the scholar had concluded but how they had connected the conclusions to other people’s work.

This is the founding claim. It has two parts. The first is that the unit of intellectual value is the link, not the document. The second is that the production of links — the trail-making — is itself a creative act, by an author, that other people will want to read.

The trail-maker as a profession

Bush did not stop at saying that scientists would make trails for themselves. He proposed, explicitly, that a new profession would arise. He called its practitioners “trail blazers.” A trail blazer would be a person who made trails through the literature on behalf of others — who took a topic and built, in their own Memex, a structured path through what had been written on it, and then made that path available to anyone else who needed an entry into the topic. This was not librarianship in the existing sense. The librarian’s job was to file documents in a place where they could be found. The trail blazer’s job was to make sense of how documents related, in a form readers could traverse.

It is worth pausing on what this proposes. Bush was suggesting that the production of structured paths through other people’s writing would be a paying job, that the resulting paths would be objects in their own right, that they would be read in the same sense that articles are read, and that the trail blazer would be an author of the trail in the same sense that the article writers were authors of their articles. The structure was the work. The information was raw material.

There is no profession on the web that corresponds to this. The closest analogues are the curator of a personal blog who links extensively into a domain, the author of a long Wikipedia article whose footnotes are themselves a kind of trail, and the person who maintains a research bibliography in some specialty. None of these are paying professions at any scale. The link as a primary object of value, traded and consumed in the way the article is, did not survive into the world the web built. There are reasons for this and the chapters on the web’s technical decisions will treat them. Here it is enough to note that Bush’s proposal contained a labor market and the web’s world does not.

What the essay did not say

Several things commonly attributed to Bush are not in “As We May Think.”

Bush did not propose digital storage. The Memex was microfilm. The choice was not incidental; Bush had spent a decade on microfilm-based retrieval and considered it the appropriate storage technology for the scale and stability of scientific literature. A digital Memex was not imaginable from where he was sitting in 1945, and he did not imagine one.

Bush did not propose networking. The Memex was a personal workstation. The trails were transferable between Memexes — Bush described this — but the transfer was physical, by sharing microfilm. There is no proposal in the essay for a connected system of Memexes communicating over wires. The networked extension of the Memex idea was supplied later, by Engelbart and Nelson, and required them to combine Bush’s proposal with the very different proposal of packet-switched communication.

Bush did not propose a computer in anything like the modern sense. The Memex’s operations were mechanical and photographic. He did discuss, in the same essay, the possibility of more powerful computing machinery — he was aware of the calculators that had been built during the war — but the Memex itself was not described as a computer. It was an information-retrieval device.

Bush did not propose direct two-way linking in the modern hypertext sense. The trails were sequences; you walked them in order. Branching trails are described but the system is closer to a linear path with named entry and exit points than to the dense web of bidirectional citations that Xanadu would later propose. The richness Nelson would put into “hypertext” was, in Bush, present in seed form but not in the elaborated form.

Bush did not propose the elimination of hierarchy. The Memex coexisted, in his description, with the existing hierarchical bibliographic infrastructure. Trails were a supplement to classification, not a replacement for it. The opposition between hierarchy and association that became the founding tension in the hypermedia literature is something later writers read back into Bush; the essay itself is ecumenical.

These are not faults of the essay. They are limits of its proposal, and they matter because the next forty years of hypermedia work consisted, in large part, of extending Bush’s proposal in each of these directions — into digital storage, into networking, into computation, into richer link structures, into a serious account of how associative structure might displace hierarchical organization. Each extension was a step away from Bush and toward something more ambitious. Each was also a step toward systems that turned out to be harder to build than their proposers thought.

How the essay landed

The essay was read by, among others, two men who would do more than anyone else to turn its proposal into working machinery.

Douglas Engelbart read either The Atlantic version or, more likely, the Life abridgment in late 1945. He was a Navy radar technician stationed in the Philippines, waiting for redeployment, and the story he told later was that he found the issue in a Red Cross library on Leyte and was struck by the Memex’s claim that machines could be built to support thinking rather than merely to compute. The exact issue and exact location have been told differently in different interviews, but the substance is consistent: Engelbart, in his early twenties, read Bush, took the proposal as a charge, and over the next two decades built the system — NLS, treated in chapter six — that was the first working version of what Bush had imagined.

Ted Nelson read Bush later, as a graduate student. By Nelson’s own account in Literary Machines and elsewhere, the encounter with “As We May Think” was formative. He was already thinking about nonlinear writing as a literary form; Bush gave him the engineering vocabulary to think about it as a system. The word “hypertext,” coined by Nelson in 1963 and first published in 1965, is an extension of Bush’s trail in the direction of writing as such. Where Bush imagined the trail-maker as a kind of trained scholar, Nelson imagined the hypertext as the natural form of writing itself, with every author producing nonlinear documents and every reader navigating them through links the author had built and links the reader chose.

The hypermedia academics at Brown — Andries van Dam, Nicole Yankelovich, Norman Meyrowitz — cited Bush as the origin of their tradition, and built systems (HES, FRESS, Intermedia) that were closer to Bush’s specific proposal in their treatment of trails as named, navigable, transmissible objects. So did the team at Xerox PARC who built NoteCards. So did the literary hypertext community. Each system extended Bush in different directions, but each acknowledged the debt, and each could be seen as one possible answer to the question Bush had raised.

The web, for what it is worth, also cites Bush. Tim Berners-Lee’s original 1989 CERN proposal opens with a discussion of the difficulty of cross-referencing information across an organization and notes Bush’s earlier work in the lineage of the problem. The lineage is acknowledged. The proposal is, however, much less than Bush’s. Berners-Lee’s web does not have trails. It does not have named navigable sequences. It does not have the proposition that the link is a first-class object that an author produces and a reader consumes. It has documents and one-way pointers between them, and the pointers are not registered with the destinations and do not persist if the destination moves. The web is, by Bush’s standards, a half-implementation of the founding proposal — the documents are there but the trails are not.

The shape of the surviving claim

What survives, across every hypermedia system from 1945 to the present, is the proposition that the structure connecting documents is itself a document, that this meta-document is the thing of intellectual value, and that machines should be designed to make the production and consumption of that meta-document easy. The systems differed enormously in how they realized this proposition. Bush’s trails were linear and microfilm-based; Engelbart’s were structured and outline-based; Nelson’s were branching and parallel; the academic hypermedia systems made them composable with formal argument structures; HyperCard made them clickable buttons on stacked cards; the literary hypertext canon turned them into the substance of narrative. But the claim is the same. Whatever the link is, it matters more than the documents.

The web’s version of the claim is degenerate. A web link is a one-way pointer from one document to another, registered nowhere, persisted by nothing except convention, and produced as a side effect of writing the source document. It has no name. It cannot be inherited. It cannot be reviewed independently of the source. It can be broken silently by anyone other than the author who made it. It carries no semantics — there is no way to say “this is a citation,” “this is a refutation,” “this is a quotation.” There is, in the bare web, no analogue of Bush’s trail. There is an <a href> tag.

This loss is the central technical loss the book is about, and it is the source of everything else. The application has eaten the document; the document was supposed to eat the link; the link was supposed to be the author’s primary contribution to the shared infrastructure of thought. None of that happened. We have applications now, and the documents inside them are increasingly disposable, and the links between the documents — when there are any — are managed by the applications rather than by the authors. This is not what Bush proposed. It is not what any of the systems descended from Bush proposed. It is what we have, and the rest of this book is an attempt to understand how we got here.

The next chapter turns from hypermedia to the network underneath it. The founding claim of the internet is older than the founding claim of hypermedia, and it is differently structured. Where Bush imagined a single workstation with extraordinary capacity, the people who built the internet imagined a federated mesh of peers, each independent, each contributing to a shared substrate that no one owned. That vision, like Bush’s, was held in clear view for two decades before it began to be eroded. Understanding it is the second half of the frame.

What the internet was supposed to be — the federated peer-to-peer original vision

The hypermedia tradition treated above is one side of the frame. The other side is the internet itself, considered apart from the web that runs on top of it. The two are distinct in ways that have been blurred almost beyond recovery. The web is an application; the internet is the substrate. The web was proposed in 1989, became dominant by 1995, and is now thirty-six years old. The internet, depending on where you place the origin, is between fifty and sixty years old, and was for the first two decades of its life a coherent proposal about how networked machines should relate to one another. The proposal was federated and peer-to-peer. Every node was an equal. The work of the network was carried at the edges; the middle was deliberately stupid. There was no central operator and no central registry of services. This was not an accident. It was a design choice, made by specific people for specific reasons, and held in clear view for long enough to become culture before the web arrived and rewrote the cultural assumption to “client-server.” This chapter is about the proposal as it was originally made.

The Cold War origin of resilience

The first published proposal for a packet-switched communications network was Paul Baran’s series of memoranda at RAND, drafted between 1960 and 1964 and published in 1964 as On Distributed Communications. Baran had been given a problem by the Air Force: design a communications system that could survive a nuclear first strike. The existing telephone network was hierarchical, with a small number of long-distance switching centers that aggregated traffic from local exchanges. A small number of nuclear weapons aimed at those switching centers could disable national communications. Baran’s response was a network of equal-status nodes connected by redundant links, in which messages were broken into pieces that found their own routes, hop by hop, from source to destination. The destruction of any single node forced the surviving pieces of the message to route around it. There was no center to destroy.

Baran called the technique “distributed adaptive message-block switching.” The phrase did not catch on. Three years later, Donald Davies, working at the National Physical Laboratory in Teddington, England, independently arrived at the same scheme and coined the term that did catch on: “packet switching.” Davies’ motivation was different from Baran’s. He was thinking about how to share an expensive computer among many users efficiently, not about nuclear survivability, and he proposed packet switching as a way to multiplex traffic onto a single transmission line without dedicating the line to any one conversation. The two motivations — resilience under attack and efficient sharing of expensive resources — produced the same architecture. A network of peers, each capable of forwarding packets, with no central authority and no privileged path.

When Lawrence Roberts began designing what became the ARPANET in 1966 and 1967 at the Advanced Research Projects Agency in the U.S. Department of Defense, he drew on both Baran’s and Davies’ work. The ARPANET’s first four nodes — UCLA, SRI, UC Santa Barbara, and the University of Utah — came online in late 1969. The first message attempt was sent from UCLA to SRI on October 29, 1969, by a graduate student named Charley Kline, working under Leonard Kleinrock. The system crashed after the letters “L” and “O” had been transmitted; the full word was supposed to be “LOGIN.” This is the founding story, and the founders enjoy telling it. The point worth keeping is what the architecture was. Four computers, in four cities, treated as equals. Any of them could send to any of them. None was the center.

The choice mattered. The competing architecture at the time was the centralized timesharing model, in which dumb terminals connected to a single mainframe and the mainframe did everything. The ARPANET could have been built that way; many corporate networks of the same era were. The choice to make the network a mesh of peers rather than a hub of clients was deliberate and was justified by specific arguments — survivability, efficient use of long-distance lines, the ability of any researcher to log into any machine — that we have largely forgotten the force of because the choice has since been so thoroughly undone.

The end-to-end principle

The peer-to-peer architecture acquired, in 1981, a written justification that would shape three decades of internet engineering. The paper was “End-to-End Arguments in System Design,” by Jerome Saltzer, David Reed, and David Clark, all then at MIT. The argument was technical but its consequences were political. Saltzer, Reed, and Clark observed that many functions a network might perform — reliable delivery, encryption, deduplication, ordering — can only be done correctly at the endpoints of a communication, because only the endpoints know what counts as a correct outcome. If the network tries to do them in the middle, it either does them imperfectly (and the endpoints have to redo them anyway) or it does them so perfectly that it has to know everything the endpoints know, which makes the middle of the network as complicated as the endpoints. Therefore, the paper argued, functions that could be implemented at the endpoints should be implemented at the endpoints, and the middle of the network should be kept as simple as possible.

The technical consequence was that the internet’s middle would be a dumb packet-forwarding fabric. The intelligence would live at the edges, in the operating systems and applications on each host. The political consequence, which Saltzer and his coauthors did not fully spell out but which their successors did, was that a dumb network is a network that cannot discriminate. A router that knows nothing about what it is forwarding cannot favor one kind of traffic over another, cannot inspect content, cannot bill differently for different services, cannot be a chokepoint for control. The end-to-end principle was a technical argument that doubled as a charter for a network in which the operator of the network had no business meddling with what passed through it.

The end-to-end principle made certain things easy and certain other things difficult. It made it easy to add new applications: anyone could write a new protocol that used the network in a new way, and the network did not have to be modified. The arrival of the web in 1991 was possible precisely because the people running the network did not need to be consulted. It made it difficult to provide quality-of-service guarantees, because the network was not allowed to know whether a packet contained voice or email or a file transfer. It made it difficult to charge for individual applications, because the network was not allowed to identify them. It made it difficult to block specific kinds of content, for the same reason. These difficulties were largely seen, at the time, as features.

Smart edges, federated control

What the end-to-end principle implied for the social organization of the internet was that there was no central operator. The ARPANET had been run by ARPA but ARPA’s role was funding and coordination; the actual machines were operated by the universities and companies that owned them. When the ARPANET split into MILNET (for the Department of Defense) and the civilian internet in 1983, and when the National Science Foundation built NSFNET as the new backbone between 1985 and 1995, no single entity controlled the network. Backbones were operated by separate organizations; regional networks by separate organizations; campus networks by separate organizations. Each peered with the others through bilateral agreements. The internet was, structurally, a federation of independently administered networks that had agreed to exchange traffic on common terms.

This federation was visible at every level of the system. Email addresses had two parts: the user and the host. The host was reached through DNS, the Domain Name System, designed by Paul Mockapetris in 1983 and 1984 and rolled out in the mid-1980s. DNS was itself federated: the root servers were a small set of machines operated by different organizations, and below them every domain owner ran their own name servers for their own zone. There was no central registry of all names, only a hierarchical delegation in which each domain owner was responsible for the names below them. When you looked up a name, you walked the delegation. This is still how it works today, mostly, although the political economy around the root has become much heavier than the technical design intended.

Routing was federated. The Border Gateway Protocol, finalized in 1989, lets independent networks announce which addresses they can reach and lets other networks decide whether to believe the announcements. There is no central routing table. Each network operator makes their own decisions and the global table is the emergent product of all those decisions. This works astonishingly well and has been the substrate for most of the internet’s growth.

Governance was federated. The Internet Engineering Task Force, formed in 1986, made standards by a process David Clark described in 1992 as “rough consensus and running code.” Anyone could attend a working group meeting. Anyone could submit a draft. Drafts that worked, in the sense that multiple independent implementations could interoperate, were promoted to standards. There was no formal membership. The Internet Society was founded in 1992 as an institutional home for IETF activities, but the IETF itself remained, and remains, an open process. Compare with the telecommunications standards bodies of the same era, which were formal intergovernmental organizations with national delegations and weighted voting. The IETF was, by design, not that. The internet’s standards were made by the people building the internet, in working groups that admitted anyone willing to show up and do the work.

Numbers were federated. The Internet Assigned Numbers Authority (IANA), run for most of its history by Jon Postel personally out of his office at USC’s Information Sciences Institute, allocated address blocks and protocol numbers. Postel’s authority was technical and personal; he had been editor of the Request for Comments series since the late 1960s and was trusted to do the right thing. The institutional structures that succeeded him — ICANN, founded in 1998 — formalized what had been informal, with mixed results that are still being debated. But for the first quarter-century of the internet’s existence, the allocation of names and numbers was done by a federation of mostly volunteers, working in the open, with the rough consent of the people who used the resources.

The applications that ran on this thing

Before the web, the internet had applications. They were not built around a single uniform interface; each had its own protocol and its own conventions. They are worth listing because the diversity of the pre-web application landscape is one of the things the web’s dominance has obscured.

Email was the first and remained the largest. RFC 821, the SMTP standard, was published by Jon Postel in August 1982, codifying practices that had been in use on the ARPANET since the early 1970s. Mail was federated end-to-end: any host running an SMTP server could send mail to any other host running an SMTP server. There were no central servers, no obligatory intermediaries, no required directory of users. By the mid-1980s, email had become the dominant traffic on the internet and the dominant medium for technical and academic correspondence. It still works, almost exactly as Postel specified it, and the chapter on email’s near-miss treats what has happened to it since.

File Transfer Protocol, RFC 959 in 1985 (consolidating much older drafts), let any user on any host transfer files to and from any other host. Anonymous FTP — using “anonymous” as the username and an email address as the password — let public archives be set up at any institution that wanted to publish files. Universities ran anonymous FTP archives. Companies ran them. Hobbyists ran them on machines in their basements. The total volume of material available through anonymous FTP in 1993 was substantial — the major archives like wuarchive at Washington University and ftp.uu.net at UUNET held tens of gigabytes each, which was a great deal at the time — and there was no central catalog. You had to know where to look, or use Archie, a search tool released in 1990 by Alan Emtage at McGill that indexed anonymous FTP sites.

Usenet, treated in its own chapter, was the federated discussion system. NNTP, the Network News Transfer Protocol, was standardized in RFC 977 in 1986. By 1991 Usenet carried thousands of newsgroups and was the substrate of most online community life.

Telnet, RFC 854 in 1983, let users log into remote machines as if they were local. The Internet Relay Chat protocol, by Jarkko Oikarinen in 1988, let users participate in real-time text conversations across federated servers. Gopher, treated in its own chapter, was released in 1991. WAIS, also treated in its own chapter, was released in 1991. The MUDs and MOOs — text-based virtual worlds — accumulated their own protocols and communities. Each application had its own client. Each had its own conventions. Each was federated end-to-end on top of the same TCP/IP substrate.

The thing to take from this list is that the pre-web internet was not impoverished. It was, by the early 1990s, a fully populated services landscape with several million users across thousands of institutions, with mature governance, with rich application diversity, and with a culture of operation that took the federated peer model as a given. The web did not arrive into an empty room because the internet was empty; the internet was the room.

The structural promises

What was structurally available, before 1993, on the open internet, that has since become difficult or impossible to find:

Anyone with a static IP could run a server. There were no asymmetric residential connections in the modern sense. If your machine was on the internet, it could accept incoming connections, and so it could be a peer to any other machine. The split between “users” who only consume and “servers” that produce, which now defines almost every consumer’s relationship to the network, did not exist as a structural property. It came in with consumer broadband in the late 1990s, when ISPs began offering asymmetric DSL and cable modem service with the upload bandwidth deliberately constrained, and when they began prohibiting servers in terms of service.

There was no platform layer between you and the network. If you wrote an application that used TCP/IP, it could reach any other application on the internet that was willing to talk to it. There was no Apple, Google, Facebook, or AWS standing between your packets and the recipient. The intermediation that defines the modern web — that almost every commercially significant exchange of bits passes through one of a small number of platform companies’ infrastructures — was specifically not a property of the original design. It was added on, over decades, by a combination of commercial incentives and technical accidents that the chapters in Part IV trace.

Naming was personal or institutional. Email addresses were yours or your institution’s; FTP and Usenet handles were under your control; Gopher and WAIS resources were addressable by the running server, not by some platform’s permission. The migration of personal naming to platform-issued identities — your handle is on a site, owned by the site, and dies if the site dies — was not a property of the substrate. The substrate let you use your own name on your own machine. You can still do this, formally; almost nobody does.

The cost of participating in the network was, for most users, the cost of being at an institution that was on the network. For users with their own dial-up accounts, it was the price of an account at one of the small ISPs that proliferated in the early 1990s, which was a real expense but not a structural barrier. There were no gatekeepers between a user with an account and the rest of the internet. This was the explicit consequence of end-to-end design. The user’s host could speak any protocol it wanted to any other host. The ISP was a transit, not a platform.

These structural promises were not equally well kept by every part of the system. The pre-web internet had its own pathologies — homogeneous and overwhelmingly American, mostly male, mostly white, mostly inside academia or the defense establishment, with a culture that was open in some senses and exclusionary in others. The web’s broader social reach was a real and significant gain. But the structural openness was real, and it was the substrate the web ran on for the first half-decade of its life, and the slow loss of that structural openness across the 2000s and 2010s is the substance of the consolidation chapters in Part IV.

What the web kept and what the web did not keep

The web, considered as an application of the internet, kept some of the original peer-to-peer vision and discarded much of it. It kept the protocol-level openness: HTTP runs over TCP, TCP runs over IP, and the network does not need to know what the bits mean. It kept the standards process: HTTP was standardized through the IETF, HTML through the W3C, and both processes are descendants of the rough-consensus-and-running-code tradition. It kept the addressing model, at least at the URL layer: a URL points to a host and a path, and the host is reached through DNS, which is still federated.

What the web did not keep — and this is the slow erosion that the rest of the book is about — was the practical equality of nodes. The web is technically peer-to-peer; everybody could in principle run a web server. In practice, the asymmetry between client and server, between consumer and provider, between the people reading the web and the people publishing it, became sharper and sharper as the web grew. Consumer connections were asymmetric. Consumer machines were behind NAT. Consumer operating systems made running a server difficult. Consumer ISPs forbade running servers in their terms of service. The mass-market reality of the web was a mass-market reality of clients. The publishers were a different and smaller group, and the platforms in the middle were a still smaller group, and the structure that emerged was the opposite of the structure the internet had originally proposed.

This is not, again, a fault of the web’s designers. Berners-Lee, Andreessen, and the people building browsers were not the people building the cable modems. The structural collapse from peer to client happened in the infrastructure layer, and the web inherited the consequences. But the consequences are real. The internet was originally a federation of peers. The web on top of it became, by accident and by design, a hierarchy of clients with platforms in the middle. The recovery work in Part V — local-first, ActivityPub, the IndieWeb, the static renaissance — is in large part work to reassert at the application layer what the infrastructure has stopped offering at the transport layer.

The two halves of the frame are now in place. Hypermedia was supposed to be an extension of authorship: machines that helped people make and read structured documents, with the structure itself being the primary intellectual product. The internet was supposed to be a federation of peers: a substrate in which anyone could publish, anyone could connect, and no one had to ask permission. The web inherited both visions, kept fragments of each, and was carried by its trade-offs to a position of dominance from which the original visions are now hard to see. The next part begins with the most ambitious and least successful of the hypermedia proposals, which was also the oldest, and which has been in development almost as long as the internet itself.

Xanadu and the rejected ideas

The story of Xanadu is the story most people associate, when they think about it at all, with hypermedia’s failure. It is the example reached for when somebody wants to argue that visionary computing projects produce visionary documents and not visionary software. Wired magazine ran a cover story in June 1995 called “The Curse of Xanadu,” by Gary Wolf, that is the most-cited piece of writing on the project and that frames it as the longest-running vaporware in history. The framing has stuck. It is also, as a way of understanding what Xanadu is and was, almost entirely wrong. Xanadu shipped working code more than once. Some of its ideas have been implemented elsewhere. Some have not, and the parts that have not are not vaporware — they are unsolved engineering problems that several systems have since attempted with mixed results. Ted Nelson has been working on the project, in various forms, for sixty-five years. The chapter below is about what he was actually proposing, why what he was proposing turned out to be hard, what the web specifically chose not to take from him, and what the present state of the recovered ideas looks like.

Nelson, and what Xanadu was supposed to do

Theodor Holm Nelson was born in 1937, the son of two figures in mid-century American entertainment (his mother Celeste Holm an Oscar-winning actress, his father Ralph Nelson a television and film director). He did graduate work at Harvard in sociology, where in 1960 he took a computer course and began thinking about how the structure of computation might let a writer escape the linear constraints of the printed page. The project he named Xanadu, after Coleridge’s Kubla Khan, dates from that moment. The word “hypertext” comes a few years later. Nelson coined it in 1963 and first published it in print in 1965 in a paper titled “A File Structure for the Complex, the Changing, and the Indeterminate,” presented at the Association for Computing Machinery’s national conference. “Hypermedia” followed shortly after. Both terms were Nelson’s, and both spread quickly into the small community that was beginning to take the problem seriously.

Nelson’s proposal — held with remarkable consistency across six decades of writing, interviews, and demonstrations — was that the natural form of writing is nonlinear and that the natural form of reading is the assembly of quotations from other writing into new writing. He treated the linear sequence of pages in a printed book as a historical accident imposed by the constraints of bound paper, not as an essential property of writing. A computer system, freed from those constraints, should let an author produce documents that branched, that referenced other documents directly rather than through copy-pasted quotation, that maintained the connection between a quoted passage and its source forever, and that let a reader move between the original and the citing context with a single gesture. The system should also, Nelson insisted, let the original authors of quoted material receive a small payment each time their words were used. The economics and the engineering were not separable in his proposal; the rights model and the technical model were features of the same system.

The project’s published list of features — Nelson has formalized it variously over the years, most famously as a “17-rule” specification in the 1980s — contains items that vary in their technical strangeness from the obvious to the unprecedented. Some are now familiar: that the system should be open to any user, that any user should be able to publish, that documents should be addressable by reference. Others are now alien: that every byte of every document is permanently addressable for the life of the system; that quoted passages should always be quoted by reference and never by copy; that the original author should always be findable from a quotation; that revisions of a document should not destroy previous versions but live alongside them; that links between documents should be visible from both ends. The list runs to seventeen items in the version most often cited and to more or fewer in other versions. The number is not the point. The point is that Nelson proposed a coherent set of properties that together constitute a serious answer to the question “what should a hypermedia system do,” and that the answer is structurally different from the answer the web gave.

Transclusion and the rights model

The single most important Xanadu idea is transclusion. The word is Nelson’s coinage, and it names a precise operation: the inclusion of a passage from one document inside another document by reference, in such a way that the passage is not copied. The included passage is shown, in the citing document, but it is the original passage, retrieved from the source. If the source changes — though in Xanadu the source does not change in the destructive sense, because version permanence keeps the old version available — the citation can be made to follow the change or to remain pinned. The included passage carries its origin with it. Click on a transcluded paragraph and you are taken to the document it was quoted from, in the place it appeared. The reverse pointer is also live: in the source document, you can see which other documents have transcluded which of its passages and follow the citations back.

Transclusion is not difficult to describe and is not impossible to implement. It is implemented, in approximate forms, in several systems alive today. What Xanadu proposed that no major working system has implemented is universal transclusion: the rule that every quotation in the system, of every kind, is a transclusion, and that copying-by-value is something the system does not do. This is the engineering claim that makes Xanadu both interesting and hard. If every quotation is by reference, then the original document must remain available forever, at a stable address, for as long as any citing document survives. If documents are written by independent authors on independent machines, the system must reconcile the durability requirement with the autonomy of the authors. Authors must not be able to break other people’s documents by editing or deleting their own. The system must therefore maintain version permanence: old versions of edited documents are preserved alongside new versions, and citations point to specific versions, not to “the current version” in a mutable sense.

Universal transclusion plus version permanence yields the basis of the rights model. Because every quotation is a reference and not a copy, the system always knows which authors are being read whenever any document is read. A reader pulling up a derivative document is, automatically, pulling up the original work of every author whose words are transcluded into it. Nelson proposed that the system bill the reader (a small amount, perhaps fractions of a cent) for each access, and divide the payment among the authors whose work was being read in proportion to how much of their work was being read. This was not micropayments in the recent sense of subscription substitutes; it was a built-in royalty system that ran whenever anyone read anything. The rights model was not bolted onto the technical model. It was the same model, viewed differently.

It is worth being honest about what is and is not original here. The idea of paying authors per use of their work was old; it underlay the music licensing system that ASCAP had been administering since 1914 and the various photocopying-rights organizations that emerged in the postwar period. What was original in Nelson’s proposal was the integration of the rights system with the storage system, such that the bookkeeping was a side effect of the storage, not a separate accounting. This integration is what universal transclusion buys you. It is also what makes the system hard to ship, because you have to get the storage and the rights and the version control and the addressing all right at the same time before you can show anyone how it would work.

Tumblers and the addressing scheme

The other Xanadu idea that has not made it into the web is the addressing scheme that Nelson called “tumblers.” A tumbler is an address that identifies, with arbitrary precision, a specific span of bytes inside a specific version of a specific document by a specific author. The address is hierarchical and infinite-precision: a publisher number, a user number, a document number, a version number, a byte range within the version. Tumblers compose: you can point to a passage inside a transclusion inside a document inside a publisher’s catalog. Any span at any level of nesting has a unique, stable address.

The web’s addressing scheme — the URL — addresses documents, not spans within documents. Recent additions (fragment identifiers, the text-fragment extension, “scroll to text fragment”) have started to add span-level addressing on top of URLs, but the addresses are second-class citizens: they are advisory hints to the rendering layer, not first-class objects the system tracks. In Xanadu the tumbler is the address. There is no separate notion of a document URL with optional fragment; every address is span-precise. This makes citations precise in a way web citations are not, and it makes the underlying database structurally aware of which parts of which documents are linked to which other parts.

Tumblers are also, like much of Xanadu, structurally expensive. To support them at the scale Nelson proposed, the system needs a global address space, allocated by some authority, with the structural properties that subordinate addresses can be issued by subordinate authorities. Nelson’s design for this — a hierarchical allocation under a global root, with each publisher controlling their own range — is technically similar in shape to DNS, but with much heavier semantic content per address. It would have worked at small scale. Whether it could have worked at internet scale is a question that has never been answered, because Xanadu has never operated at internet scale.

The institutional history

The hard part of writing about Xanadu is being honest about its institutional history, because the institutional history is mostly the story of a project that did not ship in any of its many phases. Nelson worked on the system, with various small teams, through the 1960s and 1970s, supported by a series of academic and consulting positions. The major institutional moment came in 1988, when John Walker, the founder of Autodesk, acquired the Xanadu Operating Company as a subsidiary of Autodesk and put serious money behind it. Walker had read Computer Lib/Dream Machines, Nelson’s self-published 1974 manifesto, and believed that Autodesk’s success could subsidize the completion of the system. The Autodesk Xanadu team grew to several dozen engineers and built, over four years, a series of implementations of pieces of the system: a server, addressing schemes, a transclusion engine, several front-end demos.

What the team did not produce was a coherent product. The scope kept expanding. The implementation kept being rewritten as parts of the design were rethought. Autodesk’s commercial position deteriorated and Walker stepped down from the CEO role in 1992. The new management did not share Walker’s enthusiasm for the project and spun the Xanadu Operating Company off, with little money and no clear path forward. The 1995 Wired piece by Gary Wolf was written into this period — the Autodesk relationship had ended, the spinoff was failing, and Wolf’s framing of the project as a thirty-five-year failure to ship became the public framing.

This framing is not exactly false. Xanadu, the full system Nelson had been describing since the 1960s, did not ship in 1995 and has not shipped since. What is missing from the framing is that pieces of the system have shipped. ZigZag, a multi-dimensional data structure that Nelson worked on through the 1990s, was released in 1999 and is documented and downloadable. OpenXanadu, a 2014 web-based demonstration, shows transclusion working in a browser. Various academic and amateur reimplementations exist. The system as a whole has not been built; specific subsystems have been built more than once.

It is also worth pointing out that the framing applies a standard — “did it ship a commercial product” — that comes from a different industry than the one Nelson was operating in. The systems in this book that did ship as commercial products mostly did so by drastically reducing scope and accepting compromises Nelson was unwilling to make. Whether that constitutes the right way to evaluate Xanadu depends on what you think the project’s goal was. If the goal was to ship a product, the project failed. If the goal was to articulate a coherent proposal for what hypermedia should be, the project succeeded, and the proposal has shaped sixty years of subsequent work even where the subsequent work did not credit it.

What the web specifically rejected

The web took some of Nelson’s vocabulary — “hypertext” is now web vocabulary, and “hyperlink” derives from “hypertext link” — and rejected almost all of his substantive proposals. The rejections are worth enumerating because each is a specific decision with consequences.

The web rejected two-way linking. Nelson had insisted that a link should be visible from both ends: the document being linked to should know which documents linked to it. The web’s HTTP and HTML link only forward. Tim Berners-Lee’s 1989 CERN proposal explicitly considered two-way linking and explicitly rejected it on the grounds that it would not scale — to make two-way links work, the destination document would have to be updated whenever a new link to it was created, which is impossible if the destination is owned by someone other than the linker. Nelson’s answer to this objection was that the link should not live in either document but in a third place, a central registry, which the system would consult to find all the links pointing into a given location. The web rejected this answer because a central registry is a central point of failure and a central point of control, and the web wanted neither. The cost of the rejection is that web links rot, that the relationship between a citing document and a cited one is invisible from the cited side, and that the citation network that links the web together is reconstructable only at enormous cost (this is what search engines spend their compute on, in part).

The web rejected version permanence. A web document is mutable. The publisher of a document can change it, replace it, or delete it, and the URL points to whatever the publisher has there now. There is no version history at the protocol level. The Internet Archive has, since 1996, attempted to retroactively provide version permanence by periodically saving copies of web pages, with mixed results. Nelson’s design had version permanence built in: a version, once published, was preserved, and citations always pointed to specific versions, not to mutable references. The cost of the web’s rejection of this property is the universal phenomenon of link rot, the inability to cite a web page with confidence that the reader will see what you saw, and the structural unreliability of the web as a substrate for serious citation.

The web rejected transclusion. HTML has IMG and IFRAME and various media inclusion elements, but they include resources from foreign servers as opaque blobs, not as part of a unified text-and-citation graph. There is no native way in HTML to quote a passage of another document by reference such that the original source is preserved and shown. You quote by copying. The cost is that citations on the web carry no live connection to their sources; that paraphrase and direct quotation are visually indistinguishable; and that the structural awareness of which documents quote which other documents is unavailable to the system. Recent extensions (text fragments, web annotations as a W3C standard since 2017) recover pieces of this, but in ad-hoc ways layered on top of an architecture that was specifically designed without it.

The web rejected the rights model. HTTP carries no notion of payment or authorship. The web’s economic model — when there is one — is advertising or subscription, both bolted on through external systems. Nelson’s proposal that the system itself should handle small-amount payments to authors as documents are read has never been implemented at scale. Various micropayment systems have tried (Flattr, Brave’s BAT, cryptocurrency tipping experiments); none has reached the scale where it changes the structure of online publishing. The cost is that the relationship between authorship and revenue has been mediated, online, by advertising platforms whose interests are not aligned with either authors or readers, and that the rights claim Nelson built into the system has had to be reconstructed, badly, by external institutions.

The web rejected the precise addressing of tumblers. URLs are document-level; fragment identifiers are advisory. The cost is that web citations cannot, generally, point to a specific passage; that the granularity of linking matches the granularity of pages rather than the granularity of arguments; and that the kind of fine-grained quotation Nelson treated as the default unit of intellectual work is harder on the web than on paper.

In each of these rejections, the web chose simplicity, scalability, and uncoordinated growth over a richer feature set that would have required coordination. The choices were defensible. They were also, in each case, choices, and they were made by people who knew the alternatives Nelson had proposed.

What is being recovered

Several pieces of Xanadu’s proposal have re-emerged in working systems, usually without the explicit acknowledgment.

Transclusion has returned, in narrow form, in several recent tools. Notion’s “synced blocks” provide an in-product transclusion: a block in one document can be a live reference to a block in another, and editing one updates the other. Roam Research, since 2019, has built its primary user experience around block references: every block in every page has an address, and a reference to a block displays the block’s current content in the citing context. Logseq and several other personal knowledge tools have followed Roam’s lead. These systems are smaller in scope than Xanadu — they are personal, not global — but the operational pattern matches what Nelson described. The chapter on personal knowledge tools (chapter 24) treats these recoveries.

Version permanence has returned in two distinct lineages. The first is content-addressable storage, descended from Git (2005) and now ubiquitous in software development. Git is not designed for hypertext, but its content model — every version of every file is identified by a hash, and the hash is the address — implements the underlying property Nelson had insisted on. The second lineage is the broader effort to use distributed content-addressable systems for general-purpose storage: IPFS, the InterPlanetary File System launched in 2014, makes content-addressing the primary addressing scheme. The web does not yet use these, except for narrow applications, but they exist and are reachable. The Internet Archive’s Wayback Machine, founded by Brewster Kahle in 1996, provides versioned snapshots of arbitrary web pages and has become an essential part of the web’s citation infrastructure, retrofitting version permanence onto the system the web did not build it into.

Two-way linking has been recovered, partially, by webmentions and backlinks. The webmention specification, a W3C recommendation since 2017, lets a citing page notify the cited page of the citation, and lets the cited page display a list of incoming references. This is much smaller than what Nelson proposed; webmentions are advisory and require both ends to implement them. But the property — that a page knows what links to it — is partially available, and has spread within the IndieWeb community. Wiki systems, going back to Ward Cunningham’s original WikiWikiWeb in 1995, have had backlinks since the beginning; the property is native to wikis. Roam’s backlinks, for personal knowledge graphs, do for individual notes what webmentions do for public pages.

The rights model has not been recovered at scale. Various attempts continue. None has yet produced a working system at the scale Nelson proposed.

The unified address space of tumblers has not been recovered. URLs plus fragments are what we have. There are research proposals to do better — robust anchor systems, hash-based content addressing combined with stable selectors — but no widely deployed system.

The verdict that should not be the verdict

Xanadu is treated, in the popular accounts, as a kind of monument to overreach. The verdict — that Nelson’s system was too ambitious to ship and that the web’s pragmatism won — is the verdict the industry has accepted. The verdict is half-right: the system was ambitious and did not ship, and the web’s pragmatism did win, and we are living in the world the pragmatism built. But the half that the verdict misses is that the things Xanadu was trying to do are the things that hypermedia is supposed to do. Two-way linking, version permanence, transclusion, precise addressing, an integrated rights model — these are not crank ideas. They are the rest of the feature set, the part of hypermedia we lost when we settled for the web’s reduced version. The recoveries chronicled in Part V are, in significant part, ad-hoc rediscoveries of features Nelson had specified by 1981 and demonstrated, in pieces, by 1990.

Nelson is now in his late eighties. He is still working on Xanadu. The system in its full form has not shipped and will not ship in his lifetime, and probably not at all. What survives is a vocabulary, a proposal, and a list of properties that any serious hypermedia system either has or has consciously chosen not to have. The web has consciously chosen not to have them. The chapter on the web’s technical decisions makes the case for why this was, in 1991, the right choice. The chapters in Part V make the case for why, in 2026, it is increasingly the wrong one, and why the alternatives Nelson sketched are being quietly reassembled in pieces.

The next chapter turns from the most ambitious of the hypermedia proposals to the most successful. HyperCard did almost nothing of what Nelson had specified. It did not have two-way links, it did not have transclusion, it did not have version permanence, it had no rights model, and its addressing scheme was a single linear stack. It shipped on five million Macintoshes, was used by millions of people for a decade, and produced a culture of end-user authorship that has not existed on any platform since. It is the case for shipping.

HyperCard and the lost end-user

HyperCard is the case that complicates everything. The argument of the last chapter — that Xanadu’s ambitions were the right ambitions, that the system that did not ship was articulating something real, that the web’s reduced feature set was a real loss — is an argument that has to reckon with HyperCard, because HyperCard was the hypermedia system that did ship. It shipped on every Macintosh sold between 1987 and 1992. It was used by millions of ordinary people to build things they would not have called software. It did almost nothing of what Nelson had specified. It had no two-way links, no transclusion, no version permanence, no rights model, no global address space. Its addressing scheme was a single linked list of cards inside a single file. And yet it produced a culture of end-user authorship that has not existed on any major computing platform since, and it is the example that anyone who wants to argue that hypermedia “could have been popular” has to point to first. This chapter is about what HyperCard actually was, what it made possible, what its decline cost the broader culture, and why nothing on the web has replaced it.

What HyperCard was

HyperCard was introduced by Apple at MacWorld in August 1987, the work of a small team led by Bill Atkinson, the principal author of MacPaint and one of the original Mac engineers. Atkinson had built QuickDraw, the graphics layer of the Macintosh, and had been thinking, after MacPaint shipped in 1984, about what a programming environment for ordinary users would look like. HyperCard was his answer. It bundled, in one application, three things that had previously required three different applications and considerable expertise to combine: a way to draw on the screen, a way to store and retrieve structured information, and a way to write small programs that linked drawings, information, and user input into interactive sequences. The bundling was the breakthrough. Each of the three things had existed in other forms. Putting them together in a single, integrated, free-with-the-machine application meant that the technical floor for making something interactive collapsed.

The data model was four levels deep. A stack was a file, the thing you opened and worked in. A stack contained cards. A card was a screen-sized rectangle that the user saw at any given time. Each card contained fields, which held text the user could enter or read, and buttons, which could be clicked. Cards also had backgrounds, which were templates shared by multiple cards in the same stack — the equivalent of a master slide in a presentation program. The whole system was layered: a button on a card was on top of the field on the card was on top of the background. The screen showed all of them composited.

Navigation was, structurally, very simple. The cards in a stack were in an order. You could go forward to the next card, back to the previous one, or — and this is the part that mattered — to any specific card that some button or script told you to go to. A button could be scripted to take the reader to any card in any stack. That capability, plus the universal availability of HyperCard on every Macintosh, made the stack a portable, executable, interactive document.

HyperTalk

The scripting language was HyperTalk, designed by Dan Winkler. HyperTalk is the unsung breakthrough of HyperCard. It was an English-like language in which the typical statement reads almost as a sentence. A button might contain the script:

on mouseUp
  go to card "Index"
  put "Welcome" into field "Title"
end mouseUp

This is, in HyperTalk, a complete program. The verb-object syntax is consistent: you put things into fields, you get things out of them, you go to cards, you play sounds, you show and hide objects. The grammar is forgiving of variations. The vocabulary is small. The language has variables, conditionals, loops, and the ability to define your own commands and functions — it is a real programming language — but its surface looks like English instructions, and its error messages are mostly comprehensible to non-programmers.

Many languages have been advertised as English-like. Most are not. HyperTalk actually was. The reason it worked is that the language designers accepted a hard trade-off: they made the language verbose, where most languages are terse, and they restricted what could be expressed to what could be expressed in this verbose style. A skilled programmer writing HyperTalk produces code that is several times longer than the equivalent in a conventional language. The trade was worth it, for the audience the language was for, because the audience was not programmers in the conventional sense. The audience was elementary school teachers, museum docents, small-business owners, doctors, lawyers, librarians, and the millions of ordinary Mac users who had something specific they wanted to make and were not interested in learning C.

The cultural effect was that you could read other people’s HyperCard scripts. You could open someone else’s stack, click on a button, look at its script, and understand what it did, and modify it, and have your modification work. This was a recovery of the BASIC-program-listings tradition of the late 1970s, in which computer magazines published programs as code and readers typed them in and modified them. HyperCard restored that pattern for the Mac generation, with a tighter integration between code and the things the code manipulated. The script for a button lived on the button. The button lived on a card. The card lived in a stack. You could move them around and the relationships moved with them.

The author–reader continuum

The single most important property of HyperCard, for the argument of this book, was that there was no distinction between author and reader. The application was the same in both directions. If you could read a stack, you could open it, edit it, change its buttons, rewrite its scripts, save your changes, and share the modified stack with a friend. There was a single keyboard command — Command-Option-T, or pressing a “Tab” key after entering certain modes — that toggled between reading and editing. Most stacks shipped with editing enabled by default. The vocabulary of “user” and “developer” did not apply, because the user and the developer were the same person at different moments.

This is the property the web did not preserve. The web’s view-source feature, treated in chapter one, was a partial recovery: you could see how a page was made, you could copy its source, you could make your own version. But the web’s authoring and reading interfaces have always been different applications. To read the web, you use a browser. To write the web, you use a text editor, or a content management system, or a static site generator, or some platform’s authoring tool. The integration HyperCard had — the same tool, used by the same person, switching between reading and writing with a keystroke — is not what the web is. The closest the web has come is in-browser editing systems like Wikipedia’s, or wikis generally, or some collaborative document tools, all of which restore the property within their own walled gardens. None of them restore it for the platform as a whole.

The continuum mattered because of what it implied about who could participate. HyperCard’s user base was not a programming community. It included programmers, but it was dominated by teachers, doctors, lawyers, hobbyists, and tens of thousands of people who had bought a Mac for some other reason and discovered, by clicking around in the included stacks, that they could make things. The activation energy for making a HyperCard stack was orders of magnitude lower than the activation energy for writing a Mac application. The proof of the activation energy being low is the population of stacks that got made, by whom, and for what.

What got made

The published HyperCard culture of the late 1980s and early 1990s included substantial volumes of work in several distinct categories. A partial inventory:

Education: schools used HyperCard heavily, especially in the years when the Mac had a strong position in K–12 institutions. Teachers built stacks for classroom use: interactive vocabulary drills, geography tutorials, science simulations, reading exercises. The Apple Classroom of Tomorrow program funded the production of HyperCard educational stacks at several sites in the late 1980s. Roger Wagner’s HyperStudio, released in 1989, was a competing stack-based authoring tool oriented toward education and remained in use in schools well into the 2000s.

Reference works: many CD-ROM reference titles of the early 1990s were HyperCard stacks, sometimes with custom extensions. The Voyager Company, founded by Robert Stein in 1984 and producing CD-ROMs from the early 1990s, used HyperCard as the substrate for its Expanded Books series and several of its multimedia titles. The interactive guide to the Beatles’ Hard Day’s Night, the multimedia Macbeth and Hamlet, and several other Voyager titles were HyperCard at the bottom.

Games: HyperCard was the original platform for Myst. Cyan, the studio run by brothers Rand and Robyn Miller, had previously made The Manhole (1988), Cosmic Osmo (1989), and Spelunx (1991) in HyperCard. Myst, released in 1993, was a HyperCard stack with QuickTime video and Sound Manager audio, and it became the best-selling computer game of the 1990s. The fact that the bestselling PC game of its decade had been built by two brothers in a small studio using HyperCard is not a detail. It is a statement about what the platform made possible.

Personal information management: thousands of small stacks were written by individual users to manage their own data — address books, recipe collections, bibliographies, customer databases for one-person businesses, lab notebooks for scientists who needed something specific. The shareware market for HyperCard stacks, on AppleNet and the BBS systems of the era, was substantial. Most of these stacks were not significant artifacts. They were significant in aggregate: they represented a culture in which ordinary computer users built ordinary tools for themselves and shared them with their friends.

Art and literature: the literary hypertext community, treated in chapter eight, used HyperCard for several of its early works. The art-software tradition produced a stream of HyperCard pieces, including some that were exhibited and published as art objects. The Voyager Expanded Books series included annotated literary editions in HyperCard format. The cultural respectability HyperCard achieved in these milieus was real; it was not a toy.

This is not the population that ships software for the web today. Web applications are built by professional developers in development organizations, with build systems and frameworks and deployment pipelines. The dollar-figure economics of web development make it hard for a doctor or a teacher to build a small thing for their practice or their classroom and share it. They can, in principle. They mostly do not, in practice, because the floor is too high. HyperCard’s floor was on the ground.

The decline

HyperCard’s commercial story is not a happy one and the responsibility is mostly Apple’s. The application shipped, free, with every Mac through System 6. When Apple needed to consolidate its software business in 1990 and 1991, it moved HyperCard to Claris, its software subsidiary, which began charging for it. The free version that shipped with new Macs was reduced to a “player” that could read stacks but not author them. A separately purchased version was required for the authoring tools. The price was modest by software-industry standards — $50 to $200 depending on version and bundle — but the effect was catastrophic. The continuum between reading and writing was broken. A user who got a Mac in 1992 could read stacks but could not modify them. The activation energy that had been on the ground was now several dollars and a separate purchase decision away.

The strategic reasoning at Apple was that HyperCard cannibalized other Apple software businesses, particularly tools like AppleWorks and the database products that Claris was trying to sell. The reasoning was wrong in retrospect, and probably should have been recognizable as wrong at the time. HyperCard was not a competing product to the database tools; it was a platform on top of which entirely different categories of work were being done, and pricing it out of universal availability did not transfer demand to AppleWorks. It just stopped the demand.

The 1990s saw the cumulative effect of this decision. The HyperCard userbase aged and was not replaced by a new generation of HyperCard users, because new Mac owners no longer had HyperCard. The competing products — SuperCard, MetaCard, the various successors that became Revolution and then LiveCode — survived but never reached the install base HyperCard had had. The web arrived in this period, and a generation of people who would have made HyperCard stacks in 1990 made web pages in 1995. The web, for all its limitations, was where the action was. HyperCard authoring continued to exist in a smaller and more devoted community through the 1990s and 2000s. Apple formally discontinued HyperCard in March 2004.

What was specifically lost

The web inherited some of HyperCard. HTML’s link element is a direct descendant of HyperCard’s button-with-go-to-card script, though without the integration with the rest of a stack’s machinery. JavaScript inherited some of the impulse that produced HyperTalk, though it inherited very little of the readability. Browser-based applications descend, in part, from the HyperCard demonstration that a single tool could host both content and behavior. The web did not start in the same place as HyperCard but several of its later developments rhyme with what HyperCard had been doing.

What the web did not inherit was the cultural pattern. The unified read-and-write tool, available to every user on every machine, with a forgiving language that allowed non-programmers to make working things — that was HyperCard’s specific contribution, and the web has never reproduced it. The closest replacements have been the various tools that revive the pattern in narrow domains: spreadsheets (which are HyperCard-in-table-form for tabular data), Scratch (which is HyperTalk-by-blocks for kids learning programming), HyperCard-revival projects (LiveCode, Decker, HyperCard.js, various others) that have small communities and no mass audience. The audience that HyperCard had — ordinary Mac users, by the millions, making things — has scattered.

It is sometimes argued that this audience reformed itself on the web. There is something to this argument. The blogging tools of the early 2000s, the wiki communities, the MySpace HTML profile customization era — these were genuine returns to mass authorship. So were the modding communities, the YouTube video production explosion, the iOS Shortcuts ecosystem that gives ordinary iPhone users a Hypertalk-like environment for automation. The pattern reappears in pieces. It does not reappear as a single integrated environment that ships with every machine and is the default place to make something.

The other thing the web did not inherit from HyperCard is the local quality of the artifact. A HyperCard stack was a file. You owned it. You could copy it to a floppy disk, hand it to a friend, store it on your own machine for thirty years and still open it. The stack belonged to the maker in the strong sense that the maker’s data was on their disk. Web applications produce no such artifact for the user. The user’s contribution to a web application is, in almost every case, content held on someone else’s server, accessible only through that server, with no local copy in any meaningful sense and no portability if the server goes away. The recovery of local-first software, treated in chapter twenty-one, is in significant part a recovery of what HyperCard had been doing as a matter of course: the artifact lives where the maker is.

The case HyperCard makes

HyperCard’s lesson is not that hypermedia could have been popular in the abstract. Hypermedia was popular, on one platform, for about five years, and the popularity ended when the platform stopped distributing it for free. The lesson is that the floor matters more than the ceiling. The hypermedia systems that were technically more ambitious — Intermedia, NoteCards, the academic systems treated in the next chapters — never escaped their institutional contexts because their floors were too high. The floor was an expensive workstation, a piece of software you had to be at a research university to use, a learning curve measured in months. HyperCard’s floor was opening an application that was already on the Mac you already owned.

The system Nelson described, and the systems the academic hypermedia community built, would have produced more powerful tools than HyperCard if they had reached HyperCard’s audience. They did not reach that audience. HyperCard did. The cost of HyperCard’s accessibility was that it was much less than what hypermedia could have been; the benefit was that millions of people used it. The web later chose a similar trade-off, on a much larger scale, and for some of the same reasons. The web at its launch was also less than what hypermedia could have been, and millions of people used it.

The difference is that HyperCard’s millions made things, and the web’s billions, with some real exceptions, mostly consume things. The activation energy on the web for making, as opposed to reading, is again high. It is not as high as it was for academic hypermedia systems, but it is much higher than it was on the Mac with HyperCard. The chapter twenty-four on Roam and Obsidian and Logseq, and the chapter twenty on Bret Victor and the dynamic document tradition, treat some of the recoveries. None of them have yet reproduced HyperCard’s particular combination of being on every machine, being the same tool for reading and writing, and being readable in its source by the people using it.

The next chapter goes back further than HyperCard, to the system that was, in a sense, what HyperCard would have been if Atkinson had been Douglas Engelbart and the Mac had been a 1968 SRI workstation. NLS was earlier, more ambitious, less successful, and almost entirely forgotten outside of the small group of people who care about this history. It is the system most computing professionals know one thing about — that it introduced the mouse — and almost nothing else, and the gap between that one thing and what NLS actually was is the size of the field.

NLS, Augment, and Engelbart’s actual proposal

The most-watched ninety minutes in the history of computing demonstrations was delivered by Douglas Engelbart on December 9, 1968, at the Fall Joint Computer Conference in San Francisco. The session was filmed; the film exists in good quality and is on YouTube. The audience saw, for the first time, the mouse, the chord keyset, real-time video conferencing between the demo hall and SRI’s research building in Menlo Park thirty miles away, screen sharing between two remote participants, structured document editing with collapsible outlines, hyperlinked references between documents, and a collaborative editing environment in which two people in two cities could edit the same file at the same time while seeing each other’s faces in inset windows. The whole thing was running on a single SDS 940 timesharing mainframe with a custom display system. It has been called, since at least the 1990s, “The Mother of All Demos.” Andries van Dam, who was in the audience, has said in subsequent interviews that the room was stunned in a way conferences are not usually stunned, and that he and many of his colleagues understood, that afternoon, that they had seen the future.

What the future turned out to look like was the mouse and very little else. The other things Engelbart had shown — the structured documents, the collaborative editing, the hyperlinked references, the bootstrapping community of practice, the entire conceptual framework into which the mouse fit as one small piece — went almost nowhere in their original form. The mouse went everywhere. Engelbart spent the rest of his career, until his death in 2013 at age eighty-eight, trying to explain to interviewers that the mouse was the least interesting thing he had built, and that the proposal underneath the mouse — what he called “augmenting human intellect” — was the thing that should have been taken seriously. This chapter is about that proposal, the system that implemented it, and the specific reasons it did not become the substrate it should have been.

The framework, not the gadget

In October 1962 Engelbart published a report for the Air Force Office of Scientific Research called Augmenting Human Intellect: A Conceptual Framework. The report is the founding document of his program; it is the thing the demo was a demonstration of, and the thing everything Engelbart did for the next fifty years was an attempt to instantiate. The argument of the report is that the central problem facing modern civilization is the increasing complexity of the problems we have to solve. Climate, war, poverty, scientific frontiers — the problems are not the problems individual minds, working with conventional intellectual equipment, can solve in available time. Therefore the problems require us to augment our intellectual capacities. The augmentation should be a co-evolution: human beings get more capable, the tools get more capable, the methods of working with the tools get more capable, and the community of people using the tools and methods gets more capable, all at once, in mutually reinforcing ways.

Engelbart called this the H-LAM/T framework, for the human using Language, Artifacts, and Methodology in which the human is Trained. The framework treated the human and the tooling as a single system. You could not improve the human without improving the tools; you could not improve the tools without improving the methods; you could not improve the methods without training the humans. Improvement at any one node required improvement at the others, and the process of improvement was recursive: tools you built to make humans more capable should themselves be improved by the more capable humans, in a positive feedback loop. Engelbart called this loop “bootstrapping,” and he meant the term in something like the sense it had then in the engineering of computer systems — a system that uses its own previous output to improve its next output.

The proposal was, on its face, less specific than Nelson’s. Nelson said: here are seventeen properties a hypermedia system must have. Engelbart said: here is a structure for how human beings and tools improve each other over time, and the test of any specific tool is whether it accelerates the improvement loop. The two proposals were not in conflict, exactly. Nelson’s items would have all been valid Engelbartian tools. But Engelbart’s frame put the tools in service of something larger — the augmentation of human capability — that the tool catalog by itself does not capture. The tool was a means; the augmentation was the end.

This is the part of Engelbart’s proposal that has been the hardest to keep alive. The Hello World version of his work — that he invented the mouse, that he had a great demo, that some of his ideas ended up at PARC — keeps the mouse and loses the framework. The framework is what NLS was for. NLS was not a product. It was an instrument of the framework. The people at SRI who used it were, in Engelbart’s terms, the test subjects of an augmentation experiment that was ongoing for as long as the lab was open.

NLS as a system

NLS stood for “oN-Line System,” named retroactively against SRI’s existing batch-mode offline system. It ran on a Scientific Data Systems SDS 940, a timesharing mainframe that supported about a dozen simultaneous users. Each user had a workstation with a CRT display, a keyboard, a five-finger chord keyset, and the three-button mouse Bill English had built. The chord keyset, used with the left hand while the right held the mouse, was Engelbart’s preferred input device for sustained editing: a trained user could enter text with the chord keyset faster than they could type on the keyboard. Most users did not adopt the chord keyset and many of them resisted the mouse for the same reasons — they would rather stay with what they knew.

The fundamental abstraction in NLS was not a document. It was a structured outline. Every piece of writing in the system was a tree of statements, with each statement having a parent statement above it and an arbitrary number of child statements below. The tree was the writing. You moved around it by selecting nodes. You collapsed and expanded subtrees by issuing commands. You viewed the document at any level of detail you wanted — the top-level summary, the top three levels, the full tree — by adjusting the view, not by editing the source. The source did not change as the view changed; the source was the full tree and the view was a projection of it.

This is the property that has taken seventy years to filter into common practice, and even now it has not arrived in its full form. The outliner — software that treats a document as a hierarchical tree of statements that can be viewed at variable depth — is now familiar in narrow forms: in OmniOutliner, in Workflowy, in the outline mode of various text editors, in the structure pane of Word, in the headings-and-folding behavior of Markdown editors. Roam and Logseq, treated in chapter twenty-four, have brought the outline back as the primary writing abstraction. None of these implementations match NLS’s depth. NLS treated the outline as the writing in a thoroughgoing way. The link, the comment, the cross-reference, the search hit — every operation in the system operated on outline nodes, not on free text. The document as a flat sequence of words, which is what HTML treats writing as, was a thing NLS did not believe in.

NLS also had what we would now call hyperlinks. A statement in one document could be linked to a statement in any other document the user had access to. The link was an address into the outline: you specified the document, the path through the outline to the target statement, and the link took you there directly, expanding the path as needed. The links were not flagged as visual elements; they were textual references in the source, identified by specific syntactic markers. This made the document readable as text without the link decoration; it made the links followable by anyone who knew the syntax; and it made the underlying graph of references queryable, because the references were text the system could search.

Beyond linking, NLS supported what Engelbart called the “journal”: a versioned, append-only archive of every document the lab produced, in which every document had a permanent number, every revision was preserved, and every reader could be cited by other readers in subsequent documents. The journal was the lab’s collective memory, and it was the substrate on which the bootstrapping loop ran. The team’s discussions of how to improve NLS were themselves in the journal, linked to from the documentation, linked to from the codebase, linked to from the meeting notes. The lab was, in effect, a wiki two decades before the wiki was invented, except with more discipline about versions and more support for outline structure.

The 1968 demo

The demo was the public face of all of this. Engelbart had been working on the system since 1959 in some form, on this specific implementation since 1965, with significant ARPA funding from J. C. R. Licklider’s office and then Bob Taylor’s at ARPA. The demo was a deliberate publicity move: ARC needed to justify the funding, the funding agencies needed to see results, and Engelbart wanted to put a marker down that this work mattered.

The technical apparatus for the demo was complicated. The SDS 940 was at SRI in Menlo Park, thirty miles south of San Francisco. The audience was at the Civic Auditorium in the city. A microwave video link, set up by Bill Paxton and a team of SRI engineers, carried two channels of video from Menlo Park to the auditorium. A leased phone line carried the mouse and keyboard input back. The auditorium’s projection system displayed Engelbart, on stage, plus the NLS screen from the workstation, plus inset windows showing Bill Paxton and Jeff Rulifson back at SRI as Engelbart talked to them. The whole rig had been bench-tested but had never been run live for an audience.

What the audience saw, in ninety minutes:

A live demonstration of structured document editing, with statements being added, moved, indented, outdented, and reorganized in real time. A live demonstration of hyperlinks, with Engelbart clicking on a reference and being taken to the target statement in another document. A live demonstration of view-control, in which the same document was viewed at various levels of outline depth and various levels of formatting. A live demonstration of word-processing operations — find, replace, delete — done on outline structures rather than on text. A live demonstration of collaboration: Bill Paxton in Menlo Park edited the same document Engelbart was editing in San Francisco, with both of them seeing each other’s cursors. A live demonstration of video conferencing, with Engelbart having a conversation with Paxton while sharing the document. A live demonstration of the mouse, the chord keyset, and the workstation as a single integrated interface.

The mouse is the part that has reached the world. The chord keyset has not. The outline as the primary document abstraction has been narrowly adopted. The integrated video conferencing took thirty years to become normal. The integrated collaboration took fifty years to become normal in the form of Google Docs and similar tools. The bootstrapping framework has, with rare exceptions, not been recovered at all.

Why it didn’t scale

NLS was a working system used in production at SRI by Engelbart’s lab for the duration of his time there. The lab itself reached forty-some staff at its peak in the early 1970s. The system was the lab’s workflow tool: documentation, code, meeting notes, project plans, and external publications all lived in NLS. The internal evidence is that the bootstrapping loop worked: the lab’s productivity, measured by its outputs, was high relative to its size, and the lab’s members were unusually capable users of the tools they had built.

The system did not, however, scale outside the lab. There were a small number of external NLS users — other ARPA-funded sites that had been given access — and they used it. But NLS did not become the standard document system at other research institutions, much less at universities or commercial firms. There are several reasons for this, and they are worth being specific about because the same kinds of reasons recur for many of the systems in this book.

First, the system required deep training. NLS was not learnable by walking up to a workstation and trying things. The chord keyset alone required weeks of practice; the command vocabulary was substantial; the conceptual model — the outline as primary, the view as a projection, the journal as a versioned archive — was alien to people who came from typewriters and word processors. Engelbart’s view was that this was correct: serious tools should require serious training, and the training should be part of the augmentation. Most users disagreed. They wanted a tool they could learn in an hour. NLS could not give them that.

Second, ARPA stopped funding the lab. The funding model that had supported ARC in the 1960s — open-ended research grants with little requirement to show specific deliverables — was changing under the Mansfield Amendment and subsequent legislation that required defense research dollars to be tied to specific military applications. Engelbart’s work was hard to justify in those terms. The ARPA funding dwindled through the early 1970s. By 1975 the lab was in serious trouble.

Third, the team scattered. Some of the most capable engineers at ARC — including Bill English, Bill Paxton, Don Andrews, and several others — moved to Xerox PARC, which had been founded in 1970 with funding orders of magnitude greater than ARC’s. PARC built the Alto, the Star, and the personal computing vision that descended through Apple and Microsoft to the modern desktop. Many of PARC’s ideas were Engelbart’s ideas, modified and simplified. The Alto’s user interface owes its mouse and its graphical operations to NLS, by direct lineage; it owes its document model (page-oriented, free-text-based, WYSIWYG) to a different intellectual tradition that Charles Simonyi and Butler Lampson among others brought to PARC. The Alto was friendlier than NLS. It was also less ambitious about what a document was.

Fourth, ARC’s institutional home eventually fell apart. In 1977 SRI sold the Augmentation Research Center to Tymshare, a commercial timesharing company. Tymshare renamed the system Augment and offered it as a commercial service for several years; the customer base was small but real. McDonnell Douglas acquired Tymshare in 1984 and continued operating Augment for internal use; the system was finally shut down in the early 1990s. Engelbart himself left Tymshare in 1986 and founded the Bootstrap Institute (later the Doug Engelbart Institute) to continue advocating for the framework. The advocacy continued until his death.

Fifth, and most importantly: NLS’s design choices were optimized for a kind of work — sustained, complex, collaborative intellectual production by trained teams — that most people most of the time were not doing. The Alto and its descendants were designed for casual office work: writing letters, formatting memos, making slides. Those tasks are easier than the tasks NLS was for. The mass market did not need NLS; it needed something simpler. The web, when it arrived, was simpler still. NLS’s complexity and depth were features for its intended audience and obstacles for the wider audience that eventually came online.

What the world kept

A short, honest accounting of what made it from NLS to the present:

The mouse. Engelbart and Bill English designed and built the first one in the mid-1960s. The patent issued in 1970. The design was licensed by Xerox to Apple for what amounted to a few thousand dollars. The mouse went into the Lisa, the Mac, and every subsequent personal computer.

The window-based GUI in concept, though most of the implementation details came from PARC and not from NLS. NLS had multiple-window views and used a graphical pointer to select between regions. PARC made the windows movable and overlapping and added the icons. The lineage runs through both.

Outlining, narrowly. The outline view in word processors, the outline as a presentation tool, the outline as a writing tool in OmniOutliner and Workflowy — these are recoveries of the NLS pattern, mostly without acknowledgment, at much lower power.

Hyperlinking, in degraded form. The web’s link is a descendant of the NLS link and of the parallel Xanadu link, but the web’s link has none of the structural awareness — no addressability into the outline, no two-way visibility, no journal-style version control — that NLS gave its links.

Real-time collaborative editing, very recently. Google Docs in 2006 was the first widely deployed system that recovered the NLS pattern of multiple users editing the same document in real time. Operational transformation and conflict-free replicated data types — the algorithms that make this work — are research traditions that originated in the 1990s and matured in the 2000s. Engelbart had this working in 1968 on a timesharing mainframe, by simpler means; we lost it for thirty-eight years and got most of it back.

What the world did not keep

The augmentation framework. The proposition that tools should be designed not in isolation but as part of a co-evolution between human, tool, method, and community — that the right measure of a tool is whether it accelerates the loop of mutual improvement — has, with rare exceptions, not been carried forward. Most software is designed to be used. NLS was designed to be improved by its users, who were also its builders. The line between the two was deliberately blurred. The line is, in current software, drawn very sharply: developers build the tool, users use it, and the feedback loop is mediated through bug reports and feature requests rather than through the users modifying the tool. This is the same loss the previous chapter named in HyperCard’s terms: the disappearance of the author–reader continuum. Engelbart had named it earlier and was clearer about why it mattered.

The journal. The discipline of putting every artifact the lab produced into a versioned, addressable, linkable archive, and treating that archive as the lab’s collective memory, is a discipline that almost no organization practices. Engineering organizations have wikis and ticketing systems and code review tools, but they have nothing like the integration Engelbart was after, in which every email is a journal entry, every code change is a journal entry, every meeting note is a journal entry, every external publication is a journal entry, and every entry is linked to every entry it relates to. The closest contemporary practice is the so-called “second brain” approach popularized in personal knowledge management, treated in chapter twenty-four. It is much smaller in scope and operates on individual notes, not on institutional outputs.

The chord keyset. This is a small loss in absolute terms but a telling one. The chord keyset is faster than the keyboard, with training, for someone using a mouse with their other hand. The reason it did not catch on is that nobody wanted to spend the weeks training. We have, as a culture, accepted that input devices should be learnable in minutes, and we have given up the speed that comes from input devices that require months. Engelbart’s view was that we made the wrong trade, because the use of a tool that one trains in for months and then uses for decades is, over a career, a much better deal than the use of a tool that one learns in minutes and uses inefficiently for decades. The chord keyset is, in this sense, a synecdoche for the larger thing the augmentation framework was about: serious tools, for serious work, that justify serious investment in learning them.

Toward the next chapter

The next chapter takes the academic hypermedia tradition that grew up at Brown University, at Southampton, and at a handful of other research universities through the late 1970s and 1980s. The academic tradition is more diverse than the SRI tradition, smaller in individual ambition than Xanadu, and more durable in influence than either. It produced systems — Intermedia, Microcosm — that were used in classrooms and offices; it produced research papers that defined what hypermedia was as a field; it produced a community that continues, in the ACM Hypertext conferences, to think seriously about what linking and structure should be. The community was largely sidelined when the web won, because the web answered the question “what is hypermedia for the public” in a way that pre-empted the academic project, but the work the community had been doing did not stop being relevant. It is the source of much of what the recovery in Part V is trying to reassemble.

Intermedia, Microcosm, and the academic hypermedia tradition

While Nelson worked on Xanadu and Engelbart on NLS, a third hypermedia tradition was forming inside research universities. It was less ambitious than Xanadu, less integrated than NLS, and less famous than either, but it shipped working systems, taught classes with them, published peer-reviewed research about them, and produced a set of formalisms — the Dexter Reference Model, the notion of open hypermedia, the standard vocabulary of anchors and links and webs — that still shapes serious thinking about hypertext when serious thinking about hypertext happens. The two centers of this tradition were Brown University in Providence and the University of Southampton in England, and the systems most associated with each are Intermedia (Brown, mid-1980s) and Microcosm (Southampton, late 1980s through the 1990s). They were not the only academic hypermedia systems; a small constellation of related projects existed at Aalborg, at Sun Microsystems, at Carnegie Mellon, and elsewhere. But Brown and Southampton are the two reference points, and the things they did that the web did not do are the substance of this chapter.

The Brown tradition

The hypermedia program at Brown was old. Andries van Dam, the Belgian-American computer scientist who arrived at Brown in 1965 and has been there ever since, began work on what became the Hypertext Editing System, or HES, in 1967, in direct collaboration with Ted Nelson. HES ran on an IBM/360 mainframe with a 2250 vector display, and it was, by Nelson’s own account, the first running hypertext system in the world. It was a significant project: NASA ended up using HES for the documentation of the Apollo program, in part because the branching structure of hypertext was a better fit for the cross-referenced technical materials than the linear structure of printed manuals. HES was an instrument, not a product; it ran on one machine in one room and required IBM-class hardware. Its significance was that it demonstrated, in 1968, that the hypertext idea could be implemented and used for actual work.

HES was followed at Brown by FRESS, the File Retrieval and Editing System, in 1969. FRESS removed several of HES’s limitations and added bidirectional linking — every link in FRESS could be traversed in either direction, and the system maintained the link database in such a way that the destination of a link knew which links pointed to it. This is one of the properties Xanadu had specified and the web later rejected, and FRESS had it working at Brown in 1969. FRESS was used to teach undergraduate English courses at Brown through the 1970s, including a poetry class taught by Robert Scholes, who used the system to let students annotate, cross-reference, and discuss texts in a way that traditional course mechanics could not match. The pedagogical experiments produced data: students who used FRESS were more engaged with the material, more willing to make connections across texts, more able to follow associative threads through a curriculum. The data was published; the use continued for over a decade.

Intermedia, the next system in the lineage, was built between 1985 and 1989 by the Institute for Research in Information and Scholarship (IRIS) at Brown, with funding from IBM and Apple. The project leader was Norman Meyrowitz, with Nicole Yankelovich, Bernie Haan, Karen Catlin, and others on the team. Intermedia was a serious piece of engineering. It ran initially on Apollo workstations, later on Macs under A/UX. It supported text editing, graphics editing, a timeline editor, and a viewer for digital video — a multimedia authoring environment in the genuine multi-medium sense, six years before the same idea reached the consumer market in compact disc-ROM format. It had bidirectional links, like FRESS, and it had something newer: linkbases.

A linkbase, in Intermedia’s vocabulary, was a separate database of links that could be applied to read-only documents. The links did not live inside the documents they connected; they lived in their own store. A reader could open a document and choose which linkbases to overlay on it. Different linkbases supported different uses: a student studying Victorian poetry might overlay the linkbase produced by their professor for one course; a researcher working on the same texts might overlay a different linkbase produced by a colleague at another institution. The texts were stable; the links were the contribution of each interpreter. This is a much more sophisticated linking model than the web’s. It separates the act of authorship of the document from the act of authorship of the citation network, and it treats the citation network as a first-class object that other people can produce, share, and combine.

Intermedia was used at Brown to teach two courses prominently: a course on English literature taught by George Landow, who became one of the major theoretical voices in early hypertext studies, and a course on cell biology taught by Peter Heywood. Landow’s course assembled the “In Memoriam Web,” an Intermedia document collection built around Tennyson’s elegiac poem with links to biographical, historical, literary-critical, and contextual sources. The web was developed by Landow with his students; it grew over multiple offerings of the course; and it became, for a period in the late 1980s and early 1990s, one of the most-cited examples of educational hypertext in the literature. Landow’s book Hypertext: The Convergence of Contemporary Critical Theory and Technology (1992) drew on the Intermedia experience and was, for a time, the standard humanities introduction to the hypertext concept.

Intermedia was not a commercial product and was not designed to be one. The system required workstation-class hardware that was beyond what most institutions could deploy. It was demanding to learn. It needed a server architecture that fit Brown’s setup and not many other places. The Intermedia team had hoped, in the late 1980s, to find a commercial partner who would turn the system into a product; the hope did not materialize, and when the funding from IBM and Apple wound down in 1990, the system stopped being supported. Norman Meyrowitz left Brown for the commercial software world; Nicole Yankelovich continued at Sun Microsystems, where she worked on a related system; the team scattered.

The Southampton tradition

Microcosm was developed at the University of Southampton in England, beginning in the mid-1980s, under the direction of Wendy Hall, with Hugh Davis, Les Carr, and others on the team. Microcosm took the Intermedia idea of separate linkbases and pushed it further into what Southampton called “open hypermedia.” The Southampton position, articulated in a series of papers through the early 1990s, was that the link should be fully decoupled from the document. A document on a Microcosm system was, in itself, just text — or just an image, or just a video. The links that connected the document to other documents were stored in a separate link service, accessed through the operating system, and applied to documents at viewing time. This had several consequences that the field considered important.

First, links could be applied to documents the linker had no permission to modify. A researcher could link from a passage in a published paper to another passage in another published paper without altering either paper. This is a property the web does not have. To link from a web page to another web page, you have to be the author of the source page. You can write commentary about another page, but you cannot decorate that other page with a link the way a reader marks up a book with marginalia. Microcosm let you do exactly that. Second, links could be generic. A Microcosm link could specify “the word ‘photosynthesis’ anywhere in any document,” and the link would be applied wherever that word appeared, in any document the user opened, until the link was deactivated. This kind of “generic link” is something the web has approximated only with browser extensions and overlays, in narrow domains, decades later. Third, links could be dynamic. A Microcosm link could be a query that produced its target at link-traversal time, by searching the document corpus. Fourth, multiple link services could be active at once, with their own scopes and policies, so a single document could be richly annotated by different communities of users with no conflict among them.

Microcosm was deployed in industrial settings, not just academic ones. Ford in the UK used it for technical documentation. The BBC used it for archival access. The Mountbatten Archive at Southampton itself was an extensively linked Microcosm corpus that historians used for research. The system was a commercial product through a Southampton spinoff, Multicosm Ltd., and continued in some form into the late 1990s before being absorbed and re-formed under various corporate identities. The research continued under different names — DLS (Distributed Link Service), Auld Linky, and others — and the Southampton group’s work eventually fed into the early Web Science Trust and into Tim Berners-Lee’s own institutional home, since Berners-Lee took up a chair at Southampton in 2004.

The Microcosm group made the argument, in a series of papers in the early-to-mid 1990s, that the web’s link model was structurally inferior to the open hypermedia model and that the web should be evolved toward something more like Microcosm. The argument was not heard in time. By the time it could have been heard, the web had a sufficiently large installed base that the cost of changing its link model was prohibitive. The Microcosm group, like most of the academic hypermedia community, redirected its work toward the web in the late 1990s and 2000s, contributing to the early development of the Semantic Web, RDF, and Linked Data — all of which can be read as attempts to introduce, on top of the web’s reduced foundation, some of the structural properties open hypermedia had provided natively.

The Dexter Reference Model

The academic hypermedia field formalized its understanding of itself in a series of workshops in the late 1980s. The most influential was held at the Dexter Inn in Sunapee, New Hampshire, in October 1988 and again in March 1989, organized by Frank Halasz and Mayer Schwartz, with a group of about thirty researchers from the major hypermedia systems of the time. The output was the Dexter Hypertext Reference Model, published in 1990 and refined over subsequent years. The model was an attempt to specify, abstractly, what a hypertext system was, in a way that could be used to describe all the existing systems and to evaluate proposed new ones.

The Dexter model has three layers. The within-component layer is the layer at which a document’s content is structured — text formatting, image layout, the internals of the thing being linked. The storage layer is where the model says the hypermedia structure lives: nodes, links, components, the graph that connects them. The run-time layer is where the model says the user interacts with the system — the application that displays nodes, navigates links, and presents the graph to the user. The model is deliberately ecumenical about implementation; it covers HES, FRESS, NoteCards, NLS, HyperCard, Intermedia, KMS, and several other systems, and it lets the systems be compared on common terms.

The most useful thing the Dexter model did, for the purposes of this book, was distinguish the components of hypermedia from each other. A link, in Dexter terms, is not a piece of a document. It is a relationship between anchors, which are positions inside or attached to components, with its own identity in the storage layer. This let the field name what the web later refused to name: that a link is a thing, that it has properties beyond its endpoints, that it can be inspected and modified and stored separately from the documents it connects. The web’s <a href> is a within-component element by Dexter’s classification, not a storage-layer link. This is a precise way of saying what the previous chapters have said less formally — that the web flattened the hypermedia model into the document, and that the flattening was a loss.

Frank Halasz also wrote, in 1988, a paper called “Reflections on NoteCards: Seven Issues for the Next Generation of Hypermedia Systems.” The paper named seven problems the field had not yet solved: search, composite nodes, virtual structures, computation in/over hypermedia, versioning, collaboration, and extensibility. The paper became the most-cited document in the field for the next decade; the ACM Hypertext conferences in the 1990s structured much of their program around these seven issues. The fact that the web, when it arrived, addressed none of them as a research question is one of the reasons the hypermedia community received the web with a mixture of relief and resignation. The web was popular. It was also, by the field’s standards, a step backward on every one of Halasz’s seven issues.

The ACM Hypertext conferences

The community held its first conference at the University of North Carolina at Chapel Hill in November 1987. The Hypertext ’87 conference was small — fewer than two hundred attendees — but it was where the field met itself for the first time, and where the relationships among the various systems and traditions became visible. Subsequent conferences followed in 1989 (Pittsburgh), 1991 (San Antonio), 1993 (Seattle), and then biennially in the 1990s and annually since. The proceedings are a complete record of the field’s research output through the period: Brown people, Southampton people, Aalborg people, PARC people, Carnegie Mellon people, the various commercial system vendors, the literary hypertext writers, and the theoreticians of hypertext as a cultural form all came to the conference and presented papers. The conference series continues — the ACM Hypertext and Social Media conference is the current name — though much of its scope has shifted to web research since the late 1990s.

What is striking about the conference proceedings from the late 1980s and early 1990s is how completely the field anticipated, named, and proposed solutions to problems the web would later face. The Hypertext ’91 proceedings contain papers on link integrity (link rot), on collaborative authoring, on personalization, on adaptive hypermedia, on the relationship between hypertext and database systems. Each is a contribution to a research program. The web, when it began in 1991, was at a level of sophistication that the conference proceedings would have classified as belonging to the early 1970s. The web’s authors — Berners-Lee in particular — were aware of the academic hypermedia tradition but chose, deliberately, to build something simpler than the academic systems specified. The reasons for the choice are treated in chapter fifteen; here it is enough to say that the simplicity was a feature for adoption and a loss for the field’s research agenda, which was rendered, almost overnight, mostly irrelevant to mainstream computing.

What the field had been doing

A summary, with no claim to be exhaustive, of what academic hypermedia in 1991 offered that the web did not:

Bidirectional linking, in HES, FRESS, Intermedia, NoteCards, KMS, Microcosm, and other systems. The destination of a link knew which sources pointed to it, and you could enumerate the backlinks of any document. The web has webmentions and external link analysis; it does not have native backlinks.

Linkbases and overlay annotation, in Intermedia, Microcosm, and Sun’s Link Service. Links could be applied to documents from outside the documents, by readers, in separate databases. The web has third-party annotation systems (Hypothes.is, since 2011; the W3C Web Annotation standard since 2017) that approximate this for some uses but are not native and not universally adopted.

Generic links, in Microcosm. A link could be specified to apply to “this term wherever it appears,” and the system would activate the link at every occurrence in any document. The web does not have this; it has search-on-the-page and browser extensions.

Versioned documents, in NoteCards, KMS, and several others. The history of a document was accessible; links to specific versions were stable. The web has the Internet Archive, layered on as third-party retrofit, and no native versioning.

Composite documents, in NoteCards in particular. A node could be a composite of other nodes, presented as a unit; the composition was a first-class object that could itself be linked to. The web has frames and iframes, which are degenerate composites; it does not have first-class composition.

Computation in/over hypermedia, the fourth of Halasz’s seven issues. Several systems treated this seriously, with mechanisms for embedded scripts, queries, and procedural attachments to nodes. The web answered this question, eventually, with JavaScript, but JavaScript took a decade to arrive and was not the hypermedia community’s preferred answer.

Multi-headed linking, in Intermedia among others. A link could have many sources and many destinations; the system would let the user pick which to follow. The web has, structurally, only one-to-one links and has to fake the others through interface conventions.

Each of these properties has been recovered, partially, in some context, by some system, for some application. None is recovered for the web as a whole.

What the academic field got wrong

The academic field had its own pathologies, and any honest treatment has to name them. The systems were institutional in the sense that they ran inside research universities, required institutional infrastructure, and were not deployable by individuals. The Microcosm-Ford partnership is a fair representative: the system was used in industrial settings, but the cost of deployment was a multi-year integration project, not a download. The academic hypermedia community did not, with the partial exception of HyperCard (which most of them did not really consider one of theirs), produce mass-market software.

The field also had a tendency, common in research communities, to treat its problems as more solved than they were. The Dexter Reference Model was a useful formalization but it papered over real disagreements between systems about what the basic objects of hypermedia even were. The field had structural sympathies for what we would now call “heavyweight” approaches: rich type systems, complex authoring tools, formal models of every entity in the system. The web’s “lightweight” approach — small specification, permissive parser, no formal model of anything — was the kind of thing the field had argued against, at length, in many papers, for sound reasons that did not turn out to be correct at internet scale. The field’s reasons were not foolish; the web’s success was not predictable on the field’s terms. But the field had its analytical apparatus too thoroughly invested in the heavyweight tradition, and when the web arrived the field was slow to recognize what was happening.

When recognition came, in the mid-1990s, the academic hypermedia community largely moved to the web. The annual conferences began incorporating web-research papers. The Semantic Web, articulated by Berners-Lee in a 2001 Scientific American article and developed through the W3C in the 2000s, was in significant part the academic hypermedia community’s attempt to retrofit some of what they had wanted onto the web’s substrate. The Semantic Web has produced significant infrastructure — RDF, OWL, SPARQL, the Linked Open Data cloud — but it has not, despite twenty-five years of effort, become the way most of the web works. It is, instead, a layer used by specific communities for specific purposes (libraries, government open data, biomedical knowledge bases) while the general web remains structurally as Berners-Lee specified it in 1991.

What survives

The academic hypermedia tradition is alive in a smaller form than its peak. The Hypertext and Social Media conferences continue. The field still has practitioners. The vocabulary the field developed — anchors, links, components, webs, linkbases, the Dexter model’s three layers — remains in use among researchers thinking about hypertext as a serious topic. The lineage runs through Web Science research at Southampton, through the digital humanities communities at Brown and elsewhere, through the various open-annotation projects, through the Open Annotation Collaboration and the W3C Annotation Working Group. The work continues. Most of it is invisible to the working web developer, who has been taught that the link is <a href> and that the rest of the hypermedia model is an academic curiosity.

It is not an academic curiosity. It is the description of what a serious hypermedia system would look like, produced by a generation of researchers who built and used such systems for two decades before the web subsumed the question. The recoveries in Part V are, in part, recoveries of academic hypermedia ideas. Webmentions are the IndieWeb’s attempt to recover Intermedia’s bidirectional links. Hypothes.is is an attempt to recover Microcosm’s overlay annotation. Roam Research’s block references are an attempt to recover composite nodes. The Semantic Web, in its more focused forms, is an attempt to recover the structured links the academic tradition specified.

The next chapter goes to the literary side of the same tradition. The hypermedia community that gathered around Storyspace, Eastgate Systems, and the Hypertext ’87 conference contained, alongside the engineers, a contingent of writers who took hypertext seriously as a form. They produced a body of work — afternoon, Patchwork Girl, Victory Garden, Twelve Blue, others — that is the closest thing the field has to a canon. The literary hypertext canon is the answer to anyone who asks what hypertext can do that ordinary writing cannot, and it is the part of the field that the web has done the least to absorb.

Storyspace, Eastgate, and the literary hypertext tradition

The academic hypermedia tradition described in the last chapter had a parallel that ran inside literature departments and writers’ rooms rather than computer science departments. It produced a body of work — novels, stories, poems, essays — that was hypertextual in form: nonlinear, multi-pathed, requiring choices by the reader to assemble what they were reading. The works are small in number compared to the volume of conventional literary output, but they exist, they were taken seriously by critics, they were taught in graduate programs, and they constitute the only sustained attempt in the history of literature to produce art in the hypertext medium. They are the answer to anyone who asks what hypertext could be as a literary form rather than a technical apparatus. The chapter is about how the works got made, the tools they were made with, the community that surrounded them, and why, when the web arrived, the form did not migrate to the new medium as cleanly as one might have predicted.

The form before the tool

It is worth establishing that nonlinear writing predates the hypertext systems that were eventually used to produce it. Jorge Luis Borges’s “The Garden of Forking Paths” (1941) is the classical reference: a story whose narrative is structured as branching paths, in which any decision the reader takes changes the events that follow, but in which the branches do not exclude each other — each branch is real, and the story is the totality of branches rather than any one of them. Julio Cortázar’s Hopscotch (Spanish Rayuela, 1963) is a novel with a “table of instructions” at the front that proposes two reading orders for the chapters: one starting at chapter one and proceeding sequentially, the other following a jump-list that produces a different sequence and includes additional chapters not in the linear reading. Italo Calvino’s If on a winter’s night a traveler (1979) interleaves a frame narrative with the opening chapters of ten other novels, structured so that each chapter is the beginning of a different book whose continuation is interrupted. B. S. Johnson’s The Unfortunates (1969) was published as a box of unbound chapters that the reader could shuffle and read in any order. Marc Saporta’s Composition No. 1 (1962) did the same, earlier.

These books exist. They are good books. They establish that the impulse toward nonlinear narrative is not a product of digital technology; the technology made certain kinds of nonlinear structure easier to produce and easier to navigate, but the impulse was already in twentieth-century literature. The hypertext systems that began to be built in the 1980s landed in a world that had already produced a small canon of nonlinear printed work, and the writers who took up the new tools had already-existing models for what they were trying to do.

Storyspace

The dominant authoring tool for literary hypertext, throughout the period the form was most active, was Storyspace. It was created in the mid-1980s by Jay David Bolter, Michael Joyce, and John B. Smith. Bolter was a classicist who had become interested in computing as a tool for thinking about written form; Joyce was a fiction writer who had been thinking about nonlinear narrative since the late 1970s; Smith was a computer scientist at the University of North Carolina who provided much of the technical work. The collaboration was unusual. Storyspace was not designed by computer scientists who hired a writer for advice; it was designed jointly by a writer, a humanist, and a computer scientist, each with a stake in the system’s substantive form.

Storyspace’s data model was a set of “writing spaces” arranged in a two-dimensional plane and nestable inside each other. A writing space could hold text. It could also hold other writing spaces. The result was a hierarchy of containers, like nested folders in a file system, but with positional information: the spaces had spatial relationships within their parent space, and the spatial arrangement was an authorial signal about how the spaces related. Spaces were connected by links. A link could be a simple jump from one space to another, or it could be guarded by a “guard field” — a condition, expressed in Storyspace’s small scripting language, that determined whether the link was available to the reader. Guard fields were typically conditioned on what the reader had previously read: a link might become available only after the reader had visited certain other spaces, or might be unavailable until certain spaces had been read.

The guard field was the system’s signature feature. It allowed the writer to control not just what links existed but when. A reader proceeding through a Storyspace work would find that the same link, clicked at different points in the reading, took them to different places, or did not appear at all. The author shaped the reader’s path by controlling the visibility of paths. This is structurally different from the academic hypermedia systems treated in the last chapter, which were largely about giving the reader more freedom to navigate; Storyspace’s design was about giving the writer more control over the reader’s experience even in a nonlinear medium. The two impulses — toward reader freedom and toward authorial control — coexist in the literary hypertext canon, and individual works strike the balance differently.

Storyspace had several other features that mattered for the works produced in it. It supported a “default link” — a link followed by default if the reader pressed Return without selecting a specific link. Many Storyspace works use the default link as the spine of the work: pressing Return repeatedly takes you through one possible reading; the other links open the alternatives. It supported a “path” concept, in which the writer could specify a sequence of spaces that constituted a reading; multiple paths could be defined for the same body of spaces, and the reader could choose which path to follow. It had a map view that let the writer see the spatial arrangement of spaces and their links, and a reader view that hid this from the reader and presented the text. The two-view structure made writing a Storyspace work feel different from writing a novel: the writer was both writing the text and shaping the underlying graph, and the graph view was where most of the structural decisions got made.

Eastgate

Eastgate Systems, the publisher and developer that brought Storyspace and most of the literary hypertext canon to market, was founded by Mark Bernstein in 1982. Bernstein was a chemist by training — he had a doctorate from Harvard in 1983 — who had become interested in hypermedia and turned a small software company toward publishing hypertext fiction. Eastgate acquired Storyspace from its original developers in 1990 and continued to develop and sell it for the next several decades. Eastgate published, on diskette and later on CD-ROM, the works that constitute most of what is canonical in literary hypertext: Michael Joyce’s afternoon, a story; Stuart Moulthrop’s Victory Garden; Shelley Jackson’s Patchwork Girl; Carolyn Guyer’s Quibbling; Joyce’s later Twelve Blue; Judy Malloy’s its name was Penelope; and others. The works were sold as physical media — a floppy disk or a CD in a small box, with a slim printed booklet — at prices in the same range as expensive trade hardcovers, fifty to one hundred dollars each. They had ISBN numbers. They were reviewed in literary journals, including some that did not normally cover digital work. They were taught in graduate programs.

Eastgate also developed Tinderbox, a personal hypertext tool by Bernstein himself, which has continued to be sold and updated through the present and is the closest thing the world has now to a maintained desktop hypertext authoring system. Tinderbox is used by writers, researchers, lawyers, and other professionals for personal note-taking and structured thinking; its install base is small but devoted, and it descends directly from Storyspace’s structural assumptions about how writing should be organized.

The canonical works

Michael Joyce’s afternoon, a story is the work usually cited as the first major literary hypertext. Joyce completed it in 1987 and Eastgate published it commercially in 1990. afternoon is a story about a man named Peter who, driving to work in the morning, sees an accident on the road and gradually comes to suspect that the people he saw may have been his ex-wife and son. The work consists of 539 writing spaces; depending on the path the reader takes, the story can be read as a meditation on memory, an account of marital betrayal, a psychological study of trauma, or simply a series of impressions of a morning’s ambiguous events. Joyce’s use of guard fields means that the same passage, read in different orders, takes on different meanings, and some passages are reachable only after the reader has visited specific others. The work is short by novel standards — readable in a couple of hours along any one path — but the totality of possible readings is much larger, and most readers have come back to afternoon multiple times to follow different paths.

Stuart Moulthrop’s Victory Garden (1991) is more political and structurally more ambitious. Set during the first Gulf War in 1991, it interleaves the lives of a group of academics and students at a Southern university with the news coverage of the war and a series of dreams and reflections about violence, place, and history. The work is much longer than afternoon — over 900 writing spaces — and uses Storyspace’s branching more aggressively. Moulthrop, an academic at the University of Baltimore for most of his subsequent career, wrote about Victory Garden in his subsequent critical work and is one of the major theoretical voices in literary hypertext alongside George Landow, Jay Bolter, and N. Katherine Hayles.

Shelley Jackson’s Patchwork Girl (1995) is the work most often taught and most often cited as evidence that hypertext can produce art at the highest level. The premise is that Mary Shelley, in the aftermath of writing Frankenstein, builds a female monster for the creature — the female counterpart that Victor Frankenstein refuses to make in the novel — and that the female monster (the patchwork girl of the title) speaks in the work, telling stories about the women whose body parts she was assembled from. The structure is a body: the writing spaces are arranged anatomically, and the reader navigates by selecting parts of the body. Jackson’s prose is dense, allusive, and beautiful; the work’s structural choices reinforce its thematic preoccupation with assemblage and fragmentation; the relationship between hypertext form and the text’s content is closer than in any other work in the canon. Patchwork Girl has been the focus of more academic critical writing than any other single hypertext, and is the work most often handed to a skeptic who doubts that hypertext can be literature.

The canon is not large. Eastgate’s catalog of original literary hypertext extends to perhaps twenty or thirty significant works over the period 1990 to roughly 2005. Other small presses and academic projects produced more; the Electronic Literature Organization, founded in 1999, has tried to maintain a directory. The total population of works that anyone has called important literary hypertext is in the low hundreds. By the standards of conventional literary publishing this is tiny; by the standards of an experimental form working in a niche medium it is substantial.

The critical apparatus

Literary hypertext had, almost from the beginning, a critical apparatus that took it seriously. Robert Coover, the novelist and Brown professor, published “The End of Books” in The New York Times Book Review on June 21, 1992, an essay that announced literary hypertext to the broad reading public and made the case that the form represented a serious next stage in literature. Coover taught a graduate course at Brown in hypertext fiction beginning around 1990, with Michael Joyce and other practitioners as visiting figures; the course was the first sustained academic instruction in writing hypertext as a literary form. Bolter’s Writing Space (1991) was the most influential theoretical book on hypertext as a writing technology. George Landow’s Hypertext (1992), already mentioned in the previous chapter, made the case that hypertext realized in technical form what poststructuralist theory had been describing about the nature of textuality. N. Katherine Hayles’s later work, especially Writing Machines (2002) and Electronic Literature (2008), took the field’s critical apparatus into the post-web era. Espen Aarseth’s Cybertext (1997), in a slightly different register, treated nonlinear texts of all kinds — hypertexts, interactive fiction, games — under a unified concept of “ergodic literature,” literature requiring nontrivial effort from the reader.

The combined effect of this critical work was to give literary hypertext a place in the academic conversation about what literature was. The place was contested — many critics outside the small community of practitioners and theorists remained skeptical — but it was real. By the mid-1990s, “hypertext fiction” was a thing the literary studies world knew existed, and the canonical works were in syllabi at a number of universities.

The community

The community that produced and read literary hypertext was small and densely connected. Most of the writers knew each other. They met at the ACM Hypertext conferences, at the smaller “Hypertext, Hypermedia, and Hyperliterature” gatherings that grew up alongside, at the Modern Language Association, and at events Eastgate sponsored. Mark Bernstein at Eastgate was the institutional center: he published the works, attended the conferences, wrote criticism of his own, and maintained the social network that kept the field cohesive. The writers also taught each other’s work: Moulthrop assigned Joyce, Joyce assigned Moulthrop, Jackson assigned both, and the canon was self-curated through the syllabi of the small number of programs teaching it.

The community had a magazine of sorts in the American Book Review, which published occasional essays on hypertext, and in the early online journal Postmodern Culture, founded in 1990 and one of the first peer-reviewed humanities journals to publish exclusively online. There was an annual Hypertext anthology edited at various points by Eastgate. Cathy Marshall, then at Texas A&M (and earlier at PARC), wrote frequently about the form. There was a critical mass.

The community also had the partial sponsorship of literary celebrities. Coover’s involvement was the most visible, but Robert Pinsky, John Barth, and other established writers expressed interest at various points. Donald Barthelme had been writing nonlinear pieces for The New Yorker and elsewhere in print form since the 1960s; his work was often cited as a precursor. The form did not lack for prestige in the years it was active.

Why the form did not migrate to the web

The web arrived in the middle of literary hypertext’s most active period and produced an obvious question: why not publish hypertext fiction on the web, where it could be read by anyone, instead of on disk through Eastgate? The question was raised at the time and answered in several ways, none of which fully account for why the migration did not happen at scale.

One answer is that the web’s link model was structurally inferior for literary purposes. Storyspace’s guard fields — links that became visible based on reading history — had no native counterpart on the web. To replicate them, you needed JavaScript, which in the mid-1990s was new, fragile, and not universally implemented. You could not, in 1996, reliably build a Storyspace-like work on the web. You can now. The lag of about five years was enough to break the momentum.

A second answer is that Eastgate was a publisher with an economic model and the web was a medium without one. Eastgate sold disks for thirty to a hundred dollars. The literary hypertext community paid the writers, modestly, through these sales. The free web disrupted this not through hostility but through default expectation: readers had been trained, by 1996 or so, to expect that what they read on the web was free. Moving the works to the web meant moving them out of the economic relationship that had supported their production. Some works did move. Joyce’s Twelve Blue (1996) was published on the web rather than on disk and is still available there. Other works followed. But the economic transition was not solved, and the rate of new production slowed.

A third answer is that the web’s authoring culture absorbed the kind of writer who might have written hypertext fiction. The blogging tools of the late 1990s and early 2000s gave writers a much larger audience than Eastgate could provide. The audience came with the cost that the form was different: a blog is sequential and dated, not branching and structural. Many of the writers who had been working in hypertext on disk shifted to blogs or other web-native forms. They did not stop writing; they stopped writing hypertext in the structural sense.

A fourth answer, less material but still relevant, is that the cultural moment for the form passed. The early 1990s had been a period of considerable enthusiasm about hypertext as the future of literature. By the early 2000s the conversation about literature on the internet had moved on, to blogs, to fan fiction, to online journals, to e-books, and the specific structural ambitions of the 1990s hypertext canon were no longer at the center of anyone’s attention. The form did not die; the conversation around it became smaller and more specialized.

What is being recovered

Twine, an open-source tool first released by Chris Klimas in 2009, has been the focus of literary hypertext’s recovery in the 2010s. Twine is a Storyspace-descendant: it lets writers create branching narratives with conditional logic, publish them as standalone web pages, and share them freely. Twine has been taken up enthusiastically by a generation of writers, particularly in interactive fiction and game communities, and has produced a substantial body of work — Anna Anthropy’s queers in love at the end of the world, Porpentine’s various works, Michael Lutz’s The Uncle Who Works for Nintendo, many others — that constitutes a second wave of literary hypertext in web-native form. The Twine canon is larger than the Storyspace canon, more diverse demographically, and operating outside the print-publishing economy through patronage, game-distribution platforms, and direct community support. It is a genuine recovery of the form, in a different shape than Eastgate’s.

Interactive fiction more broadly — the descendants of the Infocom text adventures of the 1980s, surviving through community tools like Inform 7 and through new platforms like Choice of Games — is a parallel tradition that overlaps with literary hypertext in important ways. The Interactive Fiction Database catalogs thousands of works. The IF community produces criticism, holds annual competitions, and continues to evolve. It is not the same as the literary hypertext canon, and most of its participants do not think of themselves in the Storyspace lineage, but the structural concerns — branching narrative, reader agency, choice as a meaning-making act — overlap substantially.

The dynamic document tradition treated in chapter twenty has, separately, recovered some of what hypertext was attempting. Bret Victor’s explorables, the Observable notebooks, and Glamorous Toolkit are all attempts to produce documents that are also computations, in which the reader’s interaction with the document changes what the document shows. This is not literary hypertext, exactly, but it is a continuation of the underlying claim that a document can be a thing the reader does, not just a thing the reader looks at.

What does not survive

The Eastgate canon itself is at risk. The works were published on diskette and on CD-ROM, in formats requiring specific operating systems and Storyspace versions. afternoon runs on classic Mac OS; Patchwork Girl runs on classic Mac OS or early Windows; both require Storyspace, which Eastgate continues to maintain but which is not part of any current operating system’s standard environment. Reading these works in 2026 requires either emulation or one of a small number of preserved authoring environments. The Electronic Literature Organization and various academic preservation projects have been working on the problem; the works have been re-issued in newer Storyspace versions periodically; but the long-term preservation question is open. A literature that depends on a specific software environment is, at the limit, a literature with an expiration date.

This is a loss the broader web has avoided through its own technical conservatism: a 1995 HTML page is still readable in 2026, because the web’s standards have evolved compatibly. The literary hypertext canon does not have this property. The works require their tools, and the tools are no longer running on the current generation of machines without help. The form has produced a body of work, and the body of work is in danger of being legible only to specialists who maintain the emulation environment.

The lesson

Literary hypertext is the answer to the question of what hypermedia could do as an art form rather than as a technology. The answer is that it could do real things — could produce works that critics took seriously, that programs of study were built around, that other writers took as models. The form did not become mainstream and probably could not have, given the constraints of the medium and the economic structure that supported it. But the form existed, the works exist, and the question of whether literary hypertext was a viable art form is not, as the dismissive accounts sometimes suggest, an open one. It was viable, briefly, in a particular institutional and technological window, and the closing of that window in the late 1990s was a loss not because the form was guaranteed to produce a thousand more masterworks but because the form had not been exhausted.

The next chapter goes to the third strand of hypermedia, less literary and less ambitious than either Brown’s or Eastgate’s, but in some ways the most directly recovered today. NoteCards at Xerox PARC, KMS at Carnegie Mellon, and the smaller knowledge-base tradition that grew up around them treated hypertext primarily as a tool for thought rather than as a tool for publishing or for literature. The systems they produced were used by their builders to do intellectual work — research, theorem-proving, software design, writing — and the use revealed properties of hypertext that the other traditions had touched less directly. The recovery, in Roam and Obsidian and Logseq, has been substantial.

NoteCards, KMS, and the knowledge-base lineage

The third strand of pre-web hypermedia, after Xanadu’s publishing ambitions and Brown’s literary-academic ones, was the knowledge-base lineage. It treated hypertext primarily as a tool for thought. The systems in this strand were built by their researchers for their researchers to use as instruments of intellectual work — design, theorem proving, writing, software architecture, argumentation. The systems were used in production, by their builders, for years at a time, on real problems. They produced a body of practical knowledge about what hypertext was useful for, what it was not useful for, and what shape a hypertext system had to have to support sustained intellectual work. The two flagship systems in this strand are NoteCards, built at Xerox PARC by Frank Halasz, Randy Trigg, and Tom Moran in the mid-1980s, and KMS, built by Knowledge Systems Inc. as the commercial descendant of CMU’s ZOG project. A third project, gIBIS, sat alongside them and pioneered the argument-mapping tradition that has been the most directly recovered in the recent personal-knowledge-tools wave. None of these systems is famous outside the small history-of-hypertext literature. All of them are, in their substantive contributions, more directly present in the current generation of tools (Roam, Obsidian, Logseq, Tana) than any of the more-celebrated lineages.

NoteCards at PARC

Xerox PARC is the research lab whose work in the 1970s and 1980s shaped almost everything about modern personal computing, mostly indirectly through the people who left it. NoteCards was a PARC project of the mid-1980s, after the Alto and Smalltalk and the laser printer and Ethernet had already established PARC’s reputation, and at a moment when the lab was still funded well enough to produce serious research software. NoteCards was developed primarily by Frank Halasz, Randall Trigg, and Thomas Moran. Halasz was the technical lead; Trigg, who had completed a doctoral thesis at the University of Maryland in 1983 on a hypertext system called Textnet, brought a research history in linking-as-citation; Moran was a cognitive scientist who studied how people actually used the system. The combination — engineer, hypertext researcher, cognitive scientist — gave the project an unusual depth of attention to whether what the system did and what users did with it were the same thing.

The data model was simple. The unit was a “card”: a rectangular note holding some content (text, graphic, sketch, image, structured list, embedded subsystem) and located at a specific position in two-dimensional space inside a “filebox.” Fileboxes could contain other fileboxes, recursively. Cards could be linked to other cards by typed links: a link had a name describing the kind of relation it represented, and the type vocabulary was extensible by users. The link was a directed relationship; the back-link was automatically maintained so that, looking at any card, the user could see what other cards linked to it. The whole structure was browsable in multiple views: as a graph (showing cards as nodes and links as arcs), as a filebox tree, as a list of recently visited cards, as a search-result set.

What made NoteCards influential was less the data model — every hypermedia system of the period had some version of nodes and links — than the way users used it. Trigg, Moran, and colleagues published a series of empirical studies of NoteCards in practice. They watched researchers, themselves and others, use the system over long periods of time on real intellectual projects, and reported on what worked and what did not. The studies are still cited because they are unusually frank. The reports cover the use of NoteCards to write papers, to design software, to plan experiments, to manage research correspondence, to draft talks. They cover failures: where users got lost in the graph, where the filebox hierarchy became unmanageable, where the system’s tools for restructuring did not match the way users wanted to restructure. They cover successes: how the link-types vocabulary evolved through use, how certain users developed distinctive personal styles of organization, how the practice of using NoteCards changed the way users thought about their work.

One of the central findings, articulated in Halasz’s 1988 paper “Reflections on NoteCards: Seven Issues for the Next Generation of Hypermedia Systems,” was that the system needed support for what Halasz called “composite nodes”: cards that were assembled from other cards, presented as a unit, but retaining the structure of their components. The user-facing problem was that an idea expressed across several cards was harder to manage than the same idea expressed in one card, because the system did not give the user a way to treat the cluster as a single object. NoteCards did not solve this fully; Halasz’s paper was, in significant part, a call for next-generation systems to solve it. The current generation of knowledge tools — Roam in particular — has solved it through the device of block-level transclusion, in which any block on any page can be referenced and displayed inside any other page, retaining its identity and updateability. Halasz’s seven issues were a research agenda; the recovery has not addressed all seven, but several have been addressed in narrow form.

NoteCards ran on Xerox D-machines — Dolphins, Dorados, and similar Interlisp-based workstations — that were never sold to a mass market. The system was used inside PARC and at a handful of external sites that had compatible hardware. The user community was perhaps a few hundred people at peak. When the D-machine line was discontinued and PARC’s funding model changed in the late 1980s, NoteCards stopped being developed; the research findings outlived the system. Halasz left PARC for academia and later industry; Trigg continued at PARC on related work; Moran moved into design research more broadly. The lineage of NoteCards’ specific design choices runs through subsequent PARC projects (Aquanet, VIKI, others), into Marshall and Shipman’s “spatial hypertext” research that continued through the 1990s, and eventually into the commercial wave that began in the late 2010s with Roam.

ZOG and KMS

The other major knowledge-base system of the period had a different lineage and a different feel. ZOG was a Carnegie Mellon project that began in 1972 under Allen Newell, with George Robertson as the principal designer and contributions from Donald McCracken and Robert Akscyn among others. The system was built on the CMU mainframes of the early 1970s and was, in its initial form, a menu-driven information retrieval system: screens of structured text with selectable items at the bottom, leading to other screens. The design was austere and the operations were fast: a ZOG screen could be navigated in fractions of a second, and the system was designed around the principle that the user should never have to wait for the next screen to appear. ZOG was deployed in production at CMU and aboard the USS Carl Vinson aircraft carrier, where the Navy used it for crew training and reference. The Vinson deployment is worth pausing on: it is one of the few examples in the history of hypermedia of a system being used by a non-academic, non-research user population for years at a time as their primary information system.

Akscyn and McCracken left CMU in the early 1980s to found Knowledge Systems Inc. and commercialize the ZOG approach. The result was KMS, the Knowledge Management System, released in the mid-1980s and developed through the late 1980s and into the 1990s. KMS preserved ZOG’s central commitment to speed: the system was designed so that navigation was effectively instantaneous, with sub-second response times on every operation. The data model was a flat space of frames; every frame was identified by a name and contained structured content. Links between frames were inline annotations attached to specific items inside a frame. There was no separate addressing scheme for sub-frame elements; the unit of linking was the frame, and the within-frame structure was an authorial convention rather than a first-class object.

KMS was sold commercially to engineering and information-intensive enterprises. It was used at Boeing for technical documentation, at Westinghouse for plant management systems, at a number of other industrial sites. The KMS user base was perhaps tens of thousands across the customer organizations. The system’s design choices — fast navigation, simple data model, integration with existing institutional document workflows — were optimized for the working-day use of professionals, not for the literary or research uses the other systems aimed at.

Akscyn and McCracken’s 1988 paper “KMS: A Distributed Hypermedia System for Managing Knowledge in Organizations” argued, against the more elaborate research systems, that hypermedia’s value at scale came from being unfussy. A user opening KMS could navigate any frame in the corpus in seconds; the system was on every desk in the organization; the frames were authored by people in the organization for their own use and the use of their colleagues. The argument was that this kind of low-ambition, high-frequency use was where hypermedia would actually live, if it lived anywhere, and that the research systems’ elaborate features were not what made the difference. The argument was, in retrospect, prescient about what wiki software would later look like. Ward Cunningham, the original wiki author, has cited KMS as one of his influences.

KMS continued to be sold and supported into the mid-1990s, when the web began absorbing the use cases. Knowledge Systems Inc. continued to exist as a smaller business and the KMS user base, like much else in this book, gradually migrated to web-based systems. The Knowledge Systems lineage did not produce a direct successor product; what the system had to offer was largely subsumed into the wiki and intranet generation that followed.

IBIS and gIBIS

A parallel lineage, smaller in scope but historically important, came from the work of Horst Rittel and Werner Kunz on Issue-Based Information Systems (IBIS) in the 1970s. Rittel had developed, in his work on what he called “wicked problems” in design and policy, a method for capturing the structure of an argument as a graph of issues, positions, and arguments. An IBIS diagram laid out the issue under discussion as a node, the positions taken on the issue as connected nodes, and the arguments for and against each position as further connected nodes. The structure was navigable: one could trace from an issue through the positions and arguments to see how a discussion had developed. Rittel proposed the method for use in design teams, planning bodies, and other settings where the rationale behind decisions needed to be made visible and durable.

gIBIS, the graphical IBIS, was a software implementation built at MCC in Austin, Texas, in the late 1980s by Jeff Conklin and Michael Begeman. gIBIS turned Rittel’s paper-based method into a hypermedia system: users could create issue nodes, position nodes, and argument nodes; could link them according to the IBIS conventions; and could view the resulting graph and navigate around it. The system was used in design meetings at MCC and at a number of customer sites. Conklin and Begeman published several papers reporting on the use, and Conklin’s subsequent book Dialogue Mapping (2005) extended the IBIS approach into a wider audience of facilitation practitioners. The method, distinct from the software, continues to be taught in some design and facilitation programs.

The IBIS / gIBIS lineage is the most direct precursor of the current generation of “Tools for Thought” that explicitly position themselves as supports for structured thinking. Roam Research, Obsidian’s various plugin extensions for graph view, and the smaller specialty tools (Heptabase, Kinopio, Scrintal) all carry forward the basic IBIS impulse: that the graph of a thinker’s argument is itself an artifact worth producing and preserving. The tools have moved away from IBIS’s specific argument grammar — they do not, generally, require nodes to be classified as issues or positions or arguments — but the underlying conviction that the structure of thought is worth making visible and navigable is the same.

What these systems shared

The knowledge-base systems differed in many specifics — NoteCards was graphical and Lisp-based, KMS was textual and optimized for speed, gIBIS was structured around a specific argumentation grammar — but they shared a set of assumptions that distinguishes them from the other hypermedia traditions in this book.

They assumed the primary user was the same person as the primary author. The systems were not publishing tools; they were thinking tools, used by their users to organize their own ongoing intellectual work. The model audience was the person sitting at the workstation, working on a long-running problem, and accumulating notes, links, and structures as they went. The system’s job was to make that accumulation useful — to make the user’s own past work findable, traversable, and combinable with their current work.

They assumed the work was durable. A NoteCards user accumulated cards over months and years on a sustained research project; a KMS user added frames to a corporate corpus that was expected to last as long as the corporation did; a gIBIS user was producing argument structures that would be referred to in later design decisions. The systems were optimized for long-term accumulation rather than short-term publishing.

They assumed the user knew what they were doing or would learn. The systems were not designed to be approachable to casual users. NoteCards required learning the link types, the filebox conventions, the navigation idioms; KMS required learning the frame-and-name addressing scheme and the inline-link conventions; gIBIS required learning the IBIS grammar. The expected payoff for the investment was that the user, once trained, would be able to do intellectual work the system specifically supported.

They assumed thinking was structural. The whole point of these systems was that ideas had structure, that the structure was worth capturing, and that captured structure could be reused and extended. This is in tension with the more-recent doctrine that good user interfaces should let users do what they want without imposing models. The knowledge-base systems imposed models, deliberately, because the models were the value.

The intersection of these assumptions is approximately the user the current personal-knowledge-tools wave has rediscovered. The Roam user, the Obsidian power user, the Logseq devotee — these are people who think structure is worth capturing, who are working on long-running personal projects, who have invested time in learning a specific way of organizing notes, who treat their notes as a substrate for their thinking rather than as a publishing medium. The lineage runs straight back to NoteCards.

Why these systems did not become mainstream

The reason the knowledge-base systems did not become mass-market software is largely the reason every system in this book did not become mass-market software in the pre-web era: they ran on hardware most people did not have, in software environments that required institutional support, with learning curves that excluded casual users. NoteCards required a Xerox D-machine; KMS required a workstation-class machine and the KMS license; gIBIS required MCC’s environment and the IBIS training. None of these were tools you could pick up at the consumer-electronics store. The systems were designed for the workstation era; they did not have a natural path into the personal-computer era; they did not survive the transition.

The web, when it arrived, did not absorb these systems’ specific capabilities. The early web was designed for publishing, not for sustained personal intellectual work. Wikis, which began with Ward Cunningham’s WikiWikiWeb in March 1995, recovered some of what KMS had been doing — fast, low-ceremony, collaborative editing of a structured knowledge base — for groups rather than individuals. Wikis spread, became substantial knowledge bases at organizations and online, and culminated in Wikipedia, which is the largest knowledge-base hypertext in the world. But Wikipedia is a publication, not a thinking tool. It is a finished artifact intended to be read; it is not, for most users, a substrate they use to do their own intellectual work. The space that NoteCards and KMS had occupied — the individual or small-team thinking tool, with hypermedia structure, used over years on long-running projects — remained mostly unoccupied through the 2000s and most of the 2010s.

The recovery, in brief

The recovery is the subject of chapter twenty-four. Here it is enough to note that it is real, ongoing, and substantial. Roam Research’s launch in 2017 (general availability 2019) marked the beginning of a wave of personal knowledge management tools that revived, in browser-based or desktop form, much of what the knowledge-base lineage had been doing. Obsidian, Logseq, RemNote, Tana, Heptabase, Reflect, Capacities, and a half-dozen others have all entered the same space. The tools differ in details but share a common ancestry: they treat notes as a network of linked, addressable, often block-level units; they support bidirectional linking; they offer graph-view visualizations of the link structure; they are designed for long-term personal use rather than for publication.

Most of the developers of these tools are aware, to varying degrees, of the historical lineage. Roam’s name is a reference to Engelbart’s “ROAM” — the early NLS prototype was sometimes called that — and the founders, particularly Conor White-Sullivan, have cited Engelbart explicitly. Obsidian’s developers have cited Vannevar Bush. The discourse around the current wave is sometimes uncomfortable for people who lived through the previous waves, because the new tools sometimes present themselves as recent inventions when they are recoveries; but the recoveries are real, and the users of the new tools are doing, in 2026, much of what the NoteCards users were doing in 1986.

The lost intermediate decades

The thirty-year gap between NoteCards (and KMS, and gIBIS) and Roam is worth marking. For most of those thirty years, the kind of work these systems supported was harder to do than it had been in 1986. There were attempts to fill the space: Lotus Agenda (1988-1992), various outliners (More, Ecco Pro), Personal Brain (since 1998 in some form), Tinderbox (since 2002), various specialty knowledge tools. None of them caught fire. The mass market was on the web, the web was a publishing system, and the publishing system did not give users a place to keep their own thinking.

The cost of this thirty-year gap is hard to measure. It is the difference, summed across a generation of knowledge workers, between having a tool designed to support sustained thinking and not having one. Most of the work that should have happened in such tools happened instead in email, in Word documents, in spreadsheets, in scattered text files, in browser bookmarks — in formats that were never designed for accumulation, that did not support linking in any serious way, and that produced no durable substrate. The intermediate decades are a loss the recovery is now slowly making up for, but the work that was not done because the tools were not available is gone.

The lineage section of the book ends here. The next part shifts from hypermedia systems to the other side of what the pre-web internet was: the protocols and architectures that proposed answers to the question of how networked services should be structured, separately from how documents within those services should be linked. Gopher, the first chapter in Part III, is the cleanest case of the contest. It was released the same year as the web, was the web’s principal competitor for two years, was technically simpler in many respects, and lost the contest in a way that turned on a single institutional decision that the people who made it now wish they had made differently.

Gopher and the case for hierarchy

The cleanest case of the contest treated in this book is Gopher. It was released in April 1991, two months before the first public version of the web outside CERN; it grew faster than the web for two years; it had, in late 1992 and early 1993, more servers and more users than the web; it was widely deployed across the academic internet, with substantial industrial uptake beginning; it was technically simpler than the web in several respects that mattered for operators; and it was, by the end of 1995, a finished product whose use was almost entirely confined to a small archival community. Gopher’s story is the story of how an internet protocol can win the early adoption contest, hold the technical lead by most measures, and lose anyway, decisively, in a way that turned on one institutional decision made in March 1993 that the people who made it have publicly regretted. This chapter is about what Gopher was, what its argument for hierarchy was as a design choice, why the contest with the web tilted the way it did, and what hierarchical navigation has been recovered as on the web that absorbed Gopher’s ideas in degraded form.

What Gopher was

Gopher was created by a small team at the University of Minnesota’s Microcomputer and Workstation Networks Center, principally Mark McCahill, Farhad Anklesaria, Paul Lindner, Daniel Torrey, and Bob Alberti. The first public release was in April 1991. The team had been working, before Gopher, on a campus-wide information system to help students and faculty find information distributed across various Minnesota servers; Gopher was the result of that work. The name was a pun: a “gopher” was the colloquial term for an office assistant who went to fetch things, and the gopher was also the University of Minnesota’s athletic mascot. The protocol was as simple as the name suggested.

A Gopher server, running on TCP port 70, presented a hierarchy of menus. Each menu was a list of items. Each item had a type — file, directory, search service, Telnet session, image, sound, binary executable, and a few others — and a name and a target. A Gopher client connected to a server, requested a menu, displayed the menu items to the user, and let the user select an item to follow. If the item was a directory, the client requested that directory’s menu and displayed it. If the item was a file, the client retrieved and displayed the file. If the item was a search service, the client prompted the user for a query and submitted it. If the item was a Telnet session, the client opened a Telnet connection to the specified host.

The whole protocol fits on a few pages. RFC 1436, the Gopher specification, was published in March 1993 and is one of the shorter RFCs in the protocol series. There were a few command bytes, a tab-separated response format, and a small set of item-type codes. Implementing a Gopher server was a weekend project. Implementing a Gopher client was a weekend project. The simplicity made the protocol portable: Gopher clients existed for Unix, VMS, DOS, Windows, Mac, and most other systems with TCP/IP stacks. Gopher servers existed for an even wider range of platforms. By late 1992 there were a few hundred public Gopher servers; by mid-1993 there were several thousand.

The case for hierarchy

The design argument Gopher made — implicit in its protocol, explicit in its documentation — was that information should be organized hierarchically and navigated by selection from menus. The argument has more substance than the dismissive accounts of Gopher tend to acknowledge.

Hierarchies are predictable. A user navigating a hierarchy knows what kind of thing to expect at each level: the top-level menu describes broad categories, the next level describes subcategories, and so on down to the leaves. The user can form expectations about where to find a specific kind of information without having to know in advance where it is. This is the property that has kept hierarchies the dominant organizing principle for libraries, file systems, and bureaucracies for thousands of years. The web’s reaction against hierarchy was, in a sense, a reaction against the central organizing principle of all prior information systems, and it is worth taking seriously the possibility that the reaction was wrong.

Hierarchies make orientation easy. A user navigating a hierarchy always knows where they are: they have descended from the root along a known path, and they can return to any ancestor by ascending one step at a time. The web’s reaction against hierarchy was a reaction against this property too. On the web, a user can arrive at a page from anywhere; the page does not always make clear where it sits in a larger structure; there is no canonical “up” from most web pages, and the back button is the closest thing the web offers to a hierarchical retreat. Web usability research throughout the late 1990s and 2000s repeatedly identified disorientation as one of the most common user problems, and design conventions like the “breadcrumb trail” exist specifically to retrofit hierarchical orientation onto a system that does not have it natively.

Hierarchies are explicit about authority. The administrator of a Gopher hierarchy decided what categories existed and what fit under each. A user looking at the menu was looking at the administrator’s classification of the available material. This is, in some ways, paternalistic; it imposes a particular structure on the user’s exploration. It is also informative: the user knows, by looking at the menu, what the administrator thought was important enough to surface and how the administrator thought the material related. The web’s reaction against hierarchy was also a reaction against this kind of explicit editorial framing. A web user navigating a corpus of pages typically encounters the pages in the order their search engine returned them, with no editorial structure visible. The cost of the web’s anti-editorial bias is that the user must do the structuring work themselves; the benefit is that the user is not constrained by some other party’s structure.

The case for hierarchy, then, is a case for predictability, orientation, and explicit editorial framing as virtues of an information system. The case is not foolish. The systems that compete with hierarchy — full-text search, associative links, faceted classification — make different trade-offs and lose what hierarchy provides. Modern interfaces typically combine all of them: a file system has both a directory hierarchy and a search box. Gopher was a system that took the hierarchy side of the trade-off seriously and made the others available only as auxiliary services.

Veronica, Jughead, and the index ecosystem

Gopher was not pure hierarchy. The protocol included a search-service item type, and Gopher quickly accumulated search tools that indexed gopherspace as a whole. The most important was Veronica, developed at the University of Nevada, Reno, by Steve Foster and Fred Barrie in 1992. The name was a pun on Archie, the FTP search tool, with both names eventually accumulating the additional reference to the Archie Comics characters as the joke deepened. Veronica indexed the menus of Gopher servers worldwide and let users search for items by title across the whole gopherspace. A second tool, Jughead (developed by Rhett Jones at the University of Utah), did the same for single Gopher servers or limited subtrees.

The Veronica index was the closest thing the pre-web internet had to a search engine in the modern sense. It was less rich than what AltaVista would offer in 1995 — Veronica indexed only menu titles, not the contents of documents — but it was a working federated index of a substantial corpus, deployed at multiple sites, with reasonable performance and broad usefulness. The Veronica architecture had a property that the search engines that displaced it did not preserve: there were multiple Veronica instances run by different operators, each indexing some portion of gopherspace, each available for use through a Gopher menu, each producing results that the user could see were limited to that index’s coverage. The federated structure of Gopher search was visible to the user. Search was a peer service in Gopher, exactly as WAIS proposed for the broader internet (the next chapter), and the contrast with the eventual centralization of web search at a small number of companies is part of what was lost when the web absorbed Gopher’s audience.

The 1993 licensing decision

In March 1993, the University of Minnesota announced that it would begin charging licensing fees for the Gopher server software when used in commercial settings. The fees were modest — five hundred dollars per server, with smaller amounts for smaller deployments — and were specifically restricted to commercial use; academic and non-commercial users could continue using Gopher without charge. The university’s reasoning was that Gopher had developed into a real software product, that supporting it cost real money, and that commercial users who were running it as part of their business should contribute to the cost.

This was a normal kind of decision in the academic software-licensing world. Many universities licensed their software to commercial users; the X Window System, for instance, was licensed by MIT with similar terms; the Berkeley Software Distribution had complex licensing arrangements that became, in the early 1990s, the subject of significant litigation. Minnesota’s terms were not unusually restrictive. They were not, in absolute terms, expensive. The decision was, in retrospect, reasonable on its own merits.

The effect on Gopher’s adoption was nevertheless catastrophic. The institutional users who had been considering Gopher for commercial deployment now had to negotiate license terms, get sign-offs from their legal departments, and assume the maintenance of an ongoing commercial relationship with the University of Minnesota. Many of them decided this was more administrative friction than the system was worth. The decision arrived at the worst possible time, in early 1993, just as commercial interest in internet services was beginning to accelerate. Commercial decision-makers were comparing Gopher with a hypothetical alternative — there were still very few web servers — and the comparison shifted in the web’s direction the moment Gopher acquired an ongoing licensing cost and the web did not.

CERN, which had been considering its own licensing position, responded to the Gopher decision the next month. On April 30, 1993, CERN released a statement making the web protocol specifications — HTTP, HTML, the URL syntax, the reference implementations — public-domain, with no restrictions on use, commercial or otherwise. The decision was made by Robert Cailliau and others at CERN, with Tim Berners-Lee’s involvement; the statement was specifically intended to remove any uncertainty that institutions might have about whether using the web would create future licensing obligations. The contrast with Minnesota’s announcement could not have been clearer, and the announcement was widely read at the time as a deliberate competitive response to Gopher.

The Minnesota team has been candid, in subsequent interviews, that the licensing announcement was the moment Gopher lost. McCahill has said the announcement was a mistake. Lindner has said that what looked like a routine commercialization decision became, in a few months, the inflection point at which institutional momentum shifted to the web. The team modified the licensing terms later in 1993, dropping the fees, but the damage was done. Institutions that had paused their Gopher rollouts to evaluate the licensing situation never came back. Many of them moved to the web instead.

This is, in many ways, an unsatisfying story. A single institutional decision, made under reasonable considerations, became a major factor in determining the shape of the internet for the next three decades. The dependency of the outcome on the decision is real but feels disproportionate. It is worth saying directly: Gopher was not doomed in March 1993. Several other factors were also pushing toward the web, particularly Mosaic’s arrival in early 1993 and the web’s faster development pace through that year. But the licensing announcement was the moment the trajectory became visible to the people who were paying attention, and it was the moment most of the technical and institutional momentum behind Gopher began to dissipate.

Gopher+ and the late phase

The Minnesota team did not give up. In late 1993 they released Gopher+, an extended version of the protocol that added several features the web had and Gopher had lacked: attributes for menu items (a kind of richer metadata), multiple representations of the same item (so a file could be retrieved in several formats), forms for user input, and a set of conventions for richer interaction. Gopher+ was, in many ways, a closer competitor to early HTTP than original Gopher had been. It was deployed at a number of sites and supported by some clients, but it never reached the saturation level of original Gopher, and it did not stem the migration to the web.

The Gopher protocol continued to be developed in small increments through the mid-1990s. The University of Minnesota maintained the canonical server software. Various third-party clients and servers continued to be developed, including some open-source ones. By 1996 or 1997 the protocol was essentially in maintenance mode; new development had stopped, the user base was shrinking, and the institutional sites that had been the protocol’s backbone were largely migrating their content to web servers. Some content remained on Gopher servers — particularly archival material that was never migrated — but the protocol’s role in the live internet was over.

The Gopher community’s persistence

What is striking about Gopher’s afterlife is that the protocol did not die. It went into a kind of stasis, and a small but persistent community continues to use it. The Floodgap Gopher server, run by Cameron Kaiser since 1999, has been a focal point of the modern Gopher community; it hosts and indexes a substantial corpus of Gopher content, including new content produced specifically for the protocol. The Pygopherd server, written by John Goerzen, has provided a modern Gopher server implementation since 2002. New Gopher clients are available for current operating systems; new content is being produced; small communities of users use Gopher daily as their primary internet protocol.

This persistence is partly nostalgia and partly principled choice. The community of people who use Gopher in 2026 is small — perhaps in the low thousands — but it is articulate about what Gopher offers that the web does not. The protocol is simple. The content is free of advertising, tracking, and javascript. The clients are fast. The corpus is small enough that browsing it feels like a navigable activity rather than a search-mediated one. The hierarchy is intact. Gopher in 2026 is, for the people who use it, a working illustration of what the internet had been before the consolidation and commercialization of the web. The Gemini protocol, treated in chapter twenty-three, is a partial successor to Gopher that has emerged in the 2020s and is, in many ways, a deliberate effort to recover what Gopher had been.

What the web absorbed and degraded

The web absorbed parts of Gopher’s design. Yahoo, founded in 1994 by Jerry Yang and David Filo, was a hierarchical directory of web pages — essentially Gopher’s organizing principle applied to the web’s content. Yahoo was, for much of the 1990s, the dominant entry point to the web; users typed yahoo.com into their browsers and walked the hierarchy of categories to find what they wanted. The Yahoo directory was Gopher’s idea, retrofitted onto a system that had been built specifically against the hierarchical model.

Yahoo’s directory was overtaken, in the late 1990s, by full-text search engines — first AltaVista (1995), then Google (1998). The shift from directory to search was the moment the web definitively chose against hierarchy as its primary organizing principle. Yahoo’s directory was deprecated, then dismantled. The DMOZ Open Directory Project, a volunteer-edited hierarchical directory of the web that had been a major Yahoo competitor through the early 2000s, was closed in 2017 after twenty years of operation. The hierarchical-directory model lives on in vestigial form (the navigation menus of most websites are local hierarchies; Wikipedia’s category system is a directory) but is not how anyone finds anything on the broader web.

The cost of the shift is hard to measure but real. A user navigating the Yahoo directory in 1996 was looking at an editor’s classification of the web’s content into categories. The classification was imperfect, biased, slow to update, and inconsistent across categories. It was, however, an explicit editorial framing of the available content, produced by humans who had read the material and decided where it fit. The user could survey a category and see, at a glance, what the editor considered the relevant material; the user could trust, or distrust, the editor’s judgments; the user could form expectations about what was available and what was not. The replacement of this kind of explicit editorial framing with the implicit framing of search rankings was a real change in what kind of relationship a user had with the corpus they were navigating. Search hides its editorial choices behind an algorithm; the directory put its editorial choices on the page. Both are editorial. Only one was honest about being editorial.

The other thing the web absorbed and degraded was the federated index. Veronica had been a federated search across many independently operated Gopher servers; the early web had Archie-style federated indexes for a few years (the Aliweb, Lycos, WebCrawler era). The consolidation of search at Google in the late 1990s ended the federation. Search on the modern web is provided by a small number of companies, with Google holding overwhelming dominance, and the federated alternative that WAIS and Veronica had embodied is recovered only in narrow domains (academic search across federated repositories, library OPAC federation) and not as the user’s primary experience of finding things on the internet.

What hierarchy keeps doing for us

For all the web’s reaction against hierarchy, hierarchy keeps coming back where it is needed. File systems are still hierarchical. URLs are still partly hierarchical, with the path component reflecting an organizational structure even when the structure is internally invented. Navigation menus on websites are local hierarchies. The Atom and RSS feed standards are hierarchical. The Markdown table-of-contents convention is a hierarchy. The site map standard for search engines is a hierarchy. The web has hierarchy embedded in many of its conventions even though its protocol-level design was against hierarchy.

The recovery in Part V of the static renaissance — Gemini, Markdown, static site generators — is in part a recovery of hierarchy as an organizing principle. The structure of a typical static site is a hierarchy of categories and posts; the URL paths reflect the hierarchy; the index pages are essentially Gopher menus in HTML clothing. The Gemini protocol, treated in chapter twenty-three, makes the hierarchy explicit again, with index pages and a structural model that is close to Gopher’s. The static renaissance has not killed full-text search, and most static sites have search added in. But the foundation has shifted back to hierarchy as the primary organizing structure, and the search is a supplement rather than the foundation.

What Gopher’s case continues to make

Gopher’s case for hierarchy was a serious case, made by serious people, that was decided against by a combination of one consequential institutional decision and a set of broader pressures that the web’s design happened to fit. The decision was not foolish, the broader pressures were not capricious, and the outcome was, in a sense, the right outcome for the kind of internet the next thirty years would build. But the case Gopher was making — that information should have a place, that users should be able to walk a known structure, that an editor’s classification is a contribution worth surfacing — has not gone away as an intellectual position. It survives in the small Gopher community, in the static renaissance, in the personal-knowledge-tools community, in libraries, in archives, and in the various organizational schemes that quietly continue to structure how humans actually find things. The web has spent thirty years building elaborate systems to retrofit hierarchy onto a substrate that explicitly rejected it. Gopher had hierarchy built in.

The next chapter takes the protocol that, alongside Gopher, made the most serious pre-web argument about how internet services should be structured. WAIS — the Wide Area Information Server — was federated where the web is centralized, peer-distributed where the web has concentrated, and explicit about search as a service where the web has buried it inside a small number of companies. It is a system that has been almost entirely forgotten, and the forgetting matters because what WAIS knew about how search should work has been re-learned, painfully, by people who did not know they were re-learning anything.

WAIS and search as a peer service

WAIS is the system in this book that has been most thoroughly forgotten. Most people working on internet infrastructure in 2026 have never heard of it. Most computer-science curricula do not mention it. Most discussions of the history of the web pass over it in a sentence or skip it entirely. This is unjust, because WAIS got something fundamentally right that nothing on the modern web gets right: it treated search as a peer service that anyone could provide, with results returned by federation across many independent indexes. The single most important property of search in the world WAIS proposed — that the user, not a platform, decides which indexes to query and what to do with their results — has been almost entirely lost. The world we live in, where the verb “to search” effectively means “to ask Google,” is the world that displaced WAIS. The system that did the displacing was the same system that displaced the rest of the alternatives in this book: the web, with its emergent property that search would be provided by whoever was best at it, and that consolidation around the best provider was the natural endpoint. This chapter is about what WAIS was, what it proposed, why the proposal lost, and what has happened to federated search since.

The system

WAIS — Wide Area Information Servers, with the plural meaning what it says — was released in 1991 as a joint project of Thinking Machines Corporation, Apple Computer, Dow Jones, and KPMG. The principal architect was Brewster Kahle, then at Thinking Machines, where he had been working since the company’s founding by Danny Hillis in 1983. Thinking Machines built massively parallel supercomputers called Connection Machines; the CM-2 had 65,536 processors and the CM-5 had up to several thousand SPARC nodes. Kahle’s interest in information retrieval, originally an academic interest from his time at MIT, had become a Thinking Machines product line: the Connection Machine could index large text corpora at speeds that contemporary single-processor machines could not match, and Thinking Machines was selling supercomputer-backed search services to corporate and government customers.

WAIS was a generalization of that work to the wider internet. Kahle and his colleagues proposed that the search functionality the Connection Machine offered could be distributed: any host on the internet could run a WAIS server, indexing whatever content was on that host, and any WAIS client could query any combination of WAIS servers across the internet. The protocol that connected them was based on Z39.50, a NISO standard for library information retrieval that had been formalized in 1988. Z39.50 was a heavyweight protocol — it was designed for the federation of bibliographic systems across libraries, with rich query semantics, structured records, and elaborate session handling — but the WAIS profile of Z39.50 simplified it considerably and made it suitable for the kinds of full-text retrieval the wider internet wanted.

A WAIS server exposed a set of databases. Each database was a collection of indexed documents on some topic. The server’s job was to accept queries, run them against its databases, score the matches by relevance, and return a ranked list of results. The client’s job was to send queries, display the results to the user, retrieve the full documents on request, and — this is the federation step — distribute the same query across multiple servers when the user asked it to. The user could ask the client to query a single server, or several servers in parallel, or every server the client knew about. The client merged the results and presented them as a unified list.

There was a “directory of servers” — a kind of meta-WAIS server that indexed information about other WAIS servers. A user who wanted to find out what databases were available on a topic could query the directory and get a list of WAIS servers that had relevant content. The directory itself was a WAIS database, navigable through the same client interface as everything else. Kahle’s design was consistent: WAIS was the substrate, and everything in the system — the data, the indexes, the directory of servers — was a WAIS database, queryable the same way.

The relevance ranking

What made WAIS more than a federated database query system was its relevance ranking. The Connection Machine’s parallelism allowed Thinking Machines to implement sophisticated scoring algorithms for matching queries against documents. The specifics of the scoring evolved through the protocol’s life, but the basic approach used term frequency, document length normalization, and various other factors familiar from the information retrieval research of the 1970s and 1980s. The result was that WAIS searches were ranked: when you got a list of results, the top result was the one the server’s algorithm thought was most relevant, the second was second-most, and so on. This was, in 1991, a real novelty for internet users. The dominant search tool of the time, Archie for FTP, did substring matching against file names. Veronica, the Gopher search, was little richer. WAIS was doing actual relevance ranking against full-text indexes, distributed across federated servers, with results presented in a unified ranking. It was, in capability if not in interface, the first internet-scale search system that resembles what users now expect.

The ranking was also relevance-fed-back: a user could mark certain documents in the result set as relevant and ask the server for “more like these,” and the server would generate a new query incorporating features of the marked documents. This was relevance feedback in the standard information-retrieval sense, deployed in a production system in 1991. The web’s search engines would not implement comparable feedback features for users until much later, and even then mostly in research interfaces rather than mainstream products.

What got indexed

WAIS servers proliferated through 1991 and 1992. By late 1992 there were several hundred public WAIS servers indexing topics that ranged from academic computer-science papers to bird-watching field reports to recipes to legal documents. The Library of Congress ran a WAIS server. The Environmental Protection Agency ran one. CERN itself ran a WAIS server for some of its physics literature. Apple ran one for technical documentation. The Internet Engineering Task Force ran one for the RFCs. Universities indexed their local collections; government agencies indexed their reports; corporations indexed their product documentation; hobbyists indexed their personal archives.

The federation worked. A user who wanted to find information on a topic could query the directory of servers, identify several WAIS servers with relevant content, ask their client to query all of them, and get back a single ranked list. The list would contain results from each of the queried servers, with the server source visible to the user. The user could see, for example, that the top three results came from the EPA’s environmental database, the next two from a university research library, and the next several from a government scientific archive. The federated structure was not hidden; it was a feature of the user experience.

This was a different relationship between user and search than the web’s. The web’s search engines, even in their earliest forms, presented results as if from a single index. The user did not see, except perhaps as small annotations on result lines, which servers the results came from. The query went to one place, and one place answered it. WAIS’s federation made visible what the web’s centralization concealed: that the corpus being searched was a federation of independent collections, that each collection had its own provenance and its own authority, and that the user was making implicit judgments about which sources to trust as part of the search activity.

The institutional context

WAIS came out of the Thinking Machines world. Thinking Machines was, in the late 1980s, one of the most ambitious computer companies in the United States. Its Connection Machines were used for scientific computing, intelligence work, and a small but real commercial search business. The company had assembled some of the most capable computer scientists of the period — Marvin Minsky was on the board, Richard Feynman had been a consultant before his death, the working scientists included Danny Hillis, Brewster Kahle, Stephen Wolfram for a period, David Waltz, and many others. WAIS was, in the Thinking Machines context, a product. The company was selling Connection Machine-based search services and WAIS was a way to extend the brand into a smaller-scale market while also serving as a substrate for selling more Connection Machines to organizations that wanted to host their own searches.

In 1992, Kahle spun off WAIS as an independent company, WAIS Inc., to develop the protocol and the associated client and server software commercially. The free reference implementation, FreeWAIS, was released and maintained by a community at the Center for Networked Information Discovery and Retrieval at Clearinghouse for Networked Information Discovery and Retrieval (CNIDR) at North Carolina State University, with the free version becoming the dominant WAIS server for most non-commercial deployments. WAIS Inc. continued to sell premium services and software to commercial customers. The two-track approach — free reference implementation for the broader community, commercial implementation for enterprise — was reasonable, and worked for several years.

The web’s arrival began to compete with WAIS along several fronts simultaneously. Web-based search engines started appearing in 1993 and 1994 — Wandex, Aliweb, WebCrawler, Lycos. The web search engines did not federate across WAIS servers; they crawled web pages and built their own central indexes. The user experience was simpler — type a query into a web form, get back a list of web links — and the corpus being searched was the web, which was growing fast and was where new content was increasingly being published. WAIS’s strengths — federation, structured data, the ability to search across heterogeneous collections — were less compelling for users who mostly wanted to find web pages, and the web search engines, despite being technically less sophisticated than WAIS in some respects, became the dominant search experience by the mid-1990s.

WAIS Inc. was acquired by America Online in May 1995, three months before the Netscape IPO. AOL’s interest in WAIS was as a search infrastructure for its own walled-garden services, not as a substrate for the federated open internet. The WAIS technology was integrated into AOL’s offerings and disappeared from the public-facing internet within a few years. The FreeWAIS community continued to maintain the open-source server for several more years before that, too, wound down. By the late 1990s, WAIS was effectively gone from public use, although Z39.50 itself continued to be used in library federation (where it remains, in the present day, the substrate for federated catalog searches across academic and public libraries).

What the web’s search did not preserve

The web’s search architecture differed from WAIS’s in several specific ways that have become structurally important.

The web’s search is centralized. A search query goes to one of a small number of companies, each of which has built a global crawl of the web and a centralized index. The dominant provider — Google, in 2026 — has a market share in many countries over ninety percent. The user has, in practice, one choice when they search the web: which centralized provider’s index to query. The federation that WAIS made the foundation of its design is, on the web, an option only in narrow domains. There are federated search experiences for academic literature (Google Scholar federates, in a sense, but is itself centralized; the federated alternatives are smaller). There are federated search experiences in library catalogs. There is essentially no federated search experience for the consumer web.

The web’s search is opaque. The user does not see which sources the results came from, in the federation sense WAIS made visible. The user sees web pages, ranked by an algorithm whose specifics are commercial secrets. The user can inspect a search result and click through to its source, but the ranking — which sources the engine considered, how they were weighted, what factors influenced their placement — is invisible. The user’s relationship with the engine is one of trust: trust that the engine is searching what the user wants searched, trust that the ranking reflects relevance and not commercial interests, trust that the engine’s index is complete enough to find what is there. WAIS made the source structure visible and so made it possible for the user to assess these properties for themselves.

The web’s search has become an advertising surface. The dominant provider’s revenue model, for most of its history, has been the placement of paid results inside the organic results. The boundary between paid and unpaid has become, over the years, less and less visible to the user. Many queries now return results in which several of the top items are advertisements that the user has to look carefully to distinguish from the organic results. WAIS had no advertising. The ranking was the algorithm’s judgment of relevance, full stop. The web’s search has become inseparable, structurally, from the advertising market it funds; WAIS’s search was inseparable from the federation it organized.

The web’s search is unaccountable. A site that does not appear in the dominant provider’s results is, for most internet users, invisible. The provider has the power to remove a site from its index for any reason, with no due process and no obligation to explain. The provider has the power to demote a site for any reason, also without process. There have been periodic controversies — the European Union’s Right to be Forgotten rulings, various antitrust actions, individual site owners protesting demotion — but the underlying structure is unchanged: search is provided by a centralized authority, and being visible online is a privilege that authority grants. WAIS distributed this power across many independent servers, each accountable only for its own corpus, and any user dissatisfied with one server’s results could query another.

The federations that remain

Federated search has not disappeared entirely. In the library world, Z39.50 and its modern successor SRU/SRW have persisted; library catalogs federate across institutions through these protocols, and a user querying a federated catalog (such as WorldCat) is using something close to what WAIS proposed. The academic search systems for scientific publications use various federation protocols — OAI-PMH for harvesting metadata, OpenSearch for federated query — that retain WAIS’s basic structure. The federated search interfaces in these domains work and continue to be used.

The fediverse, treated in chapter twenty-two, has been slowly recovering federated search for the social-network domain. The various ActivityPub-based platforms do not yet have a federated search story comparable to what WAIS had — searching the fediverse is, in 2026, still difficult — but several projects (Mastodon’s optional full-text search, the various community-run search aggregators) are working in the right direction. The federated structure of the fediverse provides at least the substrate for federated search; whether it will produce a working system at scale is still an open question.

The decentralized search projects — YaCy (since 2003), various smaller efforts using blockchain and similar substrates — continue to attempt to recover the federated search property. None has reached the scale where it competes with the centralized providers for general use. The cost-and-quality gap between a single large centralized search engine and a federated network of smaller engines remains the main obstacle; building good search at scale is expensive, and federation does not, by itself, solve the expense.

Kahle after WAIS

The afterlife of Brewster Kahle is worth following because it is the clearest example of a designer of one of these systems continuing to do related work after the system itself was absorbed. Kahle founded the Internet Archive in 1996, the year after WAIS Inc. was acquired by AOL. The Internet Archive’s mission — universal access to all knowledge — is the WAIS mission extended to preservation. The Archive’s tools include the Wayback Machine, which preserves snapshots of the web; the Open Library, which provides federated access to library catalogs; archive.org’s collection of digitized books, films, software, and audio; and several federated-access initiatives.

The Wayback Machine is the closest thing the web has to the property WAIS made native: durable access to material. The Wayback Machine retrofits versioning onto the web by preserving snapshots; WAIS’s design assumed that the WAIS servers themselves were durable and that the content was accessible through them indefinitely. The retrofitting works imperfectly — many sites are not crawled, many crawls miss material, the legal status of the Archive’s preservation has been challenged repeatedly — but it has become an essential part of the web’s citation infrastructure, used by millions of researchers daily.

Kahle has been one of the most articulate critics of the web’s centralization, in his role at the Internet Archive and in his advocacy for what he has called the “decentralized web.” His proposal — that web content should be stored in distributed, peer-replicated form, with multiple independent copies and no single point of failure — is in significant part a restatement of what WAIS had been doing. The Decentralized Web Summit conferences Kahle has organized since 2016 have been one of the major venues where the recovery of federated infrastructure is being discussed. The lineage from WAIS to the Internet Archive to the decentralized-web movement is direct; the people are the same; the proposal is the same; the world is just larger and more centralized than it was in 1991, and the recovery is correspondingly harder.

The cost of the loss

What was lost when WAIS lost is not, on the face of it, a feature most users miss. Most users in 2026 are happy with their search engine. The federated-search ideal is abstract; the centralized-search experience is concrete and works well for most of what most users do. The cost of the loss is therefore not visible to most users on most days. It is visible at the margins, where the marginal cases reveal what the structure can and cannot do.

The marginal cases are: politically sensitive searches, where users have legitimate reason to doubt that the centralized provider’s index is complete; specialized academic searches, where the federated alternatives provide better recall on narrow topics than the general-purpose engines; archival searches, where the Wayback Machine and similar services do work the live web cannot; and policy disputes, where the question of who controls what is findable becomes the substance of the issue. In each of these cases, the user is reminded that search is something a small number of companies provide and that the user is, when searching, dependent on those companies’ choices.

WAIS proposed a different relationship. In WAIS’s world, the user chooses which indexes to query, and the user is responsible for assessing the indexes’ coverage and credibility. The work of search is distributed across the user and the various server operators, rather than concentrated in one company. This is more work for the user and is, in many ways, slower and less convenient than what the consolidated search providers offer. It is also more honest about what search is and who is doing it, and it is more robust against the failure modes of consolidation. The trade was not unanimous; the world chose convenience. The chapters in Part V cover several of the smaller-scale recoveries of the federated alternative.

The next chapter takes the third major federated service of the pre-web internet. Usenet was the place online discussion happened, for two decades, on a federated substrate that no single party controlled. Its decline is the most thorough demonstration in the history of internet services of what happens when a federated peer system is displaced by walled-garden alternatives. The decline was not predetermined and the system’s continuing existence — Usenet is still there, in archival and reduced form — is a kind of fossil record of what online conversation can look like when no one is in charge.

Usenet, FidoNet, and federated-by-default

For roughly twenty years, between the late 1970s and the late 1990s, the dominant venue for online conversation was a federated peer-to-peer system that no single party controlled. It worked. Tens of thousands of independent servers ran the software, exchanged messages through store-and-forward propagation, and produced an aggregate conversation space that, at its peak in the mid-1990s, included tens of thousands of distinct newsgroups, millions of participants, and an estimated daily message volume in the terabyte range. There was no central server. There was no central administrator. There was no terms-of-service document anyone could sign. The participants in the conversation were on machines administered by their own institutions or paid for by their own subscriptions, and the conversation moved between those machines by a propagation mechanism that resembled the way gossip moves through a village. This was Usenet. Its dial-up cousin FidoNet operated on the same principles for a similar audience of personal-computer users. Both systems worked, neither was perfect, and both were displaced by web-based alternatives in a process that took about a decade and that produced a structurally different model of online discussion. The web model is the model we now have. This chapter is about the one we did not keep.

How Usenet started

Usenet was created in 1979 and went live in 1980. The originators were Tom Truscott and Jim Ellis, graduate students at Duke University, and Steve Bellovin, a graduate student at the University of North Carolina at Chapel Hill. They had a small problem: they wanted a way to exchange announcements and discussions between Duke and UNC, and the existing tools — email, file transfer over UUCP — were not designed for many-to-many bulletin-board-style conversation. Truscott and Ellis wrote a set of shell scripts that propagated messages between hosts using UUCP, the Unix-to-Unix Copy Protocol that had been part of Unix since 1977. The messages were organized into “newsgroups,” each newsgroup being a topical channel that subscribers at any participating host could read and post to. Bellovin’s role was the network design: the propagation model in which each host kept a list of its peers and forwarded messages to them, with duplicate-detection mechanisms to prevent loops.

The first installations were at Duke and UNC. Within a year, several more universities had joined. The growth was organic and unmanaged: a sysadmin at a new institution would obtain the news software, configure it to peer with someone running it elsewhere, and join the network. There was no application process. There was no registration. There was no central directory. The peering arrangements were bilateral, negotiated between the sysadmins who agreed to feed each other news. The protocol’s design meant that any peering arrangement was sufficient to put a host on Usenet; you did not need to be peered with a “main” server because there was no main server. You just had to be connected, somehow, to the rest of the graph.

The original transport was UUCP over modem links. Messages traveled by store-and-forward: a host would batch up its outgoing messages, dial its peers periodically (typically nightly), exchange messages, and disconnect. Latency was measured in hours or days. A message posted at MIT might take three days to reach Berkeley, depending on the connectivity in between. This sounds slow now and was slow then, but it was acceptable to the participants because the alternative — no conversation at all — was worse.

The network grew

Through the 1980s, Usenet grew steadily as Unix systems proliferated through universities and corporate research labs. The propagation infrastructure also grew. Eric Allman wrote B News in 1981, replacing the original A News shell scripts with a more efficient C implementation; Henry Spencer and Geoff Collyer wrote C News in 1987, replacing B News with a more efficient and more correctly behaved implementation; Rich Salz wrote INN, the InterNetNews server, in 1991, which combined news transport with the NNTP protocol that had become standard. NNTP — the Network News Transfer Protocol, specified in RFC 977 by Brian Kantor and Phil Lapsley in 1986 — let news propagation happen over TCP/IP connections instead of UUCP, which dramatically reduced latency and allowed real-time reading and posting against remote news servers. By the early 1990s, most Usenet news traffic was moving over NNTP, although UUCP propagation remained important for sites without persistent internet connectivity.

The hierarchies of newsgroups were organized into a structure called, by 1987, the “Big Seven” — comp, sci, soc, talk, news, rec, and misc. Each top-level hierarchy was the home of newsgroups on a category of topics: comp.* for computing, sci.* for science, soc.* for social issues, talk.* for politically charged discussion, rec.* for recreation and hobbies, news.* for Usenet itself, misc.* for everything else. A “humanities” hierarchy was added in 1995, making the Big Eight. Creating a new newsgroup in the Big Eight required a formal process: a proposal, a discussion period, a vote, and (if the vote passed by the required margins) a control message that propagated through the network and created the group on participating servers.

The alt.* hierarchy was created in 1987 by John Gilmore, Brian Reid, and Gordon Moffett as a workaround for the formal creation process. Alt groups could be created by anyone with the ability to send a control message; there was no vote, no waiting period, and no central approval. The alt hierarchy quickly became larger than the Big Seven combined and contained newsgroups on every conceivable topic. The alt structure was, in some sense, the first deliberately ungoverned region of the internet, predating the libertarian rhetoric around the early web by several years. It was also where most of Usenet’s actual cultural life happened, especially through the 1990s.

The governance, such as it was

The governance of Usenet was informal and distributed. There was no Usenet Inc. There was no Usenet board. There were, however, a number of social institutions that emerged from the practice of running and reading news.

Backbone cabal. In the early years, a small group of sysadmins at well-connected sites — the “backbone cabal” — handled the high-volume news propagation that connected major regions of the network. Their cooperation was necessary for news to flow efficiently; their authority over newsgroup creation, in the Big Seven, was correspondingly substantial. The cabal was never formal; its membership was understood by participants but never officially listed; and its existence was sometimes denied by its members for rhetorical effect. By the late 1980s the cabal had effectively dissolved as backbone connectivity diversified, but the legend of the cabal — “There Is No Cabal” became a recurring joke — remained part of Usenet’s culture.

Newsgroup moderators. Some newsgroups were moderated, meaning that posts to the group were sent to a moderator, who approved or rejected them before they propagated. Moderation was specified in the group’s creation; once a group was moderated, posts to it were rejected unless they came from the moderator. The moderator’s identity was specified in the group’s control message and could be changed only with another control message. Moderation was a practical solution to the spam and noise problem in groups with topical focus; it required the moderator to do real work, and the burnout rate among moderators was high.

The FAQ. Many newsgroups maintained Frequently Asked Questions documents that summarized the group’s conventions, scope, and answers to common questions. The FAQs were posted to the group periodically — usually monthly — and copies were maintained at archive sites. Reading the FAQ before posting was considered a basic obligation of new participants. New participants who posted without reading the FAQ were corrected, often unkindly. The FAQ was, in a sense, the legible part of the newsgroup’s culture; the rest of the culture was implicit and had to be learned by reading the group for a while before participating.

Killfiles. The reader’s primary defense against unwelcome content was the killfile: a local list of authors, subjects, or message patterns that the reader’s newsreader would automatically discard. Killfiles were per-reader; they did not affect the content other readers saw. The decision about what to read was the reader’s, not the network’s. This is a property the modern social media platform has not preserved: in current platforms, the platform decides what to show each user, and the user’s ability to filter is limited to the controls the platform provides. Usenet’s killfile was a programmatic interface; users could write arbitrary patterns and the newsreader would apply them.

These governance institutions were lightweight, unglamorous, and worked. Usenet was a fully functional discussion system for two decades, run by no one, controlled by no one, and yet sustaining a coherent and productive conversation across thousands of newsgroups. The system’s flaws were real — and treated below — but the basic question of whether a federated, ungoverned discussion system could work at scale was answered, affirmatively, by Usenet’s existence.

FidoNet

Usenet’s parallel for the personal-computer world was FidoNet. Founded by Tom Jennings in 1984 in San Francisco, FidoNet was a store-and-forward network of bulletin board systems running the Fido BBS software (or compatible alternatives) and exchanging messages over dial-up modem links. The architecture was hierarchical: zones, nets, hubs, and nodes, with messages propagating up and down the hierarchy according to FidoNet’s routing conventions. The propagation mechanism was the same as Usenet’s: each BBS dialed its peers periodically, exchanged a batch of messages, and disconnected. The latency was higher than Usenet’s — typically a few days for a message to propagate across the network — but the network grew rapidly as personal computers and modems became more affordable.

FidoNet’s structure was different from Usenet’s in important ways. The participating systems were not university or corporate research servers; they were home computers, mostly, run by hobbyists out of their basements or spare rooms. A FidoNet sysop was typically a single individual operating a single BBS. The cost of participating in FidoNet was the cost of a long-distance phone call to dial your peers; this cost was real, in the era of expensive long-distance, and was sometimes substantial, but it was not prohibitive for committed hobbyists. The participants in FidoNet skewed younger, less professional, and less academic than the participants in Usenet, with substantial overlap in the technical-hobbyist community that read both.

Echomail was FidoNet’s equivalent of Usenet newsgroups: topical message areas that propagated across the network, with sysops choosing which echoes to carry on their boards. There were hundreds of echoes by the late 1980s and thousands by the early 1990s. The echoes covered programming, hobbies, politics, religion, fiction, technical support — the full range of human interest, much as Usenet did, but among a different demographic. The two systems were sometimes connected by gateways that exchanged messages between specific FidoNet echoes and specific Usenet newsgroups, blurring the line but never fully merging the communities.

FidoNet peaked in 1995 with roughly thirty-five thousand listed nodes. The decline began as personal computer users gained internet access through commercial ISPs, which offered email, Usenet, and (after 1994) web access at lower cost and higher convenience than running a BBS. The BBS culture that FidoNet was the network of dissolved through the late 1990s as the modem-based community migrated to the internet. FidoNet still exists, in tiny form, with a small community of nodes continuing to exchange echomail over modern internet transport; it is a curiosity now rather than a working system.

The decline of Usenet

Usenet’s decline is the more important story for this chapter, because Usenet was the larger system and the more direct precursor of what online conversation might have been on the web. The decline had several causes.

Eternal September. In September 1993, AOL — at the time the largest commercial online service in the United States — began offering Usenet access to its members. The result was that the volume of new participants flooding into Usenet’s existing newsgroups overwhelmed the social mechanisms that had previously managed the integration of newcomers. Every September, in previous years, the new academic year had brought a wave of college freshmen onto Usenet, and the existing community had spent a few weeks teaching them the conventions. The 1993 wave was different: it was much larger, it was permanent (AOL members did not graduate), and the new participants did not, in most cases, want to learn the conventions of a community they considered themselves a customer of. The phrase “Eternal September” was coined to describe the situation, and it became part of Usenet’s vocabulary for the rest of its life.

Spam. On April 12, 1994, two lawyers named Laurence Canter and Martha Siegel posted an advertisement for their immigration services to several thousand Usenet newsgroups simultaneously. This was the first widely recognized commercial spam on the internet, and the response from the Usenet community was vigorous: complaints to Canter and Siegel’s ISP, retaliatory mail, and the development of automated spam-cancellation tools. The cancellation tools were partially effective. Spam, however, kept coming, in escalating volumes through the 1990s, and the social and technical apparatus Usenet had for dealing with it was repeatedly overwhelmed. By the late 1990s, many newsgroups were carrying more spam than legitimate content, and reading them had become a labor of filtering rather than a pleasure of reading.

Binary newsgroups. The alt.binaries.* hierarchy was the home of binary file distribution: software, images, audio, and (especially after the late 1990s) video. The bandwidth consumed by binary newsgroups grew enormously through the late 1990s and 2000s. By the mid-2000s, more than 99% of Usenet’s bandwidth was alt.binaries traffic, and the textual conversation that had been Usenet’s original purpose was a tiny fraction of the total. Many ISPs concluded that the bandwidth cost of carrying full Usenet feeds was no longer worth the small benefit to a small number of customers, and began dropping their Usenet service in the early-to-mid 2000s. The major ISPs — AOL, Verizon, Comcast, AT&T — had all dropped consumer Usenet access by the late 2000s. The textual newsgroups were almost empty by then anyway, having been hollowed out by spam and the migration of conversation to web forums.

Web forums. The phpBB, vBulletin, and similar web-forum platforms that emerged in the late 1990s offered, on the web, what Usenet had offered: topical discussion, threaded conversation, archived history. The web forums were not federated — each forum was a single site, run by a single administrator, with its own user accounts and its own database — but they were easier to set up, easier to moderate, easier to defend against spam, and easier for new users to participate in than Usenet was. The migration of conversation from Usenet to web forums was gradual and incomplete, but by the mid-2000s most of the active topical conversation that had been on Usenet was on web forums instead. The price was the loss of federation. A given conversation now belonged to a specific forum on a specific site; if the site closed, the conversation died.

Platforms. The web forums in turn were absorbed, through the 2010s, into a smaller number of large platforms — Reddit, Discord, the various Facebook and Twitter alternatives. The platforms were not federated, were operated by single companies, and concentrated discussion into a handful of large venues. By the early 2020s, the consolidation was nearly complete: most online discussion that was not happening in private messaging apps was happening on a few platforms, each of which had its own rules, its own moderation regime, its own algorithmic feed, and its own commercial interests.

What was lost

The loss in the migration from Usenet to platforms was specific. Several properties Usenet had, the platforms did not.

Federation. Usenet was federated by default. A user on one server could read and post to newsgroups whose primary readership was on other servers. A user dissatisfied with one server’s policies could move to another. A server administrator dissatisfied with the network could refuse to carry certain newsgroups, without preventing other servers from carrying them. The platforms are not federated. A user dissatisfied with a platform’s policies can leave the platform; they cannot, generally, take their participation in the community with them.

User-controlled filtering. The killfile let each Usenet reader decide what to read. The platforms control what users see through algorithmic feeds that are not under user control. Users can mute or block individual accounts on most platforms; they cannot, generally, instruct the platform to never show them content matching arbitrary patterns. The locus of filtering authority has moved from the user to the platform.

Topic stability. A Usenet newsgroup, once created, was a stable address for a topical conversation. The newsgroup persisted across decades; the conversation in it accumulated across years; an archive of the group was available to new participants who wanted to learn its history. The platforms’ equivalent — a subreddit, a Discord server, a Facebook group — is technically stable but is, in practice, much more easily disrupted by platform decisions: the platform can ban the community, change the moderators, alter the visibility, or change the underlying rules. The community on a platform exists at the platform’s pleasure.

Identity persistence outside the venue. A Usenet poster’s identity was their email address, which was their identity outside Usenet as well. The poster’s reputation was, in a sense, portable: it was attached to a name and address that meant something in other contexts too. The platforms’ identities are platform-specific. A Reddit username has no portability outside Reddit; a Discord username has no portability outside Discord. The user’s reputation, such as it is, is captured by the platform and does not follow the user when they leave.

Archival. Usenet’s full archive — every message ever posted — was, in principle, preserved at multiple sites. Google acquired DejaNews’s archive in 2001 and made it the basis of Google Groups, which retains a substantial portion of historical Usenet. The platforms’ archival practices are inconsistent: some platforms preserve indefinitely, some delete, some allow user-initiated deletion, and the long-term availability of platform content is governed by the platforms’ commercial interests rather than by any archival commitment.

What is being recovered

ActivityPub and the fediverse, treated in chapter twenty-two, are the most direct recovery of Usenet’s federated model. The fediverse is, in effect, Usenet with web-style identity and presentation: a federation of independently operated servers, each hosting its own users, exchanging messages with other servers through a standard protocol. Mastodon, Pleroma, Lemmy, Misskey, and the other fediverse implementations are not Usenet in the technical sense, but they share its structural commitments. Lemmy in particular is structurally close to Usenet: it offers federated discussion communities, similar to newsgroups, with each community hosted on a specific server but readable and postable from any server. The fediverse is growing, slowly, and is now in the position Usenet was in around 1988 or 1989: working, established at small scale, with a passionate community and a slow but steady growth curve.

NNTP itself continues to exist. Several news servers continue to run, primarily for binary distribution but also for some textual newsgroups that have small but persistent communities. Eternal-September.org, founded around 2010, provides free NNTP access for non-binary newsgroups and has served as a refuge for textual Usenet participants who want to continue using the protocol. The protocol works; the question is whether anyone uses it. The answer, in 2026, is yes, in small numbers.

The IRC ecosystem persists, with Internet Relay Chat servers federated across networks (each major network — Freenode/Libera, Undernet, EFnet, and others — is internally federated). IRC is real-time chat rather than threaded discussion, so it does not directly substitute for Usenet, but the federated structure has been maintained continuously since the early 1990s. Matrix, a newer protocol with similar federation properties for chat, has been gaining ground since 2014 and is the most prominent current example of a federated chat protocol with serious institutional backing.

What the federated history teaches

The lesson of Usenet and FidoNet, taken together, is that federated online discussion can work at scale, for decades, without central administration, as long as the participants are willing to do the work of maintaining the federation. The work is real: server operators have to peer, sysadmins have to handle spam, communities have to maintain their FAQs and welcome their newcomers, users have to maintain their killfiles. The work is also distributed: no single party bears the entire cost, and no single party has the entire authority. The platforms have replaced this distributed effort with concentrated platform-side work — moderation teams, algorithmic enforcement, terms-of-service enforcement — and have, in exchange, gotten near-total control of the resulting communities. The trade is not obviously good. Most users do not feel the loss directly because the platforms are convenient and the federated alternatives are unfamiliar. But the loss is real, and the recovery is being attempted in the fediverse on a scale that suggests at least some users feel it.

The next chapter takes the one federated service from the pre-web era that survived. Email is the protocol that did not get displaced; the system Postel specified in 1982 still runs, on the same architecture, with the same federation, and is the only piece of pre-web federated infrastructure that remains in mass use. It has not, however, survived in good condition. The chapter is about what happened to email that almost happened to all the other federated services in this book, and what it would mean to fix it.

Email’s near-miss

Email is the federated peer-to-peer system that survived. The Simple Mail Transfer Protocol Jon Postel specified in RFC 821 in August 1982 still runs the world’s email. The architecture has not changed: any host on the internet can run an SMTP server, accept incoming mail from any other SMTP server, send outgoing mail to any other SMTP server, and participate as a peer in a network in which there is no central authority and no central administrator. Email addresses are still under the domain owner’s control. Mail still propagates through DNS-mediated host-to-host transfer. The protocol still works. By the structural criteria this book has been applying — federation, peer status, lack of central control, user choice of provider — email is the great success story of the pre-web internet, the one piece of federated infrastructure that did not fall to the consolidation that ate the others.

This story is half right. Email survived. It survived in compromised form. The protocol is still federated; the actual sending and receiving of email, however, is in 2026 controlled by an oligopoly of three or four providers who collectively host most of the world’s mailboxes and who collectively decide what mail flows through the network and what does not. Setting up your own SMTP server is technically possible and effectively impractical, in a way that is structurally different from anything Postel intended. The system worked, then was overwhelmed by spam, then was rescued by an anti-spam regime that incidentally centralized control of the network into the hands of the operators who could afford to participate in it. The chapter is about how this happened, what was preserved, what was lost, and what it would mean to fix email at this point.

The protocol that worked

Email predates SMTP. Ray Tomlinson at Bolt, Beranek and Newman sent the first network email message between two computers on the ARPANET in 1971, using a program called SNDMSG running on the host’s existing operating system mailbox. Tomlinson chose the @ symbol to separate the user from the host, a choice that has survived through every subsequent revision of email addressing. Through the 1970s, email proliferated on the ARPANET with various ad-hoc transport mechanisms; by the late 1970s the ad-hoc mechanisms were producing interoperability problems serious enough to motivate a standardization effort. SMTP, published as RFC 821 in August 1982, was the result. The companion specification RFC 822, by Dave Crocker the same month, defined the message format — the headers, the body, the addressing — that has remained substantially unchanged since. RFC 974, in 1986, defined MX records, which let DNS resolve a domain name to the appropriate mail-receiving host.

The architecture had several properties that gave email its character. Mail addresses had two parts: the local part (the user) and the domain (the host or the organization). The domain was a DNS name, resolved through the federated DNS hierarchy. The MX record told the sending host which actual server to deliver to. Mail traveled in clear text across the network, with no encryption at the transport layer (TLS for SMTP would arrive later, as RFC 3207 in 2002). Mail was best-effort: SMTP servers retried failed deliveries for several days before giving up, and bounced messages back to the sender if delivery was not possible. The protocol was simple enough that an experienced programmer could implement an SMTP server in a weekend; many did.

The federation was the design’s central commitment. There was no central mail authority. There was no required intermediary. A host with SMTP, an MX record in DNS, and a connection to the internet was, structurally, an email peer. Anyone with such a host could send and receive mail from anyone else with such a host. The promise of email in the 1980s was the promise of a global mail network in which any organization, large or small, could participate on equal terms with any other. This promise was kept for the first two decades of email’s mass use. It is not kept now.

How mail propagated

The flow of an email message in the 1980s and through most of the 1990s was simple. A user composed a message on their host. The host’s mail submission daemon received the message and queued it for delivery. The mail transport daemon read the recipient address, looked up the recipient’s domain in DNS, found the MX record pointing to the recipient’s mail server, opened an SMTP connection to that server, and delivered the message. The recipient’s mail server stored the message in the recipient’s mailbox. The recipient’s mail client — running on the same machine, or accessing the mailbox remotely through POP3 or IMAP — read the message.

This flow assumed several things that are no longer assumed. It assumed that the sender’s host was a real internet host with a routable IP address. It assumed that the recipient’s host was a real internet host with a routable IP address. It assumed that the sender’s host’s IP was not on any blocklist. It assumed that any host receiving mail would attempt to deliver it. It assumed that the sender was identified by their address in the From: header, accurately. None of these assumptions held by the late 1990s. The deviation from them is the substance of what happened to email.

POP3 and IMAP, the protocols for accessing remote mailboxes, were added in the mid-1980s and refined through the 1990s. POP3 (RFC 1939 in its 1996 form, earlier in earlier versions) let a user retrieve mail from a remote server to their local machine. IMAP (RFC 1730 in 1994, refined in subsequent RFCs) let a user manipulate their mailbox on the server without downloading the entire contents. These protocols separated the role of the mail server (which received and stored mail) from the role of the mail client (which let the user read and compose). The separation made it possible for a user to access their mail from multiple devices and from multiple locations, and it laid the groundwork for the later separation of mail hosting from mail reading.

MIME — Multipurpose Internet Mail Extensions, specified by Nathaniel Borenstein and Ned Freed in RFCs 1521, 1522, and later updated in 2045-2049 between 1992 and 1996 — added the ability to send non-ASCII content, structured messages with multiple parts, and attachments. MIME extended email substantially beyond the plain-text design of the early protocol. The extensions have proven durable; modern email is still MIME at the wire format level, with the elaborations that have accumulated since.

The arrival of spam

The first widely cited piece of internet spam was sent on May 3, 1978, by Gary Thuerk, a marketer at Digital Equipment Corporation, to several hundred ARPANET users, advertising a DEC product demonstration. The message was met with disapproval and was discussed extensively at the time; it did not, however, establish a pattern. Spam in any volume did not become a serious problem on the network for another decade and a half, because the network was small enough and the participants culturally similar enough that the social cost of sending unwanted mass mail was greater than the benefit.

This changed in the mid-1990s, for the same reasons everything else in this book changed: the internet became commercially significant, the participants became more numerous and more diverse, and the social mechanisms that had previously constrained unwanted behavior stopped scaling. The Canter and Siegel Green Card spam in 1994, discussed in the previous chapter as a Usenet event, was also delivered to email mailing lists, and was followed by a steady increase in the volume of unsolicited commercial email through the late 1990s.

By the early 2000s, the situation was severe. Studies estimated that spam constituted more than half of all email traffic by 2003 and more than 70% by 2005. Mailbox operators were spending substantial resources on filtering. Users were drowning in unwanted mail. The protocol had no built-in defense against spam — it had been designed in an era when the cost of sending mail was real (you needed a machine on the internet) and the social cost of misbehaving was high (your peers would refuse to peer with you). Both conditions had eroded. Sending spam was effectively free, and the spammers’ peers, paid to provide internet access regardless of what was sent, had no incentive to police them.

The response was an arms race. Filtering at the receiving end developed quickly: heuristic filters that looked for spam-like patterns, Bayesian filters that learned from labeled examples (Paul Graham’s 2002 essay “A Plan for Spam” was widely influential in popularizing Bayesian approaches), reputation systems that scored senders by their past behavior, and blocklists that aggregated bad-actor IP addresses for sharing across operators. The DNSBL — DNS-based blacklist — became a standard way for receivers to query whether a sending IP was known to send spam. By the mid-2000s, the major receivers were running aggressive multi-layered filtering pipelines.

The arms race also pushed authentication. SPF (Sender Policy Framework, RFC 4408 in 2006) let a domain owner specify which IP addresses were authorized to send mail for that domain. DKIM (DomainKeys Identified Mail, RFC 4871 in 2007) let a sender cryptographically sign their outgoing mail with a key published in DNS. DMARC (RFC 7489 in 2015) combined SPF and DKIM with a policy framework that let domains specify how receivers should treat messages that failed authentication. By the late 2010s, SPF, DKIM, and DMARC were considered table stakes for serious mail senders; mail without all three was treated with suspicion.

The deliverability problem

The cumulative effect of the anti-spam arms race was that sending email reliably became hard. Receivers — particularly the major receiving providers, by then a small number of companies handling most of the world’s inboxes — had developed elaborate criteria for what to accept and what to filter. An organization sending email at any volume had to satisfy these criteria. SPF, DKIM, and DMARC had to be configured correctly. The sending IP had to have a clean reputation. The sending domain had to have a history of sending legitimate mail. The mail had to pass content filters. The pattern of sending had to look normal. The recipient list had to be clean of invalid addresses, complaint-generators, and known spam traps. None of this was negotiable. Mail that did not satisfy the criteria was filtered, often silently, with no notification to the sender.

The criteria are reasonable defenses against spam. They are also, structurally, a barrier to entry. A new domain, with no sending history, has a difficult path to deliverability. A small organization sending mail from its own server has to navigate the deliverability requirements without the benefit of professional anti-abuse staff. An individual self-hosting their email faces a meaningfully different problem from what self-hosting email was in 1995. The cost of joining the federation has gone up, and the cost is paid in skilled-time-and-attention to satisfy the major receivers’ criteria.

The major receivers have, in turn, become a small set. Gmail, launched by Google on April 1, 2004 (the famously skeptical reception, given the date, did not last), grew rapidly through the 2000s and by the mid-2010s was hosting hundreds of millions of mailboxes. Microsoft’s Outlook/Hotmail/Live family of services hosts comparable numbers. Yahoo Mail, Apple’s iCloud Mail, the various ISP-provided mail services, and the enterprise-focused providers (Google Workspace, Microsoft 365) collectively account for the great majority of the world’s mailboxes. Estimates vary, but the rough numbers in 2026 are that Gmail and Outlook between them serve over half of consumer mailboxes globally, and that the top five providers serve a clear majority.

This concentration changes the practical meaning of email’s federation. The protocol is still federated; anyone with a domain and a server can in principle send and receive mail. The actual receiving of mail, however, happens at a small number of operators. To send mail that reaches users in 2026, you mostly have to satisfy the criteria of Gmail and Outlook. Their criteria are not transparent. Their judgment is final. Their reasons for filtering particular messages are typically not given. A self-hosted email sender who finds their mail going to Gmail’s spam folder has limited recourse. The federation has become a federation in name and an oligopoly in practice.

The encryption that did not happen

A parallel story runs alongside the deliverability story. Email was designed in clear text. Anyone with access to the network between the sender and receiver could, in principle, read the message. As email became important for sensitive personal and commercial communication, this property became uncomfortable. The protocol-level fix — encrypting the connections between mail servers — arrived in 2002 with RFC 3207 (STARTTLS for SMTP). By the mid-2010s most major mail providers were using TLS for inter-server transport, encrypting mail in transit, with cooperation campaigns by Google and others to push the remaining holdouts toward encrypted transport.

End-to-end encryption — encryption of the message content such that only the sender and the recipient can read it, with no possibility of reading by intermediate servers — is a different problem. The most prominent attempt was PGP, Pretty Good Privacy, written by Phil Zimmermann and released in 1991. PGP let users encrypt messages with their recipients’ public keys, so that only the holder of the corresponding private key could decrypt them. PGP was, technically, a serious piece of cryptographic software. It was also, in its key-management requirements and user-interface complexity, prohibitive for most users. The slogan “PGP is unusable” became a recurring conclusion of usability studies.

PGP did not become widely adopted. Its successor projects — GnuPG, various GUI integrations, the WebKey Directory standard, Autocrypt — have not made it widely adopted either. S/MIME, the X.509-based alternative, has had some uptake in corporate settings but is similarly invisible to most users. The result is that the great majority of email in 2026 is not end-to-end encrypted. The major providers can read the contents of the mail they handle, and they use this access for various purposes (spam filtering, search indexing, advertising in some cases, machine-learning training in others). The trade-off between encryption and the various server-side features users want — search, filtering, classification — has been resolved, structurally, in favor of the server-side features and against end-to-end encryption.

Self-hosting in 2026

It is worth being specific about what self-hosting email looks like in 2026. The technical components are easier to assemble than they have ever been: containerized mail servers, automation tools, modern TLS, automatic DKIM key generation, integrated SPF/DKIM/DMARC configuration. A motivated individual can have a self-hosted email setup running in a few hours. What they cannot easily achieve is reliable deliverability to Gmail and Outlook.

The reasons are well documented in the running commentary of the self-hosting community. New IPs get blocked. Cloud-provider IPs are often pre-blocked by major receivers because spammers use them. Even with SPF/DKIM/DMARC correctly configured, new sending domains have to slowly build reputation by sending small volumes of high-quality mail and gradually increasing volume. The reputation can be lost easily; a few users marking messages as spam can put a domain on a receiver’s bad list, and getting off the list is difficult. The major receivers do not generally explain their decisions or provide remediation paths beyond their general-purpose appeal forms.

The cumulative practical effect is that the federated peer model email was designed around is, in 2026, available only to operators who can afford to maintain serious anti-abuse practice. Most individuals and small organizations who try to self-host email find that they need to relay through a commercial mail-sending service (Mailgun, SendGrid, Postmark, Amazon SES) to achieve acceptable deliverability. The relay services have their own reputations and their own infrastructure to satisfy the major receivers. The structure has, in a generation, become hierarchical: receivers at the top, large senders and relay services in the middle, smaller senders depending on the relay services, individual users at the bottom. The peer-to-peer federation has been preserved in name and replaced in practice with a layered system in which the top of the layer is held by a small number of operators.

What has been recovered, attempted, and remains

There are recovery efforts. The smaller mail providers — Fastmail, ProtonMail, Mailbox.org, Tutanota, and a handful of others — operate as alternatives to the major receivers, with various positioning around privacy, encryption, or independence from the advertising-driven mail providers. ProtonMail, founded in 2014, has been particularly visible for its end-to-end encryption when both parties are on ProtonMail. Fastmail has been operating as an independent paid email provider since 1999. The smaller providers maintain deliverability with the major receivers through investment in anti-abuse practice and through their reputations as cooperative members of the mail community; they do not, however, change the structural problem.

JMAP (JSON Meta Application Protocol), specified in RFC 8620 in 2019, is a modern replacement for IMAP designed for better performance and easier client implementation. JMAP is structurally analogous to IMAP — it specifies how clients talk to their mailbox provider — and so does not by itself change the federation story. It does, however, make it easier for new mail clients to participate in the ecosystem, which has some indirect benefits for the broader mail community.

Various decentralization proposals exist for email. Federated identity systems, distributed mail servers, blockchain-based replacements, post-quantum encryption — there is a steady trickle of research and small-scale experiment. None of these has approached mainstream adoption. The cost of email’s deliverability problem is high enough, and the alternative protocols are immature enough, that the practical alternative for most users is to stay with the major providers and accept the structural concentration.

What email keeps and what email lost

What email kept is the protocol-level federation: the architecture by which any domain owner can in principle participate as a peer, the addressing scheme that does not depend on a platform, the message format that is the same across all participants, and the basic operations (send, receive, forward, reply) that work the same way regardless of provider. These are real and they matter. A user whose email is provided by Gmail can correspond with a user whose email is provided by Fastmail without either party knowing or caring which providers the other is using. The choice of provider is a user-side choice in a way that platform choices on social media are not. A user who wants to leave Gmail can take their mail with them and continue using their existing address (if they own the domain) or change their address (if they were using @gmail.com) without changing how email works.

What email lost is the practical equality of participation. The federated structure that the protocol describes is not the structure email actually has. A user setting up email from scratch in 2026 has dramatically fewer practical options than a user doing the same in 1996. The path to running your own mail server, achieving deliverability, and being a fully participating peer in the email network is narrower than it was. The major receivers have, through the necessity of fighting spam, accumulated the practical power to decide who participates in the network on what terms. The power is exercised reasonably most of the time and unreasonably some of the time, and the affected parties have limited recourse in either case.

The thing email is, then, is the federated system that survived in deteriorated form. It is the case study for what the other federated systems would have looked like if they had survived. The fact that email survived at all — that it was not absorbed into walled-garden replacements the way Usenet was — is the encouraging part of the story. The fact that surviving has not been free of compromise is the cautionary part. The federated peer system Postel specified in 1982 still exists. The kind of mass participation in it that the design implied is harder to come by than it was, and the structural reasons for the difficulty are not going to go away.

The next chapter takes the strangest and most ambitious of the pre-web alternative architectures. Plan 9 from Bell Labs was the operating system the Unix team built when they decided that Unix had not been ambitious enough. It treated the network as native, every resource as a file, every file as accessible from anywhere on the network, and every operation as a file operation. It did not win. It was not supposed to win, in the commercial sense. But what it proposed about how computing should look has been quietly adopted, in pieces, by almost every system that has come since, and the parts that have not been adopted are the parts most worth looking at.

Plan 9 and 9P

The strangest of the pre-web architectures, and the one most worth taking seriously even though it sits oddly inside the book’s argument, is Plan 9 from Bell Labs. Plan 9 was not a hypermedia system, not an internet protocol in competition with the web, and not a federated discussion network. It was an operating system. It was, however, an operating system that proposed an answer to the question “how should networked computing look” that was structurally different from what Unix had proposed, what Windows would propose, what Mac OS would propose, and what the web on top of Unix-Windows-Mac OS would propose. The answer was that the network should be the operating system. Every resource on every machine on the network should be addressable as a file. Every process should have its own private view of the file system. Every operation should be a file operation. And the protocol that connected the parts — 9P — should be the only protocol you needed for almost anything. Plan 9 lost as a system. It won as a vocabulary; pieces of its design have been absorbed, mostly without credit, into almost every system that has come since. This chapter is about what Plan 9 actually was, what it proposed, what survived, and what did not.

Where it came from

Plan 9 was the work of the same group that had built Unix at Bell Labs through the 1970s and into the 1980s. By the late 1980s the Computing Sciences Research Center at Bell Labs — the part of Bell Labs that had produced Unix — had concluded that Unix, as it had been deployed and extended by the world outside Bell Labs, had grown into something different from what they had been trying to build. Unix had become a per-machine operating system, with networking added on as a peripheral concern. Distributed computing meant cobbling together TCP/IP services on top of local machines, with each machine retaining its own user accounts, its own file system, its own process model, and its own conventions. The promise of a uniform distributed system, with one user identity across the network, one filesystem across the network, and one programming model across the network, had not been kept by Unix and its descendants. The Bell Labs group decided to try again.

The principal designers of Plan 9 were Rob Pike, Ken Thompson, Dave Presotto, and Phil Winterbottom, with substantial contributions from Howard Trickey, Tom Duff, Doug McIlroy, and others. The development began around 1986. The first internal release was around 1989; the first public release came in 1992 under the name “Plan 9 from Bell Labs,” a reference to the Ed Wood film Plan 9 from Outer Space that became the official explanation of the name. Three more editions followed: 1995, 2000, and 2002 (the “Fourth Edition”). The system was released initially under Lucent Technologies’ research license; in 2002 the source code was released under the more permissive Lucent Public License, and in 2014 (post-Lucent, by then Alcatel-Lucent) it was relicensed under the GPLv2. The system is still maintained, in two active forks: 9front, which is the more active community fork, and plan9port, a port of the user-space programs to other Unix systems that has kept some of Plan 9’s vocabulary alive on Linux and macOS.

The central design idea

Plan 9’s central design idea was an extension of the Unix “everything is a file” doctrine. Unix had treated files, devices, and a few other resources as accessible through the same file-system interface; a program reading data did not need to know whether the data was coming from a disk file, a terminal, or a pipe, because all of them looked like file descriptors. Plan 9 pushed this idea further than Unix had been willing to. In Plan 9, the network was a file. Processes were files. The display was a file. The mouse was a file. Memory was a file. Audio devices were files. Every resource the operating system managed was exposed through the file system, and every operation on every resource was a file operation: open, read, write, close.

The consequence was that almost no operation in Plan 9 required a special-purpose system call. Where Unix needed dozens of system calls for various things (socket, bind, listen, accept, ioctl, mmap, and a long list of others), Plan 9 needed essentially the file operations and a few more. A program that wanted to make a TCP connection did not call a socket function; it wrote to a file in the /net hierarchy. A program that wanted to query the kernel about a process did not call a system call; it read a file in /proc. A program that wanted to draw on the screen did not call a graphics library function; it wrote to a file in the window system’s namespace.

This sounds austere and slightly insane. It is austere; it is not insane. The reason it works is that the file system was extended to be expressive enough to support the operations the resources needed. A file in /net was not a passive storage location; it was an active endpoint, with reads and writes that triggered network operations. A file in /proc was not a snapshot; it was a live view, with reads that returned current state. The protocol that connected programs to resources, 9P, was rich enough to express the semantics each resource needed within a uniform file-operations interface.

The benefit was that any program that could read and write files could use any resource the operating system exposed. This included resources on remote machines. If a remote machine exposed its /net hierarchy on its 9P file server, a program on a local machine could mount the remote /net into its own namespace and make network connections from the remote machine as easily as from the local one. The same was true of /proc: you could read the process list of a remote machine by mounting its /proc into your namespace and reading the files. The same was true of the display: you could mount a remote machine’s window system into your namespace and draw on its screen as if it were yours.

Per-process namespaces

The second of Plan 9’s design commitments was that each process should have its own private view of the file system. Unix processes inherit a shared global file system; what /usr/local/bin means is the same for every process on the machine. Plan 9 processes inherit a private namespace that can be different from any other process’s. A process can mount things into its namespace at arbitrary paths, can unmount them, can replace one mount with another, can union two directories into one virtual directory, and can do all of this without affecting any other process. The shell starts a new process with a copy of the parent’s namespace, but the child can modify its own namespace independently.

This is a profound generalization of the Unix chroot mechanism. Chroot lets a process change the apparent root of the file system; Plan 9’s namespaces let a process change anything about the file system, with arbitrary granularity. The consequences for system design are substantial. A network service running as a user could be confined to a namespace containing only the files it needed, with no access to the rest of the system. A workspace for a particular task could be a namespace combining the relevant files from many sources, with the task’s tools seeing only the relevant ones. A user logged in to a terminal could have a namespace combining files from the terminal’s local disk, the user’s home machine, and any cluster of remote machines the user wanted to draw from, all stitched together into a single coherent view at the user’s preferred paths.

The current popularity of containers — Linux namespaces, Docker, Kubernetes — is, structurally, a recovery of what Plan 9 had done with namespaces in 1992. The Linux kernel’s namespace facilities, developed in the 2000s, made it possible to give each process group a private view of various aspects of the system: mounts, processes, network, hostnames. Docker, released in 2013, packaged these facilities into a developer-friendly tool. Kubernetes, released in 2014, scaled the namespace abstraction to clusters. Each step has been a partial recovery of what Plan 9 had been doing. The recoveries have arrived in industrial form, with massive adoption, twenty-plus years after the original design.

The recoveries are not, however, complete. Plan 9’s namespaces were uniform: every resource was a file, every namespace was a tree of files, and the operations on namespaces were the same regardless of what was inside. Linux’s namespaces are siloed: the mount namespace handles file system mounts, the network namespace handles networking, the PID namespace handles processes, and the various namespaces do not compose into a unified abstraction. The result is that working with Linux namespaces means working with each silo’s specific API, while working with Plan 9 namespaces meant working with files. The uniformity that was Plan 9’s central commitment has not been recovered.

9P

The protocol that connected the parts was 9P. 9P is a small wire protocol for file system operations: a client sends requests to a server, the server responds, and the operations are the standard ones — attach (open a connection), walk (navigate to a path), open (open a file for reading or writing), read, write, clunk (close), and a few others. 9P is small enough that a complete implementation fits in a few thousand lines of code. The protocol was redesigned in 2000 as 9P2000 (also called “Styx” in the Inferno operating system) to clean up some early-version messiness, and the 2000 version is what continues to be used.

The simplicity of 9P is a feature, in the same way that the simplicity of HTTP is a feature: a simple protocol can be implemented in many languages on many platforms by many developers, and a wide variety of clients and servers can interoperate. 9P has been implemented in C, Go, Rust, Python, Ruby, and many other languages, both as client and as server, with many of the implementations being short enough to read in an afternoon. The protocol’s elegance is one of the reasons it has had quiet influence well beyond Plan 9’s user base.

The other reason is that 9P solves a problem nobody else has solved as cleanly. The problem is: how do you expose a service to remote clients in a way that lets them use the service as if it were local? HTTP solves this by mapping operations to URLs and returning serialized data; the client has to parse the data and interpret it according to the application protocol. RPC frameworks solve it by defining application-specific procedures that clients invoke; each application gets its own protocol. 9P solves it by exposing the service as a file system that clients mount and interact with using ordinary file operations. The client does not need to know anything about the service except how to read and write files. A new service can be added to a network and clients can use it without any new code.

This pattern is the deep insight Plan 9 contributed. The web’s REST architecture, articulated by Roy Fielding in his 2000 PhD dissertation and treated more fully in chapter fifteen, is in some respects a less-rigorous restatement of the same idea: resources are addressable, operations on resources are a small fixed set, and clients can interact with new services using the standard operations. REST is HTTP-based, with all of HTTP’s specific design choices; 9P is file-system-based, with the file system’s specific design choices. The underlying architectural insight is the same.

UTF-8

A side product of Plan 9’s development is one of the few unambiguous wins to come out of the project: UTF-8, the variable-width encoding of Unicode that has become the default text encoding for almost everything on the internet. UTF-8 was designed by Rob Pike and Ken Thompson on a placemat at a New Jersey diner in September 1992. Plan 9 needed an encoding that could represent Unicode characters in byte streams without breaking compatibility with ASCII-only software. The constraints — ASCII compatibility, self-synchronization, no embedded null bytes, byte-stream-friendly — led to the design that Pike and Thompson worked out over dinner. UTF-8 was first implemented in Plan 9, used as the default encoding from the start, and submitted as an internet standard in RFC 2044 (1996) and refined in subsequent RFCs.

UTF-8 is now the default text encoding for HTML, for JSON, for source code in most modern languages, for filenames on most modern file systems, for protocols across most of the modern internet. It is the most successful standard ever to come out of Plan 9. It is also a piece of the Plan 9 design philosophy — make the simple cases simple, make the complex cases possible, prefer self-describing formats — that has been absorbed without the rest of the design.

Why Plan 9 did not win as a system

Plan 9 was used at Bell Labs, was deployed at a handful of other research institutions, and acquired a small community of dedicated outside users. It did not, however, become a mass-market operating system, and was never really intended to. Bell Labs had been broken up and restructured several times by the mid-1990s; the funding model that had supported the Computing Sciences Research Center was no longer producing the kind of patient long-term research support that had let Unix grow through the 1970s. Plan 9 was developed in a research lab that was, by the mid-1990s, increasingly under pressure to produce commercial results. The system was released, but Bell Labs (by then Lucent) did not put serious marketing behind it. Most computer users in the 1990s wanted Windows or a Unix workstation, not an experimental research operating system.

There were also real technical obstacles to adoption. Plan 9’s “everything is a file” doctrine, while elegant, was incompatible with the existing Unix software ecosystem. Programs that had been written to use sockets, ioctl, and the rest of the Unix system-call repertoire did not work on Plan 9; they had to be rewritten to use file operations. The Plan 9 team rewrote much of the standard Unix toolkit for their system, including new versions of the shell (rc), the editor (sam, then later acme), the window system (8½, then rio), and many of the standard utilities, but the result was a system that could not run Unix software directly. For users with substantial existing Unix software investments, this was prohibitive.

The system also chose, deliberately, several non-Unix conventions that made transition harder. The Plan 9 build system, the Plan 9 file format conventions, the Plan 9 command names — many of these were different from Unix in small ways. The cumulative effect was that adopting Plan 9 required adopting a different software ecosystem, and the ecosystem was much smaller than Unix’s. Plan 9 was, in this sense, the high-purity option, and the high-purity option is rarely the winning option in software ecosystems.

What got absorbed and what didn’t

Plan 9’s quiet influence on subsequent computing has been substantial. Several specific contributions have been adopted, usually without credit:

UTF-8, as discussed above, has become the universal text encoding.

Per-process namespaces have been recovered in Linux’s namespace mechanisms, Docker, and Kubernetes, in siloed form that does not match Plan 9’s uniformity but is structurally derived from the same insight.

The /proc filesystem, exposing kernel and process state as readable files, was adopted into Linux and most other Unix systems through the 1990s. Plan 9 had it first, in the most thoroughgoing form; Linux has a subset that has nevertheless been useful enough to become a standard way of inspecting system state.

The FUSE (Filesystem in Userspace) framework, developed in the early 2000s, lets user-space programs implement file systems that the kernel can mount. FUSE is, in effect, a way to expose arbitrary user-space services as file systems, which is what Plan 9 had been doing natively. FUSE-mounted file systems for SSH, for cloud storage, for archived data, for custom applications, are now common on Linux and macOS.

The Go programming language, designed by Pike and Thompson at Google starting in 2007, carries forward many Plan 9 design sensibilities — the small standard library, the emphasis on composition over inheritance, the goroutine concurrency model, the emphasis on plain text and concise syntax. Go is the most direct programming-language descendant of Plan 9, and several Plan 9 alumni (Pike, Thompson, Russ Cox, Dave Presotto) have been involved in its development.

The 9P protocol itself has been used in several places outside Plan 9. The Linux kernel’s VirtFS (the v9fs module) implements 9P as a shared-folder protocol for virtualization, used by QEMU/KVM and the WSL on Windows. The protocol’s simplicity makes it a good fit for VM-to-host communication where minimizing protocol overhead matters.

What has not been absorbed is the unification: the proposition that the operating system, the network, and the user environment should be a single coherent system in which every resource is uniformly addressable through one abstraction. Linux is a Unix variant; Windows is a Windows variant; macOS is a Mac variant; the cloud is a layered cake of various technologies. The unified namespace Plan 9 proposed has not arrived. Each layer of the contemporary stack has its own abstractions, its own protocols, its own conventions, and the user must navigate between them.

What Plan 9 has to say to the web

The relevance of Plan 9 to the broader argument of this book is structural. Plan 9 proposed that the network should be transparent: that there should be no meaningful distinction, at the architectural level, between a resource on your local machine and a resource on a remote machine. The web’s distinction is sharp: local resources are accessed through the operating system’s file API, remote resources are accessed through HTTP and a browser. Plan 9’s distinction was thin: both kinds of resources are accessed through the file system, and the protocol underneath is the same. A document on your local disk and a document on a server in Tokyo are, in Plan 9, the same kind of thing — a file you read with the same call. In the web’s world, they are different kinds of things accessed through different mechanisms, with the differences being visible at every layer of the stack.

The web’s choice has scaling and engineering benefits. The local file and the remote document have to behave differently in many cases — caching, error handling, security, performance — and pretending they are the same kind of thing puts the burden of distinction on the application instead of the operating system. The web’s approach lets each application handle the distinction in the way most appropriate for the application. Plan 9’s approach put the burden on the operating system, and the operating system did not always have enough information to do the right thing.

But Plan 9’s choice has costs the web’s choice does not have. The web’s distinction between local and remote has become, over the decades, a wall: files on your computer cannot easily be linked to from the web; web resources cannot easily be embedded in your local desktop environment; the two worlds run in parallel with limited interchange. A Plan 9 system that mounted remote resources into your local namespace did not have this wall; a remote file behaved like a local file, with caching and error handling delegated to the file system. The recoveries in Part V — local-first software, syncing systems, the various attempts to give web users persistent local data — are in some sense recoveries of what Plan 9 had been doing as a matter of course.

What we kept and what we didn’t

What we kept from Plan 9 is a vocabulary: UTF-8, /proc, FUSE, namespaces, the Go language, the 9P protocol’s use in specific niches. The vocabulary has been useful; the elements have been absorbed into systems that have themselves been useful.

What we did not keep is the unification. The proposal that an operating system should be a single coherent design, with one abstraction (the file) doing the work of many, with the network transparent, with each process having its own view, with every resource on every machine addressable through the same call — that proposal has not been recovered at scale. The closest contemporary system, in spirit, is the way Kubernetes structures cluster resources, with everything addressed through declarative APIs that look superficially like file systems. The resemblance is shallow; Kubernetes is not Plan 9, and the Kubernetes APIs are application-specific in a way Plan 9’s file system was not.

Plan 9 is the system in this book where the loss is hardest to feel. Most users have no direct experience of what a unified namespace operating system would feel like, because nobody has shipped one. The loss is theoretical; it is the loss of an architectural alternative that the people building Plan 9 had built and used and found good, and that the rest of us, working in the operating systems we have, do not even know we are not using. The chapter is here partly to say: this alternative existed. The people who built it were among the best operating-system designers in the history of the field. They built a working system, ran it for a decade, and made an architectural argument that has been quietly absorbed in pieces and has never been recovered as a whole. The argument is still there. The pieces are still there. The system is still there, in 9front and in plan9port and in the small communities that keep it alive. The recovery, if it happens, will be a recovery of attention as much as a recovery of code.

The five-chapter survey of internet alternatives ends here. The next part turns to the system that beat them. Part IV is about how the web won — the technical decisions, the commercial inflection, the standards politics, the accidental dominance of JavaScript, and the platform decade. The web’s victory was real and is worth understanding on its own terms, separately from the alternatives it displaced. The four chapters in Part IV try to do that.

The technical decisions that mattered — stateless HTTP, URLs without coordination, lossy linking, view-source

The web won. The last ten chapters have been about the alternatives it displaced; this chapter is about what made it win at the protocol level. The web is, considered as a piece of engineering, a particular set of choices made by particular people for particular reasons. The choices were not obvious at the time. Several of them were specifically rejected by competing systems. Several are still controversial in the niche literature on hypermedia. All of them were made deliberately, by Tim Berners-Lee and the small group of collaborators around him at CERN through 1989 and 1990, with subsequent refinement by the wider community as the protocol grew. This chapter treats the choices that mattered most: statelessness, uncoordinated URLs, one-way lossy linking, permissive parsing, and view-source. Each was a trade-off. Each had a cost. Each was, in the context of 1990, defensible, and several of them turned out, at the scale the web eventually reached, to be the right call. Understanding what the web chose is the first step in understanding why it won.

Where the web came from

In March 1989, Tim Berners-Lee, a software engineer at CERN — the European Organization for Nuclear Research — wrote a short proposal titled “Information Management: A Proposal” and submitted it to his manager, Mike Sendall. The proposal addressed a practical problem at CERN: the laboratory was a large and complex organization with thousands of researchers, many of them visiting for short periods, working on documentation distributed across many systems and many media. New researchers spent weeks figuring out where the information they needed lived. Established researchers had no efficient way to follow cross-references between documents on different systems. The institutional knowledge of CERN was fragmented across NeXT machines, VMS systems, Unix workstations, and paper, with no uniform way to access any of it.

Berners-Lee proposed a system in which any document on any of these systems could be referenced by a uniform identifier, requested through a uniform protocol, and rendered through a uniform format. The system would be a federated hypermedia application running on top of the internet, with no central server, no required registration, and no required coordination beyond the network already provided. Sendall, after some delay, approved the proposal with the note “Vague but exciting” written on the cover. Berners-Lee revised the proposal with Robert Cailliau in November 1990 and began implementation. By late 1990 he had a working server (running on a NeXTcube) and a working browser (running on the same NeXT). On August 6, 1991, he posted an announcement of the World Wide Web project to the alt.hypertext newsgroup on Usenet, inviting interested parties to participate. The web was, at that moment, one server, one client, a small set of documents, and Berners-Lee’s promise that the design was worth taking seriously.

The design Berners-Lee had committed to had three principal components: URLs for addressing resources, HTTP for transferring representations of resources, and HTML for marking up the representations. Each component made choices that distinguished the web from the alternatives in the previous chapters. The choices were not made in isolation; they were a coherent set, each reinforcing the others.

Statelessness

The most fundamental of the choices was that HTTP would be stateless. Each HTTP request from a client to a server stood alone. The server did not maintain memory of previous requests from the same client. The connection (in HTTP/0.9 and 1.0) was closed after each response. There was no concept of a session in the protocol; there was no concept of a user; there was no concept of a logged-in state. A request asked for a representation of a resource; the server returned the representation; the connection closed; the next request, if any, was a fresh start.

This was a deliberate departure from how most networked services worked. Telnet maintained a session. FTP maintained a session. The hypermedia systems treated in the academic-hypermedia chapter — Intermedia, KMS, NoteCards — maintained extensive per-user state. Gopher was stateless, but Gopher was an outlier; most networked services at the time assumed that the server had ongoing knowledge of what the client was doing.

The argument for statelessness was scaling. A stateful server has to remember things; the memory consumes resources; the resources limit how many clients the server can handle simultaneously. A stateless server forgets immediately; it can handle any client whose request arrives and immediately return to a clean state. The server’s capacity is bounded by request-processing throughput, not by concurrent-session count. For a system that might have to serve thousands of concurrent users on commodity hardware, statelessness was the architecture that let the hardware reach its limit.

The argument against statelessness was that it threw away features the stateful systems had been providing. Awareness of who was reading what, of where in the document graph a user had been, of which links a user had already followed — all of these required state, and the web specifically did not have it. The cost was paid in two ways. Applications that needed state (essentially all of them, eventually) had to invent it on top of the stateless protocol, using cookies, session tokens, server-side session stores, and the elaborate apparatus of modern web authentication. The application layer absorbed the complexity the protocol had refused to take on. And users lost the benefit of features (collaborative awareness, link history, position tracking) that the stateful systems had offered as a matter of course.

The trade was, in retrospect, the right one. The stateless protocol let the web grow to scales the stateful alternatives could not have reached. The added complexity at the application layer became, eventually, the platform on which sophisticated stateful applications were built. But the cost — that the application layer is where state has to live, that protocol-level features cannot count on it, and that the web’s basic substrate is, structurally, a series of disconnected transactions — has shaped everything that has happened since.

Uncoordinated URLs

The second of the deep choices was that URLs would be uncoordinated. Anyone with a host on the internet could mint URLs for resources on that host. There was no central authority that approved URL allocations. There was no registry of URLs that resolved them to canonical destinations. The system was: you put a server up on your machine, you decided what paths it served, and the URLs were http://yourmachine/yourpath. The hierarchy of authority was DNS, which already existed, and DNS was federated.

This was a rejection of what every serious hypermedia system had proposed. Xanadu had a global address space with tumblers and a registry. The academic hypermedia systems had link databases that registered links separately from documents. Gopher had a centralized hierarchy of servers indexed by Veronica. WAIS had a directory of servers that registered which databases were available where. Each of these systems assumed, in one form or another, that some authority had to know about each resource for the resource to be findable. The web’s answer was: no such authority. The internet’s name resolution (DNS) was enough; below that, each domain owner managed their own namespace; below that, there was no coordination required.

The benefit of uncoordinated URLs was that the web could grow without permission. Anyone with a host could publish; no application to a central authority was required; no coordination with other publishers was needed. The cost was that links could break for any reason at any time, that there was no system-level guarantee that a URL would continue to work, and that the citation network of the web was constructed by individual link-makers with no system-level support for keeping the citations valid.

This cost is what we call link rot. A 2010 study by Klein, Van de Sompel, and others found that approximately half of the URLs cited in academic papers became unreachable within a decade. Subsequent studies have found similar patterns across many domains. The web’s citation infrastructure is structurally fragile in a way that print’s was not, and the fragility traces directly to the choice to forgo URL coordination. The trade-off was: pay the cost of broken links to get the benefit of permissionless growth. The web has, on balance, paid the cost.

The recoveries are imperfect. The Internet Archive’s Wayback Machine, founded in 1996, has been the closest thing to a retrofitted versioning layer for the web. Persistent identifier systems — DOIs for academic publishing, ARKs for cultural heritage materials, Handles for various domains — provide URL-like identifiers with explicit promises of permanence. Each of these systems has carved out a niche where the web’s default uncoordinated URLs were too fragile to be relied on. None has reached the scale where it changes the web’s basic relationship to its own past.

Lossy one-way linking

The third deep choice was that links would be one-way and lossy. A link from page A to page B was a property of page A. Page B did not know about the link. If page A changed or was removed, the link disappeared from the system’s record without page B noticing. If page B moved or was renamed, the link in page A would silently break, with no notification to page A’s author and no automatic update of the link.

The contrast with the alternatives is sharp. Xanadu had two-way links with version permanence. Intermedia had two-way links with linkbases. NoteCards had backlinks. The academic hypermedia community had spent two decades developing the theoretical and practical apparatus for richer link models. Berners-Lee’s 1989 proposal specifically considered two-way linking and specifically rejected it, on the grounds that requiring the destination of a link to know about the link would prevent the system from being permissionless: you cannot link to my page unless I let you, if my page has to be updated whenever you link to me.

The choice was, structurally, the right one for a permissionless system. The cost was that the citation structure of the web exists only in the source documents; from the destination, you cannot see what links to you. Search engines, by crawling the web, reconstruct this information at enormous cost — much of what makes search engines work, in fact, is the inferred backlink graph that the protocol itself refused to maintain. The information is recoverable, by external means; it is not native to the system.

Smaller-scale recoveries have been deployed. Webmentions (W3C recommendation since 2017) let a citing page notify a cited page of the citation, and let the cited page display incoming mentions; the cited page has to opt in to the system, but where both sides opt in, two-way linking is recovered. Pingbacks (a precursor of webmentions, dating from 2002) provided similar functionality for the WordPress era. RSS feed enclosure links, the Linkback systems in some publishing platforms, and the various comment-thread aggregators all provide pieces of the property the protocol does not natively support. None of these are universal; all are bolt-ons.

The deeper cost, beyond the technical one, is that the web has an asymmetric model of authorship. The link is a unilateral act by the source author; the destination is a passive recipient. Citation as a social act is asymmetric on the web: the citer chooses, the cited is informed only by the analytics they install. This is not how citation works in print, where the cited work, once cited, has a verifiable existence in the citing work’s bibliography that the cited work’s author can see and respond to. The web’s one-way linking has eroded the social dimension of citation, in ways that have been felt particularly sharply in academic publishing and in the various reputation systems that depend on citation.

Permissive parsing

The fourth choice, sometimes treated as an implementation detail and sometimes as a deep architectural commitment, was that HTML would be permissively parsed. The original HTML specification was small; browsers were expected to render the document even when the markup was malformed; authors who produced bad HTML would see something on the screen, possibly not what they intended, but not nothing. The browser’s job was to make the best of whatever input it got.

This was a sharp contrast with SGML, the markup language family HTML descended from, which had a strict validation regime: documents either conformed to a Document Type Definition or did not, and non-conformant documents were not processed. SGML’s strictness was a feature for the kinds of professional publishing it had been designed for, where document validity was checked by tools and authors had time and incentive to fix errors. SGML’s strictness was a barrier for the much more casual authorship the web was about to invite.

The web’s permissive parser was, in effect, a statement that authorship would not require validation. Anyone who could write something that looked like HTML could publish. The browser would deal with the rest. This made authorship dramatically more accessible; it also made the population of HTML in the wild dramatically less clean. By the mid-1990s, much of the HTML on the web was malformed in some way, and browsers had built elaborate “tag soup” parsers — heuristics for guessing what the author had meant when the markup was ambiguous — to handle it.

The cost of tag soup was a competitive pressure. A browser that did not handle malformed HTML the way Netscape or Internet Explorer did would render existing pages incorrectly, and users would conclude that the browser was broken. New browsers entering the market had to reverse-engineer how the existing browsers handled malformed input. This was substantial work, and it became a significant moat protecting incumbent browsers. The eventual standardization of HTML5 in the late 2000s included, for the first time, a specification of how parsers should handle invalid input, codifying what had been informal practice. The HTML5 parsing algorithm is hundreds of pages of specification text dedicated to the question of what to do with input that is, by older standards, not HTML at all.

The recovery from tag soup has been XHTML, then HTML5’s strict parsing for application/xhtml+xml documents, and then the broader return to validation in many publishing workflows (static site generators, content management systems with template validation, the markup-aware editors used in modern web publishing). The web’s raw substrate remains permissive; the layers above it have, in many cases, recovered the validation discipline that the substrate refused.

View-source

The fifth choice was a feature, not a protocol decision, but it was load-bearing for the web’s culture. View-source — the menu item in early browsers that opened the page’s HTML source in a separate window — let any reader of a web page see how the page was constructed. The HTML was visible, readable, and copyable. Anyone curious about how a page achieved an effect could open the source, find the relevant markup, and learn.

The cultural effect was that the early web was a school. A generation of web authors learned HTML by reading other people’s HTML. Pages were borrowed, modified, republished. Techniques spread through view-source the way recipes had spread through cookbooks. The activation energy for becoming an author of the web was reading some pages, viewing their source, and trying things; no formal instruction was required and no special tools beyond a text editor.

The cultural effect lasted as long as the web’s source was readable. Through the late 1990s and into the 2000s, view-source continued to be a learning tool. As JavaScript grew and pages became applications, the source became less readable; modern JavaScript bundles are minified, obfuscated, and unreadable to anyone but the author. View-source still works as a menu item; what it shows, on most modern web pages, is incomprehensible. The cultural pattern that view-source enabled has weakened, although it persists for the parts of the web that still use legible HTML and CSS.

The choice to make source visible was not specifically against any of the alternatives, but it was a meaningful contrast with several. HyperCard had similar transparency: stacks could be opened and inspected. Most desktop applications did not, and most platform-mediated content does not now. The web’s transparency was a real and substantial property, particularly in the years it lasted, and its erosion is one of the quieter losses that the platform decade has produced.

The IMG tag and the inflection toward applications

A specific choice within the early web that is worth singling out is the IMG tag, added to HTML by Marc Andreessen at NCSA in 1993 and implemented in NCSA Mosaic. The IMG tag let HTML include an image inline with text, with the image fetched from a separate URL and rendered alongside the surrounding text. The tag was added to Mosaic without going through any formal standards process; it shipped, and other browsers adopted it because users wanted the feature. Berners-Lee was, at the time, opposed to the specific design Andreessen chose, preferring an extensible OBJECT-style mechanism that would have handled images as one case of a general inclusion mechanism. The OBJECT-style alternative was eventually specified, but IMG had already won the market.

The argument over IMG was, in retrospect, a smaller version of a larger pattern. The web’s design needed to handle media beyond text. Andreessen’s choice was pragmatic: a single-purpose tag for the most common case. Berners-Lee’s preference was structural: a general mechanism that handled images, video, embedded documents, and other inclusions through a unified abstraction. Andreessen’s approach shipped; Berners-Lee’s approach was not implemented for years; the web ended up with a proliferation of single-purpose tags (IMG, EMBED, OBJECT, VIDEO, AUDIO, IFRAME, CANVAS) each handling its own narrow case, with no unified inclusion mechanism. This is a recurring pattern: pragmatic single-purpose features beat general abstractions, the web ships, and the long-term cost is a tangle of overlapping mechanisms.

The deeper consequence of IMG, beyond its specific design, was that it made web pages visual. Pre-IMG pages were text-with-links; post-IMG pages were illustrated documents, which led, by stages, to formatted documents, which led to designed pages, which led to interactive applications. The IMG tag is the moment the web stopped being a hypertext system and started being a presentation medium. The application web — JavaScript, CSS, the modern browser-as-platform — is a descendant of the IMG tag’s commitment to visual presentation as a first-class concern.

The HyperCard chapter argued that what we lost was the unified read-and-write tool with a low floor for end-user authorship. The web’s evolution from hypertext to visual presentation to application is one part of why we lost it. The web could have remained a hypertext system, with images as one kind of resource alongside text, but the visual ambition that IMG enabled created the conditions for the application-platform web that followed. The choice was not made deliberately as a turn away from authorship; it was made for good reasons in 1993. The consequences for the broader trajectory were significant and largely unanticipated.

Putting the choices together

The five choices treated above — statelessness, uncoordinated URLs, lossy linking, permissive parsing, view-source — and the sixth (the visual evolution started by IMG) form a coherent design. Each reinforces the others. A stateless protocol works with uncoordinated URLs because the URLs don’t need to be remembered between requests. Uncoordinated URLs require lossy linking because two-way links would need coordination. Lossy linking implies permissive parsing because the system has to tolerate the broken links and other malformed input that uncoordinated growth produces. Permissive parsing enables view-source because the source is whatever the author wrote and the browser figures out the rest. The whole design is internally consistent.

The consistency is what made the web fast to learn, fast to deploy, and fast to grow. The web’s competitors had richer designs but were not internally consistent in the same way; each made some features powerful by requiring infrastructure the web did not require. Xanadu’s two-way links required a global registry. Intermedia’s linkbases required institutional infrastructure. KMS’s speed required dedicated hardware. The hypermedia systems were rich in particular dimensions and demanding in correspondingly particular ways. The web was thin in every dimension and demanding in none. The thinness was the price for the scaling.

The chapters in Part V take, in different ways, the position that some of these trade-offs need to be revisited. Local-first wants to recover the per-client persistence the web threw away with statelessness. Personal knowledge tools want to recover the two-way linking the web threw away with one-way links. The static renaissance wants to recover the document focus the web threw away in its turn toward applications. Each recovery is a way of negotiating with the trade-offs the protocol chose. None is a wholesale rejection of the web’s design.

Roy Fielding and REST

A useful retrospective frame for the web’s design came in 2000, when Roy Fielding completed his PhD dissertation at UC Irvine. Fielding had been one of the principal authors of HTTP/1.1 and was, by 2000, a thoughtful theorist of the web’s architecture. His dissertation, “Architectural Styles and the Design of Network-based Software Architectures,” named the web’s underlying style REST — Representational State Transfer — and articulated the constraints that the style imposed on architectures that followed it. The constraints were six: client-server separation, statelessness, cacheability, uniform interface, layered system, and (optional) code-on-demand.

Fielding’s framing has been influential beyond its original purpose. The REST acronym has been adopted, often imprecisely, by an entire industry of web API designers who use it to mean “we have HTTP endpoints with reasonable URLs.” The original meaning was more specific: a REST architecture is one in which the server exposes resources at addresses, the client navigates between resources through hypermedia links embedded in the representations, and the state of the application moves from the server to the client as the client follows links. This is, in essence, the structure of the web of documents: you fetch a page, the page contains links, you click a link, you fetch the next page. Fielding was articulating, in 2000, the design that the web had implemented in 1991, and showing why the design’s constraints had been load-bearing for its scaling.

The REST constraints were not arbitrary. They corresponded to the choices treated in this chapter: client-server separation made the protocol pluggable; statelessness made it scalable; uniform interface made it interoperable; layered system made it evolvable; code-on-demand let the protocol grow without breaking existing clients. The web’s success had been a demonstration that an architecture with these constraints could grow; Fielding’s dissertation was the analytical articulation of why.

REST as an architectural style has been important for the design of web APIs and for the broader thinking about how internet services should be structured. It has also been routinely misunderstood. Most “REST APIs” in practice violate Fielding’s constraints in significant ways, particularly the hypermedia-as-the-engine-of-application-state constraint. The web’s actual practice has drifted from the architectural style its underlying protocol embodied. The drift is one of the things that Part V’s chapters track: the web increasingly is not architecturally a hypermedia system; it is increasingly a thin client to remote applications.

The costs paid

The chapter has been about the technical decisions that gave the web its shape. Each decision was a trade-off; each trade-off has had downstream costs. The summary is worth being explicit about.

The cost of statelessness has been the application-layer scaffolding that recovers state where applications need it. Cookies, sessions, OAuth tokens, the complex authentication and authorization machinery of modern web applications — all of it exists because the protocol does not provide what applications need. The cost has been complexity at the application layer, and the cost has been distributed across millions of applications, each solving the same problem incompletely.

The cost of uncoordinated URLs has been link rot. Half the citations in academic papers break within a decade. The web’s relationship to its own past is, structurally, fragile, and the recovery (the Internet Archive, persistent identifier systems, web archiving projects) has been retrofit and incomplete.

The cost of lossy linking has been the citation network being invisible from the cited side. The deep structure of the web is reconstructable only by external means, and the institutions that reconstruct it — search engines, primarily — have become structurally central in a way the protocol did not require.

The cost of permissive parsing has been browser implementations being enormous and difficult to write, a structural barrier to new entrants in the browser market, and a stream of subtle compatibility issues that have absorbed engineering attention for thirty years.

The cost of view-source’s effective erosion — as pages have become applications and source has become minified bundles — has been the loss of the teaching tradition that view-source had supported. The activation energy for becoming a web author is now higher than it was in 1996.

These are real costs. The web is the right system for the world to have built in 1991, given what the world wanted networked computing to do. The trade-offs the web chose were defensible at the time and have, on balance, been right at scale. The recovery work in Part V is not work to replace the web; it is work to recover, on top of the web’s substrate, properties that the substrate did not provide. The web is not going away. The question for the recovery is which of the original alternatives’ features can be reassembled into the web’s world and which cannot.

The next chapter takes the moment the web became commercial. The technical decisions Berners-Lee and his early collaborators made were one thing; the commercial inflection that came with Mosaic and Netscape was another, and the two together produced the trajectory of the next thirty years. Andreessen and the people around him are the protagonists of the next chapter; Berners-Lee and the people around him recede into the standards-body history that comes after.

Mosaic, Netscape, and the commercial inflection

The web that Tim Berners-Lee released from CERN in 1991 was a research artifact. It had one server, a few users, and a browser that ran on NeXT machines. The web that became the substrate for civilization was a commercial product, built on the same protocols but with a different cast of characters, different incentives, different priorities, and a different sense of what the project was for. The transition between the two webs took less than four years, and the principal actors in it were Marc Andreessen, Jim Clark, the team that built NCSA Mosaic and then Netscape Navigator, and the financial markets that turned the Netscape IPO of August 1995 into the most consequential commercial moment in the history of the internet. This chapter is about that transition: how Mosaic happened, how Netscape happened, what the IPO meant, what the resulting Browser Wars produced, and how the trajectory of the web bent during the four-year window in which the commercial inflection occurred. The technical decisions of the previous chapter had given the web its shape; the commercial decisions of this chapter gave the web its direction.

Mosaic at NCSA

The National Center for Supercomputing Applications was founded at the University of Illinois Urbana-Champaign in 1986 as one of the supercomputer centers funded by the National Science Foundation. NCSA had, by the early 1990s, become a hub for scientific computing and visualization work, with a substantial software development operation. One of the projects at NCSA was the Software Development Group, where a handful of undergraduate and graduate-student programmers worked on visualization tools, network software, and various internet utilities. Marc Andreessen was one of the undergraduates in this group. Eric Bina was a staff programmer in the same group. Together, beginning in late 1992, they began work on a web browser for X Window System, intended for the Unix workstations that were the dominant scientific computing platform at the time.

The browser was released on January 23, 1993, as Mosaic for X. It was free, freely redistributable, and almost immediately popular. Mosaic was not the first web browser — Berners-Lee’s original NeXT browser preceded it by two years, ViolaWWW and a handful of other browsers existed before Mosaic — but it was the first browser that was both easy to install on common Unix workstations and graphically rich enough that the pages looked like something. The IMG tag, treated in the previous chapter, was Mosaic’s most consequential addition: inline images, fetched alongside the text and rendered in place, made web pages visual in a way that the previous browsers had not allowed. The combination of accessible installation, graphical presentation, and rapid release cadence put Mosaic ahead of every other browser within a few months of its release.

A small team at NCSA, building on the Andreessen-Bina X version, produced ports of Mosaic to Microsoft Windows (released in August 1993, with Chris Wilson and Jon Mittelhauser as principal authors) and to the Apple Macintosh (released in September 1993, with Aleks Totic and Mike McCool as principal authors). The Windows and Mac ports mattered more than the X version had, because they brought the web to consumer hardware. By the end of 1993, Mosaic was available on every major personal-computing platform, and the number of web servers in the world had grown from about fifty at the start of the year to several hundred by the end. The growth curve traced Mosaic’s availability closely.

The Mosaic team had a reputation, at the time and since, for moving fast. Features were added quickly. The IMG tag, the form input controls that let users submit data, the early bookmarking and history features that made the browser usable for sustained reading — these were added during 1993, in cycles measured in weeks rather than months. The development pace was a real competitive advantage: by the time other browsers were catching up to Mosaic’s December feature set, the Mosaic team had already moved on to the next round. The pace was sustainable because the team was small, intensely focused, and operating in the kind of resource-rich but unsupervised environment that NCSA had become for the small group of people who worked on web software there.

It is worth noting what Mosaic was not. It was not invented in a corporate research lab. It was not the product of years of design and review. It was an undergraduate’s project, with a staff programmer’s support, written in a few months on a tight schedule, in a culture that valued shipping. The technical choices were pragmatic. The design priorities were “what makes users like the browser more, ship it.” The discipline that had characterized hypermedia research — the careful debate over linking models, the formal apparatus of the Dexter Reference Model, the attention to argumentation structures and version control — was largely absent from the Mosaic development process. This is not a criticism. Mosaic worked. The discipline that was absent was discipline appropriate to a different scale of project.

Andreessen leaves; meets Clark

Andreessen graduated from UIUC in December 1993 and left NCSA for Silicon Valley. The immediate reason was that NCSA had begun to assert ownership over Mosaic and was, in his view, marginalizing the team that had built it. The deeper reason was that the commercial opportunity Mosaic represented was, by late 1993, visible to anyone who looked: hundreds of new web servers per month, growing demand for browsers, a software market that did not yet have a dominant commercial product. Andreessen moved to California and took a job at a small startup. He had been there for a few months when he was contacted, in early 1994, by Jim Clark.

Clark was the founder of Silicon Graphics, the visualization-workstation company that had dominated the high-end graphics market through the late 1980s and early 1990s. He had recently left SGI and was looking for the next project. A mutual acquaintance had suggested Andreessen as someone worth talking to. The meeting happened. Clark, who had the capital and the network to put a serious software company together, asked Andreessen what was worth building. Andreessen’s answer was a commercial web browser, with the original Mosaic team recruited away from NCSA, building a product designed for the consumer and commercial markets that were about to emerge.

Clark agreed. The company was founded in April 1994, in Mountain View, California, originally as Mosaic Communications Corporation. The founding team included Andreessen, Bina, Totic, Mittelhauser, McCool, and several others from the NCSA Mosaic project. Clark put up the initial capital and brought on additional investors. NCSA, when it learned the company had taken its name and its team, threatened legal action. The company changed its name to Netscape Communications Corporation in November 1994, settled with the University of Illinois for a modest payment, and released its first product — Netscape Navigator 1.0 — in October 1994 (with the final version shipping in December).

The transition from NCSA Mosaic to Netscape Navigator was, on the surface, the same team producing a successor product. Underneath, it was a transition from research to industry. Netscape was a venture-backed company with a billion-dollar ambition. The team had to ship a product on a quarterly cadence, with a roadmap aligned with the company’s commercial plans, against competitors who would soon include the largest software company in the world. The development culture had to industrialize. The features had to drive adoption that would justify the valuation. The web, which had been a research project, was now a market.

Netscape’s product velocity

Netscape moved quickly. The first commercial version of Navigator shipped in late 1994, free for personal use and paid for commercial use. Within a few months it had become the dominant browser, with market share estimates in the 70-80% range through 1995. The product cycled rapidly: Navigator 2.0 in March 1996, 3.0 in August 1996, 4.0 (Communicator) in June 1997, with each release introducing significant new features and reaching tens of millions of users.

The features Netscape added during 1995 and 1996 shaped the web more than the underlying protocols did. Cookies, designed by Lou Montulli at Netscape and shipped in 1994 in early form, gave the stateless protocol a way to maintain state across requests; the cookie became the substrate for everything from logged-in sessions to advertising tracking. JavaScript, designed by Brendan Eich at Netscape in 1995 (originally called Mocha, then LiveScript, then renamed JavaScript for marketing reasons related to Netscape’s partnership with Sun), gave the browser a programming language for scripting page behavior. SSL, designed by Taher Elgamal’s team at Netscape and shipped as SSL 2.0 in February 1995 and SSL 3.0 in late 1995, gave the web encryption-in-transit and made commerce possible. The PNG image format, frames, table-based layout, plugins, embedded multimedia — each of these was a Netscape addition to the web’s vocabulary, mostly shipped before the standards bodies had a chance to specify them, and most of them subsequently standardized in retroactive fashion.

The pace of feature addition had two effects. The first was that Netscape became, briefly, the de facto standards body for the web: features Netscape shipped were features the web had, regardless of what the W3C or IETF eventually said about them. The second was that the web became more complicated, faster, than its specification process could absorb. The W3C, founded in 1994 (treated in the next chapter), spent much of the next decade catching up to what the browser companies had already shipped, with the standards process producing post-hoc rationalizations of decisions made by Netscape and (later) Microsoft engineers.

The features were also, increasingly, features that pushed the web toward applications rather than documents. Cookies enabled sessions, sessions enabled applications, applications enabled the kind of stateful interaction the original web design had specifically rejected. JavaScript enabled client-side logic, client-side logic enabled real interactivity, interactivity enabled the kinds of UIs that desktop applications had been producing and that the web was about to learn to produce. SSL enabled commerce; commerce required logins and shopping carts and payment processing; payment processing required, in turn, more session state, more JavaScript, more application infrastructure. Each Netscape feature shipped for a defensible reason — users wanted commerce, they wanted dynamic pages, they wanted to be logged in — and the cumulative effect was a web that was less a hypermedia document system and more a runtime environment for distributed applications. The shift was not designed; it was the accumulated weight of individual decisions, each defensible in isolation, that bent the medium’s trajectory.

The IPO

Netscape filed for an initial public offering in the summer of 1995. The offering was priced at $14 per share, then raised to $28 the day before. On August 9, 1995, the stock opened at $71, traded as high as $74.75 during the day, and closed at $58.25 per share. The company, which had been founded sixteen months earlier and had never recorded a profitable quarter, was valued at $2.9 billion. The IPO is the conventional marker for the moment the commercial internet became a mass-market financial phenomenon. The internet became a thing that people invested in, that newspapers covered as a financial story, that brought money flooding into anything that could position itself as related to the web.

The IPO had several specific consequences for the web.

It put a price tag on the browser. Until August 1995, the browser was, depending on which one you used, a research artifact, a freely distributed scientific tool, or a low-cost shareware product. After August 1995, the browser was a strategic asset worth billions of dollars. Microsoft, which had been notably absent from the early web, treated the Netscape valuation as a wake-up call: a competitor was emerging in a market Microsoft considered its own (desktop software), and the competitor was being valued at levels that suggested the threat was serious. Internet Explorer 1.0 shipped on August 16, 1995, a week after the Netscape IPO. The Browser Wars had begun.

It made the web a venture-capital category. Before the IPO, web-related businesses had been small startups with limited funding and modest ambitions. After the IPO, web-related businesses were the hottest investment category in the venture-capital world, and capital flooded into anything that could plausibly claim to be web-related. The eventual peak — the dot-com bubble of 1999-2000 — was the direct continuation of the trajectory the Netscape IPO had set. The bubble produced enormous waste (hundreds of failed startups, billions of dollars lost) and enormous infrastructure (broadband deployment, data centers, the early dominance of Amazon and Google) that the long-term web depended on.

It made advertising the default business model. Netscape’s own revenue came from selling the browser, the server software, and various commercial products. The companies that built businesses on top of Netscape’s browser, however, mostly could not charge for what they did: web users had been trained to expect free, and the free model needed a revenue source. Advertising became, by default, the answer. The first banner ads had appeared on HotWired in October 1994; by late 1995, banner advertising was a serious business; by the late 1990s, web advertising was a major industry. The structural commitment of the consumer web to advertising as the primary revenue mechanism dates from this period, and almost everything about the web’s subsequent evolution — the privacy story, the platform story, the algorithmic-feed story — descends from the choice of advertising as the underlying business model.

It changed who was building the web. Before the IPO, the people building the web were mostly the same people who had been on the internet for years: academic researchers, engineers at internet-aware companies, hobbyists. After the IPO, the people building the web were increasingly people who had just arrived, with capital and ambition and an interest in the commercial opportunity. The culture that had built the early internet — open, technical, oriented toward standards and interoperability — was diluted by the influx of commercial actors with different priorities. This was not entirely bad; the influx brought resources and expertise that the academic-and-research community could not have provided. But it was a change, and the web that the new arrivals were interested in building was a different web from the one Berners-Lee had proposed.

The Browser Wars

Microsoft’s Internet Explorer was the company’s response to Netscape, and the response was substantial. Internet Explorer 1.0 in August 1995 was a weak product. By Internet Explorer 3.0 in August 1996, Microsoft had a competitive browser. By Internet Explorer 4.0 in September 1997, Microsoft had a better browser than Navigator in several respects. By 2000, Microsoft had won.

The mechanics of the win were several. Microsoft bundled Internet Explorer with Windows; users got the browser free with the operating system, with no separate download or installation required. Microsoft invested heavily in the browser’s engineering, with hundreds of engineers working on it; Netscape, a smaller company with less capital, could not keep pace. Microsoft used its operating-system position to ensure that Windows favored its own browser; the Department of Justice antitrust trial of 1998-2001 found that Microsoft had engaged in anticompetitive behavior in this regard. By the time Netscape was acquired by AOL in November 1998 for $4.2 billion in stock, the Browser Wars were effectively over, and Internet Explorer was the dominant browser with market share above 90% by 2002.

The Browser Wars are remembered, in retrospect, as a period of fast feature development and incompatibility between browsers. Both Netscape and Microsoft added features competitively, often without standards-body input, with the result that web pages could behave differently in the two browsers. Web developers spent a substantial fraction of their time writing code that worked around browser incompatibilities. The “browser sniffing” patterns of the late 1990s, in which JavaScript code branched on which browser was running and behaved differently in each, are the residue of this competitive environment. The cost of the wars, in developer time and in user experience, was substantial. The benefit was rapid feature development that the standards-driven process probably would not have produced.

The end of the wars, with Microsoft’s victory, produced a different kind of cost. Internet Explorer’s dominance through the early 2000s, with Microsoft having little competitive pressure to improve it, led to a period of stagnation in browser features. IE6, released in 2001, remained the dominant browser for nearly a decade, and its limitations shaped web development through that period in ways that hold web designers’ breath when they remember them. The eventual recovery — Firefox in 2004, Chrome in 2008, the modern browser ecosystem — required the kind of competitive pressure Microsoft’s dominance had eliminated. The recovery is one of the more cheerful stories the web has to tell.

After Netscape

Netscape’s specific story did not end well. The acquisition by AOL in 1998 was, at the time, a substantial transaction, but AOL’s commercial trajectory peaked shortly afterward; the AOL-Time Warner merger of 2000 has been described, by Time Warner’s own executives in retrospect, as a disaster. Netscape’s browser was reduced to a niche product and was eventually discontinued in 2008. The Mozilla project, into which Netscape had released its browser source code in 1998 (a milestone that anticipated by years the open-sourcing of other major commercial products), continued and produced Firefox, which has been one of the most important browsers in the period since.

Andreessen himself went on to other projects: Loudcloud (a cloud computing company, founded 1999), Opsware (the rename and pivot after the dot-com bust, eventually sold to HP for $1.6 billion in 2007), and Andreessen Horowitz (the venture capital firm he co-founded with Ben Horowitz in 2009, which has become one of the dominant Silicon Valley VC firms of the last fifteen years). His role in the broader trajectory of the commercial internet has continued well past Netscape.

Jim Clark went on to start Healtheon (a health-care internet company, founded 1996, merged with WebMD in 1999) and various other ventures. He has been generally regarded as one of the great entrepreneurs of the period, with multiple multi-billion-dollar companies to his credit.

The Netscape engineering team, after the AOL acquisition and the eventual wind-down, scattered across the industry. Several principal alumni went on to other significant roles: Brendan Eich became CEO of Mozilla, then founded Brave; Jamie Zawinski became one of the more visible commentators on Netscape’s history; Lou Montulli, who had designed cookies, continued as an engineer at various companies; the broader team contributed to the development of much of the modern web infrastructure in the two decades that followed.

What the commercial inflection meant

The Netscape story is, in some ways, ancillary to the broader argument of the book. Netscape did not change the web’s protocols substantially; it did not change the URL or the HTTP method set or the basic page model. But the commercial inflection it represented changed the direction the web took in ways that have proven much more important than the protocol-level decisions of the previous chapter.

The commercial inflection meant that the web’s evolution was driven, primarily, by commercial concerns rather than by the requirements of hypermedia as a research field or the requirements of authorship as a humanistic practice. The browser, which was the user’s primary interface to the web, was a commercial product whose success was measured by user adoption and corporate revenue. The standards that emerged were retrospective rationalizations of decisions made for competitive reasons. The features that shipped were features that drove adoption: visual richness, dynamic interactivity, commerce-friendly state management, advertising-friendly tracking. The features that did not ship were features the commercial logic had no incentive to ship: rich linking models, durable addressing, federation-friendly identity, user-controlled customization.

The web after Netscape was, structurally, a commercial product layered on top of a research substrate. The research substrate’s choices — uncoordinated URLs, stateless protocol, permissive parsing — were appropriate to the research project Berners-Lee had been doing. The commercial layer that the Netscape inflection produced was different in kind, oriented toward different goals, and shaped by different incentives. The two layers have continued to coexist, with the commercial layer growing thicker and the research substrate becoming increasingly invisible underneath it.

This is the structure that the rest of Part IV traces. The next chapter takes the standards bodies that tried, with mixed success, to govern the web’s evolution against the pressure of commercial development. The chapter after that takes the browser’s evolution into the modern application platform. The chapter after that takes the platform decade, in which a small number of companies absorbed most of what the rest of us thought we were building. Each of these stories is, in part, a continuation of the trajectory the Netscape IPO set in motion. The web that Berners-Lee specified in 1991 was a research object. The web that the world uses in 2026 is something else, and the Netscape inflection is one of the moments when the something-else came into focus.

The standards story, taken up next, is the story of how the web’s governance tried to keep up with the commercial pace. The story has its own arc — the early IETF dominance, the founding of the W3C, the WHATWG revolt, the eventual peace — and it produces a different perspective on the same trajectory the Netscape chapter has just sketched. The institutions that govern the web are not the institutions that originally proposed it, and the displacement is part of the story.

The standards body story — IETF, W3C, WHATWG

Every running protocol on the internet is governed by some institution that decides what is and is not the protocol. The institutions are not famous; their proceedings are dry; their politics are visible only to participants and the small community of journalists who cover infrastructure. They are nevertheless among the most consequential institutions of the contemporary world, because they decide what the web is allowed to do, what features it must support, who is allowed to add new ones, and what counts as a legitimate disagreement. The web’s standards have been governed, at different times and in different combinations, by the Internet Engineering Task Force, the World Wide Web Consortium, the Web Hypertext Application Technology Working Group, and ECMA International, with various ad-hoc arrangements among them. The history of those institutions and their interactions is the history of how the web has been governed at the technical layer, and the history is messier than the institutional self-descriptions usually suggest. This chapter is about that history: how it produced the web’s current standards, who has been driving the decisions, where the conflicts have come from, and what has been won and lost in the institutional politics.

The IETF tradition

The Internet Engineering Task Force was formalized in 1986, but its working method had been in place at the various ARPA-funded standards groups for the previous fifteen years. The method was: anyone could participate, anyone could submit a draft, drafts were discussed in working groups, and a draft became a standard when there was “rough consensus” among the working group and “running code” demonstrated that the draft was implementable. David Clark, the MIT engineer who was one of the IETF’s most influential figures, summarized the method in a 1992 talk: “We reject: kings, presidents and voting. We believe in: rough consensus and running code.” The slogan stuck.

The IETF’s working method was, by the standards of formal standards bodies, almost anarchic. There was no membership. Anyone could come to a meeting; the meetings were three times a year, in various cities around the world. Working groups operated mostly through mailing lists, and the lists were open subscriptions. The decisions were made by the chairs and area directors based on their assessment of the discussion, with no formal voting and no quota system. The Internet Architecture Board (IAB) and Internet Engineering Steering Group (IESG) provided light oversight. The whole apparatus depended on the participation of competent volunteers — engineers from various companies and universities who showed up to the meetings, did the work, and produced the specifications.

The method had limitations and the limitations were known. Rough consensus could be hard to determine and rough consensus on contentious topics could exclude perspectives that were not represented in the working group’s volunteer pool. The working groups tended to be dominated by people who had time to attend the meetings and follow the mailing lists, which skewed the demographics in predictable ways. The “running code” requirement biased the process toward implementations that already existed, which sometimes meant that the standards followed market-driven decisions made elsewhere. But the method worked, in the sense that it produced specifications that interoperated and that the actual protocol implementations broadly conformed to. The IETF’s RFCs (Requests for Comments) are the closest thing the internet has to authoritative documentation, and the standardization process that produced them is the closest thing the internet has to a constitutional system.

The IETF produced the foundational web standards: HTTP/1.0 in RFC 1945 in 1996, HTTP/1.1 in RFC 2068 (1997) and RFC 2616 (1999, revised through RFC 7230 in 2014 and RFC 9110 in 2022), and the URI specification in RFC 3986 (2005). The HTTP standardization in particular was a substantial effort, with Roy Fielding and Henrik Frystyk Nielsen as principal editors, and with substantial input from the major browser and server companies. HTTP/1.1, in particular, was a real protocol — pipelining, persistent connections, content negotiation, chunked transfer, conditional requests — that was used at internet scale for over fifteen years before HTTP/2 began to displace it.

The W3C

The HTML side of the web was a different story. HTML was not, originally, an IETF standard; it was a CERN-produced specification that grew through informal extension as Mosaic and the early browsers added features. The IETF began an HTML working group in 1994 that produced HTML 2.0 (RFC 1866 in 1995), but it became clear that HTML’s evolution was happening too fast for the IETF process to keep up with, and that the political dynamics among the browser vendors were not suited to the IETF’s volunteer-driven model. A different institution was needed.

The institution that emerged was the World Wide Web Consortium, founded in October 1994 at MIT, with Tim Berners-Lee as director. Berners-Lee had moved from CERN to MIT specifically to start the W3C; CERN, as a physics laboratory, was not the appropriate institutional home for a long-term standards body for the web. The W3C was structured as a membership organization. Companies and other institutions paid membership dues; in exchange they got the right to participate in working groups, vote on recommendations, and influence the W3C’s direction. The dues were substantial — the highest membership tier (for large companies) cost tens of thousands of dollars per year — and the membership was, in consequence, dominated by companies that had a commercial stake in web standards.

The W3C produced “Recommendations” rather than “Standards.” The terminological choice was deliberate: the W3C had no power to compel anyone to implement its specifications, and the term “Recommendation” was meant to acknowledge that compliance was voluntary. In practice, the major browsers implemented the W3C Recommendations (mostly), and the Recommendations functioned as standards in the working sense.

The W3C’s working method differed from the IETF’s. The IETF’s “rough consensus and running code” became, at the W3C, a more deliberate process of working drafts, candidate recommendations, proposed recommendations, and final recommendations, with formal review periods and member voting. The pace was slower. The IETF could turn around a specification in months; the W3C often took years. The slowness was sometimes a feature (it produced more carefully-thought-out specifications) and sometimes a bug (it left the browsers to invent features that the W3C process could not keep up with). The browser companies, particularly during the late 1990s, frequently shipped features before the W3C had specified them, and the W3C then had to retrofit specifications to match what the browsers had done.

The XHTML 2.0 failure

The W3C’s most-celebrated failure was XHTML 2.0. After producing HTML 4.01 in 1999 and XHTML 1.0 in 2000 (a reformulation of HTML 4 in XML syntax), the W3C’s HTML Working Group turned its attention to XHTML 2.0, which was to be a clean-slate redesign of HTML. XHTML 2.0 would drop legacy features, require strict XML conformance, introduce a uniform link mechanism, restructure the form model, and generally bring HTML closer to the kind of semantic-web vision Berners-Lee had been articulating. The work proceeded through the early 2000s. The browser vendors, watching, became increasingly unhappy.

The browser vendors’ objection was practical. XHTML 2.0 was not backwards-compatible with the HTML that was actually deployed. Implementing XHTML 2.0 would require the browsers to support two parallel parsing engines — one for the legacy HTML in the wild, one for the new XHTML 2.0 — and would require web authors to choose between the two. The W3C’s working group was, the browser vendors believed, designing for a hypothetical future in which authors would migrate to the new format, ignoring the fact that authors had not migrated to XHTML 1.0 in the years since it had been recommended. The web in 2004 was overwhelmingly HTML 4 with the various extensions the browsers had added; XHTML 2.0 was a plan to start over, and the browser vendors did not want to start over.

In June 2004, three browser vendors — Apple, Mozilla, and Opera — published a joint statement announcing the formation of the Web Hypertext Application Technology Working Group (WHATWG) as an alternative to the W3C’s HTML standardization effort. WHATWG would produce specifications for HTML and related technologies that took the existing web as the starting point, that specified what browsers actually did, and that evolved compatibly with the deployed base. The W3C continued its XHTML 2.0 work for several more years before formally abandoning it in 2009.

The WHATWG revolt was, in retrospect, a turning point in the institutional history of web standards. The browser vendors had effectively declared that they would standardize the web’s central technologies themselves, with or without the W3C’s involvement. The W3C, after some initial conflict, accepted the situation and began collaborating with WHATWG on what became HTML5. HTML5 was a specification of the existing web — what browsers actually did, what authors actually wrote — with extensions for new features (canvas, video, audio, web storage, web workers, etc.) that were already being implemented or planned by browser vendors. HTML5 was published as a W3C Recommendation in 2014, but the specification continued to be developed jointly with WHATWG, and the relationship between the two organizations remained complex through the 2010s.

The 2019 agreement

In May 2019, the W3C and WHATWG signed a formal Memorandum of Understanding. The MoU resolved the long-standing tension by accepting WHATWG’s “Living Standard” model — in which the specification is continuously updated rather than versioned — as the canonical specification for HTML and the DOM, with the W3C deriving its Recommendations from WHATWG’s living standard. The agreement was, effectively, the W3C’s acknowledgment that WHATWG had won the substantive argument: the web’s central technologies would be specified by the browser vendors, working in the WHATWG process, with the W3C playing a coordinating role for adjacent technologies and for the formal Recommendation track that some industries and governments require.

The implications of this arrangement are worth being specific about. The HTML and DOM standards are now produced by an institution (WHATWG) whose membership is, effectively, the major browser vendors: Apple, Google, Mozilla, and Microsoft. The WHATWG’s working method is open in the sense that anyone can read the specifications and submit issues, but the decisions are made by the browser vendor representatives, with limited representation from authors, users, or independent technical experts. The W3C, which had been the formal venue for broader participation in web standards, is now a coordinating body for adjacent technologies (accessibility, internationalization, semantic-web, RDF, CSS — CSS continues to be a W3C standard) rather than the primary venue for the web’s central technologies.

This is not, on balance, a bad outcome. The browsers are where the web actually lives; the browser vendors have the technical expertise and the institutional resources to produce serious specifications; the WHATWG’s living-standard model is more responsive to the web’s actual evolution than the W3C’s slow Recommendation process had been. But the shift is a real one, and it should be named: the web’s central standards are now produced by a vendor consortium with limited external accountability, rather than by a broader institutional process. The trade-off is responsiveness for participation.

ECMA and JavaScript

JavaScript’s standardization has been a separate institutional story. JavaScript was created at Netscape in 1995, as the previous chapter described, and was submitted by Netscape to ECMA International — a European standards body originally founded as the European Computer Manufacturers Association in 1961 — for standardization in 1996. ECMA’s Technical Committee 39 (TC39) was given responsibility for the language. The first edition of ECMAScript (the standard’s official name) was published in 1997; subsequent editions have followed at varying pace.

TC39 has produced JavaScript’s evolution through a careful and increasingly successful process. The committee includes representatives from the browser vendors, from companies that use JavaScript heavily, and from various other interested parties. The process for adding features to the language uses a “stage process” in which proposed features advance through stages of consideration, with each stage requiring more substantial evidence of design and implementation feasibility before the feature can become part of the language. The process is slow by the standards of feature-addition in other languages but fast by the standards of formal standards bodies, and it has produced a language that has evolved substantially while maintaining backward compatibility with the JavaScript of 1996.

The TC39 process is, by reputation, one of the better-functioning standards processes in modern computing. The browser vendors take it seriously; new features that pass TC39’s stages get implemented in browsers within a reasonable time; the language’s evolution has been broadly coherent rather than fragmentary. The cost has been the language itself, which has grown enormously and now contains many features and many ways to do similar things, with the various features representing different generations of TC39’s preferred styles. The success of the process has also been the cause of the language’s bloat.

ECMA’s other relevant standards include ECMA-262 for the core JavaScript language, ECMA-402 for internationalization, and various other JavaScript-adjacent specifications. The W3C, WHATWG, and TC39 collaborate on the various web APIs that bridge JavaScript and the DOM, with the WHATWG handling the DOM, the W3C handling many of the broader APIs, and TC39 handling the JavaScript language itself. The boundaries are sometimes contested but are largely workable.

The EME controversy

The standards-body story has had its share of substantive controversies. The most prominent in recent years was the W3C’s standardization of Encrypted Media Extensions (EME), which provides a JavaScript API for digital rights management systems in the browser. EME does not itself contain DRM; it provides a hook by which DRM modules can be invoked. The DRM modules are proprietary, supplied by various companies (Widevine from Google, FairPlay from Apple, PlayReady from Microsoft), and they are the actual mechanism by which media providers (Netflix, Spotify, etc.) restrict how their content can be used.

The case for EME was that DRM was going to exist on the web one way or another. Media providers required it; browsers were already implementing it through proprietary plugins (Flash, Silverlight); the plugins were a security and stability disaster; a standardized API would let browsers implement DRM in a controlled way that did not require proprietary plugins. The case against EME was that DRM was, in many participants’ view, an inappropriate technology to standardize. DRM restricts what users can do with content they have legitimate access to; it requires non-free code in the browser; it interferes with accessibility, with archiving, with security research, with the basic principles of an open web. The Free Software Foundation, the Electronic Frontier Foundation, and many individual web standards participants opposed EME on these grounds.

The W3C standardized EME anyway, in 2017, after a multi-year debate. Cory Doctorow, a writer and activist who had been a participant in the standards process through the EFF, resigned from the W3C in protest. The standardization passed by a vote of the W3C membership, with the support of the major browser vendors and the media companies, and against the opposition of various civil-society organizations and individual participants.

The EME case is worth dwelling on because it shows the limits of the standards-body model. The W3C is, formally, a consortium that produces specifications by consensus among its members. In practice, the members are mostly companies, and the companies’ interests are mostly commercial. When commercial interests align around a standard that is bad for users or for the broader web (as the EME opposition argued was the case), the standards process produces the standard. The civil-society organizations that participate in the W3C are outnumbered and out-resourced. The IETF’s traditional bias toward “rough consensus” rather than majority voting was, in the W3C, replaced by formal membership voting in which corporate members had the deciding say.

The corporate dominance pattern

EME was an unusually visible case of a broader pattern. The web’s standards are made by a small number of large companies — primarily Google, Apple, Microsoft, and (with declining influence) Mozilla — with various smaller companies and civil-society organizations participating at the margins. The W3C’s membership rolls include hundreds of organizations, but the active participants in the working groups that actually produce specifications are dominated by the browser vendors. The WHATWG is, structurally, a browser-vendor consortium. ECMA’s TC39 is, in practice, browser-vendor-dominated.

The dominance is not, in many cases, malign. The browser vendors have legitimate technical expertise; they have the implementation experience that other parties lack; they have to live with the consequences of the standards in ways that less-implementing participants do not. There is a real argument that the people writing the standards should be the people writing the code, and that the browser vendors are accordingly the appropriate body. The argument has force.

The argument also has costs. Standards produced by a small group of large companies tend to reflect the interests of those companies, even when the participants are trying to act in the broader web’s interest. Features that benefit browser vendors get implemented; features that benefit smaller players or alternative use cases sometimes do not. Privacy features that limit advertising tracking have been contested, sometimes for years, with the various commercial interests of the participants visible in the contests. Web payments, identity, authentication — each of these standards has been shaped by the commercial interests of the participants, and the shape sometimes shows.

The standards-body story is not a story of villains. It is a story of how technical decisions get made in a world where the institutions that make them have to be funded and the funding mostly comes from the parties whose technical interests are being decided. The same pattern plays out in many other technical-standards contexts; the web is not unique. But the pattern has consequences for what the web becomes, and those consequences are part of the broader story of how the web has evolved away from its original design.

What has been lost in the institutional history

A summary of what the standards-body story has cost, relative to what the web’s original design assumed:

The IETF’s volunteer-driven, broadly-participatory model has been displaced, for the web’s central standards, by a vendor-driven model. The shift may have been necessary (the IETF model probably could not have kept up with the browser pace) but it has narrowed the range of voices in the standards conversation.

The W3C’s broad membership has not, in practice, produced broad participation in the key decisions. Corporate members dominate; civil-society members participate at the margins; users are not represented except indirectly through the various advocacy organizations that try to speak for them.

The pace of standardization has lagged the pace of implementation. Features get shipped first and standardized after, which means the standards function more as documentation of decisions than as deliberative shaping of them. The window in which the broader web community could have influenced a feature’s design is, by the time the standard is being written, mostly closed.

The semantic web project, treated in passing in the academic-hypermedia chapter, was the most ambitious attempt to shape the web’s evolution through the standards process, and it has had limited results. RDF, OWL, SPARQL, and the Linked Data infrastructure exist and are used in specific domains, but the broader web has not adopted them. The reasons are many — the technologies are hard to use, the use cases were never as compelling as their proponents hoped, the browser vendors did not invest in supporting them — but the result is that the standards-driven attempt to give the web a richer semantic infrastructure has not produced the world it imagined.

What the institutional story has nevertheless preserved

The standards-body story has not been a story of pure decline. The institutions have continued to do real work and the work has had real effects.

HTTP has been substantially improved through the IETF process. HTTP/2 (RFC 7540 in 2015), which descended from Google’s SPDY protocol, brought multiplexing, header compression, and server push to HTTP, improving performance significantly. HTTP/3 (RFC 9114 in 2022), built on QUIC, has continued the improvements with better behavior over unreliable networks. The IETF’s standardization of these protocols has been competent, broadly participatory by the IETF’s standards, and successful in producing implementations that interoperate.

HTML5 has been a substantial success as a specification. The work began as a WHATWG revolt against the W3C’s XHTML 2.0 direction and ended as the foundational specification for the modern web. The specification is enormous and detailed; it documents the actual behavior of browsers across many edge cases that previous specifications had ignored; it has given web developers a clearer foundation to build on than they had before. The HTML5 work has been one of the most consequential pieces of standards work in the history of the web.

ECMAScript has, through TC39, evolved into a much more capable language than it was in 1996, while preserving compatibility. The 2015 edition (ES6) was a major upgrade; subsequent editions have added features steadily; the language is, in 2026, broadly considered fit for the wide range of uses it is put to. The standards process has worked.

CSS has been a quiet success of the W3C process. The various CSS modules — CSS3, CSS4 (as the next generation of features has come to be informally called), Grid, Flexbox, Container Queries, custom properties — have been produced through a careful, slow-moving working group process that has, in retrospect, served the web well. CSS’s reputation has improved over the decade since the modular approach matured; layout in modern browsers is much more capable than it was in 2010, and the standards process is largely responsible.

The accessibility standards, the internationalization standards, the various adjacent specifications that the W3C has continued to produce — these are real work, done by serious people, with real effects on the usability of the web for users who depend on them.

What this story leaves out

The chapter has focused on the institutions and the politics. It has left out, mostly, the people who do the work. The web’s standards are written by individual engineers and editors who spend their careers in the working groups, mailing lists, and conference calls of the standards bodies. Many of them are long-tenured experts whose names appear on dozens of specifications. They are, almost without exception, doing the work in good faith, trying to produce specifications that serve the web well. The institutional politics constrain what they can do; the politics do not make them villains.

The next chapter takes the language that became, for reasons no one in particular planned, the most-deployed runtime environment on the planet. JavaScript was an afterthought in the design of Netscape Navigator, was standardized in haste through ECMA, was reviled by most serious programmers through the 2000s, and is now the substrate of essentially every consumer application that runs in a browser. Its accidental dominance is one of the more peculiar stories in the history of computing, and its consequences for what the web has become are very large.

The browser as operating system — JavaScript’s accidental dominance

JavaScript is the most-deployed programming language in the world. It runs in every web browser; in 2026 it runs on most of the world’s servers through Node.js; it runs inside desktop applications built with Electron and its descendants; it runs inside mobile applications built with React Native; it runs inside embedded systems through various lightweight runtimes. The estimated number of devices on which a JavaScript engine runs is in the billions. The language that achieves this deployment was designed in ten days in May 1995 by Brendan Eich at Netscape, with the constraint that it had to look like Java for marketing reasons, with no formal review of its design, with no expectation that it would become important, and with several specific design choices that its author has since publicly regretted. The accidental nature of JavaScript’s design and the consequential nature of its deployment are not in proportion, and the disproportion has shaped what the web is. This chapter is about that disproportion: how JavaScript arrived, how it became unavoidable, what its dominance has done to the web, and what the consequences have been for the document that the web was originally designed around.

Eich’s ten days

Brendan Eich joined Netscape in April 1995, hired to build a scripting language for the browser. The product context was that Netscape Navigator 2.0 was scheduled to ship in late 1995 with several new features, one of which was to be a programming language for embedding logic in web pages. The marketing context was that Java had just been released by Sun Microsystems in May 1995 and was the most-hyped programming language of the moment. Netscape had a partnership with Sun that included an agreement to bundle the Java runtime in Navigator, but Netscape’s leadership also wanted a scripting language that was easier to use than Java and that did not require the Java runtime for simple scripting tasks. Eich was given approximately two weeks to produce a working prototype, with the constraint that the language should look like Java so that the partnership marketing would make sense.

Eich’s ten days produced what he called Mocha. The language was a small, dynamically-typed, prototype-based scripting language with a syntax that looked superficially like Java’s: curly braces, semicolons, function keyword, var declarations. Underneath the Java-flavored syntax was a different language entirely. Mocha had first-class functions (a feature from Scheme, one of Eich’s preferred languages). It had prototype-based object inheritance (a feature from Self, the Smalltalk variant). It had loose typing and automatic type coercion that produced behavior different from Java’s stricter typing. It had a small set of built-in objects and a string-and-number-centric standard library. It had no module system, no error-handling beyond simple try/catch (which was added later), no proper class system (also added later), and no namespacing of any kind. The whole thing was, in language-design terms, an unholy mashup of incompatible traditions, produced under time pressure with no review and shipped because it had to be.

The language was renamed LiveScript before Navigator 2.0 shipped, and then renamed JavaScript in December 1995 for the announcement of the Netscape-Sun partnership. The naming has caused decades of confusion: JavaScript and Java share a syntactic family but are otherwise unrelated languages, with different semantics, different runtimes, different standard libraries, and different design philosophies. The naming was, by Eich’s own subsequent admission, a marketing decision that the language has had to live with.

The first version of JavaScript shipped in Netscape Navigator 2.0 in March 1996. It could handle form validation, simple animations, dynamic HTML manipulation, and other narrow scripting tasks. Microsoft, watching, reverse-engineered the language and shipped a compatible implementation called JScript in Internet Explorer 3.0 in August 1996. The two implementations differed in some details, and the browser-incompatibility nightmares of the late 1990s included substantial JavaScript-specific issues. The submission to ECMA for standardization happened in November 1996; ECMAScript 1 was published in June 1997. The language had been stabilized externally before its design was reviewed by anyone other than its original author.

The DHTML era and the AJAX inflection

For the first several years of JavaScript’s existence, it was used primarily for what was then called Dynamic HTML or DHTML: small scripts that manipulated the page’s HTML to produce effects that were not possible with static markup alone. Dropdown menus, mouse-over image swaps, form validation, simple animations, the rollover effects that were the early signature of dynamic web pages. DHTML was widely deployed but not, in any deep sense, important. The web was still primarily a document medium with some interactive decoration; JavaScript was the decoration.

The shift came in the early 2000s, slowly at first and then suddenly. Microsoft had added the XMLHttpRequest object to Internet Explorer 5.0 in 1999, originally as a feature for Outlook Web Access. Mozilla, Apple, and Opera implemented compatible versions in their browsers over the next few years. XMLHttpRequest let JavaScript make HTTP requests to the server without reloading the page; the page could update its content in response to user actions by fetching new data from the server in the background. This is a small-sounding capability with large consequences.

The capability was used, beginning around 2003 and 2004, to build web applications that behaved more like desktop applications than like documents. Google Maps, released in February 2005, was the most prominent early example: a map you could drag and zoom continuously, with the map tiles being fetched as needed from the server through XMLHttpRequest, with no page reloads. Gmail, released in April 2004, was another: an email client with a desktop-like interface that lived inside a single web page. Both of these felt, to users of the era, like a different kind of thing than the web they had known.

Jesse James Garrett, a designer at Adaptive Path, coined the term AJAX (Asynchronous JavaScript and XML) in February 2005 to describe the pattern. The term spread quickly. AJAX was the moment the web stopped being a hypermedia document system and started being an application platform. The shift was structural. Pre-AJAX web pages were documents that you navigated; the unit of interaction was the page, and the page was a thing you fetched, looked at, and possibly submitted a form from. Post-AJAX web pages were applications that you used; the unit of interaction was the user action, and the page was a long-lived stateful environment in which actions happened.

The change in the web’s character was not announced. There was no W3C Recommendation that said “the web is now an application platform.” The browser vendors had not, in any coherent way, decided to make this change. It happened because developers found XMLHttpRequest useful, because users responded to applications built with it, because Google’s exemplars proved that the pattern worked, and because the commercial logic of the web rewarded application-like experiences. The shift from document to application was bottom-up, organic, and irreversible.

V8 and the performance era

JavaScript was, through the early and mid-2000s, slow. The implementations were interpreters with limited optimization; performance varied across browsers by an order of magnitude; complex JavaScript applications strained the browsers of the era. The slowness was a real constraint on what could be built. Google Maps and Gmail were impressive precisely because they had been engineered to work around the JavaScript performance limitations, with substantial effort spent on optimizing the application code to fit within what the engines could handle.

Google released the Chrome browser in September 2008. Chrome’s principal innovation was its JavaScript engine, V8, designed by Lars Bak and a team in Aarhus, Denmark. V8 was a just-in-time compiler that produced native machine code from JavaScript source, with optimization techniques borrowed from decades of compiler research in other languages. V8 was, on launch, approximately ten times faster than the JavaScript engines in the other browsers, and the gap forced the other vendors to catch up. Mozilla’s TraceMonkey, Apple’s Nitro (later JavaScriptCore), Microsoft’s Chakra (in Internet Explorer 9) — each was a response to V8, each was a substantial engineering investment in JavaScript performance, and each had cumulative effects on what was possible to build in the browser.

By 2010 or so, JavaScript performance was no longer the primary constraint on what could be built. Applications that would have been impossible in 2005 ran smoothly in 2012. The result was that the application web, which AJAX had made possible at the lower-end, became practical for serious applications. The mature single-page application era — where almost the entire user-facing logic of a web application runs in JavaScript in the browser, with the server providing data through JSON APIs rather than HTML pages — became feasible. The shift had begun with AJAX in 2004; it became dominant practice in the 2010s.

V8 had a second consequence that was, in some ways, larger than its first. Ryan Dahl, an engineer who had been watching the V8 work, realized that the V8 engine could be extracted from the browser and used as a standalone JavaScript runtime. He built Node.js, released in May 2009, which embedded V8 as a server-side JavaScript runtime with a non-blocking I/O model. Node.js was an immediate success in a niche that nobody had quite expected: server-side JavaScript turned out to be a useful tool, both because JavaScript was a language that web developers already knew and because the event-driven I/O model fit naturally with the kinds of network applications web developers were building.

The combination of fast browser engines and Node.js produced, by the mid-2010s, a world in which JavaScript was the lingua franca of both client and server, in which the same language and many of the same libraries could be used on both sides of the network, and in which the package ecosystem (npm, the Node Package Manager) had grown into the largest software library in the world. The npm registry contained, by 2020, more than a million packages, with billions of downloads per week. The scale of the JavaScript ecosystem is genuinely unprecedented; nothing in software history had grown this big this fast.

Frameworks

The application web’s growth produced demand for frameworks: structured ways to organize the code of a JavaScript application that handled common concerns like state management, DOM updates, routing, and component composition. The framework story has been one of rapid succession.

jQuery, by John Resig, was released in August 2006. It was not a framework in the modern sense; it was a library that smoothed over browser incompatibilities and made common DOM manipulation tasks easier. jQuery was, however, the dominant library of the late 2000s and early 2010s, and most JavaScript applications of the period used it. Its eventual decline came as the browsers themselves became more consistent and as more ambitious frameworks emerged.

Backbone.js (Jeremy Ashkenas, 2010) and Knockout.js (Steve Sanderson, 2010) were among the early frameworks that introduced explicit structure for client-side applications, with models, views, and the binding between them. Angular (Misko Hevery and Adam Abrons at Google, 2010, with substantial rewrites in subsequent versions) introduced a more opinionated framework with two-way data binding and dependency injection. Ember (Yehuda Katz, 2011) provided convention-over-configuration in the Rails tradition.

The framework that has had the largest sustained impact is React, released by Facebook in May 2013. React’s principal contribution was a programming model based on declarative component descriptions and a virtual DOM that handled the messy details of updating the actual DOM efficiently. React’s success drove a wave of imitators and complements: Vue.js (Evan You, 2014), Svelte (Rich Harris, 2016), Solid.js, Preact, and many others have built on React’s component model. The component model is now the dominant way of organizing web applications, with most modern web applications structured as trees of components written in JSX or similar syntaxes.

The framework churn has been, depending on perspective, either a healthy ecosystem evolution or a chronic source of pain for working developers. The term “JavaScript fatigue” emerged around 2016 to describe the experience of trying to keep up with the ecosystem’s evolution: new frameworks, new tools, new conventions, new package managers, new build systems, each requiring relearning and rebuilding. The fatigue is real. It is also, in some sense, the price of an ecosystem that has been growing rapidly for two decades, with each generation of practitioners trying to improve on the previous one’s mistakes. The ecosystem’s energy has been one of the web’s structural advantages over slower-moving alternatives; the energy’s downside is the churn.

The document-application inversion

The cumulative effect of JavaScript’s growth is that the web has, slowly, inverted its relationship between document and application. The early web was a document medium with applications as occasional special cases (a search form, a guestbook, a simple shopping cart). The middle web was a document medium with increasingly sophisticated application features layered on top. The contemporary web is, for many of its users most of the time, an application medium with documents as occasional special cases (a Wikipedia article, a static blog post, a documentation page).

The inversion has had structural consequences for the kinds of properties the web exhibits.

A document is addressable. It has a URL. The URL points to the document. Anyone can link to the document. The link will, modulo link rot, retrieve the document. An application’s URL, by contrast, points to the application’s entry point. The user’s experience within the application — what they are looking at, what state the application is in, what they have done — is typically not in the URL. Single-page applications have, to varying degrees, attempted to recover URL-based addressability through history API manipulation and route-based architectures. The recoveries are partial. A URL into the middle of a complex web application is much less reliable, as a citation or a shared link, than a URL into a document.

A document is preservable. You can save it. The Internet Archive can save it. Someone can read it twenty years later by retrieving the saved copy. An application is not easily preservable. The application is the live system: the server, the database, the JavaScript runtime, the network connections to various services. Saving the JavaScript file does not save the application, because the application is more than the file. The Internet Archive saves what it can of web applications, but the saves are dramatically less complete and less useful than the saves of documents.

A document is composable. You can quote from it, link to specific parts of it, embed it in other documents, transform it. An application is much less composable. The application’s content is, often, not visible to anything outside the application’s own runtime. Search engines can crawl it imperfectly, with the help of various server-side rendering techniques. Other applications can call its APIs, with permission. But the easy quote-and-link composition that documents support is not available for applications.

A document is readable in its source. View-source on a document shows you the document. View-source on a modern web application shows you a minified JavaScript bundle and a nearly-empty HTML shell. The learnability that view-source provided in the document era is mostly gone in the application era.

These are real losses. They are not losses anyone has decided to inflict on the web; they are emergent consequences of the inversion from document to application. The recovery efforts treated in Part V are, in part, attempts to recover the document properties — addressability, preservability, composability, source visibility — for parts of the web where they still matter.

The npm ecosystem and its pathologies

The npm registry deserves its own brief treatment, because it has become a significant piece of the JavaScript story and exhibits both the strengths and the pathologies of the ecosystem.

The strengths are real. A working JavaScript developer can, with a few commands, pull in libraries for almost any task they have ever needed to do, from low-level utilities to high-level frameworks. The ecosystem covers an enormous range of needs. The barrier to publishing a package is low; anyone with an account can publish anything. The barrier to using a package is also low; anyone with npm install can pull it in.

The pathologies are also real. The low barriers mean that the registry contains many packages of low quality, many overlapping packages, many abandoned packages, and a substantial population of packages that are essentially trivial. The famous “left-pad” incident in March 2016 — when a single-developer’s removal of a 17-line utility package broke a large fraction of the JavaScript ecosystem because so many other packages depended on it — illustrated how the dense dependency graph of npm could fail catastrophically from very small disturbances. The dependency graphs of modern JavaScript projects are enormous: a typical web application can have thousands of transitive dependencies. The supply-chain security implications are serious; the various attacks on the ecosystem through compromised packages have been a recurring problem.

The npm ecosystem is, in some ways, the most direct artifact of JavaScript’s accidental dominance. A language and ecosystem this large, this dense, and this consequential would, under most circumstances, be governed and curated more carefully than npm is. The npm registry’s open-publishing model is the natural extension of the ethos that produced JavaScript itself: ship it, let the market sort it out, accept the chaos as the price of the growth. The model has been broadly successful and has paid its own price.

WebAssembly

WebAssembly, standardized in 2017 as a W3C Recommendation, is the most recent major addition to the browser’s runtime environment. WebAssembly (often shortened to Wasm) provides a portable bytecode format that browsers can execute at near-native speed. The bytecode can be produced from many source languages — C, C++, Rust, Go, and others have working WebAssembly toolchains — and lets web applications run code that does not need to be JavaScript.

The motivation for WebAssembly was practical. Some applications had performance requirements that JavaScript, even with V8’s optimizations, could not meet. Photoshop on the web, video editing applications, scientific computing applications, games — these benefited from being able to compile from C++ or Rust to a portable bytecode that ran in the browser at near-native speed. WebAssembly has, in the eight years since its standardization, found a real niche. It is not the dominant runtime — JavaScript still is — but it is a meaningful supplement, used in significant applications and growing in adoption.

The WebAssembly story is interesting for what it does and does not change. It does not change the basic architecture of the application web: applications still run in the browser, talk to servers through HTTP, and live inside the broader web’s substrate. It does open the browser to languages other than JavaScript, which has incremental benefits for what kinds of applications are practical and which developers can build for the web. The longer-term consequences are still unfolding; whether WebAssembly becomes a more central piece of the web’s runtime or remains a specialized supplement is, in 2026, still being decided.

The browser as operating system

The cumulative effect of JavaScript, the frameworks, the npm ecosystem, WebAssembly, and the various web APIs is that the browser has become, in functional terms, an operating system. A modern web application is, structurally, similar to a desktop application: it has UI components, persistent state, background processing, network connections, access to device hardware (camera, microphone, location), and a complete runtime environment. The browser provides the abstraction layer between the application and the underlying hardware, in much the way that Windows or macOS does for desktop applications. The web platform’s specification — the full set of APIs that browsers must implement — is, in 2026, comparable in size and complexity to the API surface of a major desktop operating system.

This is not an accident. It is the cumulative consequence of decades of feature addition, each defensible in isolation, that has produced a runtime environment of operating-system scale inside a runtime environment that was designed in 1995 as a way to add interactivity to documents. The browser is the operating system most users actually use for most of their consumer software, and the operating system underneath the browser — Windows, macOS, ChromeOS, iOS, Android — has become, for most consumer purposes, a relatively thin wrapper around the browser.

The shift from “operating system runs applications, one of which is a browser” to “operating system runs a browser, which runs applications” is one of the most important structural changes in computing in the last quarter-century. It has consolidated enormous power in the hands of the browser vendors, who collectively define what is possible in the browser through the W3C/WHATWG process. It has produced economies of cross-platform development that have benefited many developers and many users. It has also, for the argument of this book, completed the document-to-application transformation that the IMG tag started in 1993. The web is no longer, in any meaningful sense, a document system. It is a runtime for distributed applications, on top of which some applications happen to render documents.

What JavaScript’s dominance has cost

A summary of the costs JavaScript’s accidental dominance has produced:

Performance complexity. Web applications now run substantial JavaScript on every page load. The cost of executing the JavaScript falls on the user’s device, with corresponding effects on battery life, mobile data usage, and the experience of users on lower-end hardware. The performance regressions that JavaScript has produced are paid most heavily by users least able to afford them.

Document fragility. Pages that depend on JavaScript to render their content are inaccessible to users without JavaScript, to search-engine crawlers that do not execute JavaScript well, to accessibility tools that work better with static HTML, and to archival systems that cannot easily preserve dynamic content. The fragility is a real loss for the web’s broader social functions.

The application monoculture. The dominance of a single language for the entire web platform has produced an ecosystem of imitation: most web applications look like each other, behave like each other, and have similar failure modes. The diversity of approaches that existed in pre-web hypermedia systems has been narrowed dramatically.

The advertising and tracking infrastructure. JavaScript provides the mechanism by which web pages embed third-party scripts that track users, deliver advertising, and collect behavioral data. The web’s privacy story is, in significant part, a story about what JavaScript has made possible that would not have been possible with static HTML.

Source opacity. As discussed above, the readability of source that view-source provided has eroded. The teaching tradition that view-source supported has weakened correspondingly.

What it has given us

JavaScript’s dominance has also given the web capabilities it would not otherwise have. Interactive applications that work on every platform without separate development. Real-time collaboration tools that descend, ultimately, from Engelbart’s vision. Browser-based video conferencing that was, twenty years ago, impossible. Maps, photo editing, document editing, scientific computing, games — all running in the browser, all written in JavaScript or compiled to WebAssembly, all available to anyone with a browser. The application web’s reach is enormous, and most of the world’s software, by user count, now runs in browsers.

The trade-off is the one this book has been describing throughout. The document properties have been eroded; the application properties have grown. The recovery work in Part V is, in part, work to bring the document properties back without losing the application properties. Whether this can be done is the question Part V tries to answer.

The next chapter takes the institutional consequence of all this: the platform decade in which a small number of companies absorbed most of what the rest of us thought we were building. Google, Facebook, Amazon, and a handful of others became, through the 2010s, the operators of the systems on which the rest of the web depended. The platform story is the political-economic counterpart to the technical story of the application web, and the two together produced the web of the present, which is what Part V is trying to find ways to recover from.

The platform decade — Google, Facebook, and consolidation

The web that the previous chapters have been describing — a federated, peer-to-peer, document-oriented infrastructure built on uncoordinated URLs and stateless protocols — was the web of approximately 1991 to 2005. The web that the world uses in 2026 is structurally different, not because the protocols changed but because a small number of companies grew, through the 2000s and 2010s, into operators of the systems on which the rest of the web depends. Google indexed the web and then became the gateway to it. Facebook built a social graph and then became the principal venue of online social life. Amazon built a commerce platform and then built the cloud infrastructure that most other web companies run on. A handful of other platforms — Twitter, YouTube (acquired by Google), Instagram and WhatsApp (acquired by Facebook), TikTok, the various app stores — absorbed adjacent functions. By 2020, most of the consumer internet’s traffic, time, and revenue passed through one of these platforms at some point in its journey. The web’s federated peer architecture had been overlaid, without being replaced, by a hierarchical platform structure that effectively determined what the federated peers could do. This chapter is about how that hierarchical structure emerged and what its emergence has done to the substrate underneath it.

Google

The platform decade arguably begins with Google. Larry Page and Sergey Brin, then Stanford graduate students, published the paper “The Anatomy of a Large-Scale Hypertextual Web Search Engine” in 1998, describing the PageRank algorithm that used the web’s link structure to rank search results. The company was founded in September 1998 in a Menlo Park garage; the IPO came in August 2004 at a valuation of $23 billion. By 2010 Google was the dominant search engine globally, with market share in many countries above 90%. By 2020 the company (renamed Alphabet, with Google as its largest subsidiary) had revenue of more than $180 billion per year, almost all of it from advertising tied to search and to the various other Google properties.

Google’s relationship to the rest of the web has been, structurally, the relationship of a gatekeeper. A web site that does not appear in Google’s index is, for most users, invisible. A web site that appears low in Google’s results is, for most users, also invisible. The criteria by which Google ranks results are not public; the broad strokes are known, but the specific decisions are commercial secrets, and the criteria evolve continuously through algorithm updates that have material effects on which sites are visible. The web exists, in a sense, twice: once as the federated network of independent sites that the original protocols imagined, and once as the much smaller filtered version of itself that Google surfaces to users. The two are not the same, and the gap between them has grown over the decades as Google has elaborated its filtering criteria.

The economic structure of Google’s filtering produces patterns that affect what the web becomes. The advertising-supported business model means that Google’s filtering is, ultimately, optimized for what produces advertising revenue. Search engine optimization — the practice of writing web pages to rank well in Google’s results — has been a substantial industry since the early 2000s, with hundreds of millions of dollars in annual spending, and the result has been a homogenization of what successful web content looks like. The pages that rank well are the pages that follow current SEO best practices, which tend to mean specific lengths, specific keyword densities, specific structures, specific kinds of metadata. The diversity of voices and styles the early web had been notable for has narrowed, partly because the rewarded patterns are specific and the unrewarded patterns disappear from view.

Google’s other properties have extended the gatekeeping into adjacent domains. Gmail (launched April 2004) hosts a substantial fraction of consumer mailboxes globally. Google Maps (2005) dominates online mapping. YouTube (acquired in October 2006 for $1.65 billion) dominates online video. Google Drive, Docs, Sheets, and the rest of the Workspace suite are used by hundreds of millions of users and enterprises. Android (acquired in 2005, released as a mobile operating system in 2008) runs on the majority of the world’s smartphones. The Chrome browser (released in September 2008) has roughly two-thirds of the global browser market share. Each of these is, individually, a substantial business. Together they constitute a stack in which Google is the platform for many of the core consumer internet activities. The platform position is reinforced by the data flows between them: a user who uses Google for search, Gmail for mail, Chrome for browsing, Android for their phone, and YouTube for video has all of their behavior visible to one company, which uses the aggregated data to improve its advertising targeting, which produces the revenue that funds the platform.

Facebook

Facebook was founded in February 2004 by Mark Zuckerberg, then a Harvard sophomore. The site spread from Harvard to other elite universities and then, in September 2006, to the general public. By 2008 it had passed MySpace as the leading social network in the United States; by 2012 it had a billion users; by 2020 it had nearly three billion across its family of services (including Instagram and WhatsApp, acquired in 2012 and 2014 respectively). The company rebranded as Meta in 2021, partly to signal the company’s intentions beyond Facebook itself.

Facebook’s relationship to the broader web has been, structurally, the relationship of a partial replacement. The site provided, increasingly, the things that people had previously gotten from various places on the open web: personal updates (which had been blogs), photos (which had been Flickr or various photo-sharing sites), longer-form content (which had been people’s own websites and other publishers), event invitations, group communications, and, eventually, news consumption. Many users’ web activity, by the mid-2010s, was substantially conducted inside Facebook. The hours-per-day average that users spent on Facebook grew through the 2010s to substantial fractions of the total time spent online; for many users, Facebook was the consumer internet.

The structural consequences of this replacement were severe for the open web. Personal blogs, which had been a thriving category in the mid-2000s, contracted sharply as users moved their personal updates to Facebook. Independent photo sites contracted as users moved their photos to Facebook and Instagram. Event-listing sites, group-coordination sites, various small-community sites — many of them lost users to the corresponding Facebook features, and many of them shut down or shrank to specialty niches. The Facebook universe was, by the mid-2010s, an effective substitute for substantial parts of the open web for substantial fractions of the user base.

Facebook also extended its reach into the web it was not replacing. The Open Graph Protocol, introduced by Facebook in 2010, was a markup convention that web pages could embed to tell Facebook how to display links to them when those links were shared. Open Graph metadata included titles, descriptions, images, and various other properties; pages that included it appeared nicely formatted in Facebook’s feed, while pages that did not appeared as bare links. The protocol was adopted widely by web publishers because the alternative — appearing badly in Facebook’s feed — was a real penalty. The effect was that web publishers, including those with no other relationship to Facebook, ended up structuring their pages in ways that served Facebook’s display needs. The platform reached back into the substrate.

The other extension was the social plugin: the Like button, the Share button, and the various other widgets that Facebook offered for embedding on third-party sites. The plugins were adopted widely; web pages across many publishers embedded them. The plugins also reported back to Facebook every visit to every page that embedded them, providing Facebook with a substantial portion of the web’s traffic data even for users who were not logged in. The tracking implications were significant and have been the subject of subsequent privacy regulations (the GDPR in particular). The plugins illustrated a broader pattern: even web pages that were not on Facebook were, through Facebook’s plugins and other infrastructure, partly within Facebook’s data-gathering apparatus.

Amazon and the cloud

Amazon’s platform play was different in kind. Amazon Web Services, launched in 2006 with S3 (Simple Storage Service) and EC2 (Elastic Compute Cloud), grew through the late 2000s and 2010s into the dominant cloud infrastructure provider. AWS now runs a substantial fraction of the world’s web applications. Estimates vary, but the typical figure for AWS’s share of the cloud-infrastructure market in 2026 is around 30-35%, with Microsoft Azure at around 20-25% and Google Cloud at 10-12%, and the remainder split among smaller providers. The three largest providers together account for roughly two-thirds of public cloud spending.

The cloud platform position is different from the consumer platform positions of Google and Facebook because the customers are other businesses rather than end users. But the effects on the web’s structure are comparable. A web application built on AWS depends on AWS for its infrastructure; if AWS has an outage, the application has an outage; if AWS changes its pricing, the application’s economics change; if AWS makes decisions about which workloads are acceptable, the application has to comply. The cloud providers’ decisions, in aggregate, shape what kinds of web applications can be economically built and operated. The substrate underneath the web is now, for most large web applications, a service from one of a small number of platform providers.

The cloud consolidation has had specific effects on the federation properties of the web. A web application running on AWS is, in a meaningful sense, running inside AWS. The egress costs of moving data out of AWS to other providers are non-trivial; the integration with AWS-specific services creates lock-in; the operational practices that work on AWS may not transfer. Building a web application that is genuinely portable across cloud providers requires deliberate effort and ongoing discipline. Most applications, having made the initial choice of a cloud provider, stay with that provider regardless of subsequent considerations. The federation that the internet’s transport layer provides is undermined, at the operational layer, by the consolidation of cloud infrastructure into a small oligopoly.

Mobile and the app store

The second great consolidation of the platform decade was the mobile app store. Apple’s App Store launched in July 2008, alongside the iPhone 3G; Google Play (originally Android Market) launched in October 2008. The app stores became, within a few years, the primary way that consumers acquired software for their mobile devices, and the mobile devices became, by the mid-2010s, the primary way that consumers used the internet for many purposes.

The app store model was, structurally, a sharp departure from the web’s permissionless distribution. To distribute software through the App Store, a developer had to register with Apple, pay an annual fee, submit each application for review, comply with the App Store guidelines, and accept Apple’s terms of service. Apple controlled what software could be distributed; Apple took a 30% cut of all paid sales and in-app purchases (reduced to 15% for smaller developers in some categories); Apple could remove an application from the store at any time for any reason. The Google Play store had comparable structure with slightly different specifics.

The app store consolidation produced a specific kind of loss for the web. Many of the things that would have been built as web applications in the 2000s — communication tools, productivity tools, games, content-delivery services — were instead built as mobile apps. The mobile apps were, structurally, not web pages. They were software distributed through the app stores, with the app stores’ rules applying. The properties the web had — open distribution, view-source, easy linking, archival accessibility, search-engine visibility — did not apply to mobile apps. A user who installed a popular mobile app was, structurally, using a piece of software they did not control, distributed through a platform they did not control, on a device whose update policies they did not control.

The mobile shift was significant for the platform decade’s consolidation because it gave the platform operators a second layer of control over what consumers did online. The web was, after the consolidation, just one venue for consumer internet activity; the apps, controlled by the same platform operators or others within the same general structure, were another. The total platform footprint — web sites and apps and the various intermediating services — was much larger than the web alone, and the consolidation was correspondingly deeper.

Algorithmic feeds and the engagement model

A specific feature of the platform decade was the algorithmic feed. Facebook introduced its algorithmic News Feed in 2009, replacing the previous chronological display of friends’ updates with a ranked display determined by Facebook’s relevance algorithms. Twitter introduced an algorithmic timeline in 2016, similarly replacing the chronological display. Instagram followed. TikTok, founded in 2016 and dominant by the early 2020s, was algorithmic from the start. By the early 2020s, almost every major social-media platform had moved from chronological to algorithmic display, with the algorithms tuned to maximize various measures of user engagement.

The engagement model — the practice of optimizing platform behavior to maximize the time users spend on the platform — became, through the 2010s, the dominant business model of the consumer internet. The argument for engagement was that engaged users see more advertising and produce more revenue. The argument was correct as far as it went, and engagement-driven product decisions produced enormous revenue for the platforms. The argument’s costs were less visible at the time and have become more visible since.

Engagement-optimized algorithms tend to surface content that produces strong emotional reactions. Outrage is engaging; polarization is engaging; conflict is engaging. The platforms became, through the late 2010s, increasingly populated by content optimized for these reactions, because the algorithms surfaced and rewarded such content, and creators of content responded to the incentives. The political consequences have been substantial, with academic and journalistic literature on the effects of algorithmic feeds on political discourse, civic engagement, and individual psychological well-being. The cumulative effect of a generation of consumer internet experience under engagement optimization has been one of the most consequential social experiments in recent history, and the results are still being absorbed.

The relevance to the broader argument of this book is structural. The federated peer-to-peer model of the early internet had no algorithmic feeds. Usenet was chronological. Email is chronological. The early web’s discussion venues were chronological. The shift to algorithmic ranking is a shift to platform-controlled curation, and the curation reflects the platform’s interests rather than the user’s stated preferences. The user of an algorithmically ranked feed is, in a meaningful sense, not in control of what they see; the platform is. This is a substantial change in the relationship between a user and the content they consume, and it is a change that the early internet’s architecture had not anticipated.

The death of the open web discourse

A periodic discourse through the 2010s, in technology press and among certain web technologists, asserted that the open web was dying. The discourse had several specific markers. Google’s discontinuation of Google Reader in July 2013 was an early flashpoint: Reader had been a popular RSS reader, and its closure was widely read as Google’s signal that RSS-based federated content distribution was not a priority. The subsequent decline of RSS as a mainstream technology, with most major publishers prioritizing social-media distribution over RSS, was treated as evidence of the broader decline.

The platform-control issues — Facebook’s algorithmic feed, the app stores’ gatekeeping, the consolidation of cloud infrastructure, the dominance of search by a single company — accumulated into a sense, by the late 2010s, that the open web’s structural properties were being eroded faster than they could be defended. Various commentators (Anil Dash, Hossein Derakhshan in his 2015 essay “The Web We Have to Save,” and many others) wrote essays arguing that the web of independent publishers, of personal sites, of federated communities, was disappearing. The essays were not, in every detail, correct — the open web did not die in any literal sense — but they captured something real about the trajectory.

The trajectory’s response, beginning in the late 2010s and accelerating in the 2020s, has been the recovery work that Part V treats. The IndieWeb movement (treated in chapter twenty-two), the local-first software movement (treated in chapter twenty-one), the personal knowledge tools wave (treated in chapter twenty-four), the static renaissance (treated in chapter twenty-three) — each of these is, in part, a response to the platform consolidation, an attempt to recover at the application layer what has been lost at the platform layer. None of them is large enough, individually, to reverse the consolidation. Collectively they are a meaningful counter-current, and the trajectory they describe is one of the few hopeful elements in the platform-decade story.

Antitrust, regulation, and the limits of what is being done about this

The platforms have, through the late 2010s and 2020s, attracted substantial regulatory attention. The European Union’s General Data Protection Regulation (GDPR), in force since 2018, imposed substantial obligations on data handling by large platforms. The Digital Services Act and Digital Markets Act, both passed in 2022, imposed further obligations. The United States has pursued antitrust cases against Google (US v Google, 2020, with a major ruling in 2024 finding Google to be an illegal monopolist in search), against Facebook (FTC v Meta, ongoing), against Apple (Epic Games v Apple, with mixed outcomes, and the EU’s various app-store mandates), and against Amazon (FTC v Amazon, filed 2023, ongoing). Various other jurisdictions have similar cases ongoing.

The regulatory response has had real but limited effects. The platforms have made changes — GDPR consent flows, app-store changes in the EU, various transparency reports, various advertising-data restrictions — but the underlying consolidation has not, so far, been reversed. The economic position of the largest platforms in 2026 remains roughly what it was in 2020, with some shifts at the margins. Whether the regulatory pressure will eventually produce structural change or merely produce procedural changes that leave the underlying structure intact is, in 2026, an open question. The recovery efforts in Part V should be read as efforts that proceed in parallel with the regulatory response, not in lieu of it.

What the platform decade has done to the substrate

The most important question for this book’s argument is what the platform decade has done to the substrate underneath it. The internet’s protocols are unchanged. HTTP, TCP/IP, DNS, SMTP — these still work as Postel and his colleagues designed them. The protocols are federated; the protocols are peer-to-peer at the architectural level; the protocols do not require any of the platforms. The substrate is intact.

What has changed is what runs on the substrate. The applications most users use, the services most businesses depend on, the infrastructure most of the web runs on — these are increasingly the property of a small number of companies. The substrate’s federation is still there at the protocol level and increasingly invisible at the application level. A user who knows only the consumer internet has no obvious reason to know that the substrate is federated; everything they experience appears to be the platforms.

The recovery work in Part V is, in part, work to make the substrate’s federation visible again. Local-first software wants to give users data that does not live on platforms. ActivityPub wants to give users social network experiences that span servers. The static renaissance wants to give users documents that do not depend on platform infrastructure. Each of these is, at root, a way of bringing the federated substrate back into the user’s experience.

There is also, less optimistically, a question about whether the substrate itself will remain intact. The internet’s infrastructure depends on the cooperative behavior of network operators, on the continued operation of standards bodies that are not captured, on the continued availability of independent name servers and registries, and on a working ecology of independent operators below the platform layer. The trends through the platform decade have, in various small ways, put pressure on this ecology. The cloud consolidation puts pressure on independent server hosting. The app store consolidation puts pressure on independent software distribution. The advertising consolidation puts pressure on independent publishing. The search consolidation puts pressure on independent finding. The cumulative pressure, while not yet existential, is real, and the work of maintaining the federated substrate has become harder than it was twenty years ago.

The conclusion to Part IV

The four chapters of Part IV have traced the web’s victory. The technical decisions of the early 1990s, the commercial inflection of 1995, the standards-body politics that followed, the accidental dominance of JavaScript, and the platform consolidation of the 2010s and 2020s — these are the substance of how the web went from being one of several proposed networked-computing platforms to being the substrate of contemporary computing. The web’s victory has been real and has been beneficial in many ways: it has made information available to far more people than the pre-web alternatives could have reached, it has produced enormous economic value, it has enabled forms of expression and community that would not otherwise have existed, and it has been, on the whole, one of the more successful experiments in public infrastructure in the history of the species.

The victory has also come with costs, which are the subject of Part V. The document was lost to the application; the personal authorship was lost to the platform; the federated peer model was lost to the consolidation; the structural properties that the pre-web alternatives had offered were lost to the simplicity of the web’s protocol. Some of these losses are being recovered. Some are not. The five chapters of Part V take the recoveries — Bret Victor and the dynamic document tradition, local-first software, ActivityPub and the IndieWeb, the static renaissance, the personal knowledge tools — and try to be honest about what is being recovered, what is partial, and what is not happening. The book ends with an assessment of what is permanent in the losses and what is not.

The first chapter of Part V takes the recovery that has had the smallest user base and the largest intellectual influence. The dynamic document tradition — running from Bret Victor’s explorables through Observable, Jupyter, and the recent renaissance in computational notebooks — has been less a mass-market phenomenon than a set of demonstrations of what a document could be if it were also a computation. The demonstrations have not yet reached a wide audience. The intellectual ambition behind them is substantial, and the influence on the recovery of the document on the web has been disproportionate to their direct user base.

The dynamic document tradition — Victor, Observable, Jupyter, Glamorous Toolkit

The web’s collapse of the document-application distinction has, in recent decades, produced a counter-tradition that takes the collapse seriously and tries to redeem it. The argument of the counter-tradition is that a document and a computation should not be different categories of thing. A document should be able to compute. A computation should be able to read as a document. The reader should be able to change parameters and see the document respond; the author should be able to compose code, prose, and visualization into a unified artifact that is neither a static page nor a packaged application but something in between, something specifically designed to support the reader’s exploration of an idea. The counter-tradition has been articulated most prominently by Bret Victor, and elaborated by the various computational-notebook systems that descend from the Wolfram Mathematica notebooks of the late 1980s, by D3.js and Observable, by Jupyter, and most recently by Tudor Gîrba and the Glamorous Toolkit team. The user base of these systems is, taken together, small. The intellectual influence is large. This chapter is about what the dynamic document tradition has been proposing, what it has built, what has been adopted, and what remains absent.

The proposition

The proposition of the dynamic document tradition is older than the web. It is older than the personal computer. The clearest early statement of it is Donald Knuth’s 1984 paper “Literate Programming,” in which Knuth proposed that programs and their documentation should not be separate artifacts but a single document, written in a system that produced both an executable program and a human-readable description as transformations of the same source. Knuth implemented his proposal in a system called WEB (no relation to the later web), used it to produce TeX, the typesetting system that has been the standard for mathematical and scientific publication ever since, and continued to use it for his other major projects through the next four decades. Literate programming did not, despite Knuth’s stature, become a widespread practice in software development. The reasons are several — the tooling was awkward, the cognitive load of writing both program and prose was high, the audience for serious mathematical documentation was small — but the proposition Knuth had made remained, after his demonstration, available as an articulated alternative to the prevailing practice. Knuth’s proposition was that the document and the computation should be the same thing, with each providing what the other needed.

A parallel tradition came out of Smalltalk at Xerox PARC in the 1970s and from Engelbart’s NLS earlier. The Smalltalk workspace was an interactive environment in which code, data, and prose lived in a single textual surface, with any expression executable in place and any result returned into the surface for further use. The workspace was a kind of dynamic document: a single textual artifact that the user constructed, modified, and computed with continuously. Smalltalk’s environment did not separate the editor from the interpreter or the document from the program. They were the same thing, and the consequence was that Smalltalk users developed a working style — alternating between writing prose, writing code, examining intermediate values, and refining each — that was structurally different from the file-based programming of Unix and from the strict-document-strict-program model of mainstream practice.

Wolfram Mathematica’s notebook interface, released in 1988 with Mathematica 1.0, was the first widely deployed system that took the dynamic-document idea to a mass-market product. A Mathematica notebook was a structured document containing text cells, code cells, output cells, and graphics cells, with the code cells being evaluable in place and the outputs being live results. The notebook could be saved, shared, reopened, and re-executed. The combination of prose and computation made Mathematica notebooks usable for technical communication in a way that previous mathematical software had not been. Stephen Wolfram has, in his more recent writing, called the notebook format the “computational essay” and argued that it should be a standard form of technical writing across many disciplines. The position is somewhat self-interested — Wolfram sells the system that produces these essays — but it is not wrong, and Mathematica’s notebooks have been used for substantial technical and educational work since the late 1980s.

Bret Victor

The figure who has most articulated the dynamic document tradition in its modern form is Bret Victor. Victor’s career has consisted of a series of essays, talks, demonstrations, and design proposals about what computing should look like if it took seriously the proposition that the medium should support the thinking. His most-cited talk is “Inventing on Principle,” delivered at the CUSEC conference in January 2012, in which Victor demonstrated working interactive programming environments in which a programmer could see, immediately and continuously, the consequences of changes to their code. The demonstrations were beautiful and unsettling: they made the standard practice — write code, save file, compile, run, observe output, iterate — look obviously primitive by comparison.

Victor’s essays have included “Magic Ink” (2006), which argued for static-information-display as a design discipline against interactive applications; “Up and Down the Ladder of Abstraction” (2011), which demonstrated explorable documents in which the reader could move between levels of abstraction continuously; “Learnable Programming” (September 2012), which critiqued the standard programming-education materials and proposed a different design philosophy; “Media for Thinking the Unthinkable” (April 2013), which proposed that the appropriate response to complex problems was the construction of media that made them thinkable; and several others. The essays are themselves dynamic documents in many cases, with interactive widgets that let the reader manipulate the examples while reading. They model, on the page, what their author is arguing for.

Victor’s “Tangle” library, released in 2011, was a small JavaScript framework for embedding interactive numbers and other reactive elements in web pages. A document written with Tangle could contain prose with parameters that the reader could drag to change, with the consequences of the changes propagating through the document — equations recomputing, charts updating, prose adjusting to reflect the new values. The library was small, well-designed, and demonstrated the technique convincingly. It has been used in essays by Victor and by others; a number of explainer pieces — Nicky Case’s various interactive essays, the explorables collected at explorabl.es, the Distill.pub journal articles on machine learning — descend technically and aesthetically from Tangle’s example.

Victor founded the Dynamicland research lab in Oakland, California, in 2014, with the longer-term goal of building physical interactive environments that took the dynamic-document idea off the screen and into the room. Dynamicland’s work has been less widely distributed than Victor’s essays — it requires being in the physical space — but it is part of the same intellectual program. The lab has continued operating into the present, though its work has been less visible to the broader programming community than Victor’s earlier essays.

The cumulative effect of Victor’s work has been substantial, despite the fact that none of his specific systems has become mainstream. He has been the most articulate voice in the past decade for the proposition that computing media should support thinking rather than merely host applications. The essays have been widely read and cited; the demonstrations have been widely watched and discussed; a generation of designers and engineers have been influenced by them. The influence has been disproportionate to the user base of his specific projects.

The notebook lineage

The other major thread in the dynamic-document recovery has been the computational-notebook lineage, which descends from Mathematica through several decades of evolution.

IPython, the interactive Python shell, was released in 2001 by Fernando Pérez, then a graduate student at the University of Colorado. IPython improved on the standard Python interpreter with better history, better introspection, and various tab-completion and pretty-printing features. The IPython Notebook was added in 2011, providing a browser-based interface with code cells and output cells in the Mathematica style. The IPython Notebook spread quickly in the scientific Python community, which had been growing through the 2000s and which needed a tool for interactive computation that matched what Mathematica and R provided in their domains.

In 2014, the IPython project rebranded as Project Jupyter to reflect its support for multiple language backends. Jupyter (the name a contraction of Julia, Python, and R, the three languages most prominently supported) is a notebook system that can run cells in any of dozens of programming languages, with the cells being evaluable in place and the outputs being displayed inline. Jupyter notebooks are JSON files that can be saved, shared, and re-executed. The format has become, over the past decade, a standard for scientific and analytical computing, with substantial use in data science, machine learning research, scientific publishing, and education.

Jupyter notebooks are, in functional terms, a Wolfram Mathematica notebook implemented in the open-source ecosystem and runnable in a browser. They have inherited Mathematica’s strengths and many of its weaknesses. The strengths are that they let authors mix code, prose, mathematics, and visualizations in a single document; that the document is executable, so that readers can re-run the computation; and that the format has been adopted widely enough that there is significant tooling for processing notebook files in various ways. The weaknesses are that the JSON format is hard to diff and version-control, that the execution order of cells is implicit and can produce non-reproducible state, that the notebook interface encourages a particular working style that has been criticized for various reasons, and that the notebooks tend to drift from their published state as authors continue to work on them after sharing.

Despite the weaknesses, Jupyter has been a major success. The Project Jupyter ecosystem includes JupyterLab (a more capable IDE-like interface), JupyterHub (multi-user notebook servers for classes and teams), Voilà (turning notebooks into standalone web applications), and many other tools. The notebook format is widely accepted by journals (with Distill.pub being a notable example) and is used by major research groups across the sciences. Jupyter is, in 2026, one of the few computational tools whose adoption has expanded steadily for over a decade with no sign of decline.

Observable, created by Mike Bostock (the original author of D3.js, the data-visualization library) and a small team starting around 2016, is a different take on the notebook idea. Observable notebooks are reactive: a cell’s value automatically updates when the cells it depends on change. This is structurally different from Jupyter, where cells execute in sequence and the state depends on what has been run when. Observable’s reactive model makes it easier to build interactive documents in which the reader’s manipulations propagate through the notebook coherently. The platform is web-based, with notebooks shared at observablehq.com, and has accumulated a substantial corpus of computational documents in fields including data visualization, journalism, education, and recreational mathematics.

Observable has been particularly visible in data journalism, where it has been used to produce interactive graphics and explanatory pieces by major news organizations. The combination of the dataflow model, the visualization-friendly D3 ecosystem, and the publishing platform has made Observable a natural fit for the kind of explanatory work that the New York Times graphics department, the FiveThirtyEight team, and various others have been producing through the late 2010s and 2020s. The user base remains smaller than Jupyter’s but the per-user influence is significant.

Glamorous Toolkit

The most recent and most ambitious project in the dynamic-document tradition is Glamorous Toolkit, developed by Tudor Gîrba and the team at the Swiss software company feenk since around 2020. Glamorous Toolkit is built on top of the Pharo Smalltalk environment and inherits Smalltalk’s commitment to integrated programming environments in which everything is live and modifiable. The project’s principal innovation is what Gîrba calls “moldable development”: the practice of building, for every kind of object or problem you work with, a custom visualization or inspector that makes the object’s structure legible. The argument is that programming is, fundamentally, a reading activity — reading code, reading data, reading state — and that the tools should support the specific reading each piece of work requires rather than treating all reading as the same.

Glamorous Toolkit’s user interface is a series of panes, each containing a view of some object — a method, a class, a data structure, a database query, a graph of dependencies. The views are not generic; they are constructed specifically for the kind of object being shown, with the developer being able to add new views as needed. The result is an environment in which a complex piece of software can be inspected at many levels and from many angles, with the inspections being themselves modifiable code that the developer maintains as part of the project.

The system also supports what Gîrba calls “knowledge ingestion”: the construction of integrated documents that combine code, prose, visualization, and analysis into a unified artifact that can be navigated, modified, and shared. A Glamorous Toolkit notebook is, in functional terms, a Jupyter notebook with first-class support for arbitrary visualizations of arbitrary objects, executed inside an integrated programming environment where the language is Smalltalk and the runtime is the whole environment.

Glamorous Toolkit’s user base is small — Smalltalk has remained a niche language despite periodic predictions of its revival — but the system is the most thorough recent implementation of the dynamic-document idea, and the team has been productive in producing both the system and the writing that explains it. Gîrba’s various talks and essays on moldable development have been influential in the small community of developers who care about programming-environment design. Whether Glamorous Toolkit will reach a broader audience is uncertain. The intellectual contribution is solid regardless.

The audience

A useful question to ask of the dynamic-document tradition is: who uses these tools, for what?

The honest answer is: relatively few people, in specialized domains. Jupyter notebooks are used by data scientists, scientific researchers, and educators in technical fields, and the user base in these domains is in the millions. Observable notebooks are used by data journalists, visualization designers, and a community of recreational mathematicians and explainer writers, with a smaller user base in the tens of thousands. Glamorous Toolkit is used by a small community of Smalltalk developers and people interested in moldable development, with a user base in the low thousands. Mathematica is used by researchers, engineers, and educators in mathematics-heavy fields, with a user base in the hundreds of thousands. The total user base of the dynamic-document tradition, summed across systems, is probably in the low millions — substantial in absolute terms but small as a fraction of the consumer internet’s billions of users.

The reason the user base is small is that the dynamic document is, structurally, a tool for thinkers and explainers, not a tool for consumers. The audience for a Jupyter notebook is a person who wants to do analysis or to follow analysis someone else has done. The audience for an Observable notebook is a person who wants to interact with a visualization or to read a piece of computational journalism. The audience for a Mathematica notebook is a person who wants to do mathematics or to follow a mathematical exposition. These are real audiences with real needs, but they are not, in aggregate, the consumer-internet audience. The dynamic document tradition is, in its current form, a tradition of tools for technical work.

This is not, in the broader argument of this book, a failure. HyperCard had a mass audience because it shipped on every Mac. The hypermedia systems before HyperCard did not have a mass audience because they ran on workstations. The dynamic document tradition is more like the workstation-class hypermedia systems: it produces tools that, for their users, are genuinely powerful, but the floor for use is high and the user base is correspondingly narrow. The question for the recovery is whether the floor can be lowered to bring the mass audience along. The Bret Victor essays and the Observable platform are, in different ways, attempts to do this, and the results have been mixed: the audience for explorable essays has grown, but the audience for the production of explorable essays is still small.

What has been recovered

A summary of what the dynamic-document tradition has recovered from the pre-web alternatives:

The document as a computation. Bush’s Memex had associative trails; Engelbart’s NLS had executable structures; HyperCard had scripts on cards. The dynamic-document tradition has restored, for technical audiences, the proposition that a document is something a reader can interact with, with the interaction being computation, not just navigation.

The integration of prose and code. Knuth’s literate programming proposed it; the workshop tradition had practiced it; the dynamic document tradition has reinstated it as a working possibility for technical work. Jupyter notebooks, Observable notebooks, Glamorous Toolkit pages — all of them treat prose and code as first-class citizens of the same document.

The reader’s manipulation of the document. Victor’s Tangle library, Observable’s reactive cells, and the various explorable-explanation tools have made it possible for a reader to manipulate a document’s parameters and see the consequences propagate. This is, in a small way, a recovery of the bidirectional reading-and-writing continuum that HyperCard had implemented.

The document as a teaching tool. The explorable essays at explorabl.es, the Distill.pub interactive papers, the Observable visualizations, the Jupyter teaching notebooks — these have become, for the audiences that use them, the preferred form of technical communication. The form is more powerful than the static print equivalents, and it is being adopted, in specific domains, as a serious mode of publication.

What has not been recovered

The dynamic-document tradition has not recovered, and probably cannot recover by itself, several things:

The mass audience. As discussed, the systems are tools for technical work, not consumer products. The mass audience that HyperCard had does not exist for the current dynamic-document tools, and the floor for production is too high to bring that audience along.

The local artifact. Most dynamic-document systems are tied to specific platforms (Observable to observablehq.com, Glamorous Toolkit to Pharo, Mathematica to Wolfram). The documents do not generally exist as self-contained files that the user owns and can preserve indefinitely. Jupyter is the partial exception — the .ipynb file is a portable artifact — but Jupyter notebooks depend on their kernel environments to execute, and the environments drift over time, with the practical consequence that a notebook from five years ago may not run today without effort. The HyperCard property of having an artifact that lives on your disk and runs forever is not, in the current tools, present in robust form.

The end-user authorship culture. The audience for using these systems is broader than the audience for producing them. The tools are still oriented toward people who are comfortable writing code, manipulating data, and thinking computationally. The audience that HyperCard had — the teachers and doctors and hobbyists who made things they would not have called software — has not been recovered by the dynamic-document tools. The Observable community has more non-programmer participants than the Jupyter community has, and the Tangle examples can be read by anyone, but the production of new dynamic documents remains a specialist activity.

The longer trajectory

The dynamic-document tradition is, in the trajectory of this book, the recovery that is most clearly intellectual and least clearly mass-cultural. The work being done is serious; the influence is real; the user base is growing slowly; the practical effects on what serious technical writing looks like have been substantial. The work is not, however, on a trajectory to displace the application web or to reach the audience that the document web of the early 1990s had. It is on a trajectory to remain a small but high-quality tradition of work, used by the technical audiences that need it and admired (or unknown) by everyone else.

This is a fair outcome and one that the tradition’s practitioners are mostly comfortable with. Bret Victor has been clear, in various essays and interviews, that the work he does is intended to influence longer-term thinking about what computing should be, not to ship products that compete in the current market. The Jupyter team, Observable team, and Glamorous Toolkit team are similarly oriented: they are building serious tools for serious work, with no aspiration to be the next consumer platform. The recovery they offer is, accordingly, partial. They are recovering, for specific audiences, properties that the document web once had broadly, with the recovery confined to the audiences that take advantage of it.

The next chapter takes a different recovery: local-first software, which is trying to recover, at the architectural layer, the property that the user’s data lives on the user’s machine. Local-first is more ambitious than dynamic documents in terms of who it wants to reach (everyone) and less ambitious in terms of what it wants to do (just make the data ownership work). The two recoveries are complementary; together they would address two of the larger losses the platform decade has produced.

Local-first and the data ownership recovery

The platform decade did, among other things, transfer a generation’s data from the user’s machines to the platforms’ servers. The transfer was not announced; it happened as a side effect of the cloud-application model that became dominant through the 2010s. Email moved to Gmail; documents moved to Google Drive; notes moved to Evernote and then to its successors; photos moved to iCloud and Google Photos and Facebook; messages moved to WhatsApp and Messenger and Slack; the various spreadsheets and project plans and personal records that used to live on hard drives moved to one or another web application’s back-end database. The transfer was, in many ways, beneficial: synchronization across devices, collaboration with others, off-site backup, access from anywhere with a browser. The transfer also produced a specific kind of dependency: the user’s data, in functional terms, belongs to the platform, and the user’s ability to use that data is contingent on the platform’s continued existence, continued operation, and continued willingness to permit the use. This dependency is what local-first software is trying to undo. This chapter is about the local-first movement: what it claims, what technologies it depends on, what has been built, and what is plausible as a path forward.

The 2019 manifesto

The local-first software movement crystallized around an essay published in April 2019 by Martin Kleppmann, Adam Wiggins, Peter van Hardenberg, and Mark McGranaghan, under the auspices of Ink & Switch, a small research group the latter three had been running in Brooklyn and San Francisco. The essay was titled “Local-first software: You own your data, in spite of the cloud.” It crystallized, in a relatively short document, a position that had been articulating itself in pieces across several research traditions for the previous decade.

The essay proposed seven ideals for local-first software. The first was speed: applications should respond immediately to user actions, without the network round-trip that cloud applications require. The second was the absence of single-device lock-in: the user’s data should work on whatever device the user has, not be trapped on the one they happened to create it on. The third was that the network should be optional: applications should work offline, with the network providing convenience features rather than being a required dependency. The fourth was seamless collaboration: when network connectivity is available, users should be able to collaborate with others without that collaboration being mediated by a central server in a way that takes their work hostage. The fifth was “the long now”: users should still have access to their data in twenty years, regardless of what has happened to the company that built the tool. The sixth was security and privacy by default: the user’s data should be private from the operator of any cloud service, not just from third-party attackers. The seventh was ultimate ownership and control: the user, not the operator, should hold final authority over their data.

The seven ideals were not novel as individual propositions. Each had been articulated, in various forms, by previous critics of the cloud-application model. What the essay did was assemble them into a coherent program and attach the program to a name. “Local-first software” became, after the essay, a term of art that designers and engineers could refer to when discussing the architectural alternatives to platform-dependent cloud applications. The movement that the essay named has, in the six years since, produced research, tooling, and a small but growing number of production applications.

CRDTs

The technical substrate that makes local-first applications possible is a body of research on what are called Conflict-free Replicated Data Types, or CRDTs. The research traces back to work in distributed systems and operational transformation through the 1990s and 2000s. Operational transformation, an algorithm developed for collaborative text editing (Ellis and Gibbs’s 1989 paper is an early reference), was the technology behind Google Wave (2009) and is the substrate for Google Docs’s collaborative editing. Operational transformation works but is notoriously hard to get right; the algorithms are subtle, and the implementations require centralized coordination to maintain correctness.

CRDTs were proposed as an alternative. The foundational paper, “Conflict-free Replicated Data Types” by Marc Shapiro, Nuno Preguiça, Carlos Baquero, and Marek Zawirski, was published in 2011. The core idea was that data structures could be designed so that their operations were commutative — operations could be applied in any order, by any replica, with the final state being the same regardless of order. A CRDT-based system can have multiple replicas modifying the data independently, exchanging operations whenever they happen to be in contact, and converging to a consistent state without requiring any central coordinator. The mathematical properties that make this possible are constraining — not every data structure admits a CRDT implementation, and the implementations that do exist often have overhead in terms of metadata size — but enough common structures (counters, sets, lists, maps, text documents) have working CRDT implementations that significant applications can be built on them.

The local-first proposition depends on CRDTs because the local-first model assumes that any replica of the data can be modified independently and that the replicas must be able to converge when they meet. This is exactly the problem CRDTs are designed to solve. Without CRDTs (or equivalent algorithms), local-first software has to choose between merge conflicts that the user must resolve manually (which is a poor user experience) and centralized coordination that defeats the local-first proposition. With CRDTs, the merge happens automatically, in the background, with deterministic outcomes that don’t require a central authority.

The library ecosystem

The CRDT research has produced a small but capable library ecosystem. The two most prominent libraries in 2026 are Automerge and Yjs.

Automerge, principally developed by Martin Kleppmann (one of the authors of the 2019 essay) with substantial contributions from others, is a JSON-like CRDT library that lets applications model their data as a structured document and synchronize it across peers. The library is available in TypeScript and Rust, with bindings to several other languages. The data model is rich enough to support text editing, list manipulation, map/object manipulation, and various structured data operations, with the underlying CRDT machinery handling the synchronization. Automerge is in active development, with regular performance improvements and new features, and is used by a number of production applications.

Yjs, developed by Kevin Jahns and a team, is a similar CRDT library with a different design emphasis. Yjs has been particularly focused on collaborative text editing, with editor-integration packages for ProseMirror, CodeMirror, Quill, and other rich-text editor frameworks. Yjs has a substantial production user base, including in commercial collaborative-editing applications, and is generally considered the more performant of the two libraries for the text-editing use case. Both libraries are open source under permissive licenses, and the choice between them is mostly a question of which library’s API fits the application’s data model better.

The libraries handle the merge problem; they do not handle the transport problem. Local-first applications also need some way to exchange operations between replicas. The transport can be peer-to-peer (direct connections between user devices), can use a relay server (which forwards operations but does not need to understand them), or can use a more conventional client-server architecture with the server being a relay rather than the canonical state-holder. The local-first model permits any of these, with the constraint that no component in the system should be a single point of trust that has access to the data unencrypted.

Ink & Switch

The research lab that produced the 2019 manifesto and several of the prominent open-source libraries deserves brief description. Ink & Switch was founded in 2015 by Peter van Hardenberg, Adam Wiggins, and James Lindenbaum, all of whom had been at Heroku before. The lab is privately funded — primarily through the founders’ personal resources, with various grants and contracts at the margins — and operates as a small (typically 10-15 person) research team. The lab’s work is mostly published as research reports, prototypes, and open-source code. The team has produced, over the past decade, a substantial body of work on local-first software, on the user-interface design of collaborative tools, on the integration of CRDTs into application architectures, and on related topics.

Ink & Switch’s prototypes have included Pushpin (a collaborative pinboard application that demonstrated local-first patterns), Capstone (a more elaborate canvas-based notebook), and a series of related explorations. None of these has been a commercial product; they are research artifacts, intended to demonstrate possibilities and to surface design problems for further work. The lab’s published reports — “Local-first software,” “Project Cambria” (on schema evolution for CRDT-based applications), “Project Aphelion” (on collaboration with strangers), and others — are the public-facing artifacts that have most influenced the broader local-first community.

The lab’s existence and approach are themselves part of the recovery story. The pre-web era had research labs that took long-running architectural questions seriously and produced demonstrations rather than products: Xerox PARC, Bell Labs, SRI, MIT’s Media Lab. The intervening decades have seen many of these labs decline or be repurposed toward shorter-term commercial work. Ink & Switch is part of a small recent revival of the research-lab model — alongside groups like Hack Club’s HQ, Future of Coding’s various initiatives, and a few others — in which technical research is done in public, on time horizons longer than a product cycle, with the output being published rather than commercialized. The pattern is fragile and depends on patient funding, but it is producing genuinely substantial work.

Production applications

The local-first movement has begun to produce production applications that real users use. The list is shorter than the discourse around the movement might suggest, but it is real.

Obsidian, the personal knowledge tool treated in chapter twenty-four, is local-first by design. Notes are stored as Markdown files on the user’s machine. Synchronization across devices is provided by either the user’s own cloud storage (Dropbox, iCloud, Syncthing) or Obsidian’s own paid sync service, with the local files being the canonical store either way. The user’s data is, in a strong sense, the user’s: it lives on their machines as files they own, in a format they can read with any text editor, and continues to exist if Obsidian the company goes away.

Linear, the project-tracking tool launched in 2019, has built its application around an aggressively local-first architecture in which the client maintains a full local copy of the relevant data and the server is a synchronization mechanism. The result is an application that feels responsive in a way that conventional cloud applications do not, with most operations completing instantly because they execute on local data. Linear is not strictly local-first in the manifesto’s full sense — the server holds the canonical state for most purposes, the user does not have full ownership of the data in the way that Obsidian provides — but the architecture is closer to local-first than to conventional cloud and demonstrates that the pattern can produce commercially successful applications.

Apple Notes has been moving in a local-first direction over recent years, with iCloud serving as a synchronization layer for notes that are stored locally on each device. The architecture is not exactly the local-first manifesto’s, but the user-facing properties — fast local responses, working offline, persistence even if Apple’s servers are unavailable — are close enough to the manifesto’s ideals that the application qualifies for inclusion in the local-first conversation.

Several smaller applications — Tarvos (collaborative note-taking), Muse (visual thinking tool), various prototypes from the Ink & Switch alumni — have explored the design space. The overall production population is still small in absolute terms; most consumer applications remain server-canonical, with the local-first patterns being adopted in pockets.

The hard problems

The local-first proposition is not free. The pattern requires solving several problems that conventional cloud applications can avoid.

Schema evolution. A CRDT-based application stores data on user devices, and the data persists across application updates. When the application’s schema changes — when new features require new data structures, or when existing structures need to be reorganized — the old data has to be migrated. Conventional cloud applications can do this with a server-side migration script that runs once. Local-first applications need each replica to be able to migrate its own data, with the migration being compatible across all the replicas the user (and any collaborators) have. The problem is hard and has been the subject of substantial Ink & Switch research (the Cambria project) without yet producing a clean general solution.

Authentication and access control. Local-first systems often want to share data among a controlled group — colleagues, friends, family — without that group having to involve a central authentication server. The cryptographic protocols for doing this are not exotic but they are also not trivial; the application has to handle key management, key rotation, group membership, and the various edge cases of trust establishment in a way that is invisible to non-technical users. Most production local-first applications have, so far, accepted some compromise here, with the application’s vendor providing some authentication infrastructure even though the data itself lives on user devices.

Storage cost. CRDT-based data structures often have substantial metadata overhead. A document that would be a few kilobytes in a conventional format may be a few hundred kilobytes in a CRDT format, because the CRDT needs to maintain the operation history to support merging. The overhead grows with the document’s lifetime. Various compaction and pruning strategies have been developed, but none is free, and applications working with large documents have to budget for the metadata cost.

Search. Conventional cloud applications can do full-text search across all users’ data with centralized indexes. Local-first applications need each replica to maintain its own index, which is more expensive in storage and computation. The indexes also need to be updated as operations arrive from peers, which is more complex than indexing a stable corpus. Several CRDT-friendly indexing approaches have been developed, but the user experience of search in local-first applications is still, in many cases, less polished than in cloud applications.

The user-facing presentation of CRDTs. Some CRDT operations have semantics that are surprising to users. Two users concurrently editing the same paragraph may, after the merge, see a result that neither of them produced — a merge of their two edits that is logically consistent but is not what either intended. Operational transformation has the same issue but typically with more sophisticated heuristics for which version to prefer. The user-experience design of local-first applications has to handle these merge surprises gracefully, and the design is hard.

What is at stake

The argument for local-first software is, at the deepest level, an argument about the relationship between users and software. The cloud-application model that has dominated the last two decades has a specific implicit assumption: that the user is the application’s customer, that the application’s vendor is the responsible party, and that the vendor’s continued existence and continued willingness to provide service are conditions of the user’s relationship with their data. This assumption is, in many cases, fine. Many cloud applications are well-run, will continue to exist for decades, and will provide their users with reliable access to their data for as long as they need it. The assumption is also, in many cases, false. Companies fail, are acquired, are discontinued, change their pricing, change their policies, lose their data, or simply decide that a particular feature or product line is no longer worth maintaining. When this happens, users of the affected applications find that their relationship to their own data has changed in ways they did not anticipate.

The local-first proposition is that this should not be a normal occurrence. The user’s data should belong to the user in a robust sense — should be stored on the user’s machines, should be in a format the user can read, should continue to be accessible if the application’s vendor goes away. The cloud convenience features (synchronization, collaboration, off-site backup) should be supplements to the local storage, not replacements for it. The user’s relationship to their data should be the same as the user’s relationship to their books or their photographs in a physical archive: theirs, persistently, in a form they can access without permission.

This proposition has parallels to the proposition that motivated the email chapter (chapter thirteen), and to the proposition that motivated the federated services chapters more broadly. Email is the surviving federated peer system; local-first is the proposal to recover, at the application layer, what email recovered at the protocol layer. If local-first succeeds at any scale, the architecture of consumer software changes: users have local data, the cloud provides services on top of the data rather than holding it, and the relationship between user and software returns to something closer to the desktop-application model than to the cloud-application model.

What is being recovered and what is not

The local-first recovery, where it succeeds, recovers several things:

The user’s data ownership. If the data lives on the user’s machine in a readable format, the user owns it in the strong sense. This is the central proposition.

Offline operation. Applications that maintain local data can work without the network, with the network being used only for synchronization. This is a usability win independent of the ownership argument.

Speed. Local-first applications can be substantially faster than cloud applications, because most operations don’t require a network round trip. Linear’s success is largely attributable to this property.

Long-term durability. If the data is in a portable format on the user’s machine, the user can continue to use it indefinitely, with or without the application’s vendor. Obsidian’s Markdown files are the clearest current example.

What the recovery has not yet achieved:

Mass-market adoption. The local-first applications described above have user bases in the millions but not the billions. The mainstream consumer internet remains overwhelmingly cloud-canonical.

A general-purpose local-first platform. There is no single application platform on which local-first applications run, the way there is for cloud applications. Each local-first application has to solve, mostly from scratch, the problems of synchronization, schema evolution, identity, and the rest. The platforms — Apple’s iCloud, Google’s Drive, Dropbox — are cloud platforms, and the local-first proposition is, in a sense, against the platform model.

End-to-end encryption that is invisible to users. The local-first manifesto includes privacy as one of its ideals, but most production local-first applications have not yet achieved the kind of seamless end-to-end encryption that the ideal calls for. The cryptographic protocols are available; the user-experience design that hides them behind a simple interface is still being developed.

The federation between local-first applications. Each local-first application is, currently, an island. Data in Obsidian is not, generally, accessible to data in Linear. The local-first movement has, at this point, mostly recovered the property of local ownership; it has not yet recovered the property of inter-application portability that the desktop-application era had partially provided.

What it would take

The conditions for local-first software to become the default architecture of consumer software are several. The libraries have to become more capable, with better performance, better schema-evolution support, and better integration with the existing application-development ecosystem. The platforms have to support it, with operating-system-level facilities for local storage, synchronization, and identity that applications can build on rather than reinventing. The user-experience patterns have to be developed so that users understand what local-first means and what they get for using it. The economic model has to be worked out — local-first applications cannot, in general, monetize through advertising on user data, because the data is on the user’s device — and the alternative models (subscription, one-time purchase, freemium with sync as the paid feature) have to be sustainable.

These conditions are not, individually, exotic. They are also not yet in place at the scale that would make local-first the default. The current state, in 2026, is that local-first is a serious architectural alternative that produces credible applications in specific domains. The trajectory is upward; the conditions for broader adoption are gradually being met; the question is the rate at which the trajectory continues.

The next chapter takes a different recovery, oriented around a different problem. ActivityPub and the IndieWeb are working on the federation problem rather than the data-ownership problem: their proposition is that the social-network functions of the platform decade can be reassembled, on federated infrastructure, with users on independent servers exchanging content through standard protocols. The recoveries are complementary; together they would address most of what the platform decade has consolidated, although neither is yet at the scale where they constitute a comprehensive answer.

ActivityPub, the IndieWeb, and the federation recovery

The platform decade absorbed federated social communication into a small number of centralized social networks. The recovery of federation, treated in this chapter, is the most visible of the recoveries in Part V because it has, in the last few years, begun to acquire user numbers in the millions rather than thousands and has, in some specific moments, played a role in the broader public’s understanding of what the alternative to the platforms could look like. The two principal strands of the federation recovery are ActivityPub, the W3C Recommendation that has produced the fediverse, and the IndieWeb, a smaller movement that has been working since around 2010 on personal-site-based alternatives to the platforms. A third strand, less visible than the first two but growing, includes the alternative protocols (AT Protocol behind Bluesky; Nostr; various others) that propose different technical foundations for federated social communication. This chapter takes the three strands in turn, describes what has been recovered, names what is still hard, and tries to be honest about the state of the recovery in 2026.

ActivityPub

ActivityPub became a W3C Recommendation on January 23, 2018. The principal authors were Christopher Lemmer Webber, Jessica Tallon, Erin Shepherd, Amy Guy, and Evan Prodromou. The standard descended from a lineage of social-network protocols that had been in development for over a decade. Evan Prodromou had been working on federated social networks since around 2008, when he founded the company Status.Net (later renamed Identica) and built a federated microblogging service called identi.ca on a protocol he called OStatus. OStatus combined several existing protocols (Atom for content syndication, PubSubHubbub for real-time notification, Salmon for cross-server replies, and others) into a working federation specification. Identica peaked at perhaps 50,000 users and operated as a federation peer for several years before Prodromou shut it down. The OStatus stack was, in its time, the most-elaborated working specification for federated social networking, and it provided a substantial part of the technical and conceptual foundation that ActivityPub built on.

ActivityPub itself rests on ActivityStreams 2.0, a W3C standard for representing social-network activities — posts, replies, follows, likes, shares — as structured JSON objects. ActivityPub specifies, on top of ActivityStreams, how servers should exchange these activities: each user has an inbox (where activities directed at them arrive) and an outbox (where activities they generate are placed for delivery), and the protocol describes how servers should push activities between users’ boxes and how clients should interact with the boxes. The design is decentralized: any server implementing the protocol can interoperate with any other, and users on one server can follow, reply to, and interact with users on any other server they can reach.

The technical design has well-understood limitations. ActivityPub does not include search across the federation, which means that finding people and content is harder than on centralized platforms. ActivityPub does not include strong identity guarantees, which means that account portability between servers is, in practice, fragile (you can move an account, but the move is not seamless and not all servers support it equally). ActivityPub does not include payment, dispute resolution, or any of the various non-technical scaffolding that platforms provide. The protocol is, by design, a thin specification of how messages flow between servers, with the rest of the social-network experience built on top by individual servers and clients.

Mastodon and the fediverse

The application that has made ActivityPub visible to a broad audience is Mastodon, created by Eugen Rochko, a German software developer, beginning in 2016. The first release was in March 2016, with a small initial user base that grew steadily through the late 2010s. Mastodon is, in functional terms, a microblogging service modeled on Twitter: short posts, profile pages, replies, boosts (the Mastodon equivalent of retweets), favorites, and direct messaging. The architectural difference is that Mastodon is federated: any organization or individual can run their own Mastodon server (called an “instance”), with their own users, their own moderation policies, their own community, and their own continued existence under their own control. Users on different Mastodon instances can follow, reply to, and interact with each other through ActivityPub, with the experience approximating what a centralized social network would provide.

Mastodon’s growth has been uneven. The user base was, through 2017-2021, in the low hundreds of thousands, with periodic small surges in response to controversies at the centralized platforms. The major inflection came in October 2022, when Elon Musk acquired Twitter and began making changes that produced widespread dissatisfaction among Twitter’s user base. Several million Twitter users registered Mastodon accounts in the weeks and months that followed. The Mastodon network, which had been operating at a few hundred thousand monthly active users, grew to several million monthly active users in late 2022 and into 2023. The growth has been uneven since then: many of the post-Twitter arrivals did not stick with Mastodon, but the user base has stabilized at a substantially higher level than before the surge, with estimates in 2026 of monthly active fediverse users in the range of one to three million.

The fediverse — the broader network of ActivityPub-implementing services — extends beyond Mastodon. Pleroma, a Mastodon-compatible service with a lighter implementation, has a substantial user base. PixelFed provides an Instagram-like photo-sharing service over ActivityPub. PeerTube provides a YouTube-like video service. WriteFreely provides blog hosting. Lemmy provides a Reddit-like community-based discussion service. Misskey, a Japanese ActivityPub implementation with a distinctive feature set, has a substantial Asian user base. Each of these services interoperates, through ActivityPub, with the others; a Mastodon user can follow a PixelFed account, a Lemmy community can be subscribed to from Mastodon, and the federation graph is, in principle, unified.

The structural achievement of the fediverse is real. It is, in 2026, the largest federated social network that has existed since Usenet. The number of operating instances is in the tens of thousands. The number of monthly active users across all services is in the millions. The protocol is open, the implementations are open-source, the moderation policies are determined by each instance’s operators, and the federation is genuinely federated in the way that Usenet was: no single party controls it. The recovery is not complete — the user base is small compared to the centralized platforms, the user experience is in many respects rougher, and many features that platform users expect are missing — but the recovery is real.

What the fediverse gets right

The fediverse, as a social-network experience, has several properties that the centralized platforms have lost or never had.

The user’s relationship to moderation is direct. Each instance is moderated by its operators, with whatever policies the operators have set. Users who don’t like an instance’s moderation can move to another instance. Users on an instance whose moderation they trust can have a meaningful relationship with the moderation team in a way that is impossible on a centralized platform with hundreds of millions of users. The result is, for many fediverse users, a more humane and more accountable moderation experience than the platforms have been able to provide.

The user’s data is, in a meaningful sense, the user’s. A fediverse user can export their data from their instance and import it to another. The export-import process is not as seamless as it should be (account portability remains, as noted above, fragile), but it is structurally possible in a way that platform exports are not. A user who is dissatisfied with their instance can leave with substantial portions of their history intact.

The community is determined by the users, not the platform. Each instance has its own culture, its own conventions, its own demographic. Users select into instances that match their interests, and the federation lets them interact with users on other instances. The result is a much more diverse landscape than the platforms provide, with instances ranging from large general-purpose servers to small special-interest communities to single-user personal instances. The federation lets all of these coexist and interact while preserving their distinct identities.

The algorithmic feed is not, by default, present. Most ActivityPub-based services display content chronologically, without the engagement-optimized ranking that the platforms have moved toward. Users see what their followed accounts post in the order they post it, without the platform deciding what to surface and what to bury. This is a structural property of the protocol design, not an accident, and it produces a user experience that many users find more sustainable than the platforms’ algorithmic feeds.

What the fediverse gets wrong

The fediverse also has real problems, which it would be dishonest not to name.

Search is difficult. ActivityPub does not have native federated search, and the various search implementations that exist are limited. Finding people and content across the federation is much harder than on the platforms. Mastodon’s recent addition of optional full-text search has helped within individual instances, but cross-instance search remains underdeveloped. The discovery problem — how a new user finds people to follow — has been a persistent friction point for fediverse growth.

The user experience is, in many respects, rougher than the platforms. The fediverse clients are produced by various small teams with limited resources; the polish that the platforms have through their multi-hundred-person product organizations is not, in most fediverse clients, present. Onboarding is hard: a new user has to choose an instance, and the choice is consequential, and the user has no good way to evaluate the choice before making it. The various features that platform users take for granted (group messaging, video calls, integrated commerce, scheduling) are absent or rudimentary.

The federation has its own pathologies. Instance defederation — the decision by one instance’s operators to stop accepting messages from another instance — is sometimes used appropriately to handle abusive instances, and is sometimes used in ways that produce communities effectively cut off from the larger federation. The dynamics of who gets defederated by whom and why have, particularly in the post-2022 period, produced significant tension within the fediverse community. The federation that works is the federation in which operators cooperate; when cooperation fails, the federation fragments.

The economic model is unclear. ActivityPub-based services do not, generally, have advertising. Most are run by their operators as volunteer or paid-by-the-community efforts; some are funded by their developers’ personal resources; some are running on grants. The sustainability of this economic structure at scale is an open question. Mastodon the project itself has nonprofit foundation status with several full-time staff; the various other fediverse projects have varied funding situations, and many are dependent on the continued willingness of small teams to maintain them for limited compensation.

The IndieWeb

The IndieWeb is a smaller and older movement than the fediverse, with a different theory of change. The principal founders are Tantek Çelik, Aaron Parecki, Kevin Marks, and others who began articulating the IndieWeb position around 2010. The movement’s central premise is that individuals should publish on their own websites, on their own domains, with their own hosting, and that the social-network functions (following, replying, liking, sharing) should be implemented through interoperable protocols across these personal sites. The IndieWeb is, in a sense, the original web’s federation recovered through deliberate practice: people writing on their own pages, linking to each other, and using protocols that make the cross-referencing visible.

The IndieWeb’s principal protocols are:

Microformats, especially h-entry, h-card, and h-feed. These are conventions for marking up HTML pages with structured social-network data — posts, profiles, feeds — that other tools can parse. A web page that includes h-entry markup can be consumed by IndieWeb-aware tools as a post in a federated network. The microformats approach has the property of being readable both by humans (as ordinary HTML pages) and by machines (as structured data), without requiring separate JSON or RSS feeds. The original microformats specifications go back to 2004 and have continued to be developed.

Webmention, a W3C Recommendation since January 2017. Webmention specifies how a citing page can notify a cited page of the citation. The mechanism is simple: when page A links to page B, page A sends a POST request to page B’s webmention endpoint with the URLs of both pages; page B verifies the link, stores the mention, and may display it on page B as an incoming reference. The result is that two-way linking, which the original web rejected for permissionlessness, is recovered for sites that opt in to the protocol.

Micropub, a W3C Recommendation since May 2017. Micropub specifies a standard API for publishing posts to one’s own website from third-party clients. The pattern decouples the publishing client from the publishing destination: a Micropub-aware editor can publish to any Micropub-compliant site, and a Micropub-compliant site can be published to by any Micropub-aware client. This is, in effect, the federated publishing protocol the platforms have replaced with their own proprietary APIs.

IndieAuth, an ongoing standardization effort, provides a domain-based identity protocol. The user’s identity is their domain (you are example.com); authentication to other sites uses OAuth-style flows with the user’s own domain as the identity provider. The result is that the user’s domain becomes a portable identity that the user controls, in contrast to the platform-issued identities that depend on the platform’s continued existence.

POSSE — Publish on Own Site, Syndicate Elsewhere — is the IndieWeb’s recommended publishing pattern. The canonical version of a piece of content lives on the user’s own site; copies are syndicated to platforms (Twitter, Facebook, Mastodon, wherever the user has accounts) for the purpose of reaching audiences that are on those platforms. The pattern means that, if any of the platforms goes away or kicks the user off, the canonical content remains on the user’s own site, with its own URL and its own persistence.

The IndieWeb has held annual IndieWebCamps since 2011 and a regular schedule of online and in-person events. The community is small — perhaps in the low thousands of active participants globally — but it has been steady, productive, and persistent. The community’s output includes the various W3C Recommendations listed above, a substantial corpus of tooling (the IndieWeb’s “Building Blocks”), a wiki of best practices, and a sustained intellectual contribution to thinking about what personal web publishing can be.

Why the IndieWeb has been small but influential

The IndieWeb’s user base is, taken at face value, tiny compared to either the fediverse or the platforms. The movement is, however, influential well beyond its user base for several reasons.

The IndieWeb has been intellectually productive. The community has produced careful, well-articulated specifications and best practices. The Microformats and IndieWeb wikis are substantial repositories of design thinking about personal publishing. The work has been peer-reviewed in the W3C and IETF, has produced standards, and has been adopted (in various subsets) by adjacent projects.

The IndieWeb has been technically generative. The various IndieWeb building blocks have been adopted by other projects, often without direct credit. Webmentions have been added to comment systems beyond the IndieWeb (most prominently to the Jekyll-based static-site generator ecosystem). Micropub has been implemented by clients that publish to fediverse servers. The IndieWeb’s thinking has influenced people who do not consider themselves part of the movement.

The IndieWeb has been culturally consequential. The argument that “you should have your own website” has, since around 2018, been adopted by various people and communities who were not previously part of the IndieWeb. The static-site renaissance (chapter twenty-three) is partly downstream of this cultural shift; the renewed interest in personal blogging through the 2020s has been informed by IndieWeb thinking even where the specific IndieWeb technologies are not used.

The IndieWeb’s small size is, in part, a function of its high cost of entry. The pattern requires the user to set up their own website, write or configure their own publishing tools, and maintain the infrastructure. This is, by the standards of the platform-decade consumer internet, a substantial commitment. The IndieWeb’s response has been to lower the floor gradually — through tools like Micro.blog (a hosted IndieWeb-aware publishing service), through specific IndieWeb-aware static-site templates, and through documentation aimed at less-technical users — but the floor remains high enough that mass adoption is unlikely without further development.

The alternative protocols

The two principal alternative protocols to ActivityPub that have emerged in recent years are AT Protocol and Nostr.

AT Protocol (Authenticated Transfer Protocol) is the substrate behind Bluesky, the social-network application that was announced by Jack Dorsey at Twitter in 2019, spun off as a separate organization in 2022, and launched publicly in 2023 after a period of invitation-only beta. AT Protocol differs from ActivityPub in several important respects. Identities are based on decentralized identifiers (DIDs) that are portable across servers, with cryptographic signatures providing identity continuity. Content is stored in repositories that are, in principle, replicable across servers. The network has explicit support for portable accounts: a user can move their account from one server to another without losing their data, their followers, or their history. The protocol was designed with the lessons of the early fediverse in mind and addresses several of ActivityPub’s known limitations.

AT Protocol’s adoption has been substantial but limited compared to the fediverse. Bluesky itself has grown rapidly since its 2023 public launch, with millions of users by 2024 and continued growth into 2026. The protocol is open and other implementations exist, but Bluesky the application remains the dominant deployment. Whether AT Protocol becomes a genuinely federated network in the way ActivityPub is — with many independent servers running different applications and interoperating — or becomes a single-vendor protocol that Bluesky the company controls is, in 2026, still being decided. The protocol’s technical merits are real; the federation properties depend on the social and economic structures around the protocol developing in a federation-friendly direction.

Nostr (Notes and Other Stuff Transmitted by Relays) is a simpler and more radical alternative protocol, designed by the developer known as fiatjaf in 2020. Nostr’s core model is that clients publish signed messages to relays, and relays propagate messages between clients. There is no concept of an account; users are identified by public keys. Relays are dumb message-forwarders; the application logic lives in clients. The protocol is much simpler than ActivityPub and supports a different model of federation, in which the user controls their identity (the keypair), the relays are interchangeable, and clients can read from and write to any combination of relays.

Nostr has acquired a substantial user base, particularly among Bitcoin-aligned communities, and has produced a working ecosystem of clients, relays, and applications. The protocol’s strengths are its simplicity and the strong identity properties of keypair-based addressing. The protocol’s weaknesses include the user-experience challenges of key management at scale, the spam-and-abuse handling that the dumb-relay model makes harder, and the discovery problem that’s even worse than ActivityPub’s. Nostr is, in 2026, a smaller but technically interesting alternative whose long-term trajectory is uncertain.

What has been recovered

A summary of what the federation recovery has achieved in 2026:

A genuinely federated social network. The fediverse, with several million users across tens of thousands of servers, is the largest federated social network since Usenet. The recovery is real and is operating at non-trivial scale.

Multiple coexisting protocols and implementations. ActivityPub, AT Protocol, and Nostr are different proposals for how federated social networks should work, each with working implementations and user bases. The diversity is itself a recovery: the platform decade had reduced the social-network space to a few centralized options, and the recovery has produced multiple alternatives.

Standards and tooling for federated publishing. The W3C Recommendations (ActivityPub, ActivityStreams, Webmention, Micropub) and the various surrounding tools and libraries constitute a substantial body of infrastructure that did not exist a decade ago. Building federated applications is now significantly easier than it was.

A user community that takes federation seriously. The fediverse and IndieWeb communities have built up, over the past five-to-ten years, a substantial corpus of practice and culture around federated social networking. The community’s existence is itself a recovery of the kind of culture that supported pre-platform online communities.

What has not yet been recovered

The platforms’ user bases. Facebook, Instagram, WhatsApp, and similar services each have several hundred million to several billion users. The federated alternatives have, collectively, perhaps ten million. The recovery has not achieved scale comparable to the consolidation it is responding to.

The platforms’ product polish. The federated alternatives are improving but still lag the platforms in many user-experience dimensions. Onboarding, search, content discovery, mobile apps, integrated features — the platforms have invested billions in these areas and the federated alternatives have invested millions.

A working answer to economic sustainability. The platforms are funded by advertising and the various business models that the federated alternatives have tried have not yet shown they can support comparable infrastructure at comparable scale.

A complete replacement for the platforms’ role in public discourse. Significant fractions of public discussion still happen on the platforms, and the federated alternatives have not yet displaced the platforms as the venue for broad-audience discussion. The 2022-2023 surge to Mastodon was an indication of what could happen if the platforms collapsed faster than they have, but the platforms have not collapsed and the federation has not, so far, been positioned to absorb the role.

The trajectory

The federation recovery is, in 2026, on an upward trajectory but a slow one. The fediverse is larger than it was five years ago and is likely to be larger still in five more years. The IndieWeb is more visible than it was. The alternative protocols are producing serious working systems. The cumulative effect, summed across the various recoveries, is that the federation alternative is more credible in 2026 than it has been at any point since the platform consolidation began.

The recovery has, however, several preconditions for further growth that are outside the control of the recovery’s participants. The platforms have to continue producing the kind of dissatisfaction that drives users to alternatives. Regulatory pressure on the platforms has to continue. The cost of running federated infrastructure has to remain accessible to community-funded operators. The technical maturation of the federated tools has to continue at a pace that closes the gap with the platforms’ polish. None of these are guaranteed.

The recovery is, then, real but partial. It is the most visible of the recoveries in Part V because it has user numbers that approach the level of significance, but it is not yet a comprehensive answer to the platform consolidation. The federation experiment continues. The next chapter takes a different recovery, oriented around documents rather than social networks: the static renaissance, the return to Markdown and static site generators and the Gemini protocol, as a deliberate retreat from the application web back toward something the web’s original document architecture had supported and that has been gradually rediscovered as still useful.

The static renaissance — Markdown, static site generators, Gemini protocol

The application web that the previous part of this book described — JavaScript-heavy, framework-driven, server-mediated, platform-embedded — produced, by the mid-2010s, a counter-movement among web developers and writers who wanted something less. The counter-movement has been called the static renaissance, the Jamstack revival, the small web, the slow web, depending on which sub-community is speaking. Its various subgroups disagree about specifics, but they share a basic stance: that the web’s complexity has grown out of proportion to what most web pages need, that a generation of basic publishing has been swallowed by the application-platform model when it did not need to be, and that the appropriate response is a deliberate retreat back toward simpler tools, simpler protocols, and a more direct relationship between the writer and the page. The retreat has produced Markdown, the static site generator ecosystem, the Gemini protocol, a small but growing community of “smol web” projects, and a renewed culture of personal publishing that bears more resemblance to the web of 1997 than to the web of 2017. This chapter is about what the static renaissance has produced, why, and what its limits are.

Markdown

The substrate of the static renaissance is Markdown, created by John Gruber with input from Aaron Swartz in 2004. Markdown is a plain-text formatting syntax that uses light, mostly-invisible punctuation to indicate document structure: asterisks for emphasis, hash marks for headings, square brackets and parentheses for links, hyphens for lists. The design goal Gruber stated in his original specification was that a Markdown document should read like plain text, with the formatting being intelligible to a human reader without any parser. The syntax was, accordingly, kept light: most readers can read a Markdown document and understand the formatting without having seen the conversion to HTML.

Markdown’s adoption has been one of the quieter successes of the past two decades. The format is, by 2026, the dominant lightweight formatting language across a wide range of tools: README files on GitHub, GitLab, and Bitbucket; notes in Obsidian, Notion (partial), Bear, and most modern note-taking apps; technical documentation; static-site source files; chat messages on Slack, Discord, and Microsoft Teams; comments on Stack Overflow, Reddit, and various forums; and many other contexts. The format is not standardized in a strict sense — there are multiple Markdown variants, with different extensions and edge cases — but the CommonMark specification, released in 2014 by Jeff Atwood, John MacFarlane, and others, has provided a common baseline that most implementations now follow.

The cultural significance of Markdown’s spread is that it has recovered, for the writing layer of the web, the property of plain-text portability. A Markdown document is a text file. It can be read by any text editor. It can be edited by any text editor. It can be saved on any machine, in any directory, in any storage medium that supports text files. The format does not depend on any particular application’s continued existence. A user who writes in Markdown owns their text in the strong sense that HyperCard users had owned their stacks: as files, on their disks, in a format they can read regardless of what happens to the tools they used to make them.

This is, in retrospect, a non-trivial recovery. The platform decade had moved most writing into the proprietary back-ends of various services: Google Docs, Notion, Evernote, the various social-media platforms. The data was held by the platform; the format was proprietary; the user’s access to their writing was contingent on the platform’s continued existence and continued willingness to provide the service. Markdown has not displaced these tools, but it has provided an alternative for the users who want one, and the alternative has been adopted widely enough that it has become a stable cultural fact rather than a niche preference.

Static site generators

The next layer of the static renaissance is the static site generator. A static site generator is a tool that takes source files (usually Markdown for content, plus various configuration and template files) and produces a directory of HTML files, ready to be served by any web server. The output is, by construction, static: there is no application logic at serve time, no database, no JavaScript needed to render the basic content, no server-side rendering on each request. The pages are HTML files that the web server serves directly.

The pattern is old. Early web sites were, by default, static files. The dynamic-application web replaced this with database-backed content management systems through the late 1990s and 2000s, and the static-files pattern fell out of fashion. The revival began around 2008 with Jekyll, written by Tom Preston-Werner (a GitHub co-founder), which combined Markdown content with Liquid templates and a build step to produce static sites. Jekyll’s adoption was accelerated by GitHub’s introduction of GitHub Pages in 2008, which provided free hosting for static sites built from GitHub repositories. The combination of Jekyll plus GitHub Pages plus Markdown content gave individual developers a frictionless way to publish a personal site, and the pattern spread quickly through the developer community.

The static-site-generator ecosystem grew through the 2010s. Octopress (2011) was a Jekyll wrapper aimed at non-developers. Hugo (2013), written in Go by Steve Francia, was a substantially faster generator that could process large sites in seconds rather than minutes. Hexo, Pelican, Middleman, Nikola, and various others occupied adjacent niches. Eleventy (2017) provided a more flexible JavaScript-based alternative. mdBook (the system this book is written in) provided a generator specifically for documentation and books. The various generators differ in their template languages, their performance characteristics, and their cultural preferences, but they share the basic pattern: source files in, static HTML out.

A natural extension of the static-site pattern came with what was, in the mid-2010s, called the Jamstack: JavaScript, APIs, and Markup. The Jamstack idea was that a static site could still have dynamic features by adding JavaScript that called external APIs from the browser. The static HTML would be the substrate; the dynamic features would be layered on top through JavaScript and third-party services for the dynamic parts (forms, comments, search, authentication). The pattern was popularized by Netlify (founded in 2014, with the term “Jamstack” coined around 2015), which provided a hosting service tailored to this architecture, with build automation, deploy previews, and integrated APIs for the common dynamic features.

The Jamstack approach has been, depending on perspective, either a real recovery of the static pattern with practical extensions or a slippery slope back into the application-web complexity it was supposed to escape. In practice it has been both: many Jamstack sites are simple personal sites with one or two minor dynamic features; others are full applications with extensive client-side JavaScript that incidentally use static HTML for their initial render. The boundary between Jamstack and application-web has, since 2018 or so, blurred substantially.

The hosting platforms

The static-renaissance hosting platforms — GitHub Pages, Netlify, Vercel, Cloudflare Pages — have been a significant enabling factor. Each provides free or low-cost hosting for static sites, with continuous deployment from Git repositories, custom domains, HTTPS, and various other amenities. The combination has made it cheap and easy to run a static site, to the point where a developer can set up a personal site in an hour and have it live on a custom domain with TLS within minutes after the first commit.

The hosting platforms have their own consolidation issues. Each is operated by a specific company with its own commercial interests; the platforms can change their pricing, their policies, or their products; a static site hosted on Netlify is, in a meaningful sense, hosted by Netlify, with all the platform-dependency that implies. The static-renaissance ethos of “you own your site” is somewhat undermined when “you own your site” means “your site lives on Vercel until Vercel decides otherwise.” The site’s source files are portable; the operational dependency is on the hosting platform.

The dependency is partial. A static site’s source can be hosted on any static-file server; the platforms provide convenience and amenity rather than essential infrastructure. A user who moved from Netlify to a different host could do so relatively easily. The portability is a real property, even if most users do not exercise it. But the consolidation of static hosting into a small number of platforms is a quiet pattern that parallels, at a smaller scale, the broader platform consolidation discussed in chapter nineteen.

The Gemini protocol

The most ambitious recovery in the static renaissance is the Gemini protocol, designed by a developer known by the pseudonym Solderpunk beginning in 2019. Gemini is a deliberate retreat from the web. It is not a layer on top of the web; it is an alternative protocol that runs over its own port (1965 by default), with its own document format (gemtext), its own URL scheme (gemini://), and its own clients. Gemini is, in its design intent, a Goldilocks protocol: more capable than Gopher but much less capable than the web, with the lower complexity ceiling being a deliberate constraint.

Gemini’s specification fits in a few pages. Requests are a single line: the URL of the requested resource, followed by a carriage return and line feed. Responses begin with a two-digit status code, a space, optional metadata, and the response body. The body is, for documents, gemtext: a plain-text format with a small number of formatting conventions (lines starting with # are headings, lines starting with > are quotes, lines starting with => are links, lines starting with ``` open or close preformatted text). The protocol requires TLS for all connections; there is no unencrypted Gemini. The protocol does not have cookies, scripts, or any of the various features that the web has accumulated. The protocol is, structurally, a hard ceiling on what Gemini can do, by design.

The Gemini community is small. There are perhaps a few thousand Gemini servers (called “capsules” in Gemini terminology) operating in 2026, with a total user base in the low tens of thousands. The content is dominated by personal blogs, journals, philosophical writing, technical notes, and the kind of thoughtful long-form material that Gemini’s aesthetic encourages. The community’s voice is articulate, often political, and deliberate about what it has chosen to retreat from. The most visible Gemini sites — at the time of writing the SourceHut Gemini portal, various individual capsules, the gemini.circumlunar.space hub — provide a real working alternative to the web for the small audience that cares about it.

The Gemini protocol has not, and is not intended to, replace the web. The community’s position is that the web is too big, too complicated, and too commercialized to be reformed; the alternative is to step away from it, into a smaller and quieter network that has been designed to remain simple. The reasoning has both technical and political components: technically, that simple protocols are more resistant to commercialization and to the kind of complexity escalation that the web has experienced; politically, that a community that controls its own infrastructure can maintain values that the broader web cannot.

The Gemini community has its critics, including from within the broader small-web movement. Some have argued that Gemini’s hard simplicity ceiling is too restrictive — that the lack of inline images, of richer link types, of even basic dynamic features makes the protocol unsuitable for many uses that simple HTML could handle without committing to the full complexity of the modern web. Some have argued that Gemini’s separation from the web is a kind of secession that limits its reach to people willing to install dedicated clients. The arguments are real and the Gemini community responds to them with the position that the trade-offs are deliberate. The community is not trying to be the next web; it is trying to be a different thing.

The longer trajectory of the static renaissance

The static renaissance has been growing slowly and steadily through the past decade. Some of its specific markers:

The IndieWeb’s “you should have a website” position has reached a wider audience. The number of personal websites in 2026 is, by various estimates, growing for the first time in many years, after a long period of decline during which writing migrated to platforms. The cultural turn toward personal sites has been visible in the various “blogroll” revivals, the renewed interest in RSS feeds, the various commentary about the relative quality of personal sites versus platform content.

Static site generators have become a default for technical documentation. Many open-source projects, many companies, many academic groups use static-site-generator-based documentation as their primary publication mechanism. The pattern is, in this domain, dominant.

The “small web” community — a constellation that includes Gemini participants, IndieWeb practitioners, personal-site enthusiasts, and various others — has acquired a sense of itself as a community. The terminology, the conventions, the events, and the sense of shared purpose have grown to the point where the community is a recognizable participant in the broader conversation about what the web should be.

Substack and Ghost and other independent publishing platforms — while not strictly static in the renaissance sense — have provided a path for writers who want something between a platform and a full personal site. Substack in particular, founded in 2017 and growing through the 2020s, has been a substantial venue for writers who want to publish independently with platform-like distribution. The Substack model has its own issues, particularly around the platform’s commercial interests and its decisions about which content to support, but it has been part of the broader cultural shift toward more independent publishing.

What the static renaissance is responding to

The static renaissance is, at its core, a response to a set of specific problems with the contemporary web. It is worth being explicit about what those problems are.

Web bloat. Modern web pages are, by historical standards, extraordinarily large. A typical web page in 2026 downloads several megabytes of JavaScript, CSS, fonts, and trackers before showing the user any content. Pages that consist primarily of a single article of a few thousand words routinely require tens of network requests and hundreds of milliseconds of processing on modern hardware. The bloat is a quality-of-experience problem for users on slow connections or older hardware; it is also an environmental problem (data transfer and processing have energy costs); it is also a structural problem (sites that depend on heavy JavaScript are fragile in ways simpler sites are not).

Tracking and privacy. The advertising-supported model of the web has produced extensive tracking infrastructure: cookies, fingerprinting scripts, third-party trackers, pixel beacons, and the various other technologies that collect user behavior data. Modern web pages routinely send data to dozens of third parties on each page load. The static renaissance’s preference for sites without third-party JavaScript is, in part, a response to this tracking infrastructure.

Algorithmic mediation. The platform decade put algorithms between the reader and the content, with the algorithms optimizing for engagement and the consequences described in chapter nineteen. Static sites that are read directly, through RSS feeds or bookmarks or links, are not algorithmically mediated. The reader controls what they read; no platform is choosing on their behalf.

Long-term durability. Web applications that depend on continuing maintenance, continuing API access, and continuing platform support are, in a real sense, ephemeral. A piece of static HTML on a stable hosting platform may continue to be readable for decades. The static renaissance prioritizes this kind of durability over the dynamic features that the application web provides.

Authorial control. The static renaissance’s writers have, in many cases, deliberately moved away from platforms specifically to have more control over what they publish, how it is presented, and who can see it. The platform decade had produced specific instances of writers being deplatformed, being shadow-banned, being subject to engagement-algorithm decisions that hurt their reach without explanation. The static-site alternative has the property that the writer controls the publication absolutely, with the limits being the writer’s own technical capabilities and the willingness of readers to find the site.

What has been recovered

A summary of what the static renaissance has recovered:

The document as a first-class object. A static-site page is a document. It has a URL. It can be linked to, archived, quoted, transformed. The various properties that documents had in the early web have been recovered for the parts of the web that operate this way.

The author’s direct relationship to the page. The static-renaissance author writes a file, runs a generator, deploys to a host. The author can see, inspect, and modify the entire production process. The continuum between writing and publishing has been substantially recovered.

The user’s relationship to the content. A reader of a static-renaissance site is reading a document, not using an application. The relationship is more like reading a book than like interacting with a service. The reader’s data is not being collected, the reader’s attention is not being optimized for, and the reader’s experience is roughly what the author intended rather than what an algorithm has decided.

Long-term durability for the parts of the web that adopt it. The Internet Archive captures static sites well. Static sites continue to work for decades. The various long-running personal sites of the static-renaissance era have demonstrated that the pattern produces durable artifacts.

What has not been recovered

The mass audience. The static renaissance is, in user-count terms, much smaller than the application web. Most internet users in 2026 spend most of their online time on platforms; the static-site web is a small minority by traffic.

The economic model. Static sites do not, in general, have an obvious business model. The most successful static-renaissance writers either have other income, run subscriptions through services like Substack or Ghost, take patronage through Patreon and similar, or simply write as a side activity. The platform decade’s model — advertising-funded engagement at scale — is not available to static-site writers, and the alternatives are smaller-scale.

The discovery problem. A static site has, by default, no built-in way to be found. Readers find static sites through links from other sites, through search engines, through RSS subscriptions, through direct word-of-mouth. Each of these mechanisms is less efficient than the platforms’ algorithmic distribution, with the consequence that static-site writing reaches smaller audiences than equivalent platform writing would.

The interactive features that platforms provide. Comments, likes, sharing, group messaging, live updates — these are the platforms’ bread and butter, and the static-site equivalents (when they exist) are usually rougher. Some static sites have very good comment systems (mostly through Webmention, ironically tying back to the IndieWeb’s work). Most do not.

Where this is going

The static renaissance is not on a trajectory to displace the application web. It is on a trajectory to coexist with it, occupying a specific niche of the web that operates by older conventions, serving readers and writers who prefer those conventions. The niche is real, has been growing, and seems likely to continue growing.

The broader question is whether the static renaissance’s values — durability, authorial control, reader sovereignty, minimal complexity — can spread back into the broader web through the various recoveries discussed in this part. Local-first software can give application users some of these values. ActivityPub can give social-network users some of them. Personal knowledge tools can give note-takers some of them. The static renaissance is, in this sense, one node in a broader recovery whose various nodes share a sensibility even when they don’t share implementations.

The book ends with a chapter on personal knowledge tools, which has been mentioned in passing throughout and which is the recovery with the most direct lineage to the knowledge-base systems of chapter nine. The chapter after that is the assessment: what’s permanent in the losses this book has chronicled, what’s recoverable but only partially, and what we should expect the next layer of the web to be able to do that the current layer cannot.

Personal knowledge tools — Roam, Obsidian, Logseq

The recovery treated in this chapter is the most direct of the recoveries in Part V. Where local-first is recovering data ownership, ActivityPub is recovering federation, and the static renaissance is recovering the document, the personal knowledge tools — Roam Research, Obsidian, Logseq, Tana, and the surrounding ecosystem — are recovering, almost without modification, the working pattern of NoteCards and KMS from chapter nine. The recovery is recent: Roam launched in 2019, Obsidian in 2020, Logseq the same year. The user bases are substantial — Obsidian alone reports over a million users — and the cultural impact has been significant within the broader “Tools for Thought” community. The recovery is also incomplete in specific ways that are worth being explicit about. This chapter takes the principal tools, the community that uses them, the discourse that surrounds them, and tries to be honest about how much of the original lineage has been recovered and how much has not.

Roam Research

The recovery began with Roam Research, founded by Conor White-Sullivan. Roam launched in private beta in 2017 and reached general availability in 2019. The system was, in its initial form, a web-based note-taking tool with two specific design choices that distinguished it from the existing market. First, it used double-bracket syntax for links: typing [[some concept]] in a note created a link to a page about that concept, with the page being either created on the spot or, if it already existed, linked to. Second, every note was a tree of indented bullet points (what Roam called “blocks”), and every block had a unique address that could be referenced from any other block in the system. The combination produced a graph of interlinked notes in which the unit of linking was the bullet point rather than the page, and in which the user could navigate by following links in any direction.

Roam was the first widely-used tool to ship these patterns in a polished, accessible form. The patterns themselves were not new. The double-bracket syntax came from wiki tradition (Ward Cunningham’s WikiWikiWeb had used CamelCase as a similar shorthand in 1995, and subsequent wikis had moved to brackets). The graph-of-notes model was older than any wiki, descending through NoteCards, KMS, and the academic hypermedia tradition. The block-level addressing was new in its polish but had precedents in various structured-note systems. What Roam did was assemble these patterns into a working consumer tool with a clean interface, intuitive interactions, and a path for non-technical users to get started.

The cultural reception was extraordinary. Through 2019 and into 2020, Roam became the subject of a near-religious enthusiasm in a specific community of academic, technical, and creative professionals who had been frustrated with the existing note-taking tools. Roam users (who called themselves “Roamans” with various degrees of irony) produced extensive blog posts, YouTube videos, courses, and books explaining how to use the tool and what it had changed for them. The discourse around Roam established, for the broader culture, the value proposition of the linked-notes pattern: that thinking with a graph of interconnected notes was qualitatively different from thinking with a folder of separate documents, and that the difference was worth the learning curve of adopting a new tool.

Roam was, however, a closed system. The notes lived on Roam’s servers; the data was accessible only through Roam’s interface; the format was proprietary. The pricing — $15 per month, with no free tier beyond a limited trial — was high by note-taking-tool standards and produced significant pushback. By 2020 and into 2021, a portion of the Roam community had begun looking for alternatives that preserved the linked-notes pattern but addressed Roam’s specific weaknesses. The alternatives that emerged are the subject of the next sections.

Obsidian

Obsidian launched in 2020, the work of Erica Xu and Shida Li (the latter using the pseudonym Silver). Obsidian’s design choice was the opposite of Roam’s: where Roam was a web application with cloud-stored notes in a proprietary format, Obsidian was a desktop application with local notes in Markdown format. The notes were files in a folder; the application was a viewer and editor that overlaid the linked-notes interface on top of an ordinary directory of Markdown files. The result was that an Obsidian user owned their data in the strong local-first sense: the notes existed as plain-text files on the user’s machine, readable by any text editor, modifiable without the application, and persistent regardless of what happened to Obsidian the company.

Obsidian’s data model differs from Roam’s in significant ways. Where Roam treats every block as a first-class addressable unit, Obsidian treats the file as the primary unit, with within-file linking working only through standard Markdown conventions. Block-level addressing exists in Obsidian (through the ^ syntax for block IDs) but is secondary. The file-as-primary model is closer to how most users think about notes — a note is a file, with a name — than Roam’s block-as-primary model, and the consequence is that Obsidian’s learning curve is somewhat lower than Roam’s for new users.

Obsidian’s plugin ecosystem has been one of its principal strengths. The application supports community-developed plugins for almost any extension: graph visualizations, kanban boards, daily-notes templates, integration with various other tools, calendar views, mind-mapping interfaces, AI assistants, and a few thousand other things. The plugin ecosystem has produced, in effect, a personal-knowledge-tool platform on top of which various smaller communities have built their preferred workflows. The flexibility has been a major reason Obsidian has outgrown Roam in user count: where Roam imposes a specific workflow, Obsidian lets the user (or the user’s plugin set) define the workflow.

The business model has worked. Obsidian the application is free for personal use; the company makes money through paid Obsidian Sync (a CRDT-based synchronization service that lets users keep their notes synced across devices) and Obsidian Publish (a way to publish a subset of one’s notes as a static website). The paid features are real services rather than artificial limitations on the application; the free tier is genuinely useful for most users; the model has supported the small team to date, with a reported user base in 2026 of well over a million.

Obsidian has, more than any other tool in this chapter, become the default option for new entrants into the personal-knowledge-tool space. The combination of local-first data, Markdown format, polished interface, extensive plugins, and free-for-personal-use pricing has made it the natural starting point for someone investigating these tools. The choice has its trade-offs (the block-level addressing is less developed than in Roam or Logseq, the user interface for graph operations is less first-class than in Roam, the synchronization story requires either the paid service or external tools), but the trade-offs are usually acceptable for the broader audience the tool has reached.

Logseq

Logseq, also launched in 2020, is the open-source alternative to Roam. Founded by Tienson Qin and a small team, Logseq adopts Roam’s block-as-primary data model — every line is a block, every block has a unique ID, blocks can be referenced from anywhere — and combines it with Obsidian’s local-first storage. Logseq notes live as Markdown (or org-mode) files in a folder on the user’s machine, organized in directories that the application understands. The format is mostly compatible with Obsidian, with some block-reference syntax that is Logseq-specific but readable as plain Markdown.

Logseq’s open-source nature is important. The application’s source code is on GitHub under the AGPL license; the development is community-driven; users can self-host the synchronization service if they prefer not to use the company’s hosted version. The community has been active and the application has improved steadily through the early 2020s, with a notable rewrite around 2023 that improved performance and user interface significantly.

Logseq has, by reputation, the most technically sophisticated user base of the three principal tools. The combination of block-level addressing, journal-based organization (every day has its own page by default), and powerful query capabilities (Logseq’s Datalog-inspired query language is more capable than the equivalents in Roam or Obsidian) has attracted users who want a more structured approach to their notes. The user base is smaller than Obsidian’s but substantial, in the hundreds of thousands.

The three principal tools — Roam, Obsidian, Logseq — together constitute a working ecosystem of mature personal-knowledge tools, with substantial communities, real production use, and continuous development. The differences between them are real and matter to specific users (block-primacy versus file-primacy, cloud versus local, open versus closed source), but the common ground is much larger than the differences. All three implement the linked-notes pattern; all three support block references in some form; all three have rich import-export with each other and with adjacent tools; all three have produced substantial communities of users who think of these tools as core parts of their working life.

The broader ecosystem

Beyond Roam, Obsidian, and Logseq, the personal-knowledge-tool space includes a substantial number of related applications, each occupying a specific niche.

Notion, founded in 2013 by Ivan Zhao and team, is not strictly a personal-knowledge tool in the linked-notes sense — it descends from the document-and-database tradition rather than from the wiki-and-graph tradition — but it has adopted some linked-notes features (page mentions, database relations) and is widely used for personal knowledge work. Notion is cloud-only and proprietary, which puts it on the opposite side from Obsidian on the local-first question. The application has a much larger user base than any of the linked-notes-pure tools, reportedly in the tens of millions, and its design choices have influenced the broader category significantly.

Tana, founded in 2022 by Tobias Vogel and team, is a more recent entrant that combines outliner-style block hierarchy with database-like structured fields. Tana’s distinctive feature is “supertags” — types that can be applied to any block, with the types having structured fields that the user can fill in. The combination produces a tool that sits between Roam-style linked notes and Notion-style structured databases. Tana’s user base is smaller than the older tools but the design has been influential.

Capacities, Reflect, RemNote, Heptabase, Mem, Athens (which sunset in 2023), and several others occupy adjacent positions. The space is, by 2026, dense with options, each with its own design philosophy and target user. The diversity is itself a recovery: a decade ago, there were essentially no serious personal knowledge tools; now there are dozens.

A specific subset of the ecosystem includes tools that integrate machine-learning capabilities, particularly the various AI-assisted notes tools that have emerged since the public availability of large language models in 2022 and 2023. The integration of LLMs into personal-knowledge tools is, in 2026, in an early phase: most of the major tools have some form of AI-assist feature (asking questions about your notes, generating connections, summarizing, drafting), with varying levels of integration. The longer-term consequences of this integration are still unfolding; it has the potential to significantly change what these tools are used for and how, but the current state is preliminary.

The Tools for Thought discourse

The community surrounding personal-knowledge tools has acquired a self-conscious identity over the past several years. The community calls itself, with some self-irony, the “Tools for Thought” community, after the longer tradition of writing about computing as a thinking aid (Howard Rheingold’s 1985 book Tools for Thought, J.C.R. Licklider’s “Man-Computer Symbiosis” essay, the broader cyberculture lineage). The discourse has been substantial: blog posts, podcasts, YouTube channels, online courses, conferences, books, and a steady stream of essays about what makes a good thinking tool, how to use these tools well, and what the historical lineage of the present generation of tools is.

Several specific figures have been prominent. Andy Matuschak, formerly of Khan Academy and Apple, has been writing about “Evergreen Notes” — a specific practice for accumulating durable, well-formed notes — and about the broader problem of how to design tools that support sustained intellectual work. Matuschak’s working notes themselves, published as a public site at notes.andymatuschak.org, have been an unusual model of what a personal knowledge garden can look like when its author treats it as a serious artifact. Matuschak’s collaboration with Michael Nielsen on Quantum Country and related experiments has produced one of the more interesting recent ventures in dynamic-document-meets-personal-knowledge territory.

Tiago Forte’s book Building a Second Brain (2022) was one of the more commercially successful entrants in the popularizing literature about personal knowledge management. Forte’s specific method — Capture, Organize, Distill, Express, or CODE — has been adopted by many users as a working framework. The book has been an entry point for many users into the broader Tools for Thought conversation.

Maggie Appleton’s writing and visual essays on digital gardens, on what notes-as-thinking-tools can be, on the cultural turn toward sustained personal websites — these have been widely shared and have contributed to the broader discourse. Other voices: Cortex Futura, Bianca Pereira, Joel Chan, Robert Haisfield, the various working researchers and educators who have been thinking carefully about these tools.

The cumulative effect of this discourse has been to establish, for a generation of intellectual workers, that personal knowledge tools are a serious category and that learning to use them well is a worthwhile investment. The conversation has analogues with the academic hypermedia community’s discourse from chapter seven, with the difference that the current Tools for Thought community has reach and impact that the academic community of the 1980s and 1990s did not have. The audience is larger; the writing is more accessible; the tools are more polished; the practice is more available.

Connection to the older lineage

The chapter is, on the argument of this book, about a recovery of what the knowledge-base systems of chapter nine had been doing. The recovery is direct enough that it is worth being explicit about the lineage.

NoteCards at PARC had cards with content, links between cards, types on the links, and the FileBox container hierarchy. Roam, Obsidian, and Logseq have notes with content, links between notes (through [[brackets]]), tags as a form of typed annotation, and folder hierarchies. The mapping is direct.

KMS had frames with structured content, fast navigation, and a flat-name addressing scheme. Roam has pages with structured (outlined) content, fast navigation through [[brackets]], and a flat-name addressing scheme. The mapping is direct.

gIBIS had typed nodes (issues, positions, arguments) and typed links between them, with the structure being the artifact. Several recent tools (Tana with its supertags, RemNote with its concept structure) have similar typed-structure systems that recover, in slightly different form, what gIBIS had been doing. The mapping is less direct but recognizable.

The recovery is not, in all cases, conscious. Many users of the current tools have never heard of NoteCards or KMS or gIBIS. The patterns the current tools implement were rediscovered, in many cases, by their designers from first principles or from intermediate sources rather than from the academic lineage. But the patterns are the same patterns. The recovery has, intentionally or not, brought back what the knowledge-base lineage had been doing in 1985, on better hardware, with more polished interfaces, for a much larger audience.

What has been recovered

A summary of what the personal-knowledge-tools wave has recovered:

The linked-notes pattern as a working consumer tool. NoteCards and KMS had been workstation-class research tools. The current personal-knowledge tools work on consumer hardware, on the web or as cross-platform desktop applications, for users with no specific technical training in hypermedia systems. The pattern is now accessible.

Block-level addressing. Roam’s block references, Logseq’s block IDs, and Obsidian’s block anchors all implement, in user-facing form, the precise sub-page addressing that Xanadu had specified and that the web had refused. The addressing is local to each tool, not federated across the web, but within the tool the property is real and useful.

Bidirectional linking. Every linked-notes tool has, by default, automatic backlinks: open a page, and you can see what other pages link to this one. The property the web rejected has been recovered for the personal-knowledge domain, where the small scale makes the bidirectional-link maintenance tractable.

The graph view as an artifact. Most of the major tools have a visualization of the user’s notes as a graph: nodes are pages, edges are links, and the user can navigate by panning around the graph. The visualization is not, for most users, the primary interface, but it provides a visible representation of the linked structure that the user has been building, and the visibility makes the structure feel like an artifact in a way that an invisible link-graph would not.

The author-reader unity that HyperCard had. The user of these tools is, in every meaningful sense, both an author and a reader. There is no separate authoring interface and reading interface; the same tool is used for both, and the user is, throughout, building the artifact they are also reading. The continuum that HyperCard had recovered, and that the web subsequently lost, is back in the personal-knowledge domain.

What remains partial

The federation between tools. Each of the personal-knowledge tools is, in its current form, an island. Roam users have Roam graphs; Obsidian users have Obsidian vaults; Logseq users have Logseq graphs. Cross-tool linking, sharing, and collaboration is possible but limited. The export-import paths exist but are not seamless. The dream of a federated linked-notes web in which any user’s notes can be referenced from any other user’s notes has not been realized. (Obsidian Publish provides a partial path for publishing individual vaults to the web, but the resulting public pages are not interoperable as a network.)

The end-user authorship reach. The personal-knowledge tools are, despite the relative ease of use compared to NoteCards or KMS, still aimed at a specific audience: people who think note-taking is important enough to learn a dedicated tool. The mass-market audience that HyperCard had reached — the teachers, doctors, hobbyists, ordinary computer users making things for their own purposes — has not been reproduced. The user base of the current tools is in the millions, which is substantial but small compared to consumer-software scales.

The long-term durability of the artifacts. Markdown-file-based tools (Obsidian, Logseq) have the local-first property that the files are durable in a strong sense. Web-application-based tools (Roam, Notion) have the property that the user’s artifacts depend on the application’s continued existence. The durability question is being answered differently by different tools, and the answer matters: a user who has invested several years of note-taking in a tool that subsequently dies has lost something significant.

The integration with the broader web. Personal-knowledge tools are, mostly, separate from the web in the sense that the notes live in their own systems and the web is a place the notes refer to. A future generation of tools that better integrates the personal-knowledge graph with the user’s web browsing, web reading, and web publishing is plausible and would be a real advance. The various read-it-later services (Readwise, Matter, Pocket), the various web annotation tools (Hypothesis, Diigo), and the various integration plugins for Obsidian and similar tools are partial moves in this direction. The integration is, in 2026, still developing.

The argument the recovery makes

The personal-knowledge tools wave is, on the argument of this book, the most successful of the recoveries because it has produced the largest user base, the most polished tools, and the most active discourse of any of the recoveries in Part V. The wave’s success has several specific features worth attending to.

The recovery has worked because it operates at the personal scale. The hard problems that broke the federation recovery and the local-first recovery — billions of users, multi-party identity, platform economics — do not apply at the personal scale. A user managing their own notes can adopt a working tool without solving the world’s problems first. The narrowness of the scope is what has made the recovery tractable.

The recovery has worked because the value to the individual user is immediate and tangible. A new Obsidian user can experience, within an hour of starting to use the tool, the difference between linked notes and folders of separate documents. The benefit does not require buy-in from a community or from a platform; the benefit accrues to the user as soon as they start writing.

The recovery has worked because the existing tools are good. Roam, Obsidian, and Logseq are, by reasonable software standards, well-designed and well-implemented applications. They work; they continue to be developed; they are not embarrassing in any obvious way. The contrast with the rough state of the federation tools in chapter twenty-two is real and matters.

The recovery has, in this sense, made a case for what the broader recovery could look like: a generation of tools that take the lessons of the lost alternatives, implement them on contemporary platforms, with contemporary user-experience standards, for the audience that wants them. The personal-knowledge tools are not, individually, a complete recovery — they leave most of the losses this book has chronicled unaddressed — but they demonstrate that some of the losses are recoverable when the conditions are right.

The final chapter assesses what the conditions look like for the other recoveries to follow. Some of the losses, on the argument of the final chapter, are recoverable on similar paths to the personal-knowledge-tool recovery: with patient work, with attention to historical lineage, with the floor lowered enough to bring in a wider audience than the original systems had had. Some are not. Naming which is which is the work of the final chapter, and the closing of the book.

What’s permanent and what’s not

The book has surveyed, at this point, the alternatives the web displaced (Parts II and III), the way the web’s victory was produced (Part IV), and the recoveries that are underway (Part V). The closing chapter is the assessment. Some of the losses chronicled in the earlier parts are being recovered; some are partially recoverable but not yet recovered; some are not on a trajectory to be recovered and probably will not be. Naming which is which is necessary if the recovery effort is to know what to aim at, and naming which is which is also a way of being honest about the contemporary web and the constraints it operates under. The chapter takes the losses in three categories: what is being recovered, what is partially recoverable but where progress is slow, and what is permanent in the sense that the conditions for recovery do not exist and probably will not.

What is being recovered

Several of the losses this book has chronicled are being meaningfully recovered, in working form, by communities that have made substantial progress on the necessary work.

The personal hypermedia graph. Chapter twenty-four documented the recovery of the working pattern of NoteCards, KMS, and the broader knowledge-base lineage in the form of Roam, Obsidian, Logseq, and the surrounding ecosystem. The recovery is real and is operating at non-trivial scale. The audience is in the millions; the tools are mature; the practice is being adopted in education, in research, in professional work, and in personal use. The pattern that the academic hypermedia community had specified by 1985 has, after thirty-five years of dormancy, returned to consumer software. The recovery is not perfect — the federation between tools is missing, the user base is still narrower than HyperCard’s was, the artifacts’ long-term durability depends on the specific tool — but the core property, that a user can build and maintain a graph of linked notes that supports their thinking, has been restored for the audience that wants it.

Local data ownership. Chapter twenty-one documented the local-first movement. The recovery is more recent than the personal-knowledge-tools recovery and at smaller scale, but it is real. Applications that store the user’s data on the user’s machines, that work offline, that survive the disappearance of their vendors — these exist in production form (Obsidian being the clearest example) and the architectural patterns that support them are maturing in the open-source library ecosystem (Automerge, Yjs, the CRDT research broadly). The recovery is partial in the sense that most consumer software is still cloud-canonical, but the path forward is visible and the necessary technologies are at the point where building local-first applications is a viable choice for new development.

The document with its address visible. Markdown plus static site generators plus the various stable hosting platforms have produced, for the substantial population of people who want them, working tools for publishing documents on the web that they own, that have stable addresses, that can be archived, and that survive their authors’ decisions to stop maintaining them. The static renaissance has been more cultural than technical — most of the underlying technologies are not new — but the cultural turn has been substantial, and the population of people who have chosen this path is growing. The web of personal sites that the platform decade had nearly extinguished has not returned to its 1997 prominence, but it has stopped contracting and has begun to grow again in specific communities.

Federated social communication. Chapter twenty-two documented the fediverse and the broader recovery of federated alternatives to the centralized social platforms. The recovery is the most visible of the recoveries in numerical terms — millions of users across the various ActivityPub services, with continued growth — and is the one that has, in specific moments (the post-Twitter migration of 2022-2023), entered the mainstream conversation. The recovery is incomplete: the user base is much smaller than the platforms’, the user experience is rougher, and the federation is fragile in specific ways. But the recovery has reached a scale at which it is structurally relevant, not just notional, and the trajectory is upward.

These four recoveries together address substantial parts of what the platform decade consolidated. They are not, individually or collectively, a return to a pre-platform web. They are, more modestly, a set of working alternatives for the users who want them, operating alongside the platforms rather than displacing them. The user who in 2026 wants to manage their personal knowledge, keep their data local, publish their writing as documents they own, and participate in federated social networks can do so. The tools work. The communities exist. The economic models, while imperfect, are sustaining the work.

What is partially recoverable

A larger category of losses is recoverable in principle but where progress is slow, the obstacles are real, and the current state is partial in a way that does not currently feel like a stable equilibrium.

Two-way linking and the full citation network. Chapter four (Xanadu) and chapter seven (the academic hypermedia tradition) documented the loss of rich two-way linking. Webmentions, backlinks in personal-knowledge tools, and the various ad-hoc citation systems recover pieces of this, but the broader web’s citation network remains one-way and lossy. The recovery in personal-knowledge tools, where the system manages the link database, is more complete than the recovery in the open web, where the link database is in the publishers’ hands and the publishers do not generally cooperate. A working web-wide two-way linking system would require infrastructure (a notification protocol, a registry, or both) that has not been built and has limited momentum behind building.

Transclusion at the document level. Chapter four also documented Xanadu’s transclusion: the ability to quote a passage of one document inside another by reference, with the quoted passage being the live original. Personal-knowledge tools have recovered this at the within-tool level (Roam’s block references, Logseq’s block embeds, Notion’s synced blocks). The web has not recovered it at the document level. The closest the broader web has is the iframe, which is a degenerate transclusion (no granularity below the document, no integration with the citing document’s text), and the various text-fragment-based partial implementations (URL fragments that target specific passages). True transclusion of the kind Nelson specified would require an infrastructure for stable document addressing, version permanence, and active reference-following that the web does not have. The recovery is plausible but would require significant work.

Versioned, durable references. Chapter four (Xanadu) and chapter fifteen (the technical decisions) documented the loss of version permanence. The Internet Archive, persistent identifier systems, and content-addressable storage (IPFS and similar) provide partial recoveries in specific domains. The broader web’s relationship to its own past is still fragile, and the recovery would require either substantial archival infrastructure that operates as public goods or a structural shift to content-addressable storage. Neither is currently on a trajectory that would change the broader web in the next decade.

End-user authorship at HyperCard’s scale. Chapter five documented HyperCard’s specific contribution: a mass-market tool for end-user authorship, distributed free with the platform, in which any user could make interactive media. The personal-knowledge-tools recovery has recovered some of this for note-taking; Twine and the broader interactive-fiction community have recovered some of it for narrative; the dynamic-document tradition has recovered some of it for technical exposition. None of these has reached HyperCard’s mass-market scale, in part because no current platform ships a HyperCard-equivalent free with every device. The recovery is plausible but would require a platform decision (Apple, Google, Microsoft, or someone) to ship such a tool by default, and no such decision is on the visible horizon.

The federated peer model at the protocol level. Chapter three documented the original internet’s federated peer architecture. Email survives in compromised form; the fediverse is a partial recovery for social networking; various peer-to-peer protocols (IPFS, BitTorrent, the various blockchain-based systems) are partial recoveries for specific use cases. The broader question of whether consumer internet usage can return to a peer model — where any user with a machine on the network is structurally an equal participant — depends on infrastructure decisions (consumer ISPs allowing inbound connections, asymmetric residential bandwidth becoming symmetric, NAT being replaced by IPv6) that are slowly happening but on long timeframes. The recovery is plausible but partial and depends on factors largely outside the control of the recovery’s participants.

The dynamic document for the mass audience. Chapter twenty documented the dynamic-document tradition. The tradition has produced excellent tools for technical audiences (Jupyter, Observable, Mathematica). The mass-audience version — explorable explanations, interactive textbooks, computational essays for general readers — has been demonstrated in specific instances (Bret Victor’s essays, the Distill.pub corpus, various Observable notebooks) but has not become a dominant mode of technical communication for general audiences. The recovery is plausible but would require either an authoring tool with HyperCard’s accessibility (which does not yet exist) or a cultural shift in how technical communication is done (which is slow).

What is permanent

A smaller but real category of losses appears unlikely to be recovered. The reasons are several, and the items in this category should be named with care.

The pre-platform consumer internet’s specific cultural moment. The web of roughly 1996-2005, with its personal pages, geocities neighborhoods, blogs, web rings, and substantial fraction of users who were also authors, was a specific cultural moment. The static renaissance is recovering some of this in pieces; the personal-knowledge-tool community has its own version of it; the fediverse has aspects of it. But the original moment had specific conditions — a small enough user base that conventions could form, a homogeneous enough demographic that those conventions could be inherited, a slow enough pace of platform development that the user culture could keep up — that are not coming back. The web’s user base is now in the billions and the platforms’ development pace is faster than any user culture could absorb. The specific texture of the late-1990s personal web is, structurally, a moment in time rather than an architecture that can be reinstated.

The genuinely peer internet at consumer scale. Most consumer internet connections are, as discussed in chapter three, asymmetric, behind NAT, in violation of the original peer-to-peer architecture. The recovery to a fully peer-to-peer consumer internet would require structural changes to the consumer infrastructure: symmetric residential bandwidth, IPv6 deployment, ISPs that permit inbound connections, operating systems that present running a server as a normal user activity. Each of these is on its own slow trajectory; the cumulative shift to make consumer machines genuine peers is, on current trends, decades away if it happens at all. Most users will, for the foreseeable future, experience the internet as clients to servers operated by other parties.

The pre-advertising web. The web from 1991 to roughly 1995 was not advertising-supported. Most of the content was produced by people who were not paid for it; the economic model was the same as for academic publication and personal correspondence — produced because the producers wanted to produce it, for the audiences they could reach. From 1995 onward, the advertising-supported web grew and now dominates. The various subscription models, paid newsletter platforms, and creator-economy services that have emerged are partial alternatives but have not replaced the advertising-supported web as the dominant model. The structural commitment of the web to advertising as a revenue mechanism is, at this point, deep enough that it is unlikely to be reversed at scale, even though individual users and communities have produced alternatives for specific contexts.

The unification Plan 9 proposed. Chapter fourteen documented Plan 9’s proposition that the operating system, the network, and the user environment should be a single coherent system. The recovery in pieces (FUSE, containers, namespaces) does not constitute a return to the unification. The current computing environment is, structurally, layered and disunified, with each layer having its own abstractions. The Plan 9 unification would require a coordinated redesign across operating systems, networks, and applications that no party has the position or the inclination to undertake. The pieces will continue to be recovered; the whole will not.

The richness Xanadu specified in its full form. Chapter four documented Xanadu’s specifications. Several of them have been recovered (transclusion in narrow tools, version permanence in narrow systems, the rights model not at all). The full system Nelson described — with universal transclusion, universal addressing, integrated rights management, and the full set of properties working together — has not been built and probably will not be. The technical conditions are gradually becoming more favorable (content-addressable storage, cryptographic identity, distributed systems research have all matured), but the political-economic conditions that would support a global infrastructure of the kind Xanadu specified are not in place. The recovery will continue to be partial.

What the recoveries together suggest

The recoveries this book has chronicled, taken together, have a shape. They are, with rare exceptions, recoveries at the application layer of properties that the web’s protocol layer threw away. Local-first software adds, at the application layer, the data-ownership property that the cloud-application model removed. Personal-knowledge tools add, at the application layer, the linked-notes pattern that the web’s flat document model omitted. The fediverse adds, at the application layer, the federation property that the platforms removed. The static renaissance adds, at the application layer, the document-orientation that the application web abandoned.

The protocol layer underneath is not changing. HTTP, URLs, HTML, JavaScript — these are largely what they were in 2010, with incremental improvements. The big changes happening are above the protocols, in the patterns that applications adopt and the communities that adopt the applications. This has implications for what kind of recovery is possible and at what pace.

The application-layer recovery is, in some ways, faster than a protocol-layer recovery would be. The protocols have enormous deployed bases and any protocol-level change requires coordination across millions of operators. Application-level changes can be made by individual application teams and adopted by individual users; the friction of change is lower. The personal-knowledge-tool wave has been able to move from “nobody has heard of this pattern” to “millions of users” in about six years, faster than any protocol-level change would plausibly happen.

The application-layer recovery is, in other ways, more fragile than a protocol-layer recovery would be. Applications can disappear. Companies can fail. Cultural moments can pass. The recovery that depends on a specific set of currently-popular applications is, in a sense, only as durable as those applications. The Markdown-files-in-a-folder pattern is more durable than this because it has been deliberately designed to outlive any specific tool. Many of the other recoveries are less robust on this dimension.

The pattern, then, is: application-layer recovery is the path of least resistance, is producing real progress, and is not as durable in the long term as protocol-layer recovery would be. The recovery that lasts is the recovery that the protocols themselves enforce. The recovery that depends on application-layer adoption is one application failure away from dissipating.

What the recoveries do not suggest is possible

The book has not been arguing that the web should be replaced. The argument has been about what has been lost and what is being recovered, with the implicit position that recovery happens on top of and alongside the web rather than in place of it. The web has been a substantial success as public infrastructure; the costs of replacing it would be enormous; nothing on the current horizon is poised to do so. The recoveries are not, in any case, alternatives to the web. They are uses of the web (or, in Gemini’s case, of an adjacent protocol) that take more seriously some of the properties that the web’s protocols permit but do not require.

The recoveries do not suggest, then, that a counter-revolution is possible. The platforms will continue to dominate consumer internet usage for the foreseeable future. The application web will continue to be the dominant kind of web for the foreseeable future. The advertising-supported business model will continue to be the dominant business model for the foreseeable future. The recoveries operate in the space these dominant patterns leave room for, which is real but is not the majority of consumer internet activity.

The recoveries also do not suggest that the losses can all be made up. Some of what was lost is gone. The HyperCard generation’s specific texture, the pre-platform web’s specific culture, the various small communities that depended on infrastructure that no longer exists — these have, in many cases, been replaced by other things, sometimes worse, sometimes better, but not by the same things. The recoveries should be read as recoveries of properties, not of specific cultural artifacts. The properties can come back; the cultural moments are gone.

The condition of the substrate

The substrate underneath the web — the internet’s protocols, the institutions that maintain them, the operators that run the networks — has held up better than this book’s argument might suggest. The IETF continues to operate. The DNS root continues to function. The major internet protocols (TCP, IP, DNS, BGP, TLS) continue to be developed and improved. The infrastructure has, despite various pressures, remained genuinely federated at the protocol level.

The pressures on the substrate are real and worth being explicit about. Consolidation of infrastructure into a small number of cloud providers has put pressure on the federation at the operational layer. Regulatory capture and the related political pressures on the substrate have been significant. The economic incentives that favor centralized platforms over federated alternatives have shaped what gets built on top of the substrate. The substrate’s continued operation depends on the continued willingness of operators, standards-body participants, and various other stakeholders to maintain it, and the willingness is not guaranteed.

The recoveries in Part V depend, in significant part, on the substrate continuing to be available. Local-first software depends on the user’s machines being able to talk to each other over the network. The fediverse depends on independent servers being able to interoperate over standard protocols. The static renaissance depends on independent hosts being able to serve content to readers. If the substrate’s federation degrades — if independent servers become harder to operate, if independent hosts become harder to find, if independent users become harder to reach — the recoveries will become harder. The substrate is not just a background condition; it is the precondition for the work that the recoveries depend on.

Maintaining the substrate, accordingly, is part of the broader recovery effort. The work is unglamorous: standards-body participation, infrastructure operation, regulatory advocacy, the various low-prestige institutional labor that keeps the internet’s federation alive. The work is also necessary, and the recovery efforts that ignore it are building on conditions they cannot count on.

What the next layer might look like

A speculative conclusion: what might the next decade of the web’s evolution produce, if the recoveries continue on their current trajectories?

The personal-knowledge-tool layer will continue to grow. Obsidian, Logseq, and the other current tools will continue to mature; new tools will emerge; the integration with adjacent layers (AI assistance, web reading tools, dynamic documents) will deepen. The audience for these tools will grow, perhaps to the low tens of millions globally, with the practice becoming a normal feature of intellectual work for the audiences that value it.

The local-first movement will continue to mature. The libraries will become more capable; the user-experience patterns will be refined; more production applications will adopt local-first architectures. The mass-market consumer software will continue to be mostly cloud-canonical, but the local-first alternatives will exist in more categories, and users who care about the property will have more options.

The fediverse will continue to grow, probably more slowly than its participants hope. The user base will reach the low tens of millions; the user experience will improve; the federation properties will mature. The platforms will continue to dominate consumer internet usage, but the federated alternative will be more available and more visible than it currently is.

The static renaissance will continue. The personal-site population will continue to grow; the tooling will continue to mature; the cultural commitment to publishing on your own site will spread further. The application web will continue to dominate, but the document web will hold its position as a stable alternative for the audiences that prefer it.

The dynamic document tradition will produce, eventually, an authoring tool that lowers the floor enough to reach a broader audience. The current tools are still oriented toward technical users; a future tool that brings the dynamic document to non-technical authors is plausible and would be substantial. The pattern is similar to HyperCard’s: a technical breakthrough waiting for the right packaging.

The AI integration will be substantial and difficult to predict. The current state of LLM integration with the various recoveries is preliminary; the next decade will see much more. The effects on what these tools are used for, who uses them, and how they relate to the broader web will be significant. Whether AI integration helps the recovery effort or further consolidates platform power is one of the larger open questions about the next decade.

A careful hope

The book has been about a contest that ended thirty years ago and what has been done in the time since by people trying to recover what the contest’s losers had been working on. The contest was real, the losers had been working on serious things, the recovery is happening, and the recovery is partial in specific ways the book has tried to be honest about.

The through-line the book proposed in the introduction — the document lost to the application, and authorship lost with it — is mostly intact as a description of what happened to the consumer web. The recoveries are partial reversals: in the personal-knowledge domain, the document is back as a first-class object the user authors; in the static-renaissance domain, the document is back as the publishing artifact; in the local-first domain, the user’s data ownership is back; in the fediverse, the federated authorship of public posts is back. Each is partial and each is real. The cumulative effect, if the recoveries continue, will be a web in which the document and the application coexist as serious categories, with users having more choice than they have currently about which kind of experience to have.

This is a modest hope. It is not the hope that the platform decade can be reversed or that the original federated peer internet can be reconstituted at scale. It is the hope that, for the audience that wants a different relationship with the web than the platforms offer, the relationship can be had. The audience is, in 2026, in the tens of millions globally. The audience’s tools are getting better. The audience’s communities are growing. The cumulative effect is not a revolution, but it is a recovery.

The losses the book chronicled were real losses. Many of them are gone. Some are coming back. The book is, in this final balance, neither pessimistic nor triumphal. It is a record of what happened, what has been done since, and what is still possible to do. The next decade will determine which of the still-possible recoveries become real. The work continues.

The book ends here. The chapters have been about people who, in their various ways, tried to build a different version of networked computing than the one we have. They mostly lost. The contest they were part of has been forgotten by most of the people who use the web they lost to. Naming them, naming what they were trying to do, and naming what is being done to recover their work, has been the project of these pages. The systems are mostly gone. The proposals are still available. What the next layer of the web does with the proposals is the open question, and it is, on the evidence of the past decade, an open question that is being taken seriously by enough people that it might be answered.