Chapter 24. The Next Web
Chapter 21 stated the result; Chapter 23 described the agents that read it. What remains is the web the agents and the dataspaces compose together: Web 3.0, as Chapter 21 defined it. Everything this chapter describes is already permitted by the derived properties; none of it is a forecast. No one builds and ships it: parties take it up one origin at a time. It does a handful of things no fused web can do.
This web gives the end user three things. The end user can navigate and drill into any data without knowing a query language, because Chapter 7’s five moves (navigate, write, restyle, rearrange, reselect) are interface primitives and none of them requires a programmer. The end user can fork and augment a running application declaratively — swap the stylesheet, change a layout, add a saved query — with no vendor involved. S3 becomes a right the user exercises rather than a courtesy the vendor grants. And the end user can federate without asking permission: federation is nothing more than merging two states, and merge is union (5.1).
None of this asks the existing web to stop, or even to notice. A silo doesn’t have to migrate to be included: wrapped (Chapter 23), it enters a federation as a view of itself, before its vendor has agreed to anything. So the transition to this next web has no launch and no platform to join. What forms instead is an accumulation: small, private dataspaces gathering around the silos until the silos hold the copy and the dataspaces hold the original. Each dataspace is detachable from the services it summarizes, from the software that serves it, and from the machine it happens to sit on. Union is additive: a dataspace runs alongside the systems already in place, and whatever stays fused keeps the failures Part IV measured. Only one thing is required: that new systems be built as dataspaces, publishing their state, instead of as applications around private databases.
The rest of the chapter walks through these capabilities, from a single application in the user’s hands out to the network that forms when many parties build this way.
The application bends
When the application’s state is a graph, the reader can reshape the application — navigate it, re-render it, reselect from it — in ways no fused page allows.
One state, many faces
Presentation is its own factor (S1), independent of the facts beneath it, so anyone can render a publisher’s state in their own way. The reader who needs large type, a screen reader’s linear order, another language, a watch-sized screen — each takes the same facts through a different present term and gets a document fit for them. Accessibility stops being a retrofit and personalization stops being surveillance: the state is shared and the rendering is the reader’s own. The document web bolted this on (parallel mobile sites, accessibility overlays) because content and presentation were fused. CSS Zen Garden (2003) showed the other way at the presentation layer alone, dressing one unchanged HTML document in hundreds of unrecognizably different designs. It reached this independence at one factor only, because the rest of the skeleton stayed fused.
A feature is a package
An application on the derived web is data, a vocabulary and a stylesheet over state (Chapter 20), so to change what it does is to change data, not code. A feature ships as a package: the terms it introduces and the templates that render them. The package merges into a running application and is withdrawn by the reverse delta, asserted and retracted the way any fact is. Nothing recompiles and nothing redeploys, because there is no application-specific code to rebuild — the catalogue becomes a storefront once a checkout package merges, and a catalogue again once it is retracted. And since the change is a delta, applying it needs neither a programmer nor even a person. A human installs it from the interface, or an agent submits the same delta (Chapter 7); one request later, the application has the new behavior. S3 stops being a vendor’s release cycle and becomes an ordinary write, open to anyone holding the right to make it.
The wish is old: HyperCard let people reshape a running application in place in 1987. What it lacked was a substrate where the reshaping composes across parties instead of trapping the stack on one machine.
In the world, dated 1987. HyperCard shipped with the Macintosh: stacks of cards a user could edit while using them, buttons and behavior rearranged in place.
In the world, prototyped. This is running code. LinkedDataHub (Chapter 19’s reference implementation) ships a package as exactly an ontology and a stylesheet: installing one merges its vocabulary into the running application and adds the XSLT templates that render it; uninstalling one is the reverse delta. The operation is an ordinary authenticated write, so an owner runs it from the interface and an agent runs it over the same endpoint, with nothing rebuilt or redeployed. It is young: it shipped in 2026, it carries one feature so far, and a new package’s templates take effect only after the stylesheet recompiles. But the mechanism is the derived one, and it runs in production.
The machine reads
The agent reads rather than scrapes (Chapter 23’s diagnosis, flipped to a capability), and each fact arrives with its source attached: the asserting party is recorded in the fourth position (Prop. 9.2), which is the graph’s own name. A claim and its provenance are one object, so a fact cannot be separated from who said it. On a web of rendered pixels a fabrication looks the same as a record; on a web of attributed facts, who says so? is answered in the data, not reconstructed after it. This does not make claims true (attribution is not verification) but it makes them accountable. Every assertion names a source to query, corroborate, or impeach, and an agent merging two graphs sees exactly which origin contributed which fact. The Semantic Web stack always sketched proof and trust as its top layers; the deployed web built the fact-sets and deferred proof and trust. Machines reading at scale now make those layers urgent.
The data is yours
The deepest change is in the state itself: it belongs to the party it describes.
State stops being scattered
Under one model and one law of merge, what lives today across a dozen unspeaking silos composes into a personal dataspace: a body of facts a party keeps under its own origin and federates with the origins it trusts. Nothing is copied around to go stale: dereferencing a name returns the owner’s current answer, because each origin is the authority on its own data.
The vision, dated 2009. This section’s personal dataspace has an earlier name. In Pull (2009), David Siegel called it the personal data locker: a person’s world (home, possessions, finances, media, health) held as one graph under its owner’s control. The services that touch it become sources that read and write, instead of keepers of their own copies. Siegel argued from market economics rather than from requirements and reached the same design this section derives: state gathered under its owner’s origin instead of scattered across silos. He described it years before any substrate could support it.
What outlives the software
State lives under its owner’s origin, not inside the software that happens to touch it, so it outlives that software, the application and the agent alike. The service shuts down, the vendor is acquired, the framework is rewritten, the assistant is replaced by a better one; the facts remain where they were, under a name that still resolves, readable by whatever reads next.
On the fused web an application takes its contents down with it: when the account closes, its history is gone, and when the link rots, the record is gone. What an agent has learned about its user is locked in the vendor’s assistant and is lost the same way. Here the code is the part that gets replaced and the data is the part that lasts: an agent gives way to a better one with nothing forgotten, because its memory was state under the served party’s origin, never the agent’s to keep.
Even the conversation that produced a change can be kept as state, each turn a document, so a delta’s provenance can point at the very utterance that caused it. Why something was done is then answered by reading the record, not by hoping a model remembers.
The principle is old and mostly ignored. Berners-Lee’s Cool URIs don’t change (1998) asked publishers to keep their URIs stable, and most publishers did not. Bush’s 1945 proposal (Chapter 6) wanted a personal store that no session’s end would erase. Both wanted what owner-held state supplies: a name that still answers, durable past the software that reads it.
Permission is a fact
What may be read, and by whom, is stated in the same state it governs, narrowed or withdrawn as an ordinary change, with no platform to grant access and none that can revoke it. One party opens a region of its world to another’s agent with a single assertion, and the boundary holds at every hop of a query that crosses between them. Composition and disclosure are not the same boundary. Any two states still compose without permission (R2), but what a given agent may read is a projection the permissions cut, so universal composition never meant universal visibility.
The vision, dated 2016. The web’s own inventor built toward this. Solid (Tim Berners-Lee’s re-decentralization project, begun in 2016) gives each person a pod whose access is itself data. Web Access Control rules are held beside the resources they govern; they state who may read what and are edited and revoked like any other fact. Permission as a statement rather than a platform setting is Solid’s design and this section’s, for the same reason: put access in the state, and no intermediary owns the gate.
What gets done
Reading is half of Definition 1.1; the write side turns capability into action.
Search runs one way: a person forms a query and the market’s pages answer, each provider having guessed in advance what to publish. Structured state runs it the other way. A need is itself facts (constraints, preferences, the criteria that qualify an answer) so it can be published as a document and read by providers, instead of typed into a search box and retained by the platform. A person states once, in the open, what they want; whoever can meet it answers, matched against the very facts that generated the request, nothing re-entered and no form filled. Stating a need is Chapter 7’s write, addressed to the market instead of to one application.
The vision, dated 2006. Publishing a need instead of searching for one has a name. Doc Searls called it the intention economy. The term dates to 2006 and the book to 2012. In that market a buyer broadcasts a qualified intent and sellers compete to satisfy it, which is search run backwards. The practice took a verb, intentcasting, and Siegel’s Pull (2009) tied it to the data locker above: the locker stores the facts, the intentcast publishes them as demand. What it always lacked was a substrate of owner-held state for the market to read.
The network forms
And once many build this way, the whole becomes more than its origins. Because states merge by union without a coordinator (R2) and any stylesheet can be pointed at the result (S3), value arises from unplanned combinations. Two dataspaces compose the moment their names meet, though their owners never coordinated, and a third party who owns neither can render the join as something new. The document web tried this once and lost it: the mashups of the mid-2000s stitched maps and listings into applications nobody’s vendor had shipped, until the platforms metered their APIs and re-siloed the data, ending the combinations at their own discretion. Union grants no such power. The joins hold because no platform owns the point where the data meets, so combining other parties’ data becomes routine rather than a fad.
And the loop compounds: publish a dataspace, and every dataspace federated with it is worth more. This is the network effect that once turned a single physicist’s filing system into the world’s front page. It now reaches the layer Web 2.0 hid, this time with no one in the middle owning the graph or charging rent on the joins.
The same compounding reaches the agent. When the agent meets a new domain, it needs no new system: it states the domain as facts over the one generic engine, and the work is finished. Chapter 23 put a question to the agent (a bespoke system per domain, or one engine with the domain as data); the answer is obvious.
So the next web is not built by a consortium or shipped in a release. It begins wherever someone stops the lateral churn and the taste-based technology trends, and treats the web as this book has treated it: from first principles, as a science. Those who do, the agents included, will have an edge over those who don’t, and the gap will only grow, because churn starts over and derivation compounds. Which curve do you want to be on?
