Solidus Pod and the Solid Protocol, Compatible, Not Conformant, Yet

Solidus Pod is Solid-compatible and migration-ready. It is not Solid-conformant.

Two overlapping circles show Solidus Pod covering most of the Solid protocol's surface, with one visible uncovered crescent marked by an empty, unchecked seal.

① The Solid protocol: the wider specification, built and maintained by the Solid community. ② Solidus Pod runs the real, unmodified reference server across most of that surface. ③ One part of that surface is still open: a formal conformance test pass has not happened yet.

What "compatible" actually means here

Run it yourself before reading another paragraph of claims:

pnpm install && pnpm start
curl -sI http://localhost:3101/      # real LDP + Accept-Patch headers

What comes back is not a simulation of Solid behavior. It's Community Solid Server 7.1.9, pinned and unmodified, real, upstream code maintained by the Solid community, running with a did:solidus bridge in front of it. The LDP headers, the Accept-Patch support, the container semantics: that's CSS doing what CSS does, not Solidus reimplementing a spec badly and calling it close enough. If you already run a Solid pod and you diff this response against one, you will not find daylight.

That's the honest half of the sentence. Here's the other half.

What Solid solved, and what we did not build

Before naming any divergence, the ordering matters: Solid solved personal data storage and access control, with real institutional deployments behind it, and Solidus did not build any part of that.

WebID, an identity that lives at a web address and resolves to a machine-readable profile, came out of W3C Semantic Web and FOAF work before Solid existed, and Solid adopted it. LDP, the read/write mechanism underneath every Pod, is a W3C Recommendation from the Linked Data Platform Working Group, older than Solid too. WAC/ACL (the rule set that decides who may read or write a given resource) is Solid's own contribution, carried forward from earlier Web Access Control vocabulary work. RDF and its common serialization, Turtle, give every one of those resources a shared, machine-readable shape. None of it is ours. Tim Berners-Lee's Solid project, developed commercially through Inrupt and specified through the W3C Solid Community Group, designed all four. Where our Pod touches any of them, it composes an existing implementation, Community Solid Server, plus our own identity bridge. Nothing in that stack is Solidus-authored protocol work.

That's not a hedge. It's the accurate description of what a compatibility layer is: we didn't invent the storage model or the access-control model, we run the reference implementation of both and attach our own identity layer to the front of it.

The gap, quoted exactly

The gap between "compatible" and "conformant" is not vague. It has a name, and it's unchecked in our own repository:

§Acceptance (Phase 5, external): Pass the Solid Conformance Test Suite against the deployed instance + prove interop with ≥1 third-party Solid app. Cannot be self-asserted.

§Status: - [ ] Solid CTS passing (Phase 5), pod/apps/solid-server/README.md

Read that acceptance line again: "cannot be self-asserted." That's not our caution, it's the actual bar for the claim. A Solid Conformance Test Suite pass against our own deployed instance is not sufficient on its own: it needs proven interop with at least one third-party Solid app, checked by someone who isn't us. We have not run the suite, we have not cleared that bar, and until both of those things happen, "Solid-conformant" is not a sentence this page will say about itself. If that changes, the honest way to say so is to link the third-party interop proof, not to update this adjective.

What full conformance would actually require, concretely: the did:solidus↔Solid-OIDC/WebID identity bridge fully proven against the CTS, not just running; an R2-backed storage configuration validated the same way; and the third-party interop check itself, which by definition can't be scheduled unilaterally. That's real, uncompleted work, not a formality waiting on a button push.

WebID vs. `did:solidus`, a bet, not a result

There is one place where Solidus Pod genuinely diverges from Solid's design rather than merely not-yet-conforming to it: identity. Solid identifies a person by a WebID, a URL that resolves to an RDF profile, with proof of control historically via TLS client certificate and increasingly via Solid-OIDC. Solidus instead anchors identity as a did:solidus DID, resolved against a chain rather than fetched from a web server, with revocation and rotation as consensus rules instead of document edits.

That is a bet, not a result, and it should be read as one. WebID has years of real institutional deployment behind it: the BBC, the NHS, the Flemish government have all run production systems on it. The tradeoff is symmetric, not one-directional: a chain-anchored identifier decouples availability from any single server's uptime and makes revocation a network-wide consensus fact rather than a cache-dependent one, but it trades a decades-proven, infrastructure-light design for a dependency on an entire consensus network existing at all. One that, right now, is four development validators. The full symmetric treatment of this comparison, what each side gains and gives up, lives on its own page rather than being re-argued here: see WebID vs. did:solidus.

What this page will not claim

It will not claim a Solid Conformance Test Suite pass, now or after one has actually happened without third-party interop proof alongside it. It will not phrase the identity divergence as WebID being worse, only as a different bet, open to disagreement. It will not cite any private conversation as validation of this architecture; the only citable facts here are the ones linked above. And did:solidus is registered in the W3C DID Method Registry, a registry listing, never described as a W3C standard.

The rest of the picture, stated plainly

The network behind did:solidus is a four-node development committee, not a production validator set.

None of that is a footnote here: it's the reason the rest of this page is worth believing. The shipped/planned split that this honesty rests on is laid out in full on what's actually shipped versus what's roadmap, this page inherits that foundation rather than re-arguing it.

If you already run Solid infrastructure, the fastest way to check any of this is not to read further, it's to run the two commands above yourself, then read the acceptance line in our own repository. Both are designed to survive exactly that kind of check.