+ On the 28th of January, 1958, Godtfred Kirk Christiansen walked into + the Danish patent office and filed for protection of a small plastic + brick. The brick was not new — his family’s company had been moulding + studded bricks for nearly a decade, and other firms moulded similar + ones. What was new was underneath: hollow tubes, set so that the studs + of the brick below would grip them from three sides. The filing + protected a coupling, not a block. The company came to call + the property it created clutch power — enough + friction that a model holds together in a child’s hands, little + enough that the same hands can take it apart, no tools, no + permission slip, no breakage. +
++ Two consequences followed, and they built one of the most beloved + systems of objects on Earth. The first is the famous one: + everything combines. A brick from the space set + snaps to a brick from the castle set, because sets are a marketing + fiction and the coupling is the product. The geometry has not + changed since the filing, which is why a brick moulded in 1958 still + seats perfectly on one moulded this year — sixty-eight years of + parts, one interface. The second consequence is quieter, and it is + the one this essay is actually about: everything comes + apart. The coupling grips; it does not weld. Your bricks + remain yours — recombinable, refusable, removable — after + every combination you make. +
++ Now look at your data. Your notes are in one company’s set, your + messages in another’s, your contacts copied inconsistently into + five more. None of it snaps together, because the web never + standardised a coupling for data — every app moulds pieces that fit + only its own kit, and calls the kit a product. This essay is about + what a coupling for data would even mean, why every previous attempt + shipped half of one, and how xNet builds both halves: + the snap, and the grip that lets go. +
+ +The bin we never got
++ Anyone who grew up with bricks knows the bin: the big box where + every set eventually goes, out of which anything can be built. The + web promised us a bin and delivered a shelf of sealed boxes. It’s + worth being precise about how, because we tried three different + lids. +
++ The first era simply denied the bin. The application owned its + data outright — its schema, its servers, its screens — and the only + universal connector on the entire web was copy and paste. (The + previous essay, The Vault and + the View, walked through how that fusion became the business + model; we won’t re-argue it here.) +
++ The second era promised the bin and kept the keys. In August 2004, + Flickr shipped a public API, and for a few giddy years “mashups” + were the web’s favourite word — data from one service recombined + with another’s into things neither had planned. It felt like + composability. It was actually a drawbridge: + access at the platform’s pleasure, revocable at the platform’s + convenience. And when the platforms worked out that the data behind + the drawbridge was the asset, up it came. Facebook shut its + friends-data API on the 30th of April, 2015. Twitter ended free API + access in February 2023 with roughly a week’s notice, stranding a + decade’s ecosystem of clients and tools. Reddit repriced its API + that same year at rates that would have cost Apollo — the beloved + third-party client one developer had spent a decade polishing — + millions of dollars a month; Apollo died on schedule, and thousands + of communities went dark in protest, which changed nothing. The + lesson generalises: an API is not a coupling. A coupling is a + property of the pieces. An API is a property of the landlord. +
++ The third era tried to legislate the bin. Europe’s GDPR grants you a + right to data portability; it does not grant you a format, so in + practice the right is a ZIP file — technically yours, parseable by + nothing you own. Below the law, the market priced the missing + coupling with unusual honesty: an entire industry (Mint, then + Plaid) was built on users handing over their bank passwords + so software could impersonate them and scrape their own balances + out of HTML, because no first-class way existed for you to hand a + program a scoped, revocable slice of your own records. Billions of + dollars, for want of a stud. +
++ None of this was for lack of vision. Ted Nelson sketched a universal + docuverse from 1960 and spent five decades not shipping it. Apple’s + OpenDoc imagined documents as bins of snap-together parts and died + in 1997, because it required every vendor to re-mould their + software around a shared coupling the platform incumbent had no + reason to bless. The Semantic Web imagined the whole web as + machine-composable data and stalled on the economics of agreement — + by 2006 even Tim Berners-Lee was steering the project away from + grand ontologies towards plain linked data. The pattern across all + three: a universal namespace without a shipped substrate is + a manifesto, and a substrate without a permission model is + a strip mine. Sixty years of proposals shipped one half or the + other. The interesting question was always both. +
+ +The coupling
++ So what is the stud-and-tube of data? When we distilled xNet’s + protocol down to what an independent implementation must honour — + the way the 1958 filing distilled a toy down to the geometry that + mattered — it came to four frozen interfaces. Everything else is + deliberately unfrozen. +
++ One node shape. Every piece of data in xNet — a + task, a contact, a paragraph, a ledger entry, a chess move — is a + node with exactly four universal fields: an id, a schema reference, + a creation time, and the cryptographic identity of its author. + That’s the entire footprint. Everything else about a node is + declared by its schema, the way everything about a brick beyond its + coupling — colour, height, whether it’s a wheel or a window — is + free to vary. +
+
+ One namespace. Every schema has a name of the form
+ xnet://authority/Name@version — and the authority can
+ be our registry, someone’s domain, or any cryptographic
+ identity at all. xnet://did:key:z6Mk…/Recipe@1.0.0
+ is a real, resolvable schema name minted by an individual person,
+ no committee, no application form. The built-in catalogue ships
+ dozens of schemas — pages, tasks, a full CRM, double-entry
+ accounts, channels and messages, canvases, maps — but the
+ catalogue holds no privileged position in the namespace. Anyone can
+ mould new parts, and the parts carry their maker’s name.
+
+ One merge rule. Every mutation is a signed, + hash-chained change record, and any two replicas that hold the same + changes fold them into byte-identical state — deterministically, + with no server as referee. We walked one note through that machine + in The Loom You Can Read; + the point here is only that the fold is part of the + coupling. Sync is not a feature of some app; it is a property + of the pieces, the way clutch power is in the plastic and not in + the instruction booklet. +
++ One permission algebra. The fourth interface is the + essay’s second act, so we’ll hold it a moment — but it belongs on + the list, and the placement is the argument. +
+ ++ What snaps on, once the coupling exists? First, data snaps + to data. Any node can hold a relation to any other node, + of any schema, made by anyone — so a CRM deal can point at the chat + thread where it was negotiated, which points at the meeting note, + which points at the contact, and no product manager anywhere + approved the combination. In the silo world each of those links is + an integration, a partnership, a roadmap item. On a shared coupling + each is just… a stud. +
+
+ Second — and this is where it gets properly LEGO —
+ you can build on bricks you don’t own. Suppose a
+ colleague shares a contact with you. You want a
+ leadScore field; she doesn’t. You extend her node with
+ a field in your namespace — an overlay, riding on the node
+ itself, syncing and merging like any core property, no fork, no
+ vendor ticket. And if what you want to add shouldn’t be visible to
+ her at all — your private notes on her contact — you attach a
+ sidecar: a separate node that references hers but carries
+ its own permissions. Here is the real shape of both moves:
+
+ Third, the coupling holds across time. Within a + schema version, changes must be additive, and every implementation + is required to carry fields it doesn’t recognise rather than drop + them — so last year’s client and next year’s client edit the same + document without either corrupting the other. Across breaking + versions, bidirectional lenses translate at read time (the previous + essay showed one in full). This is the discipline the brick teaches: + backwards compatibility is not sentimentality, it is what makes a + collection possible. A datum you created in xNet’s first + year is a 1958 brick — it seats on everything we mould later, + because the spec makes breaking the seat a violation, not a + release note. +
++ And fourth, the players multiply. Apps become + interchangeable views — that inversion had its own essay. Developers + get the whole substrate as + a couple of React hooks, and + third-party code plays inside capabilities it declares up front — + the workshop + rules. But + the newest player at the table is the one the silo era simply cannot + seat: the agent. Your workspace exposes itself to + any AI tool speaking the open model-context protocol — which means + an assistant can query your tasks, cross-reference your contacts, + and draft into your pages through the same coupling, under the + same permission checks, visible in the same audit trail as any + human collaborator. In the silo world, giving an AI your data means + uploading your life into yet another vault. On a coupling, the + agent comes to the bricks, plays with exactly the ones it’s + handed, and leaves fingerprints. +
+ +Who gets to play
++ Every “LEGO for software” essay ever written stops at the snap. But + ask an actual child the governing question of the actual toy and + you will not hear a question about combination. You will hear: + whose bricks are these, and who said you could touch them? + The toy works socially because possession is legible and physical — + your bricks are in your room. The moment data syncs, possession + stops being physical, and the question has to be answered in the + architecture or it is answered by whoever holds the servers. We + have spent this entire series on what that second answer costs. +
++ So xNet answers it in the architecture, three ways at once. +
+
+ The rules ride on the data. Authorisation in xNet
+ is not middleware in some app — it is declared on the schemas and
+ nodes themselves, as data: which roles exist, how a subject earns
+ one, which of seven actions (read, create,
+ update, write, delete,
+ share, admin) each role may take, with
+ deny beating allow on every conflict. Because the rules are data,
+ they sync like data, and every honest implementation — ours, yours,
+ a stranger’s — is required by the spec to reach the identical
+ allow-or-deny decision on the same graph. Google proved this shape
+ of permission system at planetary scale years ago, inside its own
+ fence — relationship checks over trillions of sharing rules,
+ millions of times a second, across Drive and Photos. The open question was whether the same discipline could
+ exist with nobody owning the fence. Making the decision
+ semantics a conformance requirement — golden test vectors and all —
+ is our answer.
+
+ Handing over bricks is delegation, not surrender.
+ When you grant access, the grant is itself a node — who, what,
+ which actions, until when — and it can carry a capability token
+ that the grantee can attenuate but never amplify: you hand
+ a contractor read access to one project, the contractor hands her
+ assistant read access to one document, and at no link in the chain
+ can anyone mint themselves more than they were given. Three bricks,
+ not the crate. A share link is the same machinery folded into a
+ URL, with one lovely detail: the secret lives in the link’s
+ fragment — the part after the # that browsers never
+ transmit — so the relay that delivers your data cannot read the
+ key that unlocks it.
+
+ And underneath both, the snap itself is cryptographic. + Content is end-to-end encrypted with its key wrapped per recipient; + the relay authorises every subscription and every publish before + forwarding, but even a malicious relay is holding bricks it cannot + seat. For a party without the key and without a grant, your data + doesn’t merely refuse politely. It doesn’t couple. There is nothing + to play with. +
+ ++ Put the two halves together and something inverts that the silo era + trained us to stop noticing. In a silo, every datum you add deepens + the platform’s moat — your photos make their album + stickier, your contacts fatten their graph. On a shared coupling, + every datum you add makes your bin more generative: the + new contact enriches your CRM view and your chat mentions + and whatever view you or your favourite agent builds next + spring. Network effects don’t disappear. They change beneficiary. + The compound interest on your own records finally accrues to you. +
+ +The weld and the grip
++ There is a version of this essay that ends with everything + connecting to everything, and we don’t believe in it. The box above + is the reason: a coupling cannot make people agree, cannot repossess + a secret, cannot moderate a network into kindness, cannot make + hosting free. What a coupling can do — the only thing it can do, + and it is enough — is change what kind of thing your data + is: from contents of someone’s set to pieces in your bin. +
++ The deep insight of 1958 was that the two properties everyone wants + from their pieces — holds together and comes + apart — are not in tension. They are the same property, tuned. + Too little friction and nothing you build survives being picked up. + Too much and it isn’t a construction toy any more; it’s a weld, a + sculpture, a thing you were sold that only pretends to be yours. + The entire silo era, seen from this angle, was a weld sold as a + toy: your data holds together beautifully — inside the set, with + the set’s pieces, until the set is discontinued. +
++ We built the other tuning. One node shape, one namespace anyone can + mint into, one merge rule, one permission algebra — friction enough + that what you build holds, and every brick still lifts off in your + hand: shareable to exactly whom you choose, extendable by people + you’ve never met, revocable tomorrow, and yours in the only sense + that has ever mattered with bricks — in your possession, + combining at your pleasure. If you want to start filling the + bin, the app is here, and your first note lands + as an open, signed, schema-typed node before you’ve thought about + any of this. If you build software, + mint a schema and mould the part we + didn’t think of — the catalogue has no gatekeeper. That’s the offer, + and the whole of it: bricks, not sets. Grip, not weld. And + nobody plays with yours unless you say so. +
+ ++ +
Sources
+-
+
- + The coupling: the LEGO Group’s own history of + + the stud-and-tube principle (patent filed 28 January 1958), and the sceptic’s corrective we + took to heart — + + LEGO as a Metaphor for Software Reuse — Does the Data Stack + Up? (2021), which argues the metaphor only works if the interface is + actually frozen. Agreed; hence the conformance suite. + +
- + The drawbridge era: + + Facebook’s friends-data API shutdown (2015); + + Twitter ending free API access (2023); + + TechCrunch on the platforms closing ranks (2024); the Reddit repricing that killed Apollo (2023); + + the screen-scraping years of financial data; and + + GDPR data portability in practice. + +
- + The half-couplings: Ted Nelson’s + + Project Xanadu; + + why OpenDoc failed; Berners-Lee’s + + Linked Data note (the 2006 course-correction); + + the AT Protocol’s lexicon namespace — the closest shipped cousin, public-by-default while + + private data remains a proposal — and + + Google Zanzibar (USENIX 2019), fine-grained sharing proven at scale, inside one + company’s fence. + +
- + The machinery and the receipts: + the xNet protocol + specification (the four interfaces, their conformance vectors, + and the schema-evolution rules), + The Loom You Can Read + (the merge rule, byte by byte), + The Tip of the Hook (the + developer surface), + The Workshop + and the Walled Garden (how third-party code is + scoped), and + The Vault and the View + (apps as views — this essay’s vertical twin). + +
+ This is an independent essay. LEGO® is a trademark of the LEGO + Group, which does not sponsor, authorise, or endorse it — the + bricks appear here as cultural reference, and all artwork on this + page is original. Product histories are compressed; follow the + citations for the fuller, messier versions. The code excerpt is + trimmed for reading; the helper functions and their behaviour + match the real source. +
+