UCAN and resources path discussion

@adamalton and @flea89 made a great doc outlining a bunch concerns around UCAN, resource path and DID.

The main topic here is that we couple the concept of root bucket with the user DID storage://<user-did> but it also goes deeper into others issues.

Please give it a read here https://hackmd.io/@adamalton/ByUEKhv-c and provide feedback please.

I already left some inline comments and also extracted some issues that we should work on.

When a user registers a DID, he is effectively reserving a namespace ( bucket key name ) so for this reason we might need to start requiring proof of ownership upon registration to avoid squatting. Right now we dont require this because if the user doesnt own the private key he cannot create a request UCAN for our service, so its safe.
For us to be able to allow delegated users to do any operation in the UI, we need to have the upload associated with the UCAN that uploaded it, and this user needs to prove he owns the private key for that UCAN in the UI to "unlock" things like list files etc. But that upload UCAN needs to include any future operations the user may do in UI.
Revocation needs a lot more research
Recovery is tricky because the bucket name is the DID, so we cant just allow the use to change to another DID and have access to the lost DID bucket.

/cc @mikeal @Gozala

storacha-network / specs