Handling Capability URLs

[csarven]

If any, what kind of Capability URLs ( https://www.w3.org/TR/capability-urls/ ) should be supported and how?

[elf-pavlik]

I think solid already has a way to use capability url approach. If resource has public read (or read-write) acl but parent container doesn't have public read, url of that public resource acts as capability url for it. It works as long as that url got created using non guessable string.

I wonder if we need to support other use cases, for example having multiple URLs for the same resource, where each of those URLs could have their own distinct ACL. In that case access to the resource would depend on which URL gets used.

[kjetilk]

I think we should be very careful about them, but I think that we might need them for stuff like recovery mechanisms and confirmation of potentially harmful actions (like, notify a user to confirm that they actually want to do rm -rf.

[elf-pavlik]

I don't understand your rm -rf example.

[kjetilk]

I don't understand your rm -rf example.

It means recursive delete of everything that you had write or control access to. Basically delete the whole tree... :-)

[elf-pavlik]

My apologies I didn't make my question clear. I do understand rm -rf command, what I don't understand: What role capability url would play in executing equivalent of rm -rf? & Do we even consider specifying equivalent of rm -rf for solid storage?

[kjetilk]

My apologies I didn't make my question clear. I do understand rm -rf command, what I don't understand: What role capability url would play in executing equivalent of rm -rf? & Do we even consider specifying equivalent of rm -rf for solid storage?

Ah, OK. Yes, recursive delete has been up many times. It has an issue open in #132. We considered it already for FPWD, see #41, but since it is a dangerous operation, we decided to postpone it.

I imagine we could have a mechanism that sends a notification of some sort, so that whoever is the right party to confirm gets a chance to confirm.

[elf-pavlik]

I think understand, such notification (maybe sent by email or solid inbox) with confirmation request could include a link to some web form where user would give explicit consent and HTTP POST that form. Since such destructive operation shouldn't get triggered by HTTP GET request and user most likely have to authenticate to express such consent I still don't see need for using capability url.

[csarven]

I think dealing with notifications for this use case may be a bit too heavy duty. In what application or operating system do we ever get "notified" about attempts to delete a container or folder? I can understand the case for notifications when deleting an account (or WebID or anything of high significance) as a confirmation step, but not for general use.