storacha-network / w3up

⁂ w3up protocol implementation
https://github.com/storacha-network/specs
Other
54 stars 19 forks source link

feat!: allow invocation configuration to be generated on demand #1507

Closed alanshaw closed 2 months ago

alanshaw commented 2 months ago

Since the blob protocol landed, it's become harder to obtain a delegation to upload a specific CAR.

It was tricky before because of sharding, but assuming you created a CAR below the shard threshold, its easy enough to obtain a store/add delegation tied to the CAR CID.

With the blob protocol, we now generate an index, and blob/add that as well. It means we can't just create a CAR and delegate can: blob/add, nb: { link, size } for the CAR, because we also need to delegate blob/add for the index, but we don't know the index CID or it's size up front...

It's ok if the delegation is not restricted to the specific CAR, but for certain use cases it's necessary to delegate just what is needed.

This PR alters the client to allow invocation configuration to be generated on demand, when the proofs are required. This is a backwards compatible change.

So, for example instead of calling: uploadFile({ issuer, with, proofs }, file) you now call:

const configure = caps => {
  const proofs = []
  for (const { can, nb } of caps) {
    // decide if want to delegate and create delegation
    proofs.push(...)
  }
  if (!proofs.length) throw new Error('no proofs available')
  return { issuer, with, proofs }
}

uploadFile(configure, file)

...and configure will be called for each proof that is needed (blob/add, index/add and upload/add).

It means also that we no longer have to recommend folks to create a CAR, get the CID and then upload it, they can just use uploadFile and pass in the invocation config function to obtain the correct delegations when required.