w3up client rewrite

[hannahhoward]

User Value

User feedback suggests our client has following issues:

1. Having multiple clients is confusing and can introduce issues with dependency management.
2. Client API is not clear about which spaces are under which accounts and which accounts client has sessions with.
3. Stateful client is not a great fit for the stateless environments like lambdas or CI workflows.

In addition to user feedback we also observed that

1. Iterating on features across multiple clients introduces significant overhead.
2. We have lots of historical code based on decisions that are no longer relevant and that complicates code maintenance.

Hypothesis

By rewriting our clients into a single client with a coherent interface we will improve user experience and reduce overhead of new development.

Subtasks:

• Review Irakli's rollout plan #26

See also:

• Future API Sketch w3up#1156
• feat: unified client w3up#1306

[reidlw]

Per Irakli: Hope this week, worst case next week

[gobengo]

@Gozala IMO It's hard to test whether anyone really likes a rewrite or not if we frame it as a major version upgrade that has happened whether they like it or not. What if we release this as a new package like w3s-client instead of backwards-incompatible rewrite of w3up-client? Then we could run an experiment to validate this hypothesis in a way that doesn't require a major version bump of w3up-client, but also doesn't prevent one later (one sprint or so) either.

[reidlw]

@Gozala @gobengo -> just reading Ben's comment above, I actually am thinking a short explanation of release plan for this would make sense in the description of the issue (or child issue?) Probably worth being explicit and give us a chance to identify needs like docs, website updates, comms, etc. Even if we wanted to do a test with some limited subset of users first?

[reidlw]

@Gozala need to add a 'Reviewer DRI'?

[Peeja]

Per conversation with @hannahhoward, deprioritizing for now. (See also: Discord)

[Peeja]

While working on #123, I see that console has dependencies on a lot of internal bits:

• @web3-storage/access
• @web3-storage/capabilities
• @web3-storage/content-claims
• @web3-storage/data-segment
• @web3-storage/did-mailto

Since it already uses @w3ui/react, it should probably get to those through that, or not concern itself with those details at all. Notably, if the versions get out of sync, it can be a problem. They could be peer dependencies, but that would mean the application is responsible for bringing them all to @w3ui/react rather than @w3ui/react providing them itself.

Mentioned here because I assume it's analogous to how the newly reorganized client package should provide things to @w3ui/core and so on.