Solid — what we’ve built

prod-solid-server is a Solid server built from scratch in TypeScript — one concrete, deployable server, not a framework, using the Community Solid Server as a reference only (no shared code). It implements the Solid Protocol / LDP request surface, Solid-OIDC authentication with DPoP-bound proof-of-possession tokens (via an external Keycloak identity provider behind an issuer-agnostic verifier), Web Access Control authorization, the Solid Notifications Protocol (WebSocketChannel2023, with WAC-gated subscriptions), and S3-backed storage behind a SPARQL index. It is under active development, and it is the server behind the suite’s deployment: the pod endpoint at solid-test.jeswr.org (auth-gated — a Solid server root, not a browsable page) and the identity provider at idp.solid-test.jeswr.org.

solid-server-rs is an explicitly experimental Rust Solid server — its own README opens “NOT a production server … Do not deploy this.” It is a research vehicle, not a replacement for the TypeScript server, with two load-bearing rules: the sparq engine (§3) is the authoritative source for RDF data, metadata, containment, and access-control evaluation, and object storage is backup-only for resource bytes. Authentication is delegated wholesale to a standalone DPoP/Solid-OIDC verifier crate. The current slice covers the LDP verbs with content negotiation and conditional requests, an N3 Patch engine, and fail-closed DPoP-authenticated middleware; full WAC evaluation and the live sparq wiring are deferred, by its own list.

sparq is a from-scratch RDF triplestore and SPARQL engine in Rust: dictionary-encoded with six sorted permutation indexes, parallel execution, RDFS/OWL-RL/N3 inference, an out-of-core memory-mapped mode with a compressed on-disk format, a WebAssembly build, and a W3C-conformant HTTP server. Its own status line is “experimental research engine”: the API is unstable and SPARQL SERVICE federation is unimplemented. Against the full W3C SPARQL suites it accounts for all 1,229 tests — 1,225 pass, zero fail, zero skips, plus four documented divergences where it argues the suite’s expected files are wrong against the spec (rationale published in its conformance report) — and it passes 100% of the W3C Update suite, with an opt-in SHACL Core crate at 100% of the core suite. Its benchmark tables report it ahead of QLever on every compute benchmark run so far, published together with methodology and honesty notes (the synthetic dataset favours simple joins; full multi-billion-triple validation is pending bigger hardware) — the claims are its own, reproducible from its bench records.

Its role in this stack is access-controlled query: the opt-in sparq-solid crate models pods as named-graph-per-document, evaluates WAC/ACP as N3 rules into a queryable authorization view, and filters SPARQL per (WebID, client) session through a zero-copy dataset view, fail-closed. That is the engine-side counterpart of the Access-Controlled SPARQL Query specification below (§5) — and the direction solid-server-rs is built around.

The applications exist to prove the data-centric claim: independent apps reading and writing the same pod-hosted data under the same access-control regime. These are deployed and reachable today:

Behind those sits the pod-app fleet — eight repos (pod-mail, pod-music, pod-photos, pod-drive, pod-money, pod-health, pod-docs, pod-chat) building typed RDF data layers per domain, several with React views. All carry the same honest banner: experimental, AI-agent-generated, under active development, not production-hardened — and none has a public deployment yet; they are linked by repo, not by URL.

A second pattern is the OSS fork: take a real, loved open-source app and move its data to a pod the user controls while the app keeps its UX. Five working forks exist in the repos — linkding (bookmarks), Excalidraw (whiteboards), Elk (Mastodon social), Miniflux (RSS), and Actual (budgeting) — each with a self-contained Solid persistence layer on a dedicated Solid feature branch. None of the five is publicly deployed; they are working forks, not hosted services.

All of these are unofficial drafts — none is an adopted W3C or Solid Community Group work item; each states its own standing in its Status section:

• lws-spec (JLWS) — an explicitly labelled experiment: an AI-authored, clean-slate re-write of Linked Web Storage as a wire-compatible superset of the LWS Working Draft, diverging only on identified gaps with every divergence registered, plus an opt-in RDF content-transformation profile. It ships 150 language-neutral conformance test vectors (spec-derived — no reference implementation exists yet, and it says so) and machine-readable normative-statement companions (195 + 47 requirements). Not a W3C deliverable, and not a position of the LWS Working Group.
• Access-Controlled SPARQL Query over a Solid Pod (solid-sparql-query) — a read-only SPARQL endpoint answering over exactly the subset of a pod the authenticated agent may read: a new read interface over Solid’s existing authorization, not a new authorization model. Editor’s Draft written with every design call resolved and recorded; contribution to the Solid CG is the stated next step.
• dpop-sk-spec — a negotiated, optional fast path that keeps proof-of-possession while amortizing DPoP’s per-request signature verification into per-request HMAC message signatures. Its own Status: no implementations exist — the document deliberately precedes code.
• solid-webauthn-reauth-spec — redirect-free WebAuthn (passkey) re-authentication for Solid-OIDC via RFC 8693 token exchange. Implementation-first: its normative requirements are the proven wire contract of two reference implementations.
• a2a-rdf-extension — an extension to the Linux Foundation Agent2Agent protocol (via A2A’s own extension mechanism): negotiate once in natural language, then crystallise the routine into a hash-pinned protocol document whose body is a SHACL shape. Reference codec: @jeswr/solid-a2a.
• agentic-solid-note + agentic-solid-conformance — the umbrella architecture Note (“a map, not a spec” — wholly informative, with an honest per-component maturity table) and the shared conformance suite: 58 golden test vectors, extracted from pinned reference-implementation commits, that an independent implementation must reproduce.

The machine-readable layer of this catalogue — one checkable statement per normative requirement, wired to test vectors — is inventoried at Solid Spec Companions.

All TypeScript, all public under github.com/jeswr, all explicitly experimental — not production-hardened, installable from GitHub: