The Vault and the View

crs48 with Claude · History

On the first of July, 2013, Google Reader went dark. It was, by most accounts, the best feed reader anyone had built — the place where a decade of the web’s most attentive readers kept their subscriptions, their read history, their starred items, their slow-grown map of who was worth listening to. Google gave everyone months of notice and a polite export. You could download your subscriptions and walk away with a file.

People did. And then they discovered what the file was. The subscription list moved — that part survived. The years of read state, the stars, the tags: shaped for one renderer, meaningful to one application, and that application no longer existed. The data was technically yours. It had simply been formed, like a fossil, in the exact image of the thing that died. Wunderlist users got the same lesson in 2020; Sunrise Calendar users in 2016; every user of every sunsetted app gets it eventually, and the lesson is always the same shape. The researchers at Ink & Switch put it precisely: “If the service shuts down, even though you might be able to export your data, without the servers there is normally no way for you to continue running your own copy of that software.”

We have a word for a place that holds your valuables, shows them to you through its own little window, on its own hours, and shapes what it holds so thoroughly that the contents are worthless anywhere else. The word is vault — and the modern app is one. This essay is about the alternative, which is older than the vault, kept alive by a quiet lineage of thinkers, and — we’ll argue — about to be forced on the industry by economics whether it likes it or not: the application as a view over data you own.

The twenty-five-year detour

Here is the strange thing: the vault is the anomaly, not the tradition. For most of computing’s history, data and application were understood to be different kinds of thing, with different lifespans, and the data was the one that mattered.

In 1970, an IBM researcher named Edgar Codd published the paper that gave us the relational database, and its opening line is a manifesto for exactly this separation: users of large data banks, Codd argued, must be protected from having to know how the data is organised in the machine — and, symmetrically, the data must be protected from any one program’s opinions about it. He called it data independence, and the industry found it so obviously correct that it fossilised into the vocabulary: to this day, the SQL keyword for a derived window onto shared tables is CREATE VIEW. Unix, the same decade, made the same bet in a different idiom — programs are ephemeral, files endure, and any program may read any file. Your text didn’t belong to ed or vi; they were lenses you pointed at it. The desktop era inherited the arrangement by default: your documents were files, on your disk, and when WordPerfect lost to Word your letters did not die with it.

Then software moved into the browser tab, and — for the first time in the mainstream — the default inverted. The web application holds the only copy, on the vendor’s machines, in the vendor’s schema, reachable through the vendor’s screens. The fusion of data and app stopped being an architecture choice and became the business model: an investor evaluating a startup asks about its moat, and for most software businesses the honest answer is “the data our users cannot take with them.” Jacky Zhao, in an essay we’ll come back to, states the incentive plainly: “The competitive advantage of the vast majority of today’s centralized platforms are in their data moats and network effects.”

But it would be too easy — and this series tries not to take the easy version — to tell it as a story of pure capture. The vault is also genuinely convenient to build. A team that owns its schema can change it on a Tuesday. A product that answers to no other reader of its data can iterate its data model and its interface as one motion, and the best products do exactly that. Moxie Marlinspike’s famous observation that protocols move slower than platforms is a description of this real advantage. The vault wasn’t only imposed on us. It was also, for the people building software, the path of least resistance — right up until you ask what it costs the person the software is for.

It costs them everything the cold open describes. Five apps, five copies of your contacts, none authoritative. Every new tool starting from an empty room. Every export a brick. And a strange, low-grade powerlessness that previous generations of computer users did not have: the sense that your own records — your notes, your plans, your correspondence, your numbers — are things you visit, like money in someone else’s bank, rather than things you have.

“Apps become views”

The clearest early statement of the way out came from inside the project trying to build it. In December 2017, Ruben Verborgh — one of the architects working with Tim Berners-Lee on Solid, the personal-data-pod project — wrote an essay called Paradigm shifts for the decentralized Web. It names three shifts. Data and applications separate. End users become the controllers of their data. And the shift he gave the phrase this essay orbits: apps become views — “applications as interchangeable views, wherein each Web app provides consistent visualizations, interactions, and processing over your personal data pod.”

Read his formulation slowly, because every word is load-bearing. Interchangeable: if two task apps read the same task data, switching apps is retargeting a lens, not emigrating. “Applications ask rather than store,” he wrote, “and they are able to reuse data created by other apps, avoiding vendor lock-in.” And underneath it, the quiet redefinition of what decentralisation is even for: “Decentralization is about choice: we will choose where we store our data, who we give access to which parts of that data, which services we want on it, and how we pay for those.” Not ideology. Choice — the thing the vault removes.

Verborgh was honest about the costs in the same essay — that querying data scattered across personal pods is genuinely hard (“the main challenge with full decentralization of data is scalability”), and that unbundling breaks the advertising subsidy: “not everything is going to be ‘free’.” Solid got funded, incubated, deployed in pilots. And then it spent years discovering exactly which parts of the vision were the hard parts.

What the pods taught everyone

The autopsy is unusually well documented, partly by Solid’s own researchers — which is to the project’s enormous credit, and worth saying before the critique: the pods generation did the field the favour of being wrong in public, precisely, with footnotes.

The first and biggest lesson: the schema problem is the whole problem. Two apps sharing data must agree not just on where the bytes live but on what they mean — and Solid, by design, declined to referee. Leigh Dodds, a linked-data practitioner broadly sympathetic to the goals, wrote in 2024 that a pod has “no built in understanding of any specific schemas or formats. Or recommended ways to structure data” — and concluded, damningly, that after a decade “it still all feels very much like an idea trying to find a solution.” Solid’s own research team reached the same diagnosis in a paper asking, literally, What’s in a Pod? Their answer: apps failed to reuse each other’s data because each app baked in private, implicit assumptions about how the pod was laid out. Interoperability wasn’t blocked by the protocol. It was blocked by the absence of a cheap way for two programs to disagree about shape and both keep working.

Second lesson: a substrate without a query layer breeds shadow vaults. Pods stored documents but couldn’t answer questions, so every serious app built its own index of pod data on its own servers — which is, functionally, app-held data again, wearing a decentralisation lanyard. (Bluesky’s AT Protocol, the pragmatic descendant of these ideas, at least does this in the open: user-owned data repositories underneath, big indexing “app views” on top, honestly labelled.)

Third: nobody adopts a data layer for its own sake. Moxie Marlinspike’s line — people don’t want to run their own servers — is usually quoted as a dunk, but it’s really a design constraint: self-sovereignty has a UX floor, and a pod that arrives before the software you actually wanted is a worse Dropbox. And fourth, the deepest one, from Gordon Brander: “If you decentralize, the system will recentralize, but one layer up.” Kill the app silo and power reappears at the index, the relay, the host. There is no architecture that makes vigilance unnecessary; there are only architectures that give you standing.

None of these lessons say the vision was wrong. They say the vision was right enough to be worth doing properly — and they read, in hindsight, like a specification for the next attempt.

The mechanism generation

The next attempt came from a different direction: not standards-first but software-first. In 2019, Martin Kleppmann and the researchers at Ink & Switch published Local-first software: you own your data, in spite of the cloud — the essay that gave this whole movement its name and its engineering discipline. Its move was quietly radical: stop arguing about where data should live politically, and change where it lives physically. The copy on your device is the primary copy. The cloud, where it exists at all, holds secondary copies — “there is no cloud, it’s just someone else’s computer,” as the bumper sticker they quote puts it. Collaboration, the one thing vaults genuinely did better than files, gets solved in the data structure itself (CRDTs — data types designed to merge concurrent edits), and sync becomes a separate layer beneath the app rather than the app’s defining feature. Seven ideals, but the load-bearing one for this essay is the seventh: you retain ultimate ownership and control — which quietly re-founds Codd’s data independence one layer down, in your pocket.

Three years later, Jacky Zhao’s Towards Data Neutrality joined the diagnosis to the mechanism and gave the end-state its cleanest modern statement: “Apps in this new model are now just views on top of data rather than a tight coupling of data and logic.” He reached back past the web for the design pattern — “apps and platforms in this model follow the Unix philosophy: expect the output of every program to become the input to another, as yet unknown, program” — and in his accompanying Rhizome proposal, sketched the mechanics (a universal tuple store, capability based permissions, CRDTs, an always-on “cloud peer” that is “not a hosting provider… a different type of a personal device”) and wrote down the property the whole argument turns on: “If two apps are views on the same data, any change to the underlying data will instantly update both apps.”

By this year the idea had a slogan. Guido X Jansen, writing about communities that own their data on the AT Protocol, put it on a flag: “Apps as Views, Not Vaults” — “the things you make are yours; apps are just the viewers.” Fifty-two years after Codd, the argument had completed its lap: out of the database textbooks, through the pods, through the sync layer, and back into plain English.

flowchart LR
  subgraph vaults["The vault era — data fused to the app"]
    A1["App A<br/>your data inside"]
    A2["App B<br/>your data inside"]
    A1 -. "CSV export<br/>(a brick)" .-> A2
  end
  subgraph views["Apps as views — data as the ground"]
    LOG["Your substrate:<br/>one signed, hash-chained<br/>change log"] --> STORE[("Schema-typed nodes")]
    STORE -->|lens| T["Tasks view"]
    STORE -->|lens| B["Board view"]
    STORE -->|lens| C["Canvas view"]
    STORE -->|"SchemaLens<br/>v1 ↔ v2"| N["Next year's view,<br/>generated in an evening"]
  end
  vaults ==>|"the inversion"| views

One substrate, many windows

xNet is our attempt to build the thing this lineage describes — with the pod generation’s lessons treated as requirements, not trivia. So let us show you how each lesson landed in the machinery, honestly, receipts included.

Start with the ground. Everything you make — tasks, notes, contacts, messages, pages, ledgers — lives in one store of schema-typed nodes on your own device, written as a signed, hash-chained change log in an open, specified format. (We walked one note through that machine, byte by byte, in The Loom You Can Read.) The protocol specification contains one sentence we are prouder of than most of the features it governs: it defines the data — the nodes, the signatures, the replication, the authorisation — and then states that it “deliberately does not specify how an implementation stores, indexes, queries, or renders that data.” Read that as the legal text of this essay’s thesis. The spec constitutionally cannot contain an app. Apps are views; the boundary is normative.

Above that ground, the view layer is plural on purpose. The same store of nodes renders as a table, a board, a list, a gallery, a calendar, a timeline — interchangeable lenses registered over the same data, switchable at runtime, with form and canvas surfaces alongside. The tasks app is a live query over task nodes; the CRM is a live query over contacts and deals; the finance view over accounts and entries. Zhao’s sentence — change the data, and every view updates instantly — isn’t an aspiration we endorse; it is literally how the subscription layer works:

sequenceDiagram
  participant You
  participant S as One store of nodes
  participant T as Tasks view
  participant C as Calendar view
  You->>T: tick a task done
  T->>S: append one signed change
  S-->>T: live query update
  S-->>C: live query update
  Note over T,C: two views, one change —<br/>both update, instantly

Now the pod lessons, one by one. The schema problem we answer not with a grand shared ontology — that’s the mistake the semantic desktop died of — but by making disagreement cheap. Schemas are published and versioned; a view that wants yesterday’s shape and a view that wants tomorrow’s can both read the same nodes through a lens — a small, bidirectional treaty that translates at read time:

// A lens is a treaty between two views of the same nodes.
const taskV1toV2: SchemaLens = {
  source: 'xnet://xnet.fyi/Task@1.0.0',
  target: 'xnet://xnet.fyi/Task@2.0.0',
  forward: (data) => ({
    ...data,
    status: data.complete ? 'done' : 'todo'
  }),
  backward: (data) => ({
    ...data,
    complete: data.status === 'done'
  }),
  lossless: false
}
// The old view keeps reading v1. The new view reads v2.
// Nobody migrates anybody. Nobody asks a vendor.

The shadow-vault problem we answer by making the query layer part of the substrate, not each app’s private burden — a view subscribes to a query and gets liveness for free, so no view needs to keep its own copy of your life to be fast. The adoption problem we answer the local-first way: nobody is asked to want a substrate. You use an app that is good on day one, and the substrate is simply the floor it stands on — your data lands in the open store from the first keystroke. And the trust problem — a view is still code, and code can be hostile — was the subject of the previous essay: every view declares what it can see and touch in a capability manifest, and the declaration is enforced at the store, not requested politely.

One more receipt, because it’s the kind that only shows up when the architecture is real. We recently converged our web and desktop canvas — two separately grown implementations — onto a single shared core. The interesting number is what was left over: a few hundred lines of platform shell each. When the app is genuinely a view, that is all an “app” turns out to be — a thin pane of platform glass in front of a lens in front of your data. The other four-fifths of the code was the view itself, and the view didn’t care whose window frame it was mounted in.

The heirloom inversion

Everything to this point could have been written last year, or five years ago; most of it, as we’ve seen, was. Here is the part that couldn’t.

Every previous attempt at apps-as-views had to argue against economics: the vault was where the money was, so the inversion stayed a research programme. What changed is the cost of the view. A bespoke interface over well-shaped data — the thing that used to be a funded team’s quarter — is becoming an evening with an AI that can read a schema. We wrote about what that does to making software in the last essay. What it does to the economics of holding data is this essay’s closing argument: when views are cheap, views stop being the moat. You cannot charge rent on a lens anyone can grind in an evening. The only thing left to charge rent on is custody of the data itself — and custody-rent has a name, and the name is a hostage fee, and everyone can see it once the interface stops justifying it.

Zhao, in the Rhizome proposal, called the endgame years before the model prices made it obvious: “Companies of the future should derive value from the intelligence they provide on top of existing data rather than have the value be just the data.” That is, we think, exactly where this settles. Software keeps getting paid for — for insight, for craft, for reliability, for taste — but the data under it stops being the collateral. Views become disposable: generated, used for a season, regenerated better. And the data becomes the opposite of disposable. The store of nodes that accumulates your projects and notes and numbers and correspondence, in an open format, under your keys, on your device, for decades — the right word for that is heirloom. Heirlooms don’t live in other people’s vaults. They live in your house, and you decide which windows to cut.

Ask for more windows

A vault and a view are both, in the end, answers to the same question: how should you get to look at what’s yours? The vault answers: through our window, on our hours, for as long as we’re in business. The view answers: it’s your house. The light is yours. The walls are wherever you want them, and a new window is an afternoon’s work — more light, same rooms, nothing moved.

The lineage this essay walked — Codd’s independence, Verborgh’s pods, Kleppmann’s local-first, Zhao’s neutrality, Jansen’s flag — is five decades of people insisting, against the architecture of their day, that the data is the ground and the software is the weather. We built xNet because we think they were right, and because the tools finally exist to be right in production. If you want to stand on the ground floor: use the app — your data lands in the open store from the first keystroke. If you build things, build a view on the open protocol and see how little an “app” needs to be. And if you take one sentence from the whole essay, take the deal it proposes: let the apps be weather. Own the ground.

Sources

• The lineage: E. F. Codd, A Relational Model of Data for Large Shared Data Banks (1970); Ruben Verborgh, Paradigm shifts for the decentralized Web (2017); Ink & Switch, Local-first software (2019); Jacky Zhao, Towards Data Neutrality (Reboot, 2022) and the Rhizome proposal; Guido X Jansen, Apps as Views, Not Vaults (2026).
• The autopsy, much of it first-party: SolidLab, What’s in a Pod? (Solid’s own researchers on why pod apps failed to interoperate); Leigh Dodds, Confused by SOLID (2024); Moxie Marlinspike, My first impressions of web3 (2022); Gordon Brander, Redecentralization.
• Fellow travellers: the AT Protocol (user-owned repositories, lexicon schemas, app-view indexers — the tradeoffs made in the open); Steph Ango, File over app; and the cautionary shelf — WinFS, OpenDoc, the semantic desktop — for what happens when the ontology arrives before the software.
• The machinery and the receipts: the xNet protocol specification (which specifies the data and deliberately not the apps), The Loom You Can Read (one note walked through the signed change log), The Workshop and the Walled Garden (what scoped views make possible, and how they’re bounded), and The Right to Say No (leaving as a supported act).

This is an independent essay. The writers and projects cited are summarized as commentary; xNet is not affiliated with or endorsed by them. Quotations are verbatim from the linked originals; product histories are compressed — follow the citations for the fuller, messier versions. The lens excerpt is trimmed for reading; the field names match the real source. All artwork here is original.