RPC/CAIP-25 Biweekly Meeting Notes 7Dec 2022

[bumblefudge]

2022-12-05

PRs to refine/move to close

• alternate extension model PR#185
  • not too controversial - let's merge it for now (or close because other PR includes all its commits)
• idempotency edit
  • merged!
• opt/req PR#187 - Preview
  • sessionProperties
  • requiredNamespaces, optionalNamespaces
  • session --> sessionNamespaces
  • merge conflicts
  • sessionIdentifier --> sessionId
  • - @bumblefudge will open a follow-on PR to mark for Review (14-day merge tag)

Ongoing issues/topics

• CAIP-27 - advise please on what would is needed
  • - sessionIdentifier-->sessionId
  • - @HMB-88 will further PR
• Remaining Issues to ship CAIP-25
  • Do today's PRs close extensions considered harmful or are there next steps we can recommend/require before close?
  • Accounts
    1. Are there account-free sessions? Are there account-required dapps or account-required sessions? Should there be a sessionParams property in CAIP-170 that allows this request/response to be part of a CAIP-25?
       • Pedro: wallet_ namespace might have an empty accounts-mode
       • Oren: We can imagine use-cases for read-only methods thru provider, etc.
       • Pedro: what if default is to allow empty accounts, but 170 could include an add_account method? avoid flags
    2. any error codes needed?
       • session property and wallet property should have own error co
    3. do CAIP-27s ever require an account, or change whether an account is authorized for a session? Can you request a method and get an account in the response?
    4. editorial PR needed to add accounts assumptions to CAIP-25 text?
  • Sessions - Are we comfortable with 25 shipping before 170? If so, should we make a wishlist or a to-do list for 170 at least?
  • wallet namespace - Same question, anything urgent or do we keep this iterating in parallel after 25 goes to Review?
    • Need separate /namespace?
    • CAIP-25 should include warning that namespace can't be required and can't have chains? Pedro: Not necessary, implementer beware
    • just stick wallet methods into a namespace?
    • - @bumblefudge to open draft PRissue for wallet_ in /namespaces to collect input but not decide any time soon
• Multiple Wallets - blocker for merge to Review or long-term issue to explore in parallel? If the former, tell Juan what to do next
  • leaving open but

Next Steps