Yes, if you compare remoteStorage with Solid, the two big differences are really:
- Solid has ACLs
- Solid has a deeper connection with RDF
The way Web Access Control works is that it mentions the WebID of the person who gets access to a certain file, folder, or folder tree. It then uses OpenID Connect and proof-of-possession tokens to allow an app to prove that it acts on behalf of the WebID that is listed in the ACL. We could do the same with webfinger addresses.
However, even in the Solid protocol, we see the downsides of having such a more complex part in the spec: the latest version of Solid says that servers should either implement WAC or ACP (Access Controll Policies) which is a competing ACL system. The main reason some people prefer ACP over WAC as that it allow them to define not only ALLOW rules but also DENY rules, and that these DENY rules can not be overruled in subfolders.
The other issue with both WAC and ACP is that it quickly becomes infeasible to express access grants in terms of access to specific files and folders. So if you look at Solid Application Interoperability (SAI), which is basically their equivalent of our remoteStorage modules, it bypasses both WAC and ACP altogether, and grants access based on shape trees that define what type of data is inside a given file, rather than on a per-resource basis.
So ACLs as they have been explored in Solid with WAC and ACP give resource-location-based access control, but what you probably want is some sort of semantic access control. Even so, you could of course have server-wide ACLs that refer to shape trees instead of referring to specific folders. And maybe we can do something like that, in parallel with how SAI evolves in the Solid project.
Another side note, if you think about data that can move around freely, as is often a requirement in data portability projects, linking access control to specific servers is probably not the right paradigm. We ran into that with the Federated Timesheets project (Federated Timesheets Community Group) and so maybe the solution is to package the data and the ACLs about it into one transportable container, but then we have to trust all servers where this data ends up to actually apply the ACLs correctly, and often the devices to which data is allowed to move should also be described there in a machine-readable way, alongside the information about which user is actually allowed to see the data.
In local-first paradigms like “Live Data” (see m-ld.org) and “Liquid Data” (see blogpost that I haven’t written yet, Liquid Data · Issue #21 · federatedbookkeeping/task-tracking · GitHub) it doesn’t even mean anything anymore to have “write access”, since it’s always allowed to write changes to your own local copy, and whether or not it’s allow to then sync that change to a remote node is sometimes not even a synchronous or deterministic decision.