Update EIP-6963: name change + term consistency + overall copy edits

[darrylyeo]

trafficstars

EIP-6963 is all about the relationship between "Dapps" and "Wallet Providers" – I want to ensure the copy and code examples reflect this clearly.

Naming things is hard. This PR should make the explanations more concise and terminology more consistent.

New EIP title:

• "Multi Injected Provider Discovery"
  • → "Event-Driven Discovery of Wallet Providers"

(The previous title does not do this EIP justice in my opinion – "provider" is an overloaded term, and "injected" is ambiguous as it could refer to the EIP-1193 provider object or the content script of a browser extension. Plus, it needs "Wallet" in the name!)

Notable terminology clarifications:

• "DApp" / "application"
  • → "Dapp" (the "a" in "dapp" is lowercase on Ethereum.org)
• "Wallet" / "provider" / "wallet provider"
  • → "Wallet Provider" (explicitly defined as a "browser extension" for the purposes of this spec)
• "library" / "Provider Discovery Library"
  • → "Wallet Provider Discovery Library" (usually interchangeable with "Dapp" for the purposes of this spec)
• "injected Wallet Provider" / "Ethereum provider" / "Ethereum interface" / "EIP-1193 provider" / "Provider object" 😵‍💫
  • → "EIP-1193 provider object"
• "injected script"
  • → "injected content script", "content script injected by a browser extension", etc.
• "window.ethereum"
  • → "global JavaScript variable window.ethereum", "EIP-1193 provider object injected at window.ethereum", "legacy window.ethereum behavior", etc.
• "web page" / "session" / "lifetime of the page" / "over time"
  • → "page session" or "webpage session"
• "Eip6963ProviderDetail object" / "Wallet Provider"
  • → "EIP-6963 compliant Wallet Provider object", "Eip6963ProviderDetail object sent by Wallet Provider", etc.
• Events (reference by their JavaScript event name instead of TypeScript interfaces specific to this spec):
  • "Eip6963AnnounceProviderEvent" → "eip6963:announceProvider event"
  • "Eip6963RequestProviderEvent" → "eip6963:requestProvider event"
• "this EIP"
  • → "EIP-6963"

Minor structural changes:

• "Wallet Provider info" section:
  • Link to "RDNS identifiers" sub-section (mirroring link to "Icon images" sub-section)
• "Events" section:
  • Add "Event loop" sub-heading

Minor spec changes:

• Allow Eip6963RequestProviderEvent to be an Event OR CustomEvent
• Explicitly disallow Dapps from rendering <svg> tags as-is
• Allow Dapps to render SVGs as an <img> tag OR XSS-resistant "equivalent means" (such as a CSS background)

[eth-bot]

🛑 Auto merge failed. Please see logs for more details, and report this issue at the eip-review-bot repository.

[github-actions[bot]]

The commit 4d506caef934566223ff1c42becad4790bf1fed5 (as a parent of 5899827e9a307cf5e56723abfd9f4a5e48e6c491) contains errors. Please inspect the Run Summary for details.

[darrylyeo]

The only breaking change here would be disallowing Dapps from rendering <svg> tags as-is.

The other spec changes loosen the requirements to use Event / <img> exclusively.

Everything else is a naming/stylistic/organizational choice and shouldn't affect new or existing implementers of the spec.

[kdenhartog]

The only breaking change here would be disallowing Dapps from rendering <svg> tags as-is.

The other spec changes loosen the requirements to use Event / <img> exclusively.

Everything else is a naming/stylistic/organizational choice and shouldn't affect new or existing implementers of the spec.

Any breaking change without large consensus here is unnecessary and potentially harmful at this point. At this point every change should be questioned substantially whether it warrants necessary change. If we think of this spec as concrete drying we're at the point where the tape is still up but it's basically ready to walk on. Now is not the time to try and spray a bunch of water on it so that we can resurface the concrete.

Also, we shouldn't assume that just because a change is non normative that it doesn't matter. The implications of subtle interpretation differences can be profound. Especially when making changes to examples which are by definition non-normative but often times the most important parts of the spec.

In my opinion we shouldn't be making changes at this point unless extremely necessary in order to enhance conformance. I do not believe these changes lead to enhanced conformance so therefore am against making these changes.

[darrylyeo]

Reverting all proposed normative changes to avoid restarting the Last Call period.

[darrylyeo]

there are some left, but I consider these as breaking changes.

@glitch-txs As I understand it, this spec is defining JavaScript functionality; the TypeScript syntax is used illustratively, so changing TypeScript interface names used as internal references shouldn't break any JavaScript implementations.

The fact that this EIP doesn't explicitly mandate a TypeScript implementation also motivated my decision to reference events by their JavaScript name ("eip6963:announceProvider event") instead of their internal TypeScript interface ("Eip6963AnnounceProviderEvent") – example. With my proposed copy changes, the TypeScript interface names are for the most part relegated to the TypeScript code snippets + reference implementation.

Using strict TitleCase as in Eip6963 is my personal style preference – not the most important part of my proposal though. Happy to revert to fully capitalized (EIP6963) if others strongly prefer :)

[darrylyeo]

Also, we shouldn't assume that just because a change is non normative that it doesn't matter. The implications of subtle interpretation differences can be profound. Especially when making changes to examples which are by definition non-normative but often times the most important parts of the spec.

@kdenhartog Agreed 100% with these points – my hope is that by consolidating terminology and applying them as consistently as possible across the document, we can prevent many of these subtle interpretation differences after the EIP moves to Final.

I took great care to preserve the original intent of both the normative and non-normative text as much as possible – happy to address any specific parts where you feel I have not!

[darrylyeo]

Update: "EIP-1193 Provider Objects" are now front and center with a dedicated definition.

Also reverted some prescriptive language related to browser extensions, as they are not the only way Wallet Providers expose EIP-1193 Provider Objects to Dapps.

[darrylyeo]

If it helps people read the code diff more easily — my revisions stem from using the four terms under the "Definitions" section as consistently as possible.

If anyone strongly prefers an alternative wording for any of the four terms, let me know and I can easily find-and-replace.

[glitch-txs]

I think we should keep the previous name for types. Imo it is a breaking change since most of us use typescript and have this EIP as reference/source of truth.

About the title I just wanted to point out that Wagmi has a library called mipd and some wallets are already using it, sharing it just to be aware of early implementations.

[darrylyeo]

I think we should keep the previous name for types. Imo it is a breaking change since most of us use typescript and have this EIP as reference/source of truth.

@glitch-txs I'd be inclined to agree if the EIP explicitly mentioned using TypeScript as a normative requirement.

While most existing/early implementations today are TypeScript-based it may not be that way in the future. Along that front, I'm trying to avoid being overly prescriptive, especially for current or future implementers who may not prefer to use TypeScript.

[github-actions[bot]]

There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions[bot]]

This pull request was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.