Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update EIP-6963: Move to Review #7034

Closed
wants to merge 2 commits into from
Closed

Conversation

pedrouid
Copy link
Contributor

This PR updates EIP-6963 status from DRAFT to REVIEW

IMPORTANT! Please comment below any feedback that you might have

@github-actions github-actions bot added c-status Changes a proposal's status s-review This EIP is in Review t-interface labels May 16, 2023
@eth-bot
Copy link
Collaborator

eth-bot commented May 16, 2023

File EIPS/eip-6963.md

Requires 1 more reviewers from @axic, @lightclient, @Pandapip1, @SamWilsn

@eth-bot eth-bot changed the title [EIP-6963] Updating status from "Draft" to "Review Update EIP-6963: Move to Review May 16, 2023
@eth-bot eth-bot added the e-review Waiting on editor to review label May 16, 2023
@github-actions github-actions bot added the w-ci Waiting on CI to pass label May 16, 2023
@everdimension
Copy link
Contributor

  1. Events are prefixed with "eip6963:": eip6963:announceProvider
    I believe this is done to make event name collisions less likely, but it also implies that this prefix may be updated with new proposals. If this is not the case, I think the EIP should prescribe the static nature of this prefix and mention that it's not supposed to be changed, even if later on interfaces like EIP6963ProviderInfo get augmented.

  2. Would you say that if we have an eip6963:announceProvider provider event, there should be a symmetrical eip6963:removeProvider event for cases (which are rare now) where a provider decides to no longer be registered? A case could be where a provider needs reset its state for some reason, perhaps even its name or the icon, or some other internal state that has to do with exposed properties.

@pedrouid
Copy link
Contributor Author

Thank you @everdimension for the feedback! 🙏

  1. I think prefixing with events and interfaces with EIP6963 is important to make the spec more static. That way if any changes were to be made in the future after the spec was finalized then it won't conflict with existing changes
  2. Someone else also recommended that we added an equivalent method to removeProvider but it also adds complexity regarding ownership since now other providers can emulate the same event to remove competitors. Then we would need to introduce authentication and sign events with public key which would be too high of a cost for marginal benefit

@github-actions
Copy link

The commit 082b591 (as a parent of b5ef6fb) contains errors.
Please inspect the Run Summary for details.

@rekmarks
Copy link
Contributor

It works. Let's ship it.

Copy link
Contributor

@kdenhartog kdenhartog left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some additional feedback:

  1. We should be requiring the EIP6963ProviderDetail, EIP6963ProviderInfo and provider objects to be frozen via object.freeze. This prevents prototype pollution of the provider and information related to the provider.
  2. Provider detail should not be explicitly coupled to EIP-1193. Doing so will unnecessarily lock this spec into EIP-1193 and require us to break compatibility again if this interface is changed.
  3. How do we plan to enforce the global unique identifier of the walletId parameter? To me this seems like it's implied that it should be done with reverse domain notation. How would you expect a test for this to be added to the wallet-test-framework under the current definition?
  4. The identifiers in the identifier section are reversed. UUIDv4 is a globally unique identifier based on it's cryptographic entropy. The example identifiers are examples of localized identifiers because there's no coordinating registry nor conflict resolution mechanism to provide a reasonable guarantee that these are globally unique.
  5. We strongly discourage lossy formats like JPG/JPEG should use normative language. Would we prefer to require these formats to not be used (MUST NOT) or make it a suggest based on SHOULD NOT/MAY NOT language?
  6. Is there any reason to not require the icon property in the EIP6963ProviderInfo is not defined as a data URI rather than allowing it to be any URI? By allowing images to be set via this property in a linking structure we encounter an issue. The URL can be taken down or encounter network issues in a way that leaves it possible that the image won't be displayed.
  7. We should state that Wallet's "SHOULD NOT" support window.ethereum anymore. The reason for this is because otherwise DApp's will file issues on wallets saying that their DApp is broken now because they aren't using window.ethereum and this allows us to point to this spec as a reason for not adding support for it and suggest the DApp updates to support EIP-6963 or a compatible wallet adapter library.
  8. We should add a privacy consideration here that provides a suggestion to consider whether the provider should be announced on every page load or if consent should be gathered from the user ahead of time. For example, extensions could check whether the page has registered a requestProvider Event and if so prompt the user if they'd like to announce their wallet to reduce the extension fingerprint. The reason this is optional today is because likely most wallets will announce the provider on page load right away to maintain compatibility with the EIP-1193 pattern. However, when combined with a different provider object (because number 2 would make this an intentional extension point) then we open the door for the user to be able to consent to the wallet being announced, wallet addresses being provided, and RPC namespaces being announced all within a single call after the user consents to it. Essentially, we'd have a pattern where the DApp can now initiate the interaction and the wallet can opt to respond to it or ignore it which would match the behavior of a user without a wallet and therefore eliminate the fingerprinting concern.

For number 2, instead we should add an interface parameter to the EIP6963ProviderInfo which allows us to indicate the provider interface such that we can expand beyond the EIP-1193 interface as it's currently defined. Then, inside the EIP6963ProviderDetail object we can untie the provider property in a way that allows for this interface to be extensible.

There's little reason for us to tie the discovery mechanism of the provider to the actual interface of the provider and this change would allow us to not ossify 1193 as the required method to achieve this.

@pedrouid
Copy link
Contributor Author

Thanks @kdenhartog for the very thorough review and feedback 🙏


Here are my replies for each point you mentioned above:

  1. No objections. Makes a lot of sense!

  2. My perception is definitely biased but I’ve been working on a new provider interface (CAIP-25 & CAIP-27) for over 2 years and I’m confident that it will not inherit anything from EIP-6963. So in my opinion making this EIP more generalized will only introduce unnecessary complexity. EIP-1193 is broadly adopted and breaking compatibility will incur huge costs so it will likely going to go in direction of CAIP-25 using an event-based or message-based interface which will not require either EIP-1193 or EIP-6963. So I will pose the question… why generalize/decouple EIP-6963 when it will exclusively be used by EIP-1193 and won’t be compatible with CAIP-25 and CAIP-27?

  3. Honestly the more I think about it I would say that we should just enforce reverse domains as walletId. There is likely a smaller than 1% of use-cases that you actually would need a walletId that cannot be a reverse domain.

  4. Maybe the wording I used made it ambiguous but let me explain with an example. If an Ethereum Library observes two wallet providers announcing with the same walletId then it can distinguish them with the locally generated uuid. Also if a wallet provider were to announce itself twice then it can be de-duplicated by checking the uuid. Important to note that the combination of walletId and uuid does not prevent impersonation and it’s only to prevent duplication.

  5. Totally agree. There is probably other sectoons were more normative language should be spec so please be give more feedback like this!

  6. Honestly I had stronger opinions about this before where I believed flexibility on this parameter would be advantageous. But similarly to walletId I think we might want to be stricter and enforce only data uri.

  7. Strongly disagree. Some dapps out there have enough resources to be up-to-date with the latest standards but this would be a massive breaking change that would break way too many dapps. This would be detrimental for the adoption of EIP-6963. In our example dapp (eip6963.org) we show how window.ethereum can be used in parallel with EIP-6963 without any issues. Dapps that support EIP-6963 can choose to ignore it or not. Dapps that do NOT support EIP-6963 will continue to work

  8. Keep in mind that the current pattern using window.ethereum is NOT part of the EIP-1193 spec. So technically announcing on page load is independent of EIP-1193. I think that it makes sense for Wallet Providers to provide the option for their users to enable or disable announcing on page load and we can describe the fingerprinting concern in the Privacy Considerations.


TLDR' I personally agree with all of your feedback and I think we should start a PR to address all points except for points 2 and 7

@kdenhartog
Copy link
Contributor

kdenhartog commented May 29, 2023

Sounds good, I'll get a PR going for these changes. Regarding our disagreement on 2 and 7, here's my response.


Can you define what qualifies as a breaking change for you? I think we keep talking past each other on this point and it's causing confusion on the goals each of us is trying to achieve with our positions on 2 and 7. Ultimately, I think our goals are the same. To increase support of EIP-6963 (purpose of 7) and create an eventual path of support for CAIP-25 (purpose of 2). Where we may differ is in how we believe that should be achieved is all.

For me, a change in the default protocol used to communicate between DApp and Wallet constitutes a breaking change. I'm inferring that for you a breaking change ONLY occurs if the interface is changed. Is that correct? If so here's where I'm not aligned with that definition. Currently, the primary method used for extension wallets is EIP-1193 as an interface and window.ethereum as the transport of arbitrary messages between the wallet and DApp. The combination of the interface and the transport method defines the protocol in my definition. Therefore, changing the protocol is inherently a breaking change even if it's backwards compatible because it's possible that either participant of the protocol may opt to no longer support the old version and only support EIP-6963+EIP-1193. Similarly, either participant may opt to not support the new protocol. This is similar to a browser maintaining support of TLS 1.0/1.1/1.2/1.3 but a server only opting to support TLS 1.2 or 1.3 because 1.0 and 1.1 have been officially deprecated. Even though the TLS protocol hasn't undergone major breaking changes and maintains backwards compatibility, lack of support by either participant can still present interoperability constraints and therefore "break" compatibility. Hence, why I'm defining this change as a "breaking change".

EIP-6963 is suggesting that wallets and DApps support new behavior so that we no longer prototype pollute the window.ethereum object. I understand it's possible to support both, but there's no guarantee that both parties will leading to potential compatibility issues. Furthermore, I don't believe we should encourage new DApps to support the old protocol. Wallets will likely need to maintain support even if we officially deprecated window.ethereum+EIP-1193. This is similar to the blink tag in HTML being deprecated officially yet still supported by most browsers.

So, by adding language to suggest that supporters of EIP-6963 "SHOULD NOT" support the old method we're creating a scenario where DApps can say, "We no longer support the defacto standard of window.ethereum instead we now only support EIP-6963 and you should be using a wallet that supports it". This is the reason I chose "SHOULD NOT" rather than "MUST NOT". By doing this we're placing a signal within the standard to suggest "hey this is the best current practice of how to communicate between a DApp and a Wallet". At some point in the future when most DApps are supporting EIP-6963 we can then disable default support of the current window.ethereum approach and greatly reduce the prototype pollution issue that EIP-6963 has set out to resolve.

Regarding number 2, I'm a bit confused. Are you of the opinion that CAIP-25 will reuse Event concurrency loops like we're doing here, but will define a different set of Event names and will define a similar but different ProviderInfo structure? I guess that's where I'm confused. Even if we use your definition of breaking change here, a wallet or DApp that wishes to support every method of communication won't reduce the number of code paths or code complexity to do so. However, by reusing EIP-6963 we can at least reduce the amount of code that needs to be written to support all 3 methods.

For reference, I'm thinking of the following 3 methods:

Current: window.ethereum + EIP-1193
Proposed: EIP-6963 + EIP-1193
Future: EIP-6963(*) + CAIP-25

(*) indicates a similar but non compatible method of arbitrary message transport may be used.

@pedrouid
Copy link
Contributor Author

re: point 7

I see your argument for point 7, I can agree that the language "SHOULD NOT" does not forbid a wallet provider from using window.ethereum yet it signals the future intent to deprecate it.

I'm ok if we include changes in the next PR to include the feedback for point 7.


re: point 2

Personally I don't see anything from EIP-6963 being re-used for future standardization in wallet providers when CAIP-25 and CAIP-27 become production-ready. There are two main reasons for this:

a) EIP-6963 does NOT include any feature or capability discovery when the Ethereum Library prompts Wallet Providers to announce themselves. This is something that we would need to change to make it CAIP-25 compatible but it would be a premature optimization for an eventual upgrade that isn't ready

b) EIPs can inherit or reference standards or interfaces from CAIPs because they are chain-agnostic. But the vice-versa is not possible because it would then "leak" dependencies on other blockchain ecosystems that are not EVM-compatible. This means that CAIP-25 would need its own discovery mechanism standard independent from EIPs

Finally another bonus reason... EIP-1193 and CAIP-25 are too diferent from each other (one is object-based and other is message-based).

Generalizing between the two would not only overcomplicate standardization but it also make EIP-1193 design flaws to prevail in the future unnecessarily.

My take is that EIP-6963 should be compatible exclusively with EIP-1193 hence it should be deprecated together in the future.


TLDR' let's include point 2 in the next PR but I still strongly disagree with point 7

@kdenhartog
Copy link
Contributor

TLDR' let's include point 2 in the next PR but I still strongly disagree with point 7

Ok, let's chat about number 2 a bit more on a call or something some time soon. I'd at least like to make sure I fully understand your viewpoint on this before we finalize this EIP in case it would be useful to add this extension point since I'm not seeing what the future approach would do instead of EIP-6963. I'm missing a few pieces of the puzzle still (e.g. I think I just realized CAIP-25 is more a replacement of EIP-1102 and EIP-2255 not window.ethereum) which might mean we just have somethings underspecified within the CAIPs and that's why I'm accidentally filling the gaps with EIP-6963.

@jxom
Copy link
Contributor

jxom commented May 30, 2023

Is there even any benefit to removing window.ethereum? If we remove it how will consumers easily interact with Ethereum without a dependant library when window.ethereum is gone? I don't really want to be playing around with/managing event listeners. Plus, I don't want to get in the scenario where we are screaming at Dapps to update their implementations by X date.

Feel like window.ethereum has served us well for years, and I see this EIP as mainly a quality-of-life improvement for "connect kit" libraries like Web3Modal, ConnectKit and RainbowKit to enable their users (fwiw, the small audience of wallet pro-users & developers) to choose their Browser Wallet.

@kdenhartog
Copy link
Contributor

kdenhartog commented May 30, 2023

Is there even any benefit to removing window.ethereum

Yes, right now any user that installs multiple extension wallets will find that the wallets behave in unexpected ways. For example, Brave regularly (about every 3 to 6 weeks) receives complaints from users that we're breaking their Metamask implementation because they think Brave Wallet is prototype polluting metamask when in reality it's a race condition between the various extensions they have installed. In Brave's case, we can override all extensions, but default to giving Extensions first dibs via brave://settings/?search=Default+Ethereum+Wallet which defaults to Extensions (Brave Wallet fallback). On top of that, because extensions are unable to freeze the window.ethereum object (doing so would break compatibility for other wallets) there's a security exploit that's been left unaddressed where malicious scripts or extensions can modify the requests and or responses from the wallet in a way that tampers with the integrity of the signed data.

@pedrouid
Copy link
Contributor Author

@jxom:

Feel like window.ethereum has served us well for years

Honestly this is kinda not true IMHO 😅 A lot of wallets wouldn't exist if it wasn't for some crazy hacks to circumvent the massive issues with window.ethereum being NOT interoperable at all

Plus if it wasn't for WalletConnect many wallets wouldn't have had a way to get into the market at all because browser extensions were completely captured by users only installing one wallet simultaneously

That being said I agree that we MUST NOT break compatibility with window.ethereum because there are too many dapps and libraries depending on it today thus EIP-6963 can be used in parallel

Yet what @kdenhartog has suggested is that we use the wording "SHOULD NOT" which essentially strongly recommends that Wallet Providers eventually deprecate the legacy pattern of window.ethereum in favor of EIP-6963

@jxom
Copy link
Contributor

jxom commented May 30, 2023

I guess the point I was trying to make is that I don’t want to get in a situation where some Dapps may not work with a particular Wallet because they don’t support 6963 yet or vice-versa. Which is essentially what you are saying.

However, I do not agree with adding in the “Wallet Provider SHOULD NOT support window.ethereum” or alike statement because this kinda adds a sense of urgency for the Wallet Provider to remove window.ethereum whilst implementing 6963 in the name of “sticking to the standard”. If we even add context that states it “eventually” should be removed, when exactly is “eventually”? When “eventually” happens, how do we communicate to Dapp developers that interface with the Wallet to migrate to 6963? Will they even have the capacity to do so?

For Dapp consumers who DO NOT consume a Wallet Connection library like wagmi, RainbowKit, Web3Modal, etc, the migration path isn’t exactly smooth since we are now inverting control to the Dapp developer to handle the Provider instance themselves (as well as ensuring it is sensibly persisted, frozen, etc). Even those who DO depend on a library that handles Wallet Connection also won’t benefit until they upgrade, which might be a problem for those who do not have the capacity/resources to upgrade (and even maybe migrate across major versions of that library). I think we should be somewhat empathetic here.

@kdenhartog
Copy link
Contributor

So what would you suggest as the proper wording to indicate this is now the best practice for how a wallet and DApp should communicate and the previous method with known issues should not be implemented any further?

@jxom
Copy link
Contributor

jxom commented May 30, 2023

I believe we should make the intention clear for both Applications & Wallet Providers. In my opinion, it could be along the lines of:

"For Applications, it is RECOMMENDED to implement and prioritize EIP-6963 over window.ethereum to ensure discovery of multiple Wallet Providers." (addresses "best practice for how a wallet and DApp should communicate and the previous method with known issues should not be implemented any further")

"For Wallet Providers, it is RECOMMENDED to keep compatibility of window.ethereum to ensure backwards compatibility." (addresses our ongoing argument of backwards compatibility)
Or maybe we don't include such statement for Wallet Providers at all. But I won't die on this hill if you want to mention that window.ethereum will eventually be deprecated though. I just don't know when "eventually" will be. 😅

@kdenhartog
Copy link
Contributor

kdenhartog commented May 30, 2023

"For Wallet Providers, it is RECOMMENDED to keep compatibility of window.ethereum to ensure backwards compatibility."

Ok, I'm generally aligned with this thinking.

"For Applications, it is RECOMMENDED to implement and prioritize EIP-6963 over window.ethereum to ensure discovery of multiple Wallet Providers."

I'd suggest one modification to this one, which is to suggest DApps SHOULD disable support for window.ethereum. I'd use a MUST here in a perfect world, but it's not practical and wouldn't realistically make a difference if we did it.

Here's my reasoning for the change. This standard could hold for another 5+ years, so without the push from either direction developer enertia suggests that window.ethereum will remain the dominant approach. This will mean we'll keep seeing complaints and error messages on DApps. Ultimately, developers are going to do what they want. Many DApp developers probably won't even know about this change for the next year.

To support my argument here's some analogous data. As an example, HTTP(s) was implemented in 2000 and it wasn't until Google changed their SEO methods in 2014 (as an incentive to force websites to change) that we started to see HTTP(s) become the more common method of usage. That change in 2014 took an international political scandal (Snowden leaks) to motivate the changes too. Luckily, we don't have as large of a web presence to affect here but the point I'm making here is that words have meaning so the stronger we can go the faster we can notice a large effect.

I generally agree with your priority of constituents here as well, where we should lean on the wallets to make the majority of the changes rather than pressing for the DApp developers to take on the burden of change. The reasoning this makes sense to me is there's only 10s of wallets but there's 1000s of DApps, so bootstrapping adoption is going to be much more easily achieved by placing the burden on wallets. With that in mind, getting to default support of this feature in wallets is going to take substantial adoption by DApps. We're only now just talking about turning on HTTP(s) by default in browsers after 23 years. So the better we can encourage DApp's turning off support of window.ethereum and migrating to EIP-6963 the faster we'll be able to get wallets supporting it by default. Realistically, I'd be surprised if a wallet could remove window.ethereum support ever because they'll get complaints it doesn't work with some old DApp. However, given I'd like to move away from window.ethereum support entirely that's the reason I don't want to mandate backwards compatibility hence my agreement with your recommendation.

Also, I like the suggestion you're making here by being more explicit about support between the various parties.

@jxom
Copy link
Contributor

jxom commented May 30, 2023

I'd suggest one modification to this one, which is to suggest DApps SHOULD disable support for window.ethereum. I'd use a MUST here in a perfect world, but it's not practical and wouldn't realistically make a difference if we did it.

I can agree with this. It'll also push wallets to support 6963 if Dapp developers are screaming at them to support it.

@kdenhartog
Copy link
Contributor

Sounds good, I'll get that change in with my PR I'm currently working on for this.

@pedrouid
Copy link
Contributor Author

@kdenhartog some feedback collected from Telegram feedback:
a. UUID should be persisted during a webpage lifecycle (generated on page load and unique per browser tab)
b. Reference Implementation should use a Map instead of an array for the providers
c. More detail over the motivation/goals for each parameter specified for ProviderInfo

@kdenhartog
Copy link
Contributor

kdenhartog commented Jun 3, 2023

Here's the beginning of a PR for the changes being updated #7134

@jskelly84
Copy link

jskelly84 commented Jun 3, 2023 via email

@pedrouid pedrouid closed this Jul 18, 2023
@pedrouid
Copy link
Contributor Author

Closed in favor of #7352

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c-status Changes a proposal's status e-review Waiting on editor to review s-review This EIP is in Review t-interface w-ci Waiting on CI to pass
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants