Community Solid Server 7.1.9, unmodified

Surfaces in use

The left column is the Solid specification surface. The right column is what our deployment actually does with it.

LDP

Containers and resources are served by CSS. Containers advertise ldp:BasicContainer and accept POST; RDF resources accept PATCH via text/n3 and application/sparql-update. The captures below are the response headers, unedited.

WebID

Every pod has a WebID profile document at profile/card. It is publicly dereferenceable, which is required for authentication to work at all — an agent resolves it to find your OIDC issuer.

WAC

Per-resource, per-agent access control through .acl documents, which is what the sharing UI writes. WAC has no expiry primitive, so we do not offer expiring links rather than implying one.

Solid-OIDC

auth.solidus.network is the issuer, declared in each profile card. A pod's address is derived from its did:solidus — base36 of SHA-256, first 20 characters — so the same DID always resolves to the same pod.

Notifications

CSS advertises a StreamingHTTPChannel2023 channel on every resource. We do not consume it in the pod UI yet, so it is listed as present in the server rather than as a product feature.

Captured responses

Static output committed with the page, never fetched at render — a compatibility page that breaks when the thing it describes is down would prove the opposite of its point. Re-run the commands yourself.

HTTP/2 401
content-type: application/json
x-powered-by: Community Solid Server
vary: Accept,Authorization,Origin
link: <https://pod.solidus.network/zzz-not-a-real-path.meta>; rel="describedby"
link: <https://pod.solidus.network/zzz-not-a-real-path.acl>; rel="acl"
link: <https://pod.solidus.network/.notifications/StreamingHTTPChannel2023/b0>;
      rel="http://www.w3.org/ns/solid/terms#updatesViaStreamingHttp2023"
www-authenticate: Bearer scope="openid webid"

HTTP/1.1 200 OK
x-powered-by: Community Solid Server
allow: OPTIONS, HEAD, GET, POST
accept-post: */*
content-type: text/turtle
link: <http://www.w3.org/ns/pim/space#Storage>; rel="type"
link: <http://www.w3.org/ns/ldp#Container>; rel="type"
link: <http://www.w3.org/ns/ldp#BasicContainer>; rel="type"
link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
link: <.../demo/.acl>; rel="acl"
link: <.../demo/.well-known/solid>;
      rel="http://www.w3.org/ns/solid/terms#storageDescription"
wac-allow: user="read",public="read"

HTTP/1.1 200 OK
x-powered-by: Community Solid Server
allow: OPTIONS, HEAD, GET, PATCH, PUT, DELETE
accept-patch: text/n3, application/sparql-update
accept-put: */*
content-type: text/turtle
link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
link: <.../demo2/note.ttl.acl>; rel="acl"
wac-allow: user="read",public="read"

The two local captures are not a dodge, and the reason is worth stating: every LDP resource on production lives inside a real person's pod, so there is no public one to curl. These run the identical CSS version against production's own configuration file, with a throwaway pod. The production capture above is the deployed instance, unedited.

Acceptance ledger

Reproduced from the solid-server README, unchecked rows and all. Four are done. Two are not, and publishing those is what makes the other four worth believing.

• done: Community Solid Server 7.1.9 adopted. The manifest declares a caret range; the lockfile pins the build.
• done: Boots and serves as a Solid pod. Two integration suites boot production's own configuration on every test run.
• done: did:solidus to WebID bridge, verified end to end: taking the DID from a live pod's profile card and re-deriving the address reproduces that pod exactly.
• done: Deployed at pod.solidus.network.
• not done: Object-storage backend. Deferred by decision, not blocked on credentials — the deployment runs a filesystem backend.
• not done: Solid Conformance Test Suite. Not run. Until it passes against the deployed instance and we have shown interop with a third-party Solid app, compatibility is the only claim we make.