Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update CAIP-25 based on CASA Gathering in Amsterdam #108

Closed
wants to merge 5 commits into from

Conversation

pedrouid
Copy link
Member

@pedrouid pedrouid commented Apr 26, 2022

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
Copy link

Talhaali00 commented Apr 28, 2022

@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
Copy link
Member

ligi commented Apr 28, 2022

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"

Copy link
Member

@ligi ligi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That said: formally (from an editors point of view I approve this change)

Copy link
Contributor

@rekmarks rekmarks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved with one non-blocking suggestion. I'll follow up with some notes regarding the shape of the params.

}
```

The JSON-RPC method is labelled as `caip_handshake` and expects two parameters:
The JSON-RPC method is labelled as `caip_handshake` and expects an array with objects with three parameters:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The JSON-RPC method is labelled as `caip_handshake` and expects an array with objects with three parameters:
The JSON-RPC method is labelled as `caip_handshake` and expects an array with objects with three properties:

@rekmarks
Copy link
Contributor

rekmarks commented May 5, 2022

@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
Copy link
Member Author

pedrouid commented May 5, 2022

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
Copy link
Contributor

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

@bumblefudge
Copy link
Collaborator

overtaken by events

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants