Delegations UI

[hannahhoward]

As a Storacha user accessing an account in the console, I should be able to delegate access to a space to another Storacha account in the console.

Details:

• For now, delegations are 1/0 -- "space/*" for a given DID. We'll have a seperate ticket for more fine grained permissions
• For now, accounts that receive delegations will still need to have their own plan for storacha, even though the space isn't provisioned to that account (we'll create another ticket for granting console access without a plan)
• Leave revocations out for now
• Delegating access to the space should roughly follow the same flow as createRecovery, access/delegate, but with a different account email.

Acceptance criteria:

On the space detail UI, below the list of files (or perhaps to the side on sufficiently wide display), I should see a UI for delegating access. It should contain a list of email accounts I have delegated access to the space for, and a button to add a new delegation.

When I add a new account to a space, and that account logs into the console, the space will show up in their UI. (after https://github.com/storacha/project-tracking/issues/125 merges)

[alanshaw]

@hannahhoward is the intention that the delegation is stashed on the server by the issuer for the audience to claim? That's a very cool idea.

Where does the list of delegations you've made live? Are they just in localStorage/IndexedDB/what?

What if this sharing section was added to the "share" page that you get to via the link in the menu (see screenshot)?

[fforbeck]

@hannahhoward @alanshaw I'm thinking about updating the JS Client to expose a new method: shareSpace that we'll invoke from the console to handle the delegation logic. The nice thing about this is that it will be available to be consumed by the CLI as well. Do you have any objections to this approach?

[hannahhoward]

@fforbeck not really ... technically this is just the combo of "createRecovery" + call access/delegate capability, which is in the tutorial, so it's not inaccessible, but it's probably a nice convenience.

[hannahhoward]

@alanshaw yes, it goes to the server -- is there any reason you need any more than access/delegate + access/claim for this? It's the same flow as normal for your own space just the claimer is different than the delegator.

[hannahhoward]

Also @fforbeck UI wise I agree with Alan a share button makes more sense w/ a modal.

[alanshaw]

I think by default if you want to use the space you'll need some of these capabilities https://github.com/storacha/w3up/blob/e02ddf3696553b03f8d2f7316de0a99a9303a60f/packages/access-client/src/access.js#L322-L334

I agree control over the exact delegations should be future work but I think by default you'll need/want to delegate the following abilities for each space (resource/with):

• space/* - for uploading blobs
• upload/*- for registering uploads
• filecoin/* - for submitting to the filecoin pipeline
• access/* - for re-delegating access to other devices
• usage/* - for querying usage

[alanshaw]

@alanshaw yes, it goes to the server -- is there any reason you need any more than access/delegate + access/claim for this? It's the same flow as normal for your own space just the claimer is different than the delegator.

Yes that makes sense. I was wondering about the list of accounts you have delegated to though. Is this persisted outside of the agent store in the browser?

[fforbeck]

This is merged to the main branch and deployed to staging: https://www.loom.com/share/119d933569244e678fa3a899ea0d05ce?sid=0c9e8b2b-6178-44d8-996f-80ed058af35f