Workshop Notes: JSON-RPC API

[expede]

• Timeslot: 2pm
• Convener: @pedrouid
• In attendance: @pedrouid, @expede, @matheus23, @avivash,

WIP I'm going to clean this up after the next session 😅

• [We should have a scribe -- I guess it's going to be @expede!]
• What is everyone doing?
  • Progressive decentralization wallet early in progress
• Pedro:
  • there's always parties: wallet and server
  • This spec should decouple it
  • WCv2 two variables: chain & wallet
  • Signal the to Dapp that you have certain requirements
  • Wallets want to support as much as possible
• Some wallets have all chains running together
• Speaking from MM: account switching & chain switching are a historical artifact
  • For the archeologiests:
  • geth used to have a single chain at a time, switch between them
  • MM inherited this model
  • Everyone hates switching, trying to get rid of it
  • Things are going to multiple chains at once, MM paying off the tech debt for that
• Shoudl we also specify the relayer? Could make UX better cross chain for stuff like gasless txs.
  • Pedro: probably out of scope, because WC is a proxy for the JSON RPC
  • More in the realm of the wallet itself
• Who is building an app that could go across several chains at once?
  • Andy: we're going to need to do this for Laconic (data availability network)
• CAIP-25 has a connect method, with params like chains array and methods array
• CAIP-27 request methods against a chain ID
• What would blockchain.js look like (where it has to work with every blockchain ever)
  • Would it have a get_account, get_chains, get_methods?
  • Also think about success/failure states, error codes. WC has 4 error codes
  • Worth having success types? No, not in JSON-RPC
• Eric: EIP-1193 only method and params are required, no JSON-RPC version, etc, and will reject if there's a JSON-RPC error
  • So, should this return generic success, or actually a structured response type? Shoudl it throw the error if it's one, etc?
  • "Exceptions should be exceptional, not control flow", versus return value level
  • WC has a framework for JSON-RPC error messages, and abtrsactiosn over provider and transports
  • Don't need to respolve the question right now
  • in the ecosystem, many dapps use them over the provider anyway. Not sure how they wrap ethereum.request, can be changed as the spec evolves
• Philipp: would it be possible/useful to have different methods for different chains?
  • Pedro: namespaces have the lots of similar methods (tx, sign, etc)
  • when you start mixing namespaces, you're mixing the set with different namespaces
    • sets of multiple chains per method
    • Under the hood, there will be a router, but what if delegated to blockchain.js or put in the spec with differet provider objects per chain, then CAIP has a create_provider method
    • In 1193, providers are injected into the DOM
    • Annyonig to specify the methods for every chain
  • (Photo 2 here)
    • Today we have sets but no scoping, but we could go very verbose way (large payloads)
    • Different chains will have different data (e.g. ZK chains)
  • Alternative: eip1195-eip1193 would be a selector for an entire selector set?
    • Something like behaviours, and which chains use them?
  • Problem with eip-1195 namespace is that it specifies the chain ID
  • Method sets
    • Default one: why would a dapp developer use anything other than the default set?
  • B is very verbose, but what if superceded CAIP-25 (new C see photo):

      [
        {chains: [], methods: []},
        {chains: [], methods: []}, ...
      ]

  • Cello when has different RPC method set, it would get a vew chain & method set, per namespace
  • It's up to the wallet to support a method for a certain namespace
  • Wallet will try to mao a method to each namespace, will throw error if the method doesn't exist, etc
  • Can we have a mulktichain provider API, with each provider on one namespace? Don't mix namespaces
  • Is there a future where wallets implement both APIs, coudl this impact UX? If a wallet implements Ethereum & Cello, wallet can handle both, so UX would be better
• In WC we have a multi-ethereum wallet, multi-solana wallet, etc
• C is a superset of A
• CAIP-25 may change
• Also need to look at events like accounts_change, chain_change(?), etc

[bumblefudge]

A/B/C refers to:

[PeterTheOne]

I participated! :D