Read, write, append, control: the four permission modes in a pod

The four modes, plainly

Read, fetch the resource.
Write, change or delete it.
Append, add to it without being able to read it or overwrite what is there.
Control, change who else has access. The permission to hand out permissions.

Append is the one people miss, and it is the interesting one. It makes an inbox possible: a stranger can drop a message into your container without reading anything already in it. Write would let them read nothing but destroy everything; Read would let them see everything and add nothing. Append is neither, and no ordinary file-sharing UI has a word for it.

Control is the one people underestimate. Granting it hands over the ability to re-grant. It is closer to co-ownership than to sharing.

Where the rules live

A rule is itself a small piece of data sitting beside the resource it protects, naming which identifiers get which modes. There is no central permissions table, which is why moving a pod moves its permissions with it.

This is Solid's design, and it is a good one. Our contribution is that we run their server rather than reimplementing it.

What our interface actually does with those four

Read our own code rather than our marketing:

setAccess(resource, agent, { read, write })
  → { read: read, append: write, write: write }

Granting "write" through our interface always grants append as well. They move together. There is no way to express append-only (the mode that makes the inbox pattern work) through anything we have built.

And Control is never granted. It appears in our code exactly once: in the revoke path, where it is set to false along with everything else. We can take it away. We never hand it out.

So the honest statement is: four modes exist, our surface offers two, and one of the two we offer is a merge of two underlying modes. The server underneath supports all four. The limitation is ours.

The one place the coarseness is a good default

A public link grants read and nothing else, append and write are explicitly set to false rather than left to a default. A "share via link" that quietly allowed writes would be a bad surprise, and this one cannot.

Credit where it is due to our own code, which is otherwise the subject of this page's criticism.

We do not speak the vocabulary directly, and that is worth knowing

Our code calls the client library's access-system-agnostic API, not the access-control vocabulary itself. The library decides how to express a grant against whichever system the server runs.

Two consequences, and they cut opposite ways. It means we are insulated from the difference between the older model and the newer policy-based one, useful. It also means the exact rules written on your resources are the library's output, not something we author or audit, and we have not examined them resource by resource.

The test a stranger can run, and why the obvious half of it is worthless here

The lexicon suggests: request a protected resource without credentials, confirm you are refused, then request it with credentials and confirm access. The second half is the real test, and you can run it today on any Solid pod, including one that is not ours.

The first half proves nothing on this host. An unknown path here returns 401, exactly like a protected one, requests fall through to the storage server. / returns 200, so the host is up. A refusal therefore tells you nothing about whether the resource exists or whether any rule was consulted.

We are flagging that against our own suggested proof, because a test that passes whether or not the feature works is not a test.

What we are not going to say

We have not run our stack against the full test suite, and we do not describe it as conformant. Self-assertion is not the bar here, a third party checking interoperation is, and until that happens the accurate word is WAC-style.