Bump MIP-5 and MIP-6 to Review status#60
Conversation
Fix EIP-1193 URL reference
- Moves the status of MIP-5 and MIP-6 to "Review". - Add more specifics related to API access and associated standards (we still need to add CAIP references for those standards).
Update the list of MIPs by status to account for those that have moved to `Review` status.
Specify the parameters that will be supported in CAIP-217 scopeObjects. Includes notes about special use cases for the `references` & `accounts` parameters.
Update status of MIP-5 & MIP-6
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
| > **Note:** MetaMask treats `requiredScopes` as `optionalScopes`. Only `optionalScopes` are recommended, though `requiredScopes` can be used to signal that your dapp will not be usable if certain [CAIP-217](https://chainagnostic.org/CAIPs/caip-217) `scopeStrings` are not authorized. | ||
|
|
||
| > **Note:** Developers are encouraged to precisely request only the authorization scopes for methods and notifications that their dapp expects to call before making additional `wallet_createSession` calls to expand authorization scopes. Requesting specific authorization scopes allows wallets to discover and implement features that are being adopted. Wallets can also further optimize permission confirmation flows to reduce unnecessary friction for some method calls. For simplicity, however, MetaMask may return more authorization scopes, methods, or notifications than the caller explicitly requested. | ||
| > **Note:** Developers are encouraged to precisely request only the authorization scopes for methods and notifications that their dapp expects to call before making additional `wallet_createSession` calls to expand authorization scopes. Requesting specific authorization scopes allows wallets to discover and implement features that are being adopted. Wallets can also further optimize permission confirmation flows to reduce unnecessary friction for some method calls. For efficiency, however, MetaMask may return more authorization scopes, methods, or notifications than the caller explicitly requested. |
There was a problem hiding this comment.
MetaMask may return different authorization scopes...? more or less authorization scopes...?
Or do we only need to hint at the incremental nature encouraged by the UI/UX defaults as you already are here?
There was a problem hiding this comment.
Bug: MIP Status Mismatch Needs Correction
The status of MIP-5 and MIP-6 is inconsistent. While their individual files (mip-5.md, mip-6.md) show status: Implemented, they are listed under the "Review" section in mips-by-status.md. The PR title also indicates the intention to bump them to "Review" status. The status should be "Review" across all files to align with the PR's stated goal.
MIPs/mip-5.md#L3-L4
metamask-improvement-proposals/MIPs/mip-5.md
Lines 3 to 4 in e9e64ca
MIPs/mip-6.md#L3-L4
metamask-improvement-proposals/MIPs/mip-6.md
Lines 3 to 4 in e9e64ca
MIPs/mips-by-status.md#L5-L8
metamask-improvement-proposals/MIPs/mips-by-status.md
Lines 5 to 8 in e9e64ca
Was this report helpful? Give feedback by reacting with 👍 or 👎
| status: Draft | ||
| stability: n/a | ||
| status: Implemented | ||
| stability: Experimental |
There was a problem hiding this comment.
Bug: MIP Status Mismatch
MIP-5 and MIP-6 have inconsistent statuses. Their individual files (mip-5.md, mip-6.md) set their status to "Implemented", but they are listed under the "Review" section in mips-by-status.md, contradicting their intended "Review" status.
3 participants
This PR is meant to capture further feedback and adjustments required to move MIP-5 & MIP-6 to
Reviewstatus.