Added OpenRPC doc for CAIP-25

[shanejonas]

This pull request adds an OpenRPC document to describe CAIP-25, not sure where to link to it in the markdown, let me know if you have any suggestions.

Here is a preview in the playground:

https://playground.open-rpc.org?url=https://raw.githubusercontent.com/shanejonas/CAIPs/caip-25-openrpc/assets/CAIP-25/openrpc.json

[hmalik88]

shouldn't this be "by-name"?

[shanejonas]

ah yes, I think we were playing around with this setting when we were chatting.

[bumblefudge]

I think by-position might be better, at least as written, because the requiredScopes and optionalScopes objects, as currently specified, are both optional-- by-name/key-locked array parsing would expect empty ones (arrays with 0 members) rather than null arrays at that keyvalue, right?

[shanejonas]

In JSON-RPC, the params key can either be an object or an array. The example in CAIP-25 uses the by-name format, where params is an object. It is not specified if this is a requirement or if using params: [] as an array is also allowed.

[bumblefudge]

my question was about a request with no optionalScopes -- am I misreading or would a response without an optional object still be valid under by-name parsing?

[shanejonas]

by-name would be

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "provider_authorization",
  "params": {
    "requiredNamespaces": {
      "eip155": {
        "chains": [
          "eip155:1",
          "eip155:137"
        ],
        "methods": [
          "eth_sendTransaction",
          "eth_signTransaction",
          "eth_sign",
          "get_balance",
          "personal_sign"
        ],
        "events": [
          "accountsChanged",
          "chainChanged"
        ]
      },
      "eip155:10": {
        "methods": [
          "get_balance"
        ],
        "events": [
          "accountsChanged",
          "chainChanged"
        ]
      },
      "cosmos": {}
    },
    "optionalNamespaces": {
      "eip155:42161": {
        "methods": [
          "eth_sendTransaction",
          "eth_signTransaction",
          "get_balance",
          "personal_sign"
        ],
        "events": [
          "accountsChanged",
          "chainChanged"
        ]
      }
    },
    "sessionProperties": {
      "expiry": "2022-12-24T17:07:31+00:00"
    }
  }
}

by position would look like:

{
    "jsonrpc": "2.0",
    "method": "provider_authorization",
    "params": [
        {
            "eip155": {
                "chains": [
                    "eip155:1",
                    "eip155:137"
                ],
                "methods": [
                    "eth_sendTransaction",
                    "eth_signTransaction",
                    "eth_sign",
                    "get_balance",
                    "personal_sign"
                ],
                "events": [
                    "accountsChanged",
                    "chainChanged"
                ]
            },
            "eip155:10": {
                "methods": [
                    "get_balance"
                ],
                "events": [
                    "accountsChanged",
                    "chainChanged"
                ]
            },
            "cosmos": {}
        },
        {
            "eip155:42161": {
                "methods": [
                    "eth_sendTransaction",
                    "eth_signTransaction",
                    "get_balance",
                    "personal_sign"
                ],
                "events": [
                    "accountsChanged",
                    "chainChanged"
                ]
            }
        },
        {
            "expiry": "2022-12-24T17:07:31+00:00"
        }
    ],
    "id": 0
}

[bumblefudge]

This is super helpful! I'll update and merge this after we decide other PRs (which would change the names of the properties and make this obsolete, haha). Some questions before our next meeting:

1. Future PRs would have to update the spec, the examples in the spec, the OpenRPC, and the OpenRPC examples, correct?
2. Should the spec link to the playground as well, or just the .json file (which a little googling leads me to think that GitPages will automatically serve as UTF-8 MIME-type application/json)?

[shanejonas]

@bumblefudge, the OpenRPC Document would serve as the formal/machine readable spec for the API, incorporating information from CAIP-25, CAIP-207, and any other relevant CAIPs.

[bumblefudge]

right, my reference to "other PRs" was to #206 and #211 , both of which would change the name of values here, as might future PRs until CAIP-25 goes to Last Call Final

[hmalik88]

This is super helpful! I'll update and merge this after we decide other PRs (which would change the names of the properties and make this obsolete, haha). Some questions before our next meeting:

1. Future PRs would have to update the spec, the examples in the spec, the OpenRPC, and the OpenRPC examples, correct?
2. Should the spec link to the playground as well, or just the .json file (which a little googling leads me to think that GitPages will automatically serve as UTF-8 MIME-type application/json)?

1. Yes
2. I don't have a strong opinion about this, the playground is to show and prove that the spec makes sense and that the rpc call would work. If we decide to ask for openRPC docs for all the JSON-RPC specs than maybe we can just have the playground link in some central place?

[obstropolos]

It looks like 217 might cover this - @shanejonas is it okay if we move this to close?

[pedrouid]

@shanejonas @hmalik88 @bumblefudge @obstropolos I think we can close this in favor of #217

[hmalik88]

@shanejonas @hmalik88 @bumblefudge @obstropolos I think we can close this in favor of #217

yeah, that's fine.

[obstropolos]

Two weeks since original request for closing - closing for now.