CAIP-25: extensions considered harmful?

[rekmarks]

Ref: #138

Problem

When the dapp submits a CAIP-25 request, it may desire to request some methods or events for specific chains only, as opposed to the entire namespace. Given that top-level keys in the request object are namespaces, this presents a challenge. Consider:

{
  "eip155": {
    "chains": ["eip155:137", "eip155:1"],
    "methods": ["eth_sign"],
    "events": ["accountsChanged"],
  },
}

The current WalletConnectV2 implementation of CAIP-25, solves this by adding a field named extensions to the namespace object:

{
  "eip155": {
    "chains": ["eip155:137", "eip155:1"],
    "methods": ["eth_sign"],
    "events": ["accountsChanged"],
    "extensions": [
      {
        "chains": ["eip155:137"],
        "method": ["personalSign"],
        "events": ["chainChanged"]
      }
    ]
  },
}

While this certainly works, it introduces complexity on the part of the wallet, which must essentially perform set operations (IIRC, the word used was "diffing") on the configuration for chains for which extensions are specified. Multiple people objected to this, and argued that a configuration format should explicitly state the configuration for each chain/namespace.

Proposed Solution

Instead of the extensions field, attendees suggested that top-level keys can be chain ids in addition to namespaces. This makes the object "literal" and ensures that no set operations have to be performed by the wallet during parsing:

{
  "eip155:1": {
    "methods": ["eth_sign"],
    "events": ["accountsChanged"],
  },
  "eip155:137": {
    "methods": ["eth_sign", "personalSign"],
    "events": ["accountsChanged", "chainChanged"],
  },
  "cosmos": {
    "chains": ["cosmos:cosmoshub-4", "cosmos:cosmoshub-5"],
    "methods": ["cosmos_signDirect"],
    "events": ["someCosmosEvent"]
  }
}

[orenyomtov]

My 2 cents on the subject:

Let's keep the JSON-RPC API spec to be as close to a 1-to-1 representation of the data that it is conveying.

By not doing so (e.g. the "extensions" feature) we introduce a lot of unnecessary complexity (and eventually bugs) at the implementation level - basically requiring each integration to implement a "transpilation" step in order to extract the data from the request.
I'd like to suggest the following axiom/value for us when designing this spec: we're solving for complexity, not data transportation optimization.
For many reasons, one being that the handshake request happens extremely infrequently, and it is usually communicated locally, e.g. between a webpage and a web extension.
Also in the model of "separation of concerns" or the unix philosophy of "make each program do one thing well" - a transportation layer compression algorithm will better take care of it anyway (brotli/gzip in the http request level).

I'd also edit the cosmos area of the proposed solution to be:

{
  "eip155:1": {
    "methods": ["eth_sign"],
    "events": ["accountsChanged"],
  },
  "eip155:137": {
    "methods": ["eth_sign", "personalSign"],
    "events": ["accountsChanged", "chainChanged"],
  },
  "cosmos:cosmoshub-4": {
    "methods": ["cosmos_signDirect"],
    "events": ["someCosmosEvent"]
  },
  "cosmos:cosmoshub-5": {
    "methods": ["cosmos_signDirect"],
    "events": ["someCosmosEvent"]
  }
}

[bumblefudge]

Closed by #187 but feel free to open a new issue if not fully so!