Command to produce key and delegation for CI

[olizilla]

There are a few too many steps to setting up a delegation for an ephemeral environment.

What if we wrap it up as single command to create a key and delegation, and upload the delegation to w3s.

$ w3 delegation create --ci

signing key # 🔐 secret ************************************************************
# hit enter to reveal

signing key # 🔐 secret MgCZ3QPOHYno7UTitT7ZX7rKj2z/hUDtFqnQt7kzDs7G0NO0BE4YA4HL9o1QveL+ulIyypVHrKVntlFcP0Tix0crdNGI=
# keep it safe. it wont' be shown again.
# set it as W3_PRINCIPAL in the env in your ephemeral environment.
# hit enter to continue

delegation url # 🌍 public
https://bagb...ipfs.w3s.link
# permits the signing key to store/add and upload/add to web3.storage
# copy the url and provide it as a param to `w3 up`
# done!

then in an ephemeral environment like CI we let folks pass in all the state to the command

# set the signing key in env
$ W3_PRINCIPAL=**** # MgCZ3QPOHY...

# pass in delegation to use for the upload
$ w3 up --proof https://bagb...ipfs.w3s.link ./my/cool/site
⁂ uploaded 10 files

w3cli already lets us set the signing key via the W3_PRINCIPAL env var, the proposal is to allow users to provide a --proof flag with a url to a delegation to use for this operation.

This is how the new golang cli works today, and we could use that in the ephemeral env, which would make it easier for folks in environments where they dont want to or cant install the latest version of nodejs

note: passing it as a url implies it the command should fetch the delegation, and use the space DID that is specified in the delegation for the current operation.

how this works today

you have to pick out the did from the key generation, and create a delegation for it with the right capabilities, and then basee64 the car bytes so they survive being passed around as an string env var...

# make the keypair by running a commnad `ucan-key` from npm
$ npx ucan-key ed
# did:key:z6MkuQ2oEKUZzkKmWp3WWUi3WA7AMB9nTqQHz3n7ZqVfYjMf
MgCaQHJP9UXljiYf3q0ndDjrj/9kvJ3nLc2v1c0yS80Gf5O0B3guVFXZh3i4/VvtHUJpAfIByon/Icqa7cjASbybfSU4=

# create the delegation, use the did from above.
$ w3 delegation create -c 'store/add' -c 'upload/add' \ did:key:z6MkuQ2oEKUZzkKmWp3WWUi3WA7AMB9nTqQHz3n7ZqVfYjMf | base64
# long screed of base64 encoded CAR bytes to copy anb paste

# copy the space did
$ w3 space info
      DID: did:key:z6MkgAmfxiYjZFLmkGMCJ3xVNBWMZtyX5pCTzBQUJt2Xx2Vn
Providers: did:web:web3.storage

on the ci side, you have to write custom code (!?) or do something like this (untested conjecture, ymmv)

# set the signing key in env
$ W3_PRINCIPAL=**** # MgCZ3QPOHY...
$ W3_PROOF=**** # long screed of base64 encoded CAR bytes

# turn the base64 string into a file
$ echo "$W3_PROOF"| base64 --decode > proof.ucan

# import the delegation (and set it as the current space?)
$ w3 space add ./proof.ucan

$ w3 up ./my/cool/site

other options considered

What's not being proposed?

coupons

w3cli allows a user to create a coupon for another user. This allows the recipient to provision a space and have the coupon creator be pay the bill for that space.

In the case of a CI environment you want to define the space for the robot to add things to rather than have it create a new space each time.

w3 coupon create did:... - That can be used to create delegation and pack it as a redeemable coupon.
#123

w3 space provision --coupon https://gozala.io/coupon - That can be used to provision space with pre-arranged coupon

support base64 encoded proofs

Explored in #122 but i don't love it.

the string should probably be multibase encoded rather than raw base64. working with an ipfs url for the delegation seems nicer than a long base encoded string.

[olizilla]

I want to streamline this process now so I can package it up as the new version of the add-to-web3 github action. With this the action would just be a single call to w3cli (or the go version) and some good docs and defaults.

[olizilla]

This could be simpler and just show you the signing key, but the proposal uses the w3 space create flow as the template. note: that flow uses mnemonic words, but we dont yet support those as the value for the W3_PRINCIPAL env var, so we dont do that here

...which is intersesting, and maybe we shoud be consistent about that and support setting the principle from a mnemonic.

...but also it seems like the space recovery command that would import from mnemonic is missing in w3cli today! w3 can space recover is listed in the readme but it's not exposed as a command.

[alanshaw]

As discussed:

• I'd have a separate command to generate a key
• Store/retrieve on IPFS feels weird to me
• Would be beneficial for w3 delegation create to have --base64 option to output as (multibase encoded) base64
• Would be beneficial for w3 up to have a --proof option that can take a base64 encoded proof or file path (which would nicely echo go-w3up CLI)
• Sugar command is great, but I'd maybe have a separate command for it (rather than a --ci option to w3 delegation create) since the output is very different when passed

[olizilla]

@Gozala plz may i have your thoughts on this too?