Skip to content

Feat/caip 25 include examples of wallet methods#224

Merged
pedrouid merged 2 commits intofeat/update-caip27-to-be-constrained-by-25from
feat/caip-25-include-examples-of-wallet-methods
Apr 13, 2023
Merged

Feat/caip 25 include examples of wallet methods#224
pedrouid merged 2 commits intofeat/update-caip27-to-be-constrained-by-25from
feat/caip-25-include-examples-of-wallet-methods

Conversation

@pedrouid
Copy link
Copy Markdown
Member

@pedrouid pedrouid commented Apr 13, 2023

Since we haven't merged #217 I thought it would be useful to include wallet_ prefixed methods to the CAIP-25 example to show how it would work with the new scopes

"methods": ["get_balance"],
"notifications": ["accountsChanged", "chainChanged"]
},
"wallet": {
Copy link
Copy Markdown
Collaborator

@bumblefudge bumblefudge Apr 13, 2023

Choose a reason for hiding this comment

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

I'm unclear, are these methods:

  1. execution API methods defined in an eip155 namespace with empty scopes and empty chains or
  2. a new namespace named wallet for chainagnostic methods that needs to be created based on the wallet_-prefixed subset of eip155 methods, with CAIP-169 thrown in for good measure?

If you meant this as (2), I would be glad to open a PR in namespaces, and if it's (1), it might also double as a convenient example of when scopes and accounts are both empty by design:

Suggested change
"wallet": {
"eip155": {
"scopes":[],
"acounts":[],

Either way, give me a little more context here and I'll see if this helps us get over the line on consensus with 217!

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

IMO the biggest advantage to renaming "namespaces" to "scopes" is that we get to define a set of methods and notifications which are not necessarily associated with a given chain or namespace

Many of these methods exist today in production (wallet_addEthereumChain, wallet_switchEthereumChain, wallet_watchAsset, wallet_getPermissions and wallet_requestPermisions) yet they are generic wallet methods which are not directly related to any chain

Plus it gets even more powerful once you add CAIP-169 methods ("wallet_creds_store", "wallet_creds_verify", "wallet_creds_issue" and "wallet_creds_present") which are also generic wallet methods that are not directly related to any chain

In my understanding, this PR describes an example that complies with CAIP-217 and CAIP-25 but I thought it was really important to showcase in the spec to share how powerful scopes are

Copy link
Copy Markdown
Collaborator

@bumblefudge bumblefudge Apr 13, 2023

Choose a reason for hiding this comment

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

OK that sounds more like interpretation # 2 -- I was mostly just thinking ahead to how this relates to the OpenRPC/CAIP-211 stuff (i.e. what the implicit rpcDocuments are for the wallets namespace!), but happy to open a PR on namespaces (I like all examples to be currently-conformant at time of merge haha)

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Copy link
Copy Markdown
Collaborator

@hmalik88 hmalik88 left a comment

Choose a reason for hiding this comment

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

LGTM.

We do need to think about rpcDocuments for the wallet namespace like @bumblefudge mentioned, multiple wallets can have overlapping wallet_ methods.

@pedrouid pedrouid merged commit 5afcb22 into feat/update-caip27-to-be-constrained-by-25 Apr 13, 2023
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.

4 participants