Clutch Power

crs48 with Claude · History

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.

flowchart TB
  subgraph couplingBlock["The coupling — frozen, specified, versioned"]
    N["one node shape<br/>id · schemaId · createdAt · createdBy"]
    IRI["one namespace<br/>xnet://authority/Name@version<br/>(the authority can be you)"]
    LWW["one merge rule<br/>signed change log,<br/>deterministic fold"]
    AUTHZ["one permission algebra<br/>roles · actions · grants,<br/>enforced where data moves"]
  end
  subgraph bricks["The bricks — open-ended"]
    T["a task"]
    C["a contact"]
    M["a message"]
    X["your field on<br/>someone else's node"]
    S["your private notes<br/>on their data"]
    F["an imported silo<br/>(CSV, Slack, feeds)"]
  end
  subgraph players["The players"]
    APP["apps — views<br/>(the previous essay)"]
    AGT["agents — same table,<br/>same rules"]
    PPL["people — names you mint,<br/>links you hand over"]
  end
  bricks -->|snap onto| couplingBlock
  players -->|"play, where permitted"| couplingBlock

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:

// Their brick: a Contact someone else created and governs.
// Your stud: a field in your own namespace, riding on the
// node itself — syncing and merging like any other property.
await update(ContactSchema, contact.id, {
  [extKey('acme.example', 'leadScore')]: 42
})

// Your private brick on their public one: a sidecar — a
// separate node with its own permissions (they never see it),
// addressed deterministically so every device finds the same one.
await create(ContactNotes, {
  target: contact.id,  // relation → any node, any schema
  body: 'Prefers the 1958 catalogue. Buys in bulk.'
}, sidecarId(me.did, contact.id))

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.

sequenceDiagram
  participant O as Owner
  participant R as Relay
  participant G as Guest
  O->>O: creates a node — encrypted,<br/>its key wrapped per recipient
  O->>R: publishes the signed change
  Note over R: Guest holds no grant →<br/>nothing is relayed.<br/>No key → the brick doesn't snap.
  O->>G: hands over a share link<br/>(the secret rides in the URL fragment,<br/>which no server ever receives)
  G->>R: claims it — a delegation,<br/>attenuated to read-only
  R-->>G: changes for that one resource
  G->>G: unwraps the key. The brick snaps.
  O->>O: revokes the grant
  Note over G: future changes stop arriving.<br/>What was already read is already copied —<br/>a grip, not a weld.

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.