Update EIP-6963: name change + term consistency + overall copy edits #7824
Conversation
|
Reverting all proposed normative changes to avoid restarting the Last Call period. |
@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 (" Using strict TitleCase as in |
@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! |
…riptive language related to browser extensions
|
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. |
|
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. |
|
|
||
| The **`rdns`** (Reverse-DNS) property serves to provide an identifier which DApps can rely on to be stable between sessions. The Reverse Domain Name Notation is chosen to prevent namespace collisions. | ||
| The Reverse-DNS convention implies that the value should start with a reversed DNS domain name controlled by the Provider. The domain name should be followed by a subdomain or a product name. Example: `com.example.MyBrowserWallet`. | ||
| The `rdns` (reverse-DNS) property serves as an identifier which Dapps can rely on to be stable between page sessions. The Reverse Domain Name Notation is chosen to prevent namespace collisions. The domain should be controlled by the Wallet Provider and be followed by a subdomain or a product name. Example: `com.example.MyBrowserWallet`. |
There was a problem hiding this comment.
| The `rdns` (reverse-DNS) property serves as an identifier which Dapps can rely on to be stable between page sessions. The Reverse Domain Name Notation is chosen to prevent namespace collisions. The domain should be controlled by the Wallet Provider and be followed by a subdomain or a product name. Example: `com.example.MyBrowserWallet`. | |
| The `rdns` (reverse-DNS) property serves as an identifier which Dapps can rely on to be stable between page sessions. The Reverse Domain Name Notation is chosen to prevent namespace collisions. The domain SHOULD be controlled by the Wallet Provider and MAY be followed by a subdomain, product name, or other discriminant. Example: `com.example.MyBrowserWallet`. |
|
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 |
@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. |
|
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. |
|
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. |
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:
(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:
window.ethereum"window.ethereum", "EIP-1193 provider object injected atwindow.ethereum", "legacywindow.ethereumbehavior", etc.Eip6963ProviderDetailobject" / "Wallet Provider"Eip6963ProviderDetailobject sent by Wallet Provider", etc.Eip6963AnnounceProviderEvent" → "eip6963:announceProviderevent"Eip6963RequestProviderEvent" → "eip6963:requestProviderevent"Minor structural changes:
Minor spec changes:AllowEip6963RequestProviderEventto be anEventORCustomEventExplicitly disallow Dapps from rendering<svg>tags as-isAllow Dapps to render SVGs as an<img>tag OR XSS-resistant "equivalent means" (such as a CSS background)