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

Implement w3access and w3session in access-client #395

Closed
Tracked by #220
alanshaw opened this issue Jan 25, 2023 · 5 comments · Fixed by #433
Closed
Tracked by #220

Implement w3access and w3session in access-client #395

alanshaw opened this issue Jan 25, 2023 · 5 comments · Fixed by #433
Assignees
Milestone

Comments

@alanshaw alanshaw added this to the w3up phase 2 milestone Jan 25, 2023
@alanshaw alanshaw self-assigned this Jan 25, 2023
@alanshaw alanshaw mentioned this issue Jan 25, 2023
95 tasks
@gobengo
Copy link
Contributor

gobengo commented Jan 31, 2023

@alanshaw are you blocked on this until resolution of

?

If so, is there one of those that would be most helpful to do focus on before the other?

@alanshaw
Copy link
Member Author

AFAIK these are not blocking - can be added later

@gobengo
Copy link
Contributor

gobengo commented Feb 1, 2023

ok. I'm still diving in, but I think you might want access/delegate implemented to fit into AccessClient#registerSpace(email) if we remove the voucher/claim handlers that it currently uses, which @hugomrdias and I briefly discussed doing today, but obv we won't do any sooner than until #393 is resolved

@gobengo
Copy link
Contributor

gobengo commented Feb 7, 2023

started PR over here that would unblock sending access/delegate invocation without error #427

@gobengo
Copy link
Contributor

gobengo commented Feb 23, 2023

use case: storacha/w3cli#46

@travis travis linked a pull request Mar 17, 2023 that will close this issue
11 tasks
travis added a commit that referenced this issue Mar 17, 2023
With this PR we're able to use two different devices on behalf of a
single account identified by an email address.

An agent (ie, a device like w3console or w3cli) can now:

1) use `access/authorize` to trigger an email verification flow that
will give them delegations to act on behalf of an account
2) create a space locally
3) add a storage provider to that space with `provider/add`
4) delegate capabilities to the account they are authorized as that
permit the account to delegate all capabilities on those spaces to other
agents - in other words, create spaces and assign all "permissions" on
those spaces to their account
5) upload data to the space

A second agent (ie, another device) can then:
1) use `access/authorize` to trigger an email verification flow that
will give them delegations to act on behalf of the same account
2) get a list of spaces they can store data in, which includes the space
created on the first device
3) upload data to the space

This PR also contains various refactoring of the `Agent` class to
minimize its responsibilities and move in the direction of letting user
agents take responsibility for state storage.

refs #395

* [x] setup tests for access-client agent + access-api
* [x] simple test agent createSpace
* [x] @gobengo test agent authorize happy path
#535
* [x] @gobengo upgrade to ucanto 6.2
#541
* [x] @travis ensure what's proposed here can work in w3up-client, w3ui,
w3console
* [x] upgrade this branch to `@ucanto/transport@5.1.1` after
storacha/ucanto#261
* [x] minimize new public api surface area on access-client Agent
* [x] (e.g. `sessionProof`)
https://github.com/web3-storage/w3protocol/pull/545/files
* [x] `sessionPrincipal`
#546
* [x] review comments
* [x] `authorize` should access/claim `with=did:mailto:...`
https://github.com/web3-storage/w3protocol/pull/556/files#

---------

Co-authored-by: Travis Vachon <travis.vachon@gmail.com>
Co-authored-by: Benjamin Goering <171782+gobengo@users.noreply.github.com>
Co-authored-by: Irakli Gozalishvili <contact@gozala.io>
gobengo added a commit that referenced this issue Apr 11, 2023
With this PR we're able to use two different devices on behalf of a
single account identified by an email address.

An agent (ie, a device like w3console or w3cli) can now:

1) use `access/authorize` to trigger an email verification flow that
will give them delegations to act on behalf of an account
2) create a space locally
3) add a storage provider to that space with `provider/add`
4) delegate capabilities to the account they are authorized as that
permit the account to delegate all capabilities on those spaces to other
agents - in other words, create spaces and assign all "permissions" on
those spaces to their account
5) upload data to the space

A second agent (ie, another device) can then:
1) use `access/authorize` to trigger an email verification flow that
will give them delegations to act on behalf of the same account
2) get a list of spaces they can store data in, which includes the space
created on the first device
3) upload data to the space

This PR also contains various refactoring of the `Agent` class to
minimize its responsibilities and move in the direction of letting user
agents take responsibility for state storage.

refs #395

* [x] setup tests for access-client agent + access-api
* [x] simple test agent createSpace
* [x] @gobengo test agent authorize happy path
#535
* [x] @gobengo upgrade to ucanto 6.2
#541
* [x] @travis ensure what's proposed here can work in w3up-client, w3ui,
w3console
* [x] upgrade this branch to `@ucanto/transport@5.1.1` after
storacha/ucanto#261
* [x] minimize new public api surface area on access-client Agent
* [x] (e.g. `sessionProof`)
https://github.com/web3-storage/w3protocol/pull/545/files
* [x] `sessionPrincipal`
#546
* [x] review comments
* [x] `authorize` should access/claim `with=did:mailto:...`
https://github.com/web3-storage/w3protocol/pull/556/files#

---------

Co-authored-by: Travis Vachon <travis.vachon@gmail.com>
Co-authored-by: Benjamin Goering <171782+gobengo@users.noreply.github.com>
Co-authored-by: Irakli Gozalishvili <contact@gozala.io>
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 a pull request may close this issue.

4 participants