[proposed spec change] container should list acl docs

[michielbdejong]

This is something we're experimenting with in IPS, but there are no plans (yet) to implement this same feature in NSS. Documenting it here as such.

Do not merge unless NSS also implements this.

[RubenVerborgh]

Do not merge unless NSS also implements this.

That's not the blocker. NSS should not be the reference implementation.

[michielbdejong]

What matters is what apps expect.

[jeff-zucker]

May I ask if anyone has a guess at how long it will be before this change is implemented in NSS? I ask because @Otto-AA, @bourgeoa and I are in the middle of revising solid-file-client to have an option to include .acl and .meta resources in Container listings and in various delete and copy methods. My guess is we should implement it and expect it to be redundant in the future but if y'all are going to implement this on the server soonish, that would change our thinking.

[acoburn]

I think we should clarify whether ACL documents are LDP-contained (ldp:contains) or whether there is some other relationship involved here: I think we are conflating LDP semantics with ACL semantics. We should also have a discussion about whether the shape of the resulting Graph connects a container directly to all of the ACLs for the contained resources:

<container> ldp:contains <child_resource>, <other_child_resource> ;
       acl:someAclProp <child_resource.acl>, <other_child_resource.acl> .

Or whether the graph structure connects these ACLs from the resources themselves (rather than from the parent):

<container> ldp:contains <child_resource>, <other_child_resource> ;
<child_resource> acl:someAclProp <child_resource.acl> ;
<other_child_resource> acl:someAclProp <other_child_resource.acl> .

There are other ways to get this information about "contained" ACLs, particularly with Prefer headers, which might be a better (or more general) way to go about this.

[RubenVerborgh]

Since we define ACLs as documents, I believe they should be treated as such for all purposes. Their only special behaviors are 1) they define ACLs 2) reading/appending/writing requires Control permissions.

If we can Read a container, we see all files, even those we cannot Read. I believe we should thus also see files we cannot Control.

[RubenVerborgh]

This issue made me realize that deleting ACL documents likely requires separate permissions: https://github.com/solid/solid-spec/issues/196 Here, the question is about viewing.

(Also shows that it is likely not a good idea to have a separate WebACL repository, since issues like these span both.)

[acoburn]

I agree that ACLs are documents. I also agree that they are LDP resources. What I think we should discuss is the relationship expressed about those documents. At present, the WAC specification defines the relationship via a link header and rel="acl" (n.b. there is ongoing discussion to change to an IRI). That, I think, would be the appropriate predicate to express such a listing of ACL documents. As it is, those ACL documents are not created via LDP means (does one POST to an ldp:RDFSource to create an ACL document for that resource?) There are also implications for direct and indirect containers if ldp:contains is the semantic of relationship.

[RubenVerborgh]

What I think we should discuss is the relationship expressed about those documents.

relationships, plural. They can be contains and acl at the same time.

[michielbdejong]

@jeff-zucker @Otto-AA @bourgeoa great, that's important information. My motivation to delay this is that I don't want to break apps, but if your apps need it, then that's a good enough reason to do the opposite. :)

Is solid-file-client also what's used in https://solid-filemanager.solid.community/public/nightly/?

In terms of timeline, if we can conclude that this change is the correction of a mistake, then we can approve it and get it implemented in both server implementations in about two weeks.

@megoth @Vinnl this would also affect the mashlib databrowser, so please make your voice heard if this change would cause you trouble.

One thing I would suggest is we mark ACL docs as such in the listing, using the 'extra metadata' mechanism from https://github.com/solid/solid-spec/blob/master/api-rest.md#streams. That way, it will be easy for your apps to filter out ACL docs in situation where you want to display them differently or not at all.

[Otto-AA]

great, that's important information. My motivation to delay this is that I don't want to break apps, but if your apps need it, then that's a good enough reason to do the opposite. :)

I don't think that solid-file-client needs this change, it would make some things easier and a bit safer (in particular deleting/copying/moving entire folders) though. We would just like to know if or when to expect this, as it has implications on how we implement some of our methods.

Is solid-file-client also what's used in https://solid-filemanager.solid.community/public/nightly/?

No, solid-filemanager only relies on solid-auth-client for this. I intend to switch to the new solid-file-client when it is available, but I guess that is not relevant for this discussion here.

Would this also mean that .meta files are in the standard container listing? Or is this a different topic?

[Vinnl]

I don't see specifically how this could break mashlib (but @megoth do doublecheck), but would appreciate a ping once it's implement to verify.

[megoth]

SharingPane does not work on .acl-files directly, so viewing an ACL-file in the data browser (aka mashlib) would probably be a bit weird (I would argue that people would think they could manage sharing directly by focusing on the ACL file). There are probably some unforeseen consequences of allowing it to inspected directly, but nothing I don't think we can fix somewhat quickly.