Update CAIP-25 based on CASA Gathering in Amsterdam

[pedrouid]

The proposed changes to CAIP-25 API for supporting multiple namespaces with separate scope for chains, methods and events as an array

The motivation is to separate methods and events for different chain sets which would not share the same methods

For example a chain with EIP155 namespace would use methods such as personal_sign and eth_sendTransaction but if we added a chain with COSMOS namespace it would use methods like cosmos_signDirect and cosmos_signAmino which are not compatible with the latter.

Hence you can have an array with separate scopes as follows

{
    "id": 1,
    "jsonrpc": "2.0",
    "method": "caip_handshake",
    "params": [
        {
            "chains": ["eip155:1"],
            "methods": ["eth_sendTransaction", "eth_signTransaction", "eth_sign", "personal_sign"]
            "events": ["accountsChanged", "chainChanged"]
        },
        {
            "chains": ["cosmos:cosmoshub-4"],
            "methods": ["cosmos_signDirect", "cosmos_signAmino"],
            "events": [],
        }
    ]
}

Additionally as part of this PR we have added events which weren't considered before as part of the spec but very relevant part of any asynchronous API

[Talhaali00]

@pedrouid Would it make more sense to separate the chain from the id and change params from a list of Namespaces to a map like the one below? It'll help reduce having to repeat chain info like eip155 when updating the Namespace as well as create an identifier for developers to easily search for the chains that are desired. Also, it might help reduce multiple Namespaces with the same parent chain information from being created due to lack of understanding or user error

params: [
       "eip155" : {
            "chains": ["eip155:1"],
            "methods": ["eth_sendTransaction", "eth_signTransaction", "eth_sign", "personal_sign"]
            "events": ["accountsChanged", "chainChanged"]
        },
        "cosmos" : {
            "chains": ["cosmos:cosmoshub-4"],
            "methods": ["cosmos_signDirect", "cosmos_signAmino"],
            "events": [],
        }
    ]       

[ligi]

I was in another session in parallel - just reading up on the notes- would be great to discuss this in the next call. While I see where this is coming from - IMHO it is a bit unfortunate that we manifest the statefulnes regarding chain/account even more. I think in an ideal world we should not have a "current account" / "current chain"

[rekmarks]

@TalhaAli00 I like that. Your format with some modifications:

params: { // object instead of array
  "eip155" : {
    "chains": ["1"], // namespace omitted from chainId
    "methods": ["eth_sendTransaction", "eth_signTransaction", "eth_sign", "personal_sign"]
    "events": ["accountsChanged", "chainChanged"]
  },
  "cosmos" : {
    "chains": ["cosmoshub-4"], // namespace omitted from chainId
    "methods": ["cosmos_signDirect", "cosmos_signAmino"],
    "events": [],
  }
}

I'm agnostic as to whether we do this. I think it's maybe slightly more ergonomic to parse and write types for the above format, but at the end of the day we can live with either. What do you think @pedrouid?

[pedrouid]

My concern with the above suggestion is that it doesn't allow supersets of namespaces

Let's say an app wants to connect to 3 EVM chains: Ethereum Mainnet, Polygon and Optimism

If all of then support the same methods then it's ok to use the above schema which keys by namespace

However if one of them has an extra method or event then we can't specify it separately like the following example:

[
        {
            "chains": ["eip155:1", "eip155:137"],
            "methods": ["eth_sendTransaction", "eth_signTransaction", "eth_sign", "personal_sign"]
            "events": ["accountsChanged", "chainChanged"]
        },
        {
            "chains": ["eip155:10"],
            "methods": ["eth_sendTransaction", "eth_signTransaction", "eth_sign", "personal_sign", "eth_signProof"]
            "events": ["accountsChanged", "chainChanged", "proofFinalized]
        }
    ]

[rekmarks]

@pedrouid great point. Let's stick with the existing format!

[bumblefudge]

overtaken by events