Discussion: EIP-1193

[alcuadrado]

As agreed at Devcon 5, I'm creating this issue to move the EIP-1193 discussion here. It's been fragmented in multiple places, making it hard for most people to follow it.

Link to the current version of the EIP: https://eips.ethereum.org/EIPS/eip-1193

Previous discussion channels

• Initial discussion in ethereum/interfaces
• Ethereum Magicians thread
• Ethereum Provider Ring Discord server (Note: Ping @alcuadrado if this link doesn't work)
• #1193 channel on the Ethereum JavaScript Community Discord server (Note: Ping @alcuadrado if this link doesn't work)

[alcuadrado]

Summary of Devcon 5 EIP-1193 meeting

Participants

This is an incomplete list of people/projects that participated. Please feel free to add yourself or others: @alcuadrado, @nivida, @davidmurdoch, @joshstevens19, @adrianmcli, @iurimatias, @ricmoo, @spalladino, @javier-tarazaga, @ylv-io, and members from Alchemy, Chainsafe, Metamask, and possibly more projects.

Format of the discussion

Initially, every member raised what they thought were the most important concerns to move the EIP forward. After that, we discussed most of them and proposed possible solutions.

List of concerns

1. EIP-1193 began as a spec on how to expose a provider in a dapp browser, but mutated into specifying its interface. It still depends on EIPs related to browser-specific stuff.

2. The way a provider is exposed (i.e. window.ethereum) only supports a single provider. This is in conflict with users installing multiple wallet extensions, and may be problematic with a multi-chain future.

3. The current provider implementations have different interfaces (i.e. send vs sendAsync).

4. There's no way to send batch requests in the current spec.

5. Some providers need open/connect and close/disconnect methods, and others don't.

6. How can a provider be known to be EIP-1193 compatible?

7. How can this EIP be extended in the future? How are those extensions going to be detected?

Proposed solutions

1. EIP-1193 will only focus on the provider's interface. How to expose in browser environments will be part of another document, possibly an RFC. Any dependency on browser-specific EIPs will be removed.

2. As this EIP won't dictate how to expose the provider, this item is outside of its scope.

3. Finalizing this EIP and adopting ti will fix it.

4. There was a short discussion about this. We concluded that we don't know what to do yet. It may be just an issue with the UI controlling the provider. If a sendBatch method is needed in the future, another EIP can extend this one.

5. We concluded that every provider should provide these methods (/cc @pedrouid ). It's up to the provider implementation to document if they need to be called or not. If a certain provider doesn't need them, it can implement them as no-ops.

6 and 7. Most of the time was spent discussing these items. We considered different approaches like not doing anything at all, imposing a certain class name, and many other techniques.

What we concluded is that providers would have a whitelist of the capabilities they offer. The most basic provider (i.e. HTTP-based provider) will have such a whitelist empty. More featureful providers will declare all of their extra features. For example, a websocket/polling-based provider that supports subscriptions, should declare that in the whitelist.

We analyzed the risk of this whitelist getting huge with time, but still decided to go with this approach. It's not clear that it will actually get huge, nor that this would even care.

We chose this approach over others, as it's more explicit and simpler.

Next steps

• @pedrouid do you want to adapt EIP-1193: Add close method #2261 so that it includes the open and close methods as described here?

• I will submit a PR removing any reference to browser-specific stuff.

• I will prepare a PR with the changes proposed in 6 & 7. We can discuss the details there.

(Disclaimer: I will probably do these things next week, as I have to get back to Argentina and will be super jet-lagged).

[nivida]

EIP-1193 will only focus on the provider's interface. How to expose in browser environments will be part of another document, possibly an RFC. Any dependency on browser-specific EIPs will be removed.

As a historical addition: We discussed always both and as @frozeman told me is this issue the source of this EIP.

The way a provider is exposed (i.e. window.ethereum) only supports a single provider. This is in conflict with users installing multiple wallet extensions, and may be problematic with a multi-chain future.
As this EIP won't dictate how to expose the provider, this item is outside of its scope.

Yes, same here I also think we should create a separate EIP which defines the injection of providers. This EIP should have a section about security concerns as well and should provide some possible solutions for doing it in a secure way. (probably MetaMask has some good inputs here for creating a RFC @danfinlay)

Required Sections:

• Defining of the window.ethereum object interface
  • window.ethereum.getProvider(..) -> Get provider for specific chain
  • window.ethereum.provider -> Get default provider selected by the user
  • ... what ever other property or method should exists on the window.ethereum object
• Security (SES, Realms Shim, Realm Proposal)

(we probably should have further discussion about the injection of providers in the related RFC PR)

There's no way to send batch requests in the current spec.

Discussed 2y ago here.

We concluded that every provider should provide these methods (/cc @pedrouid ). It's up to the provider implementation to document if they need to be called or not. If a certain provider doesn't need them, it can implement them as no-ops.

Agreed.

What we concluded is that providers would have a whitelist of the capabilities they offer. The most basic provider (i.e. HTTP-based provider) will have such a whitelist empty. More featureful providers will declare all of their extra features. For example, a websocket/polling-based provider that supports subscriptions, should declare that in the whitelist.

We analyzed the risk of this whitelist getting huge with time, but still decided to go with this approach. It's not clear that it will actually get huge, nor that this would even care.

We chose this approach over others, as it's more explicit and simpler.

Sounds good!

• But where exactly do we define and extend this whitelist?
• Is it allowed to have an object stored behind a capability key for getting some further configuration possibilities?

I would propose (as discussed at Devcon in Osaka) a method called getCapabilities:

export interface EIP1193 {
 // .... other methods
 getCapabilities(): Capabilities;
}

export interface Capabilities {
  [capability_key: string]: any;
}

[pedrouid]

Thanks @alcuadrado for sharing the summary of Devcon's meeting 🙏

I agree that open/close methods should be added with the ability to make them no-ops for certain providers which might not require them.

However we technically don't need the open method since EIP-1102 already specified a similar method enable which is now widely used.

I will update the #2261 to add the note for no-ops but other than that I don't see the need to have open if it will serve the same purpose for enable

Regarding all other points, I have no other objections and I'm glad we have reached consensus specially on point number 2. We should merge #2090 which includes related changes.

[axic]

As agreed at Devcon 5, I'm creating this issue to move the EIP-1193 discussion here. It's been fragmented in multiple places, making it hard for most people to follow it.

As a historical addition: We discussed always both and as @frozeman told me is this issue (ethereum/interfaces#16) the source of this EIP.

Interesting – the EIP itself lists https://ethereum-magicians.org/t/eip-1193-ethereum-provider-javascript-api/640 as the official forum.

In case there is an agreement to use this issue, can someone update the EIP as well as perhaps add links to the other two mentioned forums into a References section?

[frozeman]

Great to see this going back to GitHub issues. I find them better readable.

Where can I see the latest agreed version of this eip?

[rekmarks]

@pedrouid EIP-1102 states that ethereum.enable() is deprecated in favor of the eth_requestAccounts RPC method. What are your thoughts on that?

Starting within a release or two, the MetaMask inpage provider will support both. We believe that it would be too disruptive for dapp developers to remove enable anytime soon.

[alcuadrado]

Interesting – the EIP itself lists https://ethereum-magicians.org/t/eip-1193-ethereum-provider-javascript-api/640 as the official forum.

In case there is an agreement to use this issue, can someone update the EIP as well as perhaps add links to the other two mentioned forums into a References section?

I created #2419 to update the EIP

I agree that open/close methods should be added with the ability to make them no-ops for certain providers which might not require them.

However we technically don't need the open method since EIP-1102 already specified a similar method enable which is now widely used.

I will update the #2261 to add the note for no-ops but other than that I don't see the need to have open if it will serve the same purpose for enable

Completely agree with this. Thanks for updating #2261 !

• But where exactly do we define and extend this whitelist?

• Is it allowed to have an object stored behind a capability key for getting some further configuration possibilities?

I would propose a method called getCapabilities:

export interface EIP1193 {
 // .... other methods
 getCapabilities(): Capabilities;
}

export interface Capabilities {
  [capability_key: string]: any;
}

I'll explore different alternatives this week and post the results here or in a PR.

Starting within a release or two, the MetaMask inpage provider will support both. We believe that it would be too disruptive for dapp developers to remove enable anytime soon.

I agree with this. I wouldn't add enable to the EIP, but removing it from the actual implementations should be done with care.

[axic]

Since @alcuadrado seems to be very actively pursuing this EIP (perhaps even to Final status?), I'd suggest to consider adding him to the author list so he could automerge updates.

@frozeman @ryanio @marcgarreau @MaiaVictor what do you think?

[nivida]

@axic Sounds like a good idea. @alcuadrado took the lead for this EIP in the related meeting we had during Devcon.

[ryanio]

I am open to adding @alcuadrado to lead closing discussions to bring us to final, if I can get a +1 from another author in agreement. Thank you for taking the initiative.

[rekmarks]

Regarding open/close

I believe that an open method should be added to #2261.

As discussed, EIP 1102 has deprecated its enable method, and replaced it with send('eth_requestAccounts'). The point of this method is to do exactly what you'd expect: ask the user to expose their Ethereum account(s).

In #2261, close is described as: Provider connection can be closed using this method. I interpret this to mean that the provider will stop communicating with any Ethereum chains and possibly the wallet itself, and no longer accept any RPC requests.

The question then becomes, if you close a Provider connection, how do you reopen it?

I don't think these methods were considered with MetaMask in mind, but I'll use us as a concrete example. In MetaMask, even if you haven't "connected" in the sense of EIP 1102 (i.e. exposed any accounts), you can still request a bunch of RPC methods, such as net_version and eth_chainId. In addition, you can also check if e.g. MetaMask is unlocked. If we ever implemented close in any non-trivial sense, there'd be no way to explicitly re-open the connection. If we re-opened the connection implicitly, e.g. on an RPC request, then I don't see the point of closing the connection in the first place.

In short, I don't believe that close is useful without an open method in EIP 1193. I created a PR against #2261 with suggested changes here: pedrouid#4

I don't think this is the case, but if the desire is to enable the dapp to ask the user to stop exposing accounts, I believe that discussion should move to EIP 1102 or EIP 2255.

To be clear, MetaMask will support this EIP either way, and as things stand, we'll support close as a no-op.

cc: @alcuadrado @pedrouid

[wighawag]

I don't think this is the case, but if the desire is to enable the dapp to ask the user to stop exposing accounts, I believe that discussion should move to EIP 1102 or EIP 2255.

For me I always interpreted this way. The same way as other wbe3 provider allow you to logout.

This is useful for dapps that for example support both a builtin provider and web based one.
By allowing the user to "close" the builtin provider we can bring them back to the "wallet choice" screen. See my post here : https://ethereum-magicians.org/t/eip-1102-opt-in-provider-access/414/59?u=wighawag

As for a "close" as a way to block rpc request. I don't see the point. If an app do not want to send rpc request, it can simply not call them anymore.

Regarding "open", assuming this would be a call to be made for dapps that want to make rpc request, this would be a breaking change as now dapp would not be able to call eth_chainId to get it know what the wallet is currently pointing at.

[rekmarks]

By allowing the user to "close" the builtin provider we can bring them back to the "wallet choice" screen.

@wighawag I think that's a compelling use case, but IMO close is still under-specified and should have a corresponding open method. If close is intended as the complement to send('eth_requestAccounts'), then I don't understand why it's being added to EIP 1193, and I'd argue that its name is misleading.

The changes to the spec I've described are not breaking, because they remain optional.

As for a "close" as a way to block rpc request. I don't see the point. If an app do not want to send rpc request, it can simply not call them anymore.

Similarly, if a dapp doesn't want to use a particular provider, couldn't it also just ignore it?