proposal: add services-core and react-services packages to encapsulate upload/access service configuration

[travis]

I started trying to write a ServicesContext that can optionally be configured to point w3ui components at staging, production or another branch. I realized this probably needs to be done in its own set of packages (one core, and one for each framework we support).

I'll probably tweak some typing in this process (ie, split the two slightly different things currently called ServiceConfig into UploadServiceConfig and AccessServiceConfig)

@alanshaw just want to make sure you don't have something in process around this - happy to expand a bit more on what I'm thinking if that'd be helpful

[jchris]

Is it possible to hoist this into the w3up-client layer?

[travis]

half of it yep! per discussion this morning with @gobengo @alanshaw @hugomrdias @Gozala it sounds like the package that actually encapsulates the service details should be outside this repository entirely so that other services and libraries can all depend on it as well.

we will still need to implement framework specific configuration components (ie, Providers in React, something else in other frameworks) and those should probably still be in their own package, worth leaving this issue open for that

[gobengo]

IMO we may not really need this.
esp after storacha/w3up#325 (comment)
Insofar as the 'services' package would contain ucanto connection endpoints and ucan aud principal IDs that will respond to w3protocol caps, I think after that issue no one will even need those anymore.

They'll just need to know whether they are trying to send invocations to did:web:web3.storage or did:web:staging.web3.storage, and they can resolve those URIs using http, maybe follow a link or two, to get to a ucanto http endpoint (and the service principal is the did:web they already have).

[travis]

oh that will definitely make this simpler - I thiiiink we'll still want a package that provides affordances for easily changing which service the w3ui components are using (ie, lets you override which DID the {Upload|UploadsList|Keyring}Provider tries to send invocations to) but I think it will be pretty basic and possibly not even needed once the proposal you linked is implemented.