Use same did across access / upload API services

[Gozala]

I think having two different did's and endpoints clients need to interact with is incidental complexity we're pushing onto users, it seems that only reason we're dealing with this is because we run some code in CF and other in AWS, but perhaps we can hide that under the curtain ?

E.g. with ucanto forwarding delegations is fairly trivial, perhaps we should consider doing that ? In the future we could probably even remove need to run code on AWS.

I don't know what is best compromise here, but I do think we should not neglect this

Parts

• access service & client should use did:web:web3.storage #237
• upgrade upload-api @ucanto/* to 4.0.0 and @ipld/dag-ucan to 3.0.0 w3infra#63
• upload-api ucanto server has id.did() corresponding to env.DID when present w3infra#90

[Gozala]

We had a call today about this and I believe we came to following conclusion:

1. We should do it before we go into production.
2. We should not do it in phase 1 to keep things simple.
3. We will evaluate our options to do what makes most sense.

Then @olizilla had pretty cool suggestion, which was:

1. Why don't we use same keypair across two endpoints so they have same DID
2. Why don't we just add DNS route that simply resolves to AWS endpoint

If we do ☝️ we'll make our clients agnostic of changes we'll do in the future. Even if we decide to host all of the capabilities under the same route in the future, we'll just point that other DNS route to the same endpoint and old clients will continue to work as expected.

I think this seems like a small enough task that we can tackle sooner that later, without us having to change any of the code.

[gobengo]

Working toward milestone

• web3.storage platform DIDs
  • production: did:web:web3.storage
  • staging: did:web:staging.web3.storage
• access-api accepts invocations with aud=did:web:web3.storage
  • access service & client should use did:web:web3.storage #237
    • feat: access-api uses DID env variable when building its ucanto server id #275
  • configure access-api staging to have env.DID=did:web:staging.web3.storage
  • configure access-api production to have env.DID=did:web:web3.storage
• upload-api accepts invocations with aud=did:web:web3.storage
  • PR so upload-api uses env.DID for ucanto server id, if present
  • configure upload-api staging to have env.DID set

Future (not now)

• unify the ucanto http service URLs so clients don't have to manage one per w3 service, but instead just one per w3 platform environment (usually only 1 when env=production)

[gobengo]

I think this is done