EIP-6963: Multi Injected Provider Discovery

pedrouid · May 1, 2023, 11:28am

Introducing a new pattern to discover multiple injected providers using window events to announce EIP-1193 providers in a two-communication standard between Ethereum libraries and Wallet peoviders.

NOTE: This EIP replaces the existing EIP5749

pedrouid · May 1, 2023, 12:28pm

What changes from EIP-5749?

EIP-6963 uses an event-based approach to discover multiple providers
EIP-6963 does not extend EIP-1193 with info but instead exposes it in parallel
EIP-6963 includes a local unique identifier and a global unique identifier for each provider
EIP-6963 does not include provider description to stay agnostic to localization
EIP-6963 supports any URI encoded image for icons (data, ipfs, http, etc)

SamWilsn · May 1, 2023, 8:27pm

Inspired by a discussion on the AllWalletDevs discord:

Is it possible for a dapp to access window.evmproviders before all wallets have had a chance to modify the array? If so, should this proposal also specify an event dapps can subscribe to? Something like:

// In the dapp:
window.addEventListener("evmprovider", () => ...);

// In the wallet's content script:
modifyEvmProviders();
window.dispatchEvent(new Event("evmprovider", ...));

pedrouid · May 11, 2023, 2:28pm

I’ve updated the EIP-6963 spec to use an event-based approach now

pedrouid · May 14, 2023, 9:19am

Reverted the “postMessage” back to “dispatchEvent” approach

Please read last comment on Github for context

github.com/ethereum/EIPs

Comment by pedrouid to Add EIP: Multi Injected Provider Interface (aka MIPI)

ethereum:master ← pedrouid:patch-16

**TLDR'** After doing some testing with both `postMessage` and `dispatchEvent`..…. I think the best solution is to revert to `dispatchEvent` _________ **PROBLEM** Using postMessage with the current spec will break as flagged by @bpierre (screenshot below) <img width="756" alt="Screenshot 2023-05-14 at 10 40 38" src="https://github.com/ethereum/EIPs/assets/10136079/e3cd4124-6d58-450c-833c-0783b85a9d8c"> ___________ **SOLUTION** The alternatives are the following: 1. use postMessage with a window map using uuid 2. use postMessage exclusively without EIP-1193 interface 3. revert to dispatchEvent instead of postMessage Option 1 with the window map using uuid is a simple solution to this problem but defies the whole purpose of postMessage since it will require wallet providers to have window access. If they have window access then they can also use dispatchEvent. Option 2 would require us to remove the dependency on EIP-1193 spec and instead make all providers use window.postMessage exclusively. IMHO this adds too much friction from both Ethereum libraries and Wallet providers to adapt Option 3 would simply replace postMessage with dispatchEvent which would immediately make this EIP feasible to be implemented with little to no breaking changes in both Ethereum libraries and Wallet providers (screenshot below) <img width="758" alt="Screenshot 2023-05-14 at 10 50 18" src="https://github.com/ethereum/EIPs/assets/10136079/e8b33538-a998-4247-8088-239ab659bcc5"> _______ **CONCLUSION** The positive impact that Option 3 has completely outweights the very low cost it has in terms of developer time in the community to adopt across multiple Ethereum libraries and Wallet providers

SamWilsn · May 15, 2023, 1:14pm

Is name in EIP6963ProviderInfo ever translated into other languages, or is it always in the native language of the wallet?

SamWilsn · May 15, 2023, 2:07pm

So you’re using events because they can pass arbitrary JavaScript objects instead of postMessage which can only pass transferable objects?

I feel pretty strongly that we should use postMessage, perhaps transferring a MessagePort to handle further communication.

I understand that this is a departure from how EIP-1193 works (which requires a request method), but using postMessage really does open up a lot of options for wallet design, some of which don’t even need special permissions to run.

You can implement an EIP-1193 compatible provider on top of a MessageChannel like so:

class PortProvider implements ethers.Eip1193Provider {
    private port: MessagePort;

    constructor(port: MessagePort) {
        this.port = port;
    }

    public request(request: Request): Promise<any> {
        return new Promise((res, rej) => {
            const channel = new MessageChannel();
            channel.port1.onmessage = (evt) => res(evt.data);
            channel.port1.onmessageerror = (evt) => rej(evt.data);
            this.port.postMessage(request, "*", [channel.port2]);
        });
    }
}

For the rest of the example, you can take a look at Wallet-Test-Framework’s dapp and fake chain halves.

rekmarks · May 17, 2023, 5:52am

Speaking for MetaMask, we’re more amenable to this proposal and are reviewing it internally. Thanks @pedrouid for driving, and to everyone who contributed!

On the postMessage vs. dispatchEvent discussion, we believe that dispatchEvent is a good solution for the specific problem this EIP aims to solve, i.e. window.ethereum clobbering. We also agree that there’s a need for a more generic messaging protocol, however:

This EIP does not seem like the right place for it.
If we’re talking browser extensions, such a protocol should use the externally_connectable permission, which recently became possible after the Chrome team fixed this bug originally filed by @MicahZoltu.

pedrouid · May 17, 2023, 7:11am

I agree with @rekmarks feedback that the need for a more generalized communication protocol is important but this EIP is not the place for this as it only focuses on EIP-1193 provider discovery which dispatchEvent suffices

That being said a protocol with externally_connectable is on my radar and that would be part of a bigger scope of work which would address both provider discovery and interface

SamWilsn · May 17, 2023, 1:21pm

Unfortunately externally_connectable isn’t universally supported yet: 1319168 - Implement externally_connectable from a website

rekmarks · May 17, 2023, 3:57pm

To the extent that we should concern ourselves with a browser that has less than 3% global market share, fair enough. Regardless, it shouldn’t be difficult to create a postMessage-based version of a protocol written for externally_connectable. Come to think of it, the standard should probably consist of a transport-agnostic message protocol with extensions for specific transports.

SamWilsn · May 17, 2023, 4:08pm

Yeah, extracting some bits of EIP-1193 into their own EIP might be worthwhile.

SamWilsn · May 17, 2023, 4:18pm

I know there are some significant drawbacks to this option, but I wanted to get a formal write-up of using scheme handlers for wallet discovery up just so we can discuss it more broadly.

Here’s the proposal pull request: Add EIP: Scheme-Handler Discovery Option for Wallets

And its discussion thread: SHADOW: A Scheme-Handler Discovery Option for Wallets

tl;dr use registerProtocolHandler and <iframe src="web+evm://"> to connect to wallets over postMessage.

sk1122 · May 18, 2023, 11:19pm

I am curious, why are we not using window.evmproviders, coupled with a great frontend library, EIP5749 can be a better solution

What are the possible drawbacks of EIP5749 over EIP6963?

pedrouid · May 19, 2023, 7:07am

EIP-6963 was created from a group that was pushing for adoption of EIP-5749

The main issue is that using a global window object can be manipulated and overwritten by different scripts

EIP-5749 also used a map instead of an array which caused issues with conflicting providers or even an attacker could replace another provider

EIP-6963 also introduces the concept of two identifiers (one local and one global) to ensure uniqueness of providers

EIP-6963 is the successor to EIP-5749 and shares the same authors

sk1122 · May 19, 2023, 2:52pm

Understood, Its a great alternative way for EIP-5749

I have been implementing a wallet standard for EVM chains which is based on the Wallet standard

I myself was working on this problem, previously I was trying to solve this by assigning each wallet their own “namespace” in the browser, something like window.wallets.metamask and window.wallets.backpack, but then quickly realised it will not be adopted by wallets as it requires a lot of work and also that anybody can update the data from window

Will integrate this in ethereum wallet adapter, how is the adoption like, any wallets integrating currently?

SamWilsn · May 19, 2023, 4:34pm

The current proposal is also vulnerable to manipulation:

const foo = window.dispatchEvent;
window.dispatchEvent = function() {
    console.log("here");
    return foo.apply(this, arguments);
};

pedrouid · May 22, 2023, 4:28pm

True… an attacker can override or proxy the payloads for dispatchEvent

But it’s better to take that risk than breaking compatibility with EIP-1193

My take is that we only get one take to break compatibility with EIP-1193 and if we are going to do it then the best candidate is CAIP-25

It’s a massive task to update all wallets and libraries to support an alternative provider interface (like EIP-1193) so this EIP-6963 is only tackling provider discovery

kdenhartog · May 22, 2023, 11:42pm

@pedrouid can you expand a bit further on why you think we only get one opportunity to break compatibility? Internet protocols have never followed that approach. Look at iterations on some of the following examples.

HTTP v1.0 / v1.1/ v1.2 / v2.0
TLS v1.0 / v1.1 / v1.2 / v1.3
SSL v1 / v2 / v3
OAuth v1 / v2.0 / v2.1
SAML v1.0 / v1.1 / v2.0

In every one of those cases there’s multiple iterations that occurred at various points of success with various degrees of adoption. I’m not following your line of reasoning that we only get one take to break compatibility. Similarly, isn’t the reason this is so contentious is because we are already breaking compatibility of the discovery mechanism portion of the protocol? Given the protocol encompasses more than just how messages are passed (window.ethereum → Event messaging) and what the interface looks like (EIP-1193 → CAIP-25) such as what failure states occur, what RPC methods are supported, what happens if we need to support multiple interfaces, etc can you expand more on why you believe keeping EIP-1193 is necessary versus adding CAIP-25 interface now?

True… an attacker can override or proxy the payloads for dispatchEvent

Uh that seems like a showstopper to me. A malicious third party iframe such as an advertisement on a DApp being able to MITM the message in order to modify the to address in a swap seems rather dangerous doesn’t it?

SamWilsn · May 25, 2023, 2:36am

If an iframe is capable of modifying the window object in the way I described, we’re already screwed because the ethereum object lives on the window as well.

I can’t speak for @pedrouid, but breaking changes are painful, and we should make them judiciously.