Anchoring permissions on a chain, versus a server enforcing an ACL
Pod does not anchor access control on a chain. A permission here is a small document beside the resource, and a server reads it and decides. That is the whole mechanism, it is Solid's design, and saying so plainly is the point of this page.
Why this page exists
Because the opposite claim keeps appearing in our own internal documents, and it is wrong.
"On-chain access anchoring" sits on this product's list of things it may never claim, and it is on that list because several strategy papers assert it anyway. A private correction gets re-litigated every time somebody new reads one of those papers. A public one does not.
So: nothing on this surface writes a permission to a chain, reads one from a chain, or proves to anybody that a rule was enforced. If you find copy of ours that says otherwise, that copy is wrong.
What the on-chain version actually is
One platform builds it properly and deserves the credit.
It offers S3-compatible object storage where access policies, retention rules and monetization logic are enforced by smart contracts rather than by a central administration panel, and where storage actions including reads and permission changes are logged on-chain for auditability. Its own framing is the sharp one: provable governance rather than policy-by-assertion.
Read that phrase against what a pod does. A Web Access Control rule is policy-by-assertion. The server asserts it applied the rule, and you believe it or you do not.
The difference that matters
Both models can express "this agent may read this resource". They differ on what happens afterwards.
| on-chain policy | server-enforced ACL | |
|---|---|---|
| Where the rule lives | a contract | a document beside the resource |
| Who evaluates it | the network | the server |
| Can a third party verify it was applied | yes, from the log | no |
| Can the operator quietly not apply it | no | yes |
| Latency and cost of a change | a transaction | a write |
| Works without a chain | no | yes |
The third and fourth rows are the ones that go against us, and they are the same row twice. A pod's access control is worth exactly what the server running it is worth, and on our deployment that server is us.
What a server-enforced list gets in return
It is not a strictly worse design, and the trade is real.
Changing a permission is a write rather than a transaction, so it is instant and free. The rule sits next to the resource, so moving a pod moves its permissions. It needs no chain, no gas, no wallet, and it works on any Solid server anyone runs, including one on a laptop.
And it is granular in a way a coarse on-chain policy usually is not: four modes, per resource, per agent, evaluated on every request.
Those are the properties Solid optimised for, and Solid was not wrong to.
Where our version is weaker than the model it implements
Two admissions, both already made elsewhere and both belonging here.
Our interface exposes two of the four modes. Append cannot be granted on its own, and the re-granting mode is never handed out.
And a grant carries no purpose, no scope and no expiry, with the share timestamp left empty in our own code. An on-chain policy with retention rules attached is expressing something our version has no field for.
What would have to be true for us to claim the on-chain version
A permission written to a chain, evaluated by something other than our server, and a log a stranger could read to check that a rule was applied.
None of the three exists. None is scheduled. There is no design document for it beyond the strategy papers that already assert it as done, which is the problem rather than the plan.