What is Community Solid Server, and what does pod.solidus.network run on top of it?

Community Solid Server is the Solid community's reference implementation, and it is not ours. We run it. pod is shipped: the thing that shipped is an integration layer around somebody else's engine.

What it is

An open-source Solid server, developed principally through academic and community work at imec and SolidLab in Ghent, with a maintainer community around it. It implements the storage model, the access-control model and the identity binding: that is, the parts of a pod that matter.

We pin version 7.1.9. The 8.x line is alpha and wants a newer runtime, so we have not moved. Pinning a stable major and saying so is the whole of that decision: there is nothing clever about it.

What it does, seen from the wire

Booted locally this session against a scratch directory:

$ curl -sI http://localhost:3199/
HTTP/1.1 200 OK
X-Powered-By: Community Solid Server
Content-Type: text/turtle
Link: <http://www.w3.org/ns/ldp#BasicContainer>; rel="type"
Link: <http://www.w3.org/ns/pim/space#Storage>; rel="type"
Link: <.../.acl>; rel="acl"

Those Link headers are the interoperability surface. They tell any client, including clients written before we existed: that this is a container, that it is a storage root, and where its access-control document lives. A stranger's tool can navigate that without knowing anything about us.

A path that was never created returned 404, so the server distinguishes "absent" from "forbidden" correctly.

What we actually add

Per our own plan, three things: an identifier bridge between our method and Solid's login model, a storage backend, and data-model mapping.

Two of those three are unticked in our own status list. The identifier side has its own page.

So the accurate sentence is: we deploy their server, we run a front end beside it, and the integration work is partly done. Anything grander would be borrowing their engineering.

Three defects in our own repository, published rather than glossed

One. Our status list has "deployed to pod.solidus.network" unticked. The surface is plainly live. The list is stale, which means you should not read the ticked items as current either.

Two. The production start script points at a configuration file that is not in the repository. As written, it would fail. Something else is launching the deployed server, and the repository does not say what, so the repository cannot tell you what production runs.

Three. Our own README tells you to curl -sI the root and expect a particular header. The root container does not return it. That header appears on a resource that supports patching, not on the storage root, we checked, on the version we pin. A reproduction instruction that does not reproduce is worse than none, because the reader concludes their setup is broken.

All three are ours, none is the server's, and they are on this page because a technical reader following our own documents deserves to know where it drifts.

What the deployed configuration looks like, and what that explains

The one configuration present in the repository selects the file storage backend, a per-pod storage location, Web Access Control for authorization and DPoP/bearer tokens for authentication.

A per-pod layout means the hostname root is not itself a storage, and that explains two things we had previously only recorded as odd:

• /.well-known/solid answers 501 on the deployed host while returning a full storage description on the local single-pod default. Not a fault. A consequence of the layout.
• Unknown paths on the deployed host return 401, not 404, because they fall through to a server whose root requires authentication. The same server, locally, returns 404, so the behaviour is our deployment's shape, not the software's.

That is consistent evidence, not proof of what production runs, for the reason in defect two.

Two servers, one hostname

/ is answered by our own front end. Other paths are answered by the Solid server. The x-powered-by header changes depending on which path you ask for, and you can see that yourself in two requests.

This is worth knowing before you debug anything here, because a status code from one of them means something different from the same status code from the other. You can check both in two requests, today, without an account.