MetaMask
Research and design "network" abstraction that can be used instead of network client
The network client is a bit too low-level to be used directly. When working with a network client, especially resolving a network client ID, you have to be aware that there are two types: an Infura network client and a custom network client. This bifurcation is necessary to have at some level because of the fact that we have two different middleware stacks (one designed for Infura RPC endpoints, one designed for everything else) and thus two kinds of network client configuration objects. However, if you just want to make a request to the network, you shouldn't have to care what kind of network it is, as we can expect that all networks feature the same JSON-RPC API. Also, if you want any information about the network, such as the native currency symbol or the nickname, you currently have to shoehorn extra properties into the network client configuration. This shouldn't be necessary, as the middleware doesn't care about them.
Consumers — in particular the DevEx team, who are running into problems with the current design while implementing multichain initiatives — would have a better time if instead of using a network client, they used an abstraction on top of it. We could call it "network", and it would essentially be the same as a network client now, except that the network client interface would be abstract, and network configuration would be allowed to hold user-provided properties.
The devil is in the details, of course, so this ticket is dedicated to understanding whether this plan is really feasible or not, and if so, how much work it would create.
Examples
This is a list of changes we've had to make which solve immediate problems but are ultimately undesirable and which we aim to fix with this proposal. Please add to this list as you find more examples!
- https://github.com/MetaMask/core/pull/2000/files#diff-02c32f437b122b5c71f0ac6bdf304cd22f6d4569c9c9b8ecbb711c11c98cd0d3R111
- https://github.com/MetaMask/core/pull/1794
Alternatively, we could use network configuration for built-in networks as well: https://github.com/MetaMask/core/issues/1279
We discussed adding a getNetworkConfiguration(networkClientId) action as a short-term fix, and consolidating setActiveNetwork and setProviderType. These two things should reduce the friction of dealing with these two types of networks.
Longer-term we discussed enhancing the custom network configuration/middleware to support Infura (as covered in #1279).
Tickets created: https://github.com/MetaMask/core/issues/2019 and https://github.com/MetaMask/core/issues/2020.
I will leave this ticket here in case it comes in handy later, but I will deprioritize it.