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.
Yeah, extracting some bits of EIP-1193 into their own EIP might be worthwhile.
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
.
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?
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
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?
The current proposal is also vulnerable to manipulation:
const foo = window.dispatchEvent;
window.dispatchEvent = function() {
console.log("here");
return foo.apply(this, arguments);
};
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
@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?
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.
I am curious, why are we not using
window.evmproviders
, coupled with a great frontend library, EIP5749 can be a better solution
Adding to what Pedro said, the initial idea of using events was to make sure no wallet was left behind since there might be a delay until the injection happens. This is currently managed by individual wallet events or a setTimeout (which isn’t ideal).
I also agree that evmproviders seems more fragile and easier to break. Regarding the iframe security concern, I think we could add an advise on the security considerations section about sandboxing any iframe used in the website. At least on the dapp side the issue will persist whether we use events, window.ethereum, postMessage or anything that’s attached to the window object.
If I’m not mistaken, sandboxing the iframe, as long as the allow-same-origin
flag is not there, will prevent the iframe from overwriting the window object.
Hey everyone, me and Boidushya from WalletConnect collaborated on an example dapp that supports EIP-6963
It will detect any EIP-6963 compatible browser wallet and display them. Plus you can connect multiple in parallel and it will display the chain and the accounts
But since there aren’t any in production, we added a button to “emulate” window.ethereum as EIP-6963 provider by wrapping it into an announceProvider event
App available at https://eip6963.org/
Source code available here: GitHub - WalletConnect/EIP6963: A web application showcasing the implementation and usage of EIP-6963 for Multi Injected Provider Discovery
Why not using a standardised window postMessage call, which any extension can answer if it wants:
Also the word “wallet” should not be used in the standard. the assumption that every crypto browser extension is wrong. blockchain based account systems can be anything but a wallet. See UniversalProfiles for example. Yes it can be a wallet, but it’s a lot more than that.
Maybe extensionId
is better:
interface EIP6963ProviderInfo {
extensionId: string;
uuid: string;
name: string;
icon: string;
}
Or even appId
The use of window.postMessage
was already considered but it would completely break EIP-1193 with little benefit.
But I would definitely consider renaming the walletId
param to something more generic… maybe providerId
?
Enkrypt chrome,opera and safari are live with 6963 if anyone wants to give it a shot
Make sure you goto https://eip6963.org it should automatically detect it
Enkrypt and Zerion extensions connecting simultaneously with EIP-6963
Hey Authors of EIP-6963, congrats on a successful twitter space advocating more adoptions.
We are starting a recurring virtual meetup for ERC authors and dApp builders to meet and talk to each other, advocate for adoption and / or give tech feedback. And we would like to invite you to come over to give a sharing on allercdevs. The event occurs bi-weekly and rotates between two timezone friendly slots, for information go to GitHub - ercref/AllERCDevs: Meeting Repository for AllERCDevs
Next sessions are 3rd session (Tuesday 2023-06-13 UTC2300) and 4th session (Thursday 2023-06-29 UTC1500)
We just merged one last PR that improves the wording for EIP-6963 regarding image requirements for the Wallet icon to be squared
The adoption is also growing nicely every day on the Wallet side… counting already with 12 wallets supporting it in production
I’ve prepared the PR on Github to move EIP-6963 from “Last Call” to “Final” status on Tuesday 10 Oct 2023
Great progress all around
I’d like to propose one last name change:
“Event-Driven Discovery of Wallet Providers”
I’d also like to tighten up the terminology being used. EIP-6963 is all about the relationship between “Dapps” and “Wallet Providers”. I want to make sure this is reflected clearly throughout the spec.
Check out my proposed changes here: