+ 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. +
+ +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: +
+ ++ 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: +
+ ++ 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. +
+