Initial Multichain MIP drafts #31

vandan · 2024-01-30T06:49:22Z

This PR includes draft MIPs for:

How dapps will initiate a handshake with MetaMask
How dapps will initiate network-specific requests with MetaMask

Initial commit of draft MIPs for a new multichain-optimized API

Refines the language used in the multichain handshake MIP. Removes Future section in the mips-by-status page General improvements: Adds proper discussion-to links to MIP-1 and MIP-2

Updates to the multichain handshake proposal

MIPs/mip-mc-handshake.md

jiexi · 2024-02-13T22:53:37Z

looks like CASA refers to themselves with a space between Chain Agnostic

https://github.com/ChainAgnostic/CASA

jiexi · 2024-02-13T22:55:49Z

MIPs/mip-mc-handshake.md

+  "jsonrpc": "2.0",
+  "method": "provider_authorize",
+  "params": {
+    "optionalScopes":{ /* only emphasize optionalScopes, indicate that required scopes are possible elsewhere */


should this comment be updated? reads like a TODO item

yes, those are old notes, which I intend to update or remove.

Co-authored-by: jiexi <[email protected]>

shanejonas · 2024-02-26T20:21:24Z

MIPs/mip-mc-handshake.md

+`eth_sign`, `eth_signTypedData`, `eth_signTypedData_v3` methods WILL NOT be included in the Multichain API as these signature methods have been superseded by the more commonly used `personal_sign` and `eth_signTypedData_v4` methods
+
+##### Valid notifications
+`accountsChanged` - Because `provider_authorize` will return the accounts that the user authorized a dapp to interact with in the response, this notification is no longer necessary. The `accountsChanged` notification WILL NOT be included in the Multichain API.


Same with networksChanged?

might these two be worth keeping as a failover/fallback for legacy dapps, but just deprecating them in huge block letters in the docs for dapps?

they will be preserved in our legacy API

MIPs/mip-mc-handshake.md

bumblefudge · 2024-02-27T17:12:43Z

MIPs/mip-mc-handshake.md

+
+This method is intended to be part of a new version of the MetaMask Wallet API that is optimized for multichain interactions.
+
+This proposal aims to implement CAIP-25's JSON-RPC Provider Authorization into MetaMask. For EVM (eip155) networks, the `rpcEndpoints` parameter is adapted to be compliant with the object structure defined in EIP-3085. Designing the interface in this way will provide a standardized approach for dApps to request access to networks and JSON-RPC methods.


the rpcEndpoints parameter is adapted to be compliant with the object structure defined in EIP-3085.

So, the whole EIP-3085 object instead of just the rpcURLs array of strings defined by EIP-3085? Maybe it might make for easier interop/conformance to just use the rpcURLs array for the CAIP-25 array of strings and stick the rest of the object (with or without the redundant member rpcURLs) elsewhere in the protocol? Apologies, I am lacking lots of context here.

You could, for example, put a map in sessionProperties keyed to each rpcURL like so:

{ "id": 1, "jsonrpc": "2.0", "method": "provider_authorize", "params": { "optionalScopes":{ "eip155:1":{ ... "rpcEndpoints":[ "https://rpc.linea.build" ] ... }, "eip155:59144":{ ... "rpcEndpoints":[ "https://rpc.linea.build", "https://backup.infura.biz" ], }, ... }, "sessionProperties": { "rpcEndpointMetadata": { "https://rpc.linea.build": { "chainName":"Ethereum (Infura)", "rpcUrls":["https://rpc.linea.build"], /* keep or drop, i have no idea what's more ergonomic/secure/less-annoying */ "nativeCurrency":{ "name":"ETH" "symbol":"ETH" "decimals":18 }, "iconURLs":["https://example.com/ethereum.svg"] /* (Optional) using an array to allow */ }, "https://backup.infura.biz": { ... } } } } }

So per conversations with @hmalik88 we were thinking of approaching this in one of two ways:

Proposing to modify CAIP-25 such that the rpcEndpoints property defined in CAIP-217 would actually be an array of objects that would conform to the EIP-3085 parameters

Create a new CAIP where we specify a modification of the rpcEndpoints in the CAIP-25 scope object per what's described in which could then be added to the 'sessionProperties' - something like caipXYZCompliant = "true" (totally unsure of how we'd want to play that) and then consumers can read rpcEndpoints according to the spec described in CAIP-XYZ

Hey Alex! I can see CAIP-217 changing a lot or a little, nbd. And yeah, if structured, security-sensitive things are going into sessionProperties, they should probably be specified in detail in a new CAIP, or even just the eip155/caip217.md profile in the namespaces repo if it's less a security-critical spec-spec and more just an explanation/semantic guidance. i'm not wed to the exact design sketched above, it's just a sort of pattern or starting point i think might work for this particular kind of embellishment. happy to schedule a meeting to discuss this-- take advantage of my being on a US time zone for a while!

The people thinking about how to getting new kinds of information into CAIP-25 messages (whether in sessionProperties or otherwise) might find this exchange interesting over on an EIP PR I opened yesterday

bumblefudge · 2024-02-27T17:20:41Z

MIPs/mip-mc-handshake.md

+
+- Additional metadata fields in `rpcEndpoints` SHOULD be compliant with the fields specified in EIP-3085.
+
+[ TODO a PR in the api-spec repo describing the provider_authorize method in OpenRPC should be added here ]


please tag me in that PR whenever it's open if i can be of any service!

bumblefudge · 2024-02-27T17:21:33Z

MIPs/mip-mc-handshake.md

+- `wallet`
+- `eip155:X` (eip155 scope)
+
+> **Note:** In the future, this specification may be extended to support Snap IDs or the full range of [CAIP-2 Namespaces](https://namespaces.chainagnostic.org/)


or some subset of that range! not all L1s are ready for MM, even if MM is ready for them 😅

wdym? traffic wise? @bumblefudge

oh i'm just teasing. i've been going down some wierd rabbitholes lately about theoretical L2s with complex or extended addressing systems (some of the ZKL2s I think already do this maybe?) and privacy-by-obscurity chainIds. don't mind me, I wasn't insinuating anything concrete, just hypothetical breakdowns of extending the account model and chainId model globally!

bumblefudge · 2024-02-27T17:28:54Z

MIPs/mip-mc-handshake.md

+- Successful provider_authorize requests with expected permissions returned in the response.
+- Error handling when an unsupported scope object or permission is requested
+- Error handling when the user denies consent for requested methods
+- Error handling when the user denies all requested or any required scope objects


this is the only "bug" in WC's implementation-- they did not have this failure case well-documented enough and thus didn't warn dapps LOUDLY ENOUGH that it was a show-stopper if they crafted their requiredScopes too broadly!

bumblefudge · 2024-02-27T17:31:06Z

MIPs/mip-mc-handshake.md

+Test cases should cover:
+- Successful provider_authorize requests with expected permissions returned in the response.
+- Error handling when an unsupported scope object or permission is requested
+- Error handling when the user denies consent for requested methods


it may be worth considering Kyle dH's warning about browser fingerprinting here; if your error messages give TOO MUCH information a malicious site can generate a lot of insincere CAIP-25 traffic and analyze the results to guess the wallet (and combine it with, e.g. IP information and other conventional "browser fingerprinting" inputs) to deanonymize someone who hasn't even authorized one account. this is why many of the error messages in CAIP-25 are optional and recommended only for "trusted environments", i.e., only send to an allowlisted dapp.

bumblefudge · 2024-02-27T19:08:36Z

MIPs/mip-mc-handshake.md

+
+## Open Issues
+List of significant open issues that require resolution in order for this MIP to be ready to be moved to the `Review` stage
+- Add OpenRPC specs for the provider_authorize method


feel free to tag me in ^this PR if i can be of any service, or just to provide implementer feedback on the CAIP-25 spec qua spec!

Here is my initial attempt at speccing out provider_authorize we can start from:

https://github.com/ChainAgnostic/CAIPs/pull/212/files

bumblefudge · 2024-02-27T19:10:50Z

MIPs/mip-mc-request.md

+
+## Definitions
+
+Add a note about how we use the terms `chain` and `network` interchangeably


haha this is an "ethereumism" and some non-chain networks like DAGs might feel more welcome in the Snaps project if you discriminate!

MIPs/mip-mc-request.md

bumblefudge · 2024-02-27T19:15:03Z

MIPs/mip-mc-request.md

+## Developer Adoption Considerations
+[Explain any considerations that developers should take into account when adopting this proposal. For example, how will it affect compatibility, and what changes may need to be made to accommodate the proposal?]
+
+The implementation would be designed to be fully backward-compatible. Existing methods for changing networks and executing transactions would remain unaffected. Once there is sufficient industry adoption of the Multichain API, backward-compatibility may be reconsidered and gradually deprecated. 


It might help to refer specifically to CAIP-25 adoption here-- CAIP-27 is supposed to work even if CAIP-25 isn't adopted (or perfectly implemented) by dapp and wallet alike, i.e., a "scope" in CAIP-27 should correspond to a scopeObject authorized with the handshake, but conceivably some wallets might implement 27 without implementing 25 as a "halfmeasure" or a way of working their way up to the more stateful CAIP-25 concept of scopes by just handling these strings as an interim goal...

MIPs/mip-1.md

Accept adjustments Co-authored-by: Bumblefudge <[email protected]>

shanejonas · 2024-03-08T17:21:12Z

MIPs/mip-mc-handshake.md

+##### Valid notifications
+`accountsChanged` - Because `provider_authorize` will return the accounts that the user authorized a dapp to interact with in the response, this notification is no longer necessary. The `accountsChanged` notification WILL NOT be included in the Multichain API.
+
+#### eip155:X Scope


eip155 isnt a great name for this namespace since smart contract accounts exist and cannot sign via eip155. ethereum or evm is more inline with the other namespaces they have already like cosmos, casper, etc.

forgive the hair-splitting, but EIP-155 isn't referred to here qua signing algo, but rather for the chainId system it created to have something to sign over 😄 .

there was definitely a lot of discussion back and forth on this, and the main argument against "EVM" was that there is no technical definition of EVM (much to the delight of the CMOs of EVM-compatible L2 bridges everywhere, hehe). the main argument in favor of eip155 is that it CAIP schemes are all heirarchical, and "eip155" explains the next layer in the matruyshka doll :D

some partial context here (CASA discord has more if you dig into the older channels)

hmalik88 · 2024-03-15T22:14:25Z

MIPs/mip-mc-handshake.md

+```
+
+## Privacy Considerations
+This proposal raises important privacy considerations, including the need to avoid data leaking and the challenge of obtaining genuine user consent. It underscores the importance of preserving user anonymity and the sensitivites involved in determining authorizations. Identifying and mitigating these issues is crucial for protecting user privacy during multichain interactions, prompting a careful evaluation of how best to balance functionality with privacy concerns.


Echoing what @bumblefudge above, it would be prudent to mirror CAIP-25's error handling to avoid things like fingerprinting risk through authorization denials/errors.

MIPs/mip-mc-request.md

Co-authored-by: Hassan Malik <[email protected]>

Connect this MIP with the relevant discussion thread Co-authored-by: Shane <[email protected]>

Significant updates to naming and MetaMask-specific choices and behaviors beyond what is specified in CAIP-25 & CAIP-27. Some topics remain as open issues and will need to be resolved in order for these MIPs to be moved to "Review" status.

jiexi · 2024-06-25T22:38:59Z

MIPs/mip-x-authorize.md

+
+## Motivation
+
+The purpose of this proposal is to offer a convenient and standard pattern for applications to negotiate multiple network authorizations with MetaMask. 


in the ethereum world, this would be more accurate as multiple chain, but I don't know if that is true in other ecosystems

By the time we move the MIP to Review status, we may be ready to incorporate alternative networks (non-EVM) to it so that's why you see "network" used in place of "chain" throughout the MIP. Trying to stay ecosystem agnostic at least in this MIP.

jiexi · 2024-06-25T22:39:56Z

MIPs/mip-x-authorize.md

+
+The `wallet_authorize` method is specifically meant to:
+
+- Allow applications to progressively negotiate a set of authorizations with MetaMask


progressively implies being able to update existing authorizations. I believe that this method replaces all existing authorizations?

This MIP is still awaiting some resolution and guidance from the lifecycle CAIP being proposed right now.

I believe there are two approaches being considered:

Use the same wallet_authorize method for initial and progressive (incremental) authorizations

Use one method for the initial authorization (replaces any existing authorizations) and another method for progressive authorizations

Minor cleanup of requests/response code examples

jiexi · 2024-06-25T22:42:16Z

MIPs/mip-x-authorize.md

+
+**wallet scope**: A scope that applies to capabilities that a MetaMask Wallet client can handle in a relatively self-contained way. They are not specific to a network or namespace.
+
+**eip155:wallet scope**: A CAIP-2 identifier with a reserved `wallet` as the `reference`. For example "eip155:wallet" indicates a scope that is not specific to a particular Ethereum network but is related to the `eip155` `namespace`.


personally prefer wallet:eip155, but there are several different views on this already

one minor advantage I see with eip155:wallet is that it appears to be compatible with CAIP-2's reference syntax.

Update naming for consistency

jiexi · 2024-06-25T22:49:34Z

MIPs/mip-x-authorize.md

+> **Warning:** Placing `scopeObjects` into `requiredScopes` indicates that a permission MUST be accepted in order for the application to function with MetaMask. If permissions for `requiredScopes` are declined, then the application will receive no authorizations and will NOT be connected to MetaMask. In most cases, `scopeObjects` should exclusively be placed in `optionalScopes`. Only use `requiredScopes` to indicate that your application cannot provide even a basic experience without them.
+
+### Valid `scopeMetadata`
+When a MetaMask user does not have an existing network configured for a given eip155 chainId, including metadata for `rpcEndpoints` in the `scopeMetadata` will suggest the user add the first endpoint in the list. MetaMask expects the `rpcEndpoints` parameter to conform with the [EIP-3085](https://eips.ethereum.org/EIPS/eip-3085) standard.


Suggested change

When a MetaMask user does not have an existing network configured for a given eip155 chainId, including metadata for `rpcEndpoints` in the `scopeMetadata` will suggest the user add the first endpoint in the list. MetaMask expects the `rpcEndpoints` parameter to conform with the [EIP-3085](https://eips.ethereum.org/EIPS/eip-3085) standard.

When a MetaMask user does not have an existing network configured for a given eip155 chainId, MetaMask will suggest the user adds the first endpoint defined in the `rpcEndpoints` property of the `scopeMetadata` object. MetaMask expects the `rpcEndpoints` parameter to conform with the [EIP-3085](https://eips.ethereum.org/EIPS/eip-3085) standard.

nit. maybe? idk

jiexi · 2024-06-25T22:55:37Z

MIPs/mip-x-request.md

+provider.request([
+  {
+    "jsonrpc": "2.0",
+    "method": "wallet_invokeMethod",
+    "params": {
+        "scope": "eip155:1",
+        "request": {
+            "method": "eth_getBalance",
+            "params": ["0xabc...", "latest"]
+      }
+    }
+    "id": 1
+  },
+  {
+    "jsonrpc": "2.0",
+    "method": "wallet_invokeMethod",
+    "params": {
+        "scope": "eip155:59144",
+        "request": {
+            "method": "eth_getBalance",
+            "params": ["0xabc...", "latest"]
+      }
+    }
+    "id": 2
+  }
+]);


Suggested change

provider.request([

{

"jsonrpc": "2.0",

"method": "wallet_invokeMethod",

"params": {

"scope": "eip155:1",

"request": {

"method": "eth_getBalance",

"params": ["0xabc...", "latest"]

}

}

"id": 1

},

{

"jsonrpc": "2.0",

"method": "wallet_invokeMethod",

"params": {

"scope": "eip155:59144",

"request": {

"method": "eth_getBalance",

"params": ["0xabc...", "latest"]

}

}

"id": 2

}

]);

provider.request([

{

"id": 1,

"jsonrpc": "2.0",

"method": "wallet_invokeMethod",

"params": {

"scope": "eip155:1",

"request": {

"method": "eth_getBalance",

"params": ["0xabc...", "latest"]

}

}

},

{

"id": 2,

"jsonrpc": "2.0",

"method": "wallet_invokeMethod",

"params": {

"scope": "eip155:59144",

"request": {

"method": "eth_getBalance",

"params": ["0xabc...", "latest"]

}

}

}

]);

nit

(moves the ids to the top)

The JSON-RPC 2.0 spec examples shows the id after method & params. Is there a reason to order them differently?

jiexi · 2024-06-25T22:58:24Z

MIPs/mip-x-request.md

+In this example, the `scope` field is populated with the [CAIP-2](https://chainagnostic.org/CAIPs/caip-2) identifier for Ethereum Mainnet, and the `request` field contains the typical JSON-RPC request for getting an Ethereum balance.
+
+##### Batch Request for Multiple Chains
+Here's an example of how JSON-RPC batch requests to get balances from both Ethereum Mainnet and Binance Smart Chain would be called by wrapping the requests in a `provider_request`:


we need to get the JSON-RPC batching MIP going again

#39

MIPs/mip-x-request.md

Add error scenario for attempts to call unauthorized methods. Co-authored-by: jiexi <[email protected]>

Elenore23

thx

Elenore23

ok

vandan added 3 commits January 25, 2024 01:44

MIPs for the multichain-optimized API

a36d33b

Initial commit of draft MIPs for a new multichain-optimized API

Update mips-by-status.md

691108f

Update mip-mc-request.md

3fc869b

vandan added the team-wallet-api-platform label Jan 30, 2024

vandan self-assigned this Jan 30, 2024

vandan added 2 commits February 1, 2024 08:50

Minor Multichain MIP updates + general improvements

e0f5102

Refines the language used in the multichain handshake MIP. Removes Future section in the mips-by-status page General improvements: Adds proper discussion-to links to MIP-1 and MIP-2

Multichain Handshake

829fbf8

Updates to the multichain handshake proposal

jiexi reviewed Feb 13, 2024

View reviewed changes

MIPs/mip-mc-handshake.md Outdated Show resolved Hide resolved

jiexi reviewed Feb 13, 2024

View reviewed changes

MIPs/mip-mc-handshake.md Outdated Show resolved Hide resolved

jiexi reviewed Feb 13, 2024

View reviewed changes

vandan and others added 2 commits February 21, 2024 15:59

Update MIPs/mip-mc-handshake.md

1ccc4a2

Co-authored-by: jiexi <[email protected]>

Update MIPs/mip-mc-handshake.md

9e8260d

Co-authored-by: jiexi <[email protected]>

shanejonas reviewed Feb 27, 2024

View reviewed changes

MIPs/mip-mc-handshake.md Outdated Show resolved Hide resolved

bumblefudge reviewed Feb 27, 2024

View reviewed changes

MIPs/mip-mc-request.md Outdated Show resolved Hide resolved

bumblefudge reviewed Feb 27, 2024

View reviewed changes

adonesky1 reviewed Mar 5, 2024

View reviewed changes

MIPs/mip-1.md Outdated Show resolved Hide resolved

Update MIPs/mip-mc-request.md

616d86c

Accept adjustments Co-authored-by: Bumblefudge <[email protected]>

shanejonas reviewed Mar 8, 2024

View reviewed changes

hmalik88 reviewed Mar 15, 2024

View reviewed changes

MIPs/mip-mc-request.md Outdated Show resolved Hide resolved

This comment was marked as spam.

Sign in to view

vandan and others added 4 commits April 9, 2024 14:23

Remove unrelated changes from the commit message

5274037

Update MIPs/mip-mc-request.md

8b1b059

Co-authored-by: Hassan Malik <[email protected]>

Update MIPs/mip-mc-handshake.md

4d9a3e6

Connect this MIP with the relevant discussion thread Co-authored-by: Shane <[email protected]>

jiexi reviewed Jun 25, 2024

View reviewed changes

Clean up code formats & errors

e9625ff

Minor cleanup of requests/response code examples

jiexi reviewed Jun 25, 2024

View reviewed changes

Naming consistency

be0305a

Update naming for consistency

jiexi reviewed Jun 25, 2024

View reviewed changes

MIPs/mip-x-request.md Show resolved Hide resolved

Update MIPs/mip-x-request.md

5c37e71

Add error scenario for attempts to call unauthorized methods. Co-authored-by: jiexi <[email protected]>

Elenore23 reviewed Dec 4, 2024

View reviewed changes


		This method is intended to be part of a new version of the MetaMask Wallet API that is optimized for multichain interactions.

		This proposal aims to implement CAIP-25's JSON-RPC Provider Authorization into MetaMask. For EVM (eip155) networks, the `rpcEndpoints` parameter is adapted to be compliant with the object structure defined in EIP-3085. Designing the interface in this way will provide a standardized approach for dApps to request access to networks and JSON-RPC methods.


		- Additional metadata fields in `rpcEndpoints` SHOULD be compliant with the fields specified in EIP-3085.

		[ TODO a PR in the api-spec repo describing the provider_authorize method in OpenRPC should be added here ]


		## Definitions

		Add a note about how we use the terms `chain` and `network` interchangeably


		## Motivation

		The purpose of this proposal is to offer a convenient and standard pattern for applications to negotiate multiple network authorizations with MetaMask.


		The `wallet_authorize` method is specifically meant to:

		- Allow applications to progressively negotiate a set of authorizations with MetaMask


		wallet scope: A scope that applies to capabilities that a MetaMask Wallet client can handle in a relatively self-contained way. They are not specific to a network or namespace.

		eip155:wallet scope: A CAIP-2 identifier with a reserved `wallet` as the `reference`. For example "eip155:wallet" indicates a scope that is not specific to a particular Ethereum network but is related to the `eip155` `namespace`.

	When a MetaMask user does not have an existing network configured for a given eip155 chainId, including metadata for `rpcEndpoints` in the `scopeMetadata` will suggest the user add the first endpoint in the list. MetaMask expects the `rpcEndpoints` parameter to conform with the [EIP-3085](https://eips.ethereum.org/EIPS/eip-3085) standard.
	When a MetaMask user does not have an existing network configured for a given eip155 chainId, MetaMask will suggest the user adds the first endpoint defined in the `rpcEndpoints` property of the `scopeMetadata` object. MetaMask expects the `rpcEndpoints` parameter to conform with the [EIP-3085](https://eips.ethereum.org/EIPS/eip-3085) standard.

Initial Multichain MIP drafts #31

Are you sure you want to change the base?

Initial Multichain MIP drafts #31

Conversation

vandan commented Jan 30, 2024 • edited Loading

jiexi commented Feb 13, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bumblefudge Feb 27, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bumblefudge Apr 5, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bumblefudge Feb 27, 2024 • edited Loading

Choose a reason for hiding this comment

shanejonas Mar 8, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bumblefudge Feb 27, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bumblefudge Mar 13, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

This comment was marked as spam.

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Elenore23 left a comment

Choose a reason for hiding this comment

Elenore23 left a comment

Choose a reason for hiding this comment

vandan commented Jan 30, 2024 •

edited

Loading

bumblefudge Feb 27, 2024 •

edited

Loading

bumblefudge Apr 5, 2024 •

edited

Loading

bumblefudge Feb 27, 2024 •

edited

Loading

shanejonas Mar 8, 2024 •

edited

Loading

bumblefudge Feb 27, 2024 •

edited

Loading

bumblefudge Mar 13, 2024 •

edited

Loading