How to check Solid compatibility yourself, with tools we don't control

Do not take our word for any of it. Compatibility is the one property a vendor should never be the source of, and every check below is one you run, with software that is not ours.

Check one: raw HTTP, no tooling at all

Ask a pod for its root and read the headers.

$ curl -sI http://localhost:3000/
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"

If those are absent, nothing else matters. They are how a client discovers what it is talking to.

An uncreated path returns 404, so the headers came from a real container rather than a server answering everything the same way.

And the trap, which is ours: on our deployed host an unknown path returns 401, so casual probing there is misleading, why. Do this check against a pod you started yourself first, so you know what correct looks like.

Check two: a data browser nobody at Solidus can influence

A general-purpose pod browser exists, Penny, by Vincent Tunru, open source under AGPLv3 with its source on GitLab. It logs into a pod and lets you inspect the data, and modify it where your permissions allow.

Point it at any pod and see whether it can navigate the data. A client written by someone with no relationship to the server's operator either works or does not, and that answer is not ours to shade.

We did not run it against our deployed host this session, so this page recommends the check rather than reporting its result. Reporting a result we did not obtain is how estates like this one lose their credibility.

Check three: the client library, and why it is the weakest of the three

@inrupt/solid-client is the standard client library, and pointing it at a pod is a fair functional test.

It is also the library our own front end uses. So if we and the library shared a wrong assumption about the protocol, this check would not catch it, the same lens on both sides. A test that shares a dependency with the thing under test is weaker than one that does not, and we would rather say that than let the check look stronger than it is.

Use it. Do not stop at it.

Check four: the conformance harness, which is the actual bar

The Solid community maintains a conformance test harness. It links test cases to the specification's own requirements, tracks their level, must, should, may, and reports how much of the specification the suite covers, in EARL, a machine-readable evaluation vocabulary.

It needs two accounts on the server under test, because the interesting questions are about how one agent's data behaves toward another. What it actually tests, in detail.

We have not run it against our deployed instance, and our own acceptance note says a pass cannot be self-asserted: a third party interoperating is the bar. So the honest status is: not run, no claim, and no implied failure either.

What our own choices tell you, honestly weighted

Our front end talks to the pod through a third-party client library rather than a bespoke API of ours. That is a weak positive: the storage surface is exercised by code we did not write, so it cannot have drifted into something only our own client understands.