What's Actually Live in Solidus Pod (and What Isn't Yet)

pod.solidus.network runs Community Solid Server 7.1.9, pinned and unmodified. That half is proven today, by a command anyone can run. A did:solidus bridge, an R2 storage backend and a Solid Conformance Test Suite result are architected and nothing more. This page is the ledger for both halves, so no other page on this surface has to re-argue its own status from scratch.

The ledger

Claim Status Proof
CSS 7.1.9, pinned, unmodified, boots as a real Solid pod Shipped pnpm install && pnpm start brings CSS up on http://localhost:3101/, file-backed. curl -sI http://localhost:3101/ returns real Solid LDP Link headers.
Local WAC-style access control, JWT+Postgres app layer Shipped Enforcement runs inside CSS itself, which is real Solid software rather than Solidus code, layered under a JWT+Postgres app-data store.
R2-backed production storage config Planned pod/apps/solid-server/README.md §Status: - [ ] R2-backed config (config/solidus-pod-r2.json) — needs R2 creds.
did:solidusSolid-OIDC/WebID bridge, in production Planned / architected Same file, §Status: - [ ] did:solidus ↔ Solid-OIDC/WebID bridge (Phase 2). Unchecked alongside it: - [ ] Deployed to pod.solidus.network (needs server access).
Solid Conformance Test Suite pass Planned, not self-assertable Same file, §Acceptance: "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).

What's shipped

The shipped half is small and specific. That is the point.

pod/apps/solid-server/README.md pins CSS to 7.1.9. The 8.x line is alpha, wants Node 22 or newer, and we have not moved to it. Run pnpm install then pnpm start and CSS comes up on http://localhost:3101/, file-backed, using its own default DataAccessor. Ask that instance for its root and the response carries genuine Solid LDP Link headers: the protocol signature of a working Solid server rather than an imitation of one.

One correction to our own README while we are here. It tells you to expect an Accept-Patch header on that root request. It is not there. Accept-Patch appears on a resource that supports patching, not on the storage container, and we checked this on the pinned version.

We did not write CSS and do not claim to have. This product composes an existing implementation built by other people, which is what the Pod lexicon entry says it does. The local instance is a real Solid pod, good enough for interop testing against tools like Penny or @inrupt/solid-client. WAC-style rules already run inside it, next to a JWT+Postgres layer we do own, handling app-level auth and data that sits beside the pod rather than inside its LDP tree.

What's planned, named individually

Three things are architected and unproven in production. Lumping them into one "in progress" row is the vagueness this page exists to replace.

R2-backed storage. config/solidus-pod-r2.json, the componentsjs config that would swap CSS's file DataAccessor for an S3/R2-backed one, is unwritten. The README's own line: - [ ] R2-backed config (config/solidus-pod-r2.json) — needs R2 creds.

The did:solidus to Solid-OIDC/WebID bridge, in production. It is Phase 2, unchecked. Read it beside the other unchecked line in that list, - [ ] Deployed to pod.solidus.network (needs server access), and the pairing is why this page says architected rather than live. Engineering todos.txt still carries an open low-priority item in the same unfinished space, wiring the pod Solid access token for the HTTP PodBundleClient. Until both boxes clear, architected is the accurate word.

A Solid Conformance Test Suite result. This is the acceptance gate that matters, and it is external by design. §Acceptance requires a run against the deployed instance plus interop with at least one third-party Solid app, and states plainly that it "cannot be self-asserted". No page on this surface will claim the gate is cleared before it is. Self-reported conformance is worth nothing even afterwards; third-party interop is the actual bar.

Say the whole picture plainly

Our Pod is Solid-compatible and migration-ready. It is not Solid-conformant and it does not run the full Solid Protocol.

Solid was designed and proven by the Solid community: WebID, LDP, WAC/ACL, RDF, with institutional deployments reported years before Solidus existed. We built none of it. Where this product touches Solid it composes Community Solid Server, real software written by that community, and adds one bet on top: a chain-anchored did:solidus identifier, registered in the W3C DID Method Registry and not a W3C standard, in place of WebID's HTTP-and-certificate identifier. Full protocol conformance is undone engineering, and this page will not round it up.

The rest of the picture is just as plain. Say that in the same breath as the CSS proof above it, not as a caveat at the bottom.

Next

Keep reading

What's Actually Live in Solidus Pod (and What Isn't Yet) · Solidus