RPC WG - Call 15 July 2024

[bumblefudge]

• agenda
  • required scopes - mark and pedro presence requested
    • pedro: synthesis of previous conversations
      • currently all headaches, no use-case; omitted from our docs 6 months ago
      • supporting it costs us lots of client-side logic and complexity
    • mark: if wallet still had authority and req was a SHOULD not a MUST...
    • al: breaking behavior when req not met is the problem; 2 diff categories for signaling purposes seems
    • bumblefudge: bikeshed names? it's not required if wallet gets to override it, it's just a different category of request
      • pedro: but requestedScopes is redundant, it's... in the request
      • mark: idunno, maybe we don't rename it but just change the specified behavior; a wallet authorizing partially the caps described as required should be allowed, since a wallet fundamentally should have override capabilities
    • pedro: it was actually intentional to give the dapp an ultimatum capability; it's just years too early for the web3 landscape
    • shane: could this just be a warning or a popup?
    • mark: can wallet return almost all properties for a given scope String? bf: not as written or as impl by WC... pedro: optional and req CAN contain scopeObjects with the same key, if only some props of that namespace are req.
    • pedro: so is the fundamental request that requiredScopes but response obligation loosened
    • bf: ok sounds like a PR for me to write - response freedom, semantics should define req as signal of caller requirement, NOT signal of connection requirement
      • - bf will open a PR
      • mark: analogy from web2 - apple exposed something similar but made it impossible for enduser to see hard requirement popups, to keep traffic and trust in the app store
        • unfair analogy to apple, because MM can discourage dapps, while app store needs to be neutral to apps and websites alike...
  • wallet namespace
    • meta-namespace
    • - bf will open a counter-PR on namespaces to save time - @vandan keep welcome to keep elaborating this one in parallel and we can discuss both options next week; SEE ALSO CAIPs#288, on which review would be both welcome and TIMELY
  • 285
    • newest version here
    • overview - updates pushed out to separate method; revoke session (no params); get_session(); notification for wallet to signal changes to session;
    • pedro: multisession and single session seem both supported
      • corner case to worry about - dapp is single session and wallet is multisession returning sessionId each time; wallet connect today would throw error (abstractable)
    • - everyone read the new version of PR 285 closely by next week!
  • merge wordsmithing PRs and scopedProperties PR
    • waiting on @hmalik88 for [https://github.com/[Caip-25] make-wildcard-ban-more-explicit CAIPs#289#discussion_r1671931151]
    • persist bikeshed?
      • getSession method eases this a bit- dapp can always fetch that state, so it's not really a "persistance" requirement
      • - bf will open a tracking issue to come back to language of persistence/state maintenance once sessionId stuff is sorted
  • CAIP-27 notifications: wallet>caller notify how?
    • eth_subscribe, other use-cases
      • how could people do this without selectChain methods?
    • separate CAIP#, diff method name, for other direction?
    • Al: semantics/method naming is only real issue, since JSON-RPC formats notifs the same way anyways (method/params)
      • shane: copypasting a 2nd CAIP is a maintenance burden, non? alex: then just add a second method into the same CAIP