Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Re-claim delegations during client setup #644

Merged
merged 2 commits into from
Oct 7, 2024
Merged

Conversation

Peeja
Copy link
Member

@Peeja Peeja commented Oct 3, 2024

The rest of storacha/project-tracking#125. This along with generating the space delegations on the fly during access/claim will make new spaces appear on the page without logging out.


If the client is restored from local storage, it may be out of date. This fetches the latest delegations from the server and updates the client. This makes loading the client from local storage a stale-while-revalidate operation.

If the client is restored from local storage, it may be out of date.
This fetches the latest delegations from the server and updates the
client. This makes loading the client from local storage a
stale-while-revalidate operation.
Copy link
Member

@fforbeck fforbeck left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me!

@Peeja Peeja merged commit 83cc125 into main Oct 7, 2024
2 checks passed
@Peeja Peeja deleted the refresh-spaces branch October 7, 2024 21:49
Peeja added a commit to storacha/w3up that referenced this pull request Oct 7, 2024
The bulk of the work for
storacha/project-tracking#125.

This together with [`w3ui` calling `access/claim` on page
load](storacha/w3ui#644) will make new spaces
appear on the page without logging out.

---

## The Strategy

* On `access/confirm`, where we previously created a `*`/`ucan:*`
delegation with proofs for each space, we now create one with no proofs.
This delegation technically provides no capability, but serves as a
signal in `access/claim`.
* During `access/claim`, we look for the Agent's `*`/`ucan:*`
delegations in the store, and translate them on the fly into ones
containing proofs for the relevant spaces. This is legitimate, because
`*`/`ucan:*` means the Agent has been granted access to anything the
Account can do, it just doesn't have the proofs that Account can do
anything yet. We're just putting 2 and 2 together.

## Remaining

* [x] We don't validate the `*`/`ucan:*` delegation before recreating
it. If `access/confirm` doesn't create an attestation, `access/claim`
will still happily make one for its new delegation. That's a (minor?)
security issue. If the delegation is in our store, we can probably trust
it, but better to care about the attestation.
* [x] Tests for all of this.

---------

Co-authored-by: Alan Shaw <alan@storacha.network>
Peeja pushed a commit that referenced this pull request Oct 22, 2024
🤖 I have created a release *beep* *boop*
---


##
[2.5.0](react-v2.4.0...react-v2.5.0)
(2024-10-07)


### Features

* Re-`claim` delegations during client setup
([#644](#644))
([83cc125](83cc125))

---
This PR was generated with [Release
Please](https://github.com/googleapis/release-please). See
[documentation](https://github.com/googleapis/release-please#release-please).

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Peeja pushed a commit to storacha/upload-service that referenced this pull request Jan 29, 2025
🤖 I have created a release *beep* *boop*
---


##
[2.5.0](storacha/w3ui@react-v2.4.0...react-v2.5.0)
(2024-10-07)


### Features

* Re-`claim` delegations during client setup
([storacha#644](storacha/w3ui#644))
([7d34281](storacha/w3ui@7d34281))

---
This PR was generated with [Release
Please](https://github.com/googleapis/release-please). See
[documentation](https://github.com/googleapis/release-please#release-please).

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants