Beyond the Pod: How the Decentralized Trust Graph Builds on Solid
Solid was the first serious attempt to give people back control of their data on the web. It deserves credit for proving the model. It also stopped at a particular point, and the reasons it stopped there say a lot about what a fuller solution has to look like. The Decentralized Trust Graph (DTG), with its credential catalog, its trust task protocols, and now its data rooms, is an attempt to carry Solid’s idea the rest of the way.
What Solid got right
Solid, launched by Tim Berners-Lee’s group in 2016, proposed a simple inversion. Instead of every application keeping its own copy of your data, you keep your data in a personal online data store, a pod, and applications come to it. Your identity is a WebID, a URL that dereferences to a profile you control. Access to each resource in the pod is governed by Web Access Control (WAC) or its successor, Access Control Policy (ACP), which let you say which WebIDs, which groups, and which application origins may read or write what. The data is linked data, so it composes across pods, and applications become interchangeable front ends over data they do not own.
That inversion is correct, and the DTG keeps every part of it. The person controls the data. Applications are guests. Identity is portable. Access is the owner’s decision, not the platform’s. Solid’s protocol work has since moved into a W3C working group on Linked Web Storage, whose stated mission is to loosely couple storage, authentication, access control, and application provider. The DTG shares that mission word for word.
Where Solid stopped
Solid made four design choices that each seemed reasonable and that together limit what it can do. None of them is a mistake. Each is a place where the technology of the time ran out.
One public identity. A WebID is a single global URL. Every application, every pod, and every counterparty sees the same identifier, so everything you do anywhere can be correlated by anyone who sees it twice. Solid protects your data and leaves your identity fully exposed.
The server is the enforcement point. WAC and ACP are access lists evaluated by the pod server. That means the server must know who is asking, must hold the membership list of every group it enforces, and can read every byte it serves. The WAC specification is explicit that content encryption and hiding group membership from the server are out of scope. You trust the host for confidentiality, for integrity, for membership, and for availability, all at once. If you host your own pod that is fine. If someone else hosts it, you are back to trusting a platform, only a smaller one.
A statement has no author and no consent. Solid stores RDF, and an RDF triple is anonymous. Anything in a pod was written there by whoever had write access, and nothing in the data says who asserted it or whether the other party agreed. If your pod says you are a member of a group, that is a fact about your pod, not a fact both you and the group signed.
A pod is a place. Pod resources are addressed by HTTP URLs on the host that serves them. Moving a pod to another provider changes every URL, and every link into it breaks. Portability of data across providers, the thing the model promised, turned out to be one of the hardest problems in practice.
And there is a fifth gap that is not Solid’s fault at all. Solid predates AI agents. It has no way to say that an agent may act for a person with strictly less than that person’s authority, and no way for a group’s agents to share what they learn without handing the transcript to a platform.
The DTG’s first move: signed, consented, scoped statements
The DTG starts from the same graph idea Solid does. Its nodes are identifiers and its edges are statements about how two nodes relate. Three things are different at the level of the statement itself.
Every edge is a W3C verifiable credential, so it has a signer. “Who says so” is part of the data, not metadata held by a server.
Edges that need two parties carry both signatures. A membership is a credential from the community to the member and one from the member back. A relationship is the same in each direction. A delegation is a grant and a matching acceptance. Consent is inside the edge, and a verifier can check it without asking anyone.
Every identifier carries a declared correlation scope. A pairwise identifier is known to one counterparty. A directed one is known to a set the holder chooses. A public one is meant to be found. The same person is a different node to different observers, by design, and only the holder can widen that. This is the piece Solid could not express: control over who may even name you.
On top of these the DTG adds two credentials that Solid has no equivalent for. A Verifiable Delegation Credential (VDC) says one party may act in another’s name for a bounded set of acts. A Verifiable Authority Credential (VAC) says what a party may do at a named scope, and it can be attenuated by its holder so an agent runs on a narrower grant than the person it works for.
That answers the identity, consent, and agent gaps. It does not answer the storage gap. A credential is a small signed statement. It is not a place to keep your notes, your decisions, or your agent’s memory. For that the DTG needed something pod-shaped.
The DTG’s second move: data rooms
A data room is a shared, credential-governed, end-to-end-encryptable space: a set of records held somewhere, readable and writable by exactly the parties its credentials admit. The design is published as a design note and a concept document in the Verifiable Trust Infrastructure repository, and its protocol is a family of trust tasks on trusttasks.org, covering creation, records, key epochs, and ownership transfer. It is at the design and early implementation stage. Nothing here is a shipped product yet.
The idea that makes a room different from a pod is that the room, not the host, defines its own membership.
A room is a node in the graph with its own DID. It is addressable, it can be messaged, and it issues its own credentials. Joining a room mirrors joining a community, one level down: the room issues an invitation, the invitee consents by presenting it, and the room issues a membership credential and an authority credential in return. From then on every read and write is a credential presentation the host verifies against the room’s public, witnessed DID log. The host keeps no member list. It cannot forge a membership, cannot enumerate one, and on the strongest tier cannot even see one.
Room authorization never touches a host access list. This is the direct answer to Solid’s enforcement point. In a pod, the server holds the ACL, so the server is part of the membership. In a room, the credentials are the membership, and the host verifies them the way any verifier would. That single change is what makes everything else possible.
Rooms are portable by construction. A room is addressed by its DID, not by a host’s row id or URL. Moving a room to another host is re-pointing the service endpoint in the DID document. Not one credential is reissued, not one record changes, and no link breaks. The design note puts it well: leaving a platform stops being an exit and becomes a setting. This is the pod portability problem solved at the identifier layer rather than the storage layer.
The host is trusted for availability and nothing else. Content is sealed under group keys managed by MLS (RFC 9420), the same protocol modern messaging is converging on, and the keys live in the members’ own Verifiable Trust Agents (VTAs). Records are signed and bound to their location, so a host cannot alter or replay them. Membership is verified against a witnessed, self-certifying log, so a host cannot forge or suppress it. What remains is that the host could stop serving, and the design makes that provable rather than deniable, by anchoring renewals and epochs in the witnessed log.
Privacy is chosen per room, on a ladder. An open room is cleartext and searchable, for material where the host reading it is not a threat. An attributed room seals content but lets the host see who acted, for anyone who must keep per-member access logs. A private room proves membership with an unlinkable zero-knowledge presentation, so the host learns that a member acted and nothing more. The private tier is the Signal private group architecture rebuilt on verifiable credentials, with one deliberate difference: Signal’s credentials are verifiable only by Signal’s server, while a room’s can be verified by any host, mirror, or peer. That is what lets a room move.
The owner is always known. Every room has one accountable party: the controller of its DID, the issuer of its credentials, and the recipient of lifecycle notices. Privacy tiers hide members from hosts. They never hide the room from responsibility. This is a place where the DTG is more conservative than a naive reading of “decentralized” would suggest, and deliberately so.
Agents are first-class. The motivating case for rooms is shared agent memory. An agent recalls from every room its principal belongs to, writes back under an attenuated, expiring, audience-bound authority credential, and never holds a key. The member’s VTA opens records and produces presentations on the agent’s behalf and releases nothing key-shaped. A human reading a room can tell colleague-written from colleague’s-agent-written, because the attribution is cryptographic rather than self-declared.
Side by side
| Solid pod | DTG room | |
|---|---|---|
| What defines membership | Access list on the server | Credentials the room issues |
| Identity of a member | One public WebID | A DID with a declared correlation scope |
| Can the host read content | Yes | Only on the open tier |
| Can the host see who acted | Yes | Only on open and attributed tiers |
| Can the host forge or enumerate members | Yes | No |
| Who asserted a fact | Not recorded | The signer, on every record |
| Did the other party agree | Not modeled | Both signatures, on every edge |
| Moving to another host | URLs change, links break | Re-point one DID document |
| Delegation and agents | Out of scope | VDC, attenuated VAC, VTA as key oracle |
| Accountable party | Pod owner, implicitly | Room owner, always known |
| What you must trust the host for | Everything | Availability, provably |
What Solid still does better, and what rooms do not try to do
An honest comparison has to say where the older system wins.
Solid is a general file store. A pod holds photos, documents, calendars, and health records of any size. A room holds records: signed, versioned, human-readable text with a stated size cap. Rooms are for shared knowledge and shared memory, not for bulk storage, at least in their current design.
Solid is queryable. Linked data in pods can be searched and reasoned over with SPARQL across the union of many people’s data. A room offers server-side search only on the open tier, and on the encrypted tiers the client ranks after decrypting. Cross-room inference is not a goal.
Solid is mature. There are multiple server implementations, real deployments, and a W3C working group. Data rooms are a reviewed design with draft protocol specifications and implementation just beginning.
None of these are accidents. Solid optimized for a rich, open, queryable data web and paid for it in trust. Rooms optimise for a host that cannot read, cannot enumerate, and cannot hold the room hostage, and pay for it in search and scale. A fuller solution over time could carry an open room as a pod-like store and a private room as a group’s sealed memory, and the DTG’s model does not prevent that.
The fuller solution
Put the pieces together and the shape is clear. Solid decentralized where data lives. The DTG decentralizes who can vouch for a fact, who gets to learn it, and now, with rooms, where a shared space lives without the host becoming part of it.
The credential catalog gives every statement in the graph a signer, a consenting counterparty where one is needed, and a holder-declared boundary on correlation. The trust task protocols give every operation, from an invitation to a record write to an ownership transfer, a specified, transport-agnostic, proof-carrying shape. The data room gives all of that a home that people can read and curate and their agents can remember from, governed by nobody except the people in it.
Solid asked the right question: whose data is it? The DTG’s answer is the same as Solid’s. It then asks the questions Solid could not: who says so, did you agree, who is allowed to know it was you, and what may your agent do on your behalf. A system that answers all of them is what a personal data web needed all along.