# CASA RPC WG - Biweekly Meetings

[📹 Join the meeting](https://meet.ethereum.org/CASA)
[💬 Join the Discord](https://discord.gg/nVyUMe9b)
[📅 Meetings calendar](https://bit.ly/thepubliccasacalendar)

## template
### PRs to refine/move to close
### Ongoing issues/topics
### Next Steps

## Future topics parking lot

- soft-wrap formatting is killing us all with merge conflicts
- jiexi's redundant scopeObject case (`eip155:1` + `eip155.scopes("1")` in same session) - better specify corner case?
- EIP-3770 and/or next-gen version?
- user-friendly overlays (such as EIP-3770) <> underlying canonical forms
- canonical
- tooling and adoption? work with dapp libraries to get the connection stuff and the Snaps stuff
- establish feedback loop with implementers and prototypers and evaluators

## 17 Dec

- [CAIP#384](https://github.com/ChainAgnostic/CAIPs/pull/384) and [CAIPs#385](https://github.com/ChainAgnostic/CAIPs/pull/385) - Status of this WG's RPCs
- al: terminology getting overloaded; we need a guide (non-norm CAIP? me: _blogpost?_)
- CAIP-217 - `references[]` --> `chains[]`
- [X] pedro to open [PR](https://github.com/ChainAgnostic/CAIPs/pull/389/files)
- CAIP-27 uses `scope` but means `chainId` (CAIP-104s not allowed)
- `scope` --> `chainId` (since can only be a caip-2)
- CAIP-25
- pedro: but shouldnt `accounts` be `addresses` on each chain?
- pedro: `chains` should be `chainreferences[(chainreference)+]`
- ADD 312, 311, AND 316 (non-normative BCP)
- CASA generally
- Website, blog, etc
- DevConnect event
- Blog post re: RPC status? Overview?
- Goals for 2026
- Capabilities (282/294) getting more solid and load-bearing
- DevRel -
- Juan still owes a non-normative EIP pointing to CAIPs and crossdeps so far

## 9 Oct

- not much agenda
- [caips#348](https://github.com/ChainAgnostic/CAIPs/pull/348)
- [ ] Jiexi to clarify/make more explicit the diff from status quo
- backstory behind [379](https://github.com/ChainAgnostic/CAIPs/pull/379/files)
- corner case caused by solana disconnect method
- bf: worth mentioning in solana/caip25.md? al: prolly only applies to metamask because of legacy/deprecated stuff, i doubt anyone else would work on it
- al: more generally, might not even worth documenting, much less standardizing, might work it self out between now and others hitting this rough edge

## 25 Sept

- Landing CAIP-282/294 ?
- CAIP-25 refactor
- order of operations:
- approve this
- add eip155/caip2
- open issue for corner-case of "implicit chainId 0 grant" (methods parked)
- versioning:
- sit in implementation backlog on both sides? call it a breaking change?
- jiexi: if no one was consuming it directly or building against it (SDK-based on both sides), never called it stable, maybe it's fine to break?
- al: but coordinating Reown/MM SDK bumps?
- good to have eyes on it, even if no one else is directly implementing it
- name-change breaks name recog/momentum
- priority
- aligned on examples and syntax; chainId 0 case can come later

## 11 Sept

- main agenda: https://github.com/pedrouid/CAIPs/pull/16
- optional accounts?
- pedro: empty arrays are bad devex, people complain; accounts? (optional) better imho
- jiexi: making `notifications` optional too, no? pedro: breaking change, tho...
- jiexi: that's fine, i can live with that
- wallet scopes?
- jiexi: lots of the methods in this feel kinda special-casey, like a wallet capability expression more than an authorization
- pedro: surprisingly on the WC side and client side, the special namespace confused lots of people;
- `wallet` scope
- pedro: these `wallet_` methods are already implicit in (reqd by) CAIP-25; these can be called inside OR OUTSIDE of a caip-25 session
- Al: I say we leave the CAIP-25 methods out of the examples, it's verbose; but i like `wallet` for non-namespaced methods
- we could also spec it later or add the example later
- pedro: might be cool to have an example, but first example should be simplest (and not have anything confusing in it)
- pedro: what does `chains` prop contain in wallet scope, tho? (it's optional in response)
- jiexi: i'm fine to leave it out for now; consensus?
- `wallet:eip155` scope
- al: needed for all the non-broadcasted signing methods (personal sign and 712)
- jiexi: i've come full circle, i think it's hard to deal with wallet:eip155; maybe it's easier to just say a non-broadcast/offchain method can be called against any chain (i.e. within an authorized scope), but must be
- pedro: that's how it works at WC today, and that's why eip155:0 is kinda useful (e.g., as the target chain in CAIP-27)
- pedro: devrel issue; anything that takes more than 15min to explain is diminishing returns for WC devs... wierdly wallet namespaces was harder to explain than eip155:0
- jiexi: other namespaces can always define their :0 equivalent... it's between ecosystems and wallets
- pedro: maybe this is an outreach thing, we should maybe approach the caip-2 authors and ask them to propose null/0 chainids?
- jiexi: but what does the caip-25 look like? how do we define scopes for these ?
- al: do you have to req/authorize chainId 0 to call non-broadcast methods against 0?
- pedro: no authZ for chainId 0 feels explicit-- you get 0 any time you authorize any eip155 chains, non? if i only have eip155 chains authorized, and i call a solana offchain method, that should fail, tho
- al: where do you stick non-broadcast methods?
- al: i am wondering if we can fully remove wallet and wallet:eip155 alike, for now?
- `wallet_addEthereumChain`, for ex?
- requested/authZd against eip155:0?
- al: diminishing returns, maybe wallets can choose how strict to be on it (or how to return it)
- extensions/exceptions are unpopular everywhere; anything chain-specific has to happen in a separate scope
- pedro: note that in the current draft, response is verbose to elaborate a snowflake chain
- pedro:
- next steps
- [ ] pedro - consolidate, merge to CASA repo
- [ ] pedro - PR on CAIP-27 making chainId mandatory and explaining to use chainId 0 or equiv when
- [X] bf - PR on namespaces/eip155/caip2.md section on semantics of chainId 0 (as opposed to CAIP:10 semantics)

## 21 August

- Agenda
- main event: [simplifying CAIP-25 PR](https://github.com/pedrouid/CAIPs/pull/12/files)
- `accounts` mandatory? empty allowed?
- bf: some VMs don't require for connection or use it at all, so some namespaces should mention in their caip10 and/or caip25 profiles how this should work
- pedro: maybe don't mention this complexity (which namespaces allow empty, etc) in caip25 spec
- al: if accounts don't live in caip25 scope objects, where DO they live? kind of a broader design issue for MM; messy redundancy of same 2-10 addresses in every chain's scope object, leads to pretty verbose state; caip-25 ALLOWS per-chain accounts, but those are a pretty small percentage of usage
- how much usage/demand is there for authorizing each address on each chain separately? hell for parser...
- pedro: ideally, all the special-casing happens in namespace profiles; doesn't a [namespace-defined chain wildcard] scope object for eip155:0 take care of this as the default/base authZ?
- al: but does that apply to `accounts` specifically? is this an EVM-specific hack?
- pedro: well, there ARE EOAs on other chains; bf: polkadot universal-account and monero/zcash "seed" accounts...
- jiexi: sideeffect of eip155:0 is leaking wallet-type;
- al: irony of removing the `chains` verbosity-reducing batching mechanism and now trying to invent a `wildcard chainId` batching mechanism as the baseline (and all other scope objects are additive or for special cases)?
- pedro: creates an inheritance model; remove caip:2 prefixes and lots of redundancy by using the eip155:0 scope as "default"
- joao: what worries me is that introducing complexity (multiple ways of implementing, multiple ways for dapps to call/request) might slow down adoption or give wallets pause
- pedro: deduping accounts and base/shared RPC methods eliminates most of the redundancy; the potentially ADDITIVE logic (special-case RPCs per-chain) is where it gets tricky, partic for RPC methods?
- Al: shouldn't the `accounts` be as additive as `methods`?
- bigger question: how agnostic is this design? does this work equally well for all VMs that have written namespace profiles, or are we too focused on the big bois?
- bf: it's fine if CAIP-25 isn't a kitchen-sink/general purpose connection mechanism, other companies could write a CAIP that's more flexible here in parallel
- al: isn't it kinda CAIP-25 or GTFO? ignoring CAIP-25 and using the others would be odd...
- pedro: caip-282 is closely coupled to caip-25, it's kinda foundational
- pedro: we're pretty sensitive to all the other L1s so far...
- jiexi: why scope to`eip155:0` and not `eip155` if you want it to be clear that it's a macro/template and not actionable by itself?
- jiexi: don't need a null identifier if you don't use an identifier at all...
- pedro: yeah it makes inheritance easier to explain/sell... no identifier is always more explicit than having to map/track which namespace uses `0` vs `any` vs `00000000000`... i like it
- jiexi: it's much easier to parse/detect, less human-error; scan for `namespace-only` scopes first, before doing chain-specific scopes
- bf: additive-only, right? if one chain doesn't have a method, you include it in every other chain and not in the baseline/default one, right?
- pedro: there's already one method like that in [today's draft](https://github.com/pedrouid/CAIPs/blob/54f010af9a36465fe17be6824fc16a7dfd80334a/CAIPs/caip-25.md) - wallet_sendCalls absent from one of the chain-spec scopes
- al: 99% of time, chain-specific exceptions are additive, not subtractive... seems simpler 99% of the time; joao: can confirm; pedro: WC too
- bf: L2Beat basically exists for this pressure on L2 outliers/stragglers
- pedro: if we have consensus on this call, i'm git pushing now to update this PR to include the `eip155` scope
- jiexi: last question: `wallet:any` and `wallet:eip155`
- does this new inheritance model cover EVERY case we made these two for? if not, what are they?
- jiexi: if scope is `eip155`, you can't call any of its methods by mistake (no endpoint); `wallet` methods ARE callable since they're just wallet RPCs (stop using `wallet:wallet` or `wallet:any`)
- jiexi: thinking about the implementation of special-casing;
- pedro: does this make the scope optional in caip-27? or loosen the caip-2 requirement on scopes in caip-27? bf: does anyone use caip-27 for wallet RPCs anyways?
- pedro: `wallet_authenticate` and `wallet_pay` are the only wallet methods WC deals with anyways; we don't need caip-27 for those, we call those directly (route to wallet, not to a node/endpoint)
- al: maybe we need a separate CAIP for wallet methods that defines how wallet methods are permissioned by caip-25 authorizations
- pedro: that reminds me, do `wallet_getSession` and `wallet_closeSession` need to be authorized explicitly in CAIP-25 handshake? for, e.g. versioning (newer CAIPs add new options here, no way to discover them otherwise)
- al: they're referenced in CAIP-25 so you need to support them to implement caip-25
- jiexi: it's still a good point, though, that making it explicit simplifies versioning/extensions... are we expecting to add more lifecycle methods, tho?
- pedro: wallet_updateSession could theoretically be needed some day for someone?
- synthesis? pedro: do we actually need any `wallet` namespace for anything then? al: the versioning/extension story makes me wonder, though
- consensus: DON'T use caip-27 for `wallet` namespace methods; caip-27 keeps requiring caip-2 scopes, not namespace scopes
- pedro: shouldn't `personal_sign` go into `wallet:eip155`; Al: that's where we already put it! we allow it if a dapp requests it inside a chainId scope object, BUT i agree
- pedro: side note, we should write a CAIP for`wallet_sign` lol
- homework?
- stew on this; merge this
- think about ways of reintroducing `references` or some other batching
- think about `wallet` method corner-cases
- pedro will open a PR with `exceptions` to hang over us like a sword of damocles
- how about `aberrations`
- al: i was thinking more `vorteces`

## 6 August

- [CAIP-25 overhaul](https://github.com/ChainAgnostic/CAIPs/pull/367/files) discussion
- l98 - capabilities by Coinbase/pre-existing name, or by eip#?
- pedro: why burden CASA with another registry to maintain?
- Al: table this for now?
- Al: I do think we need a Capabilities section to explain this?
- sidebar: chaos of capabilities being defined (sometimes!) across various EIPs
- getting rid of references shorthand and force one-chain-each scopes? unanimous, it seems
- pedro: compressed messages (we pay by the wss) but totally fine for audit logs/exports/etc to explicitly have very verbose CAIP-25 messages
- jiexi: what about addresses[] dropping the caip-10 prefix, now that scopes are always keyed to exactly 1 caip-2?
- seems unanimous
- jiexi: what about `wallet` namespace? `wallet:eip155` but also `wallet:any`? special case
- pedro: we're making the definition of a scopeObject really hard just for a special-case
- table for now?
- jiexi: [caip-2 usage](https://github.com/ChainAgnostic/CAIPs/pull/367/files#r2252184983) of `eip155:0`
- al: overload "EOA" flag AS "wildcard"? all versus any?
- pedro: shouldn't this be in the namespaces spec? jiexi: sure, but maybe link to it and use it in an example?
- consensus: add explanation to eip155/caip-2 that :0
- jiexi: semantics: scope not being an accurate name anymore? scopes objects full of scopeObjects?
- bf: technically the scopeObject is actually a GRANT, and the "scope" (or maybe "domain"?) of each grant is the key
- jiexi: this feels downstream of the wallet/chainId-0 issues...
- jiexi: permissions <> feature discovery <> capabilities
- does listing a capability in a request get interpreted as a requirement? or a request?
- if a wallet upgrades after creating a session but before it goes dead, can it re-authorize or add that new cap?
- bf: but we resemanticizing scopedProperties? was anyone using those?
- alex: rpcEndpoints were being proposed by dapps (use this RPC, with this metadata)
- al: maybe we keep both capabilities and properties?
- BETTER (???)
- pedro: capabilities can't be in request, can only be (informationally) volunteered in response
- pedro: what if wallet can't overwrite props, and dapp can't overwrite capabilities? could be a useful symmetry
- al: devex gets painful if the semantics drift into permissions terrain; if these are informational/unenforced, much safer
- followup
- [ ] bf to follow up on al's EIP PR
- [ ] bf may not make it to next meeting, carry on without him and async

## 23 July

- general catch-up
- Solana launch <> Multichain launch; multichain SDK ships soon, roll out to connectors and big dapps
- tug-of-war between dapps wanting (easier for them) one-offs versus big-picture multichain unified API

### PRs to refine/move to close

- [ERC-7682](https://eip.tools/eip/7682) - PRs inbound to tweak it
- [eth-mag](https://ethereum-magicians.org/t/erc-7682-auxiliary-funds-capability/19599)
- [al's first PR](https://github.com/ethereum/ERCs/pull/1126/files)
- chainAgnostic equiv fast-follow once we've got it working on eth w/key partners?
- pedro: meta-comment about coinbase driving cap-based approach rather than working with caip-25
- al: plan is to align the two as much as possible
- pedro: bystanders/lookieloos - swingstate dynamics? default pattern should be "feature parity + multichain"
- pedro (screensharing one proposed simplification of caip-25 to just scopes/caps/properties): coinbase wallet standards more appealing compared head-to-head because they're much simpler
- Al: i'm open to the discussion, we don't use req/opt scopes currently, reducing complexity in a lot of the syntax would probably be fine (we already use a simplified version in our implementation anyways); but i also think we should defer to joao and jiexi who've been implementing this for years, time-crunched, tho
- pedro: coinbase's steady drip of new Caps which we're chasing one by one as CAIPs... maybe we need to make caip-25
- al: but we also win by having features they can't; they'll always win at ergonomics (for example in-wallet bridging and natively-multichain txns and whatnot)
- Al: How soon can we merge [CAIP-282](https://github.com/ChainAgnostic/CAIPs/pull/282/files) and [CAIP-294](https://github.com/ChainAgnostic/CAIPs/issues/294)?
- Joao: [upstream PR](https://github.com/pedrouid/CAIPs/pull/9) already merged
- Joao: [CAIPs#341](https://github.com/ChainAgnostic/CAIPs/pull/341/files) still opewn tho
- Pedro: Gotta add joao and al as co-authors! why am i blocking on this?

### Ongoing issues/topics

### Next Steps

- [ ] - Async work on CAIP-25 syntax clean-up - Pedro will write up a target-state vision doc (**just** scopes, caps, and props), whether as markdown doc and/or as PRs
- [ ] - Pedro merge Caips#341, clean up and finish 282+294
- [ ] 7682 as a CAIP?
- Pedro: i'm optimistic the CAIP-25 cleanup will make this simpler/faster
- luka's balance-check CAIP

### 23 June

- [CAIPs#348](https://github.com/ChainAgnostic/CAIPs/pull/348/files) needs a few tweaks
- [CAIPs#341](https://github.com/ChainAgnostic/CAIPs/pull/341/files) - g2g?
- intros
- Alex M ( Wallet API team )
- caip10: wildcards -- new CAIP as extension of caip:10
- caip2 <> wallet_createSession and providers?
- experimenting with less-atomic connection/permission requests; previously, all new requests overwrote previous, but now managing some state to have better defaults for modal/user-input; existing permissions could be {suggested? | provided?} as default in at least one case, and this may get rolled out to multichain API as well
- pedro/WC approach?
- fundamental UX question: if dapp has perms for chains 1 2 and 3, then requests 456, does modal show 12 and 3 already pre-checked? current UX doesn't display (or persist) 12 and 3 in this case. current prototype isn't displaying 123 and 456 any differently.
- vandan: division of labor between dapp and wallet; both have to persist, but this change is on the wallet side; dapp still needs to send 123 AND 456 to add 456
- is this against the spirit of caip25? any reason NOT to do this?
- bf: i like it?
- jiexi: ambiguity/multiple semantically-equivalent requests should be stamped out; verbosity is fine, making dapps include perms they want to persist is fine;
- al: is it ever a big deal for a dapp to get extra chains or scopes that wallet persisted and they didn't? nbd?
- we could scope this however (just eth, just eth+sol, all multichain...)
- bf: i recommend all multichain! could nudge other wallets to display re-perm/incremental reqs this way

### 9 June

- new CAIPs
- finally need to merge [282](https://github.com/ChainAgnostic/CAIPs/pull/282/files)
- small PRs after that in case of delta between metamask in prod and 282 as-is
- finally update the informational EIP about CAIPs and link to 282
-

### 28 Apr

- [DeFi Wonderland draft CAIP + Namespace PR](https://github.com/ChainAgnostic/CAIPs/pull/350) on binary CAIP-2s and CAIP-10
- draft until he finishes the normative bits (or just descopes some of them for now)
- Jiexi: should caip2- and caip10-equiv be separate CAIPs? might some need one but not the other?
- bf: also, someone might need the binaries but not the asciis...
- [Joao's PR on Pedro's PR]
- null wallets continued
- what cases need a new CAIP?
- bf: 0 can still mean "EOA" if `null` means "any chain/no chains" (in eip155)
- solana: would we be the only ones using it?
- 1.) Al: are there other VMs that would use this instead of just a special-case like 0 in eip155?
- 2.) Al: would all namespaces that use it as-is, or will they all profile it in special-snowflake ways?
- 3.) Jiexi: Universal/default value seems fraught; for many VMs/L1s, we're not sure where to ask, and self-onboarding L1s/VMs might make a rash decision they regret later
- binary caip2s/10s create a similar problem... if we're yoloing there why not yolo here
- Al: but is it a universal case? or just occasional special cases that can be special-cased in code/in userland?
- setting precedent is important tho
- open an issue on CAIPs? add a section to namespace templates?
- Juan will take the [action item](https://github.com/ChainAgnostic/namespaces/issues/142) to update this this week

### 15 Apr

- wildcarding
- accounts management, data objects in metamask
- Al: daniel and gustavo have been using eip155:0 for EOAs in the backend (dapps didn't seem to be using it over CAIP-25 connections); every address (whether EOA or not) is always chainId-specified in CAIP-25, but in the wallet, addresses get balances and scopes attributed to them per chainId/CAIP-2
- Al: mental model of most dapp devs and users isn't EAO, it's "wallet" (EOA, across chains) and "smart account" (chain-bound); how can the standards express this across VMs/L1s? can we reuse this logic or will it be bespoke
- Daniel: Refactoring from Account > Address > Chains-where-active before we knew about the SAFE 0 convention; now trying to understand if 0 can be 0 everywhere? We considered using a * but that would break a lot of things and be weird
- Juan: Could just make a new CAIP that extends CAIP-2 to reserve `_` on all namespaces as the "wildcard" chainId
- Al: We could add something to CAIP-25 that makes CAIP-25 requests able to ask for address (or caps?) in req? Daniel: Can't requests use namespace-wide scope? (Sidebar about **informational** namespace-wide objects with empty `references[]` array)
- Jiexi: no way to affirmatively express [non RPC-method-name] capabilities of a CHAIN, i.e. a bespoke gas capability, or a smart account capability
- scopedProperties?
- Daniel: metamask has "account type" (eoa, 4337, etc); i don't think we should hardcode account type into address, partic outside eth, because in BTC and other L1s, address is multi-type; chain-specific metadata per-address in CAIP-25 scopes? could be backwards-compatible
- Al: Maybe eoa/s.c. isn't something high-level enough for all namespaces? does it need to be standardized?
- 5792/[eth CAIP25 profile](https://github.com/ChainAgnostic/namespaces/pull/139/files)
-
- namespace mapping

### 31 March

- [5792](https://eips.ethereum.org/EIPS/eip-5792) group
- writeup to remove and/or better-specify chainId
- failure cases: chainId diff from currently connected one,
- alex unlikely to get to that writeup; juan could try?
- error code seems a worthwhile compromise
- API confusion
- LSR: "chainId should've been connection metadata all along" (we agree!)
- not ideal but also work-around-able
- possible chainOverride cap? won't be in the EIP itself, so might not get enough adoption to worry about even
- Al: send_transaction:CAIP-27::multichain sendCalls:????
- jiexi: but how batch multichain atomically?
- bf: non-atomic, but at least "flowControl: strict" sequential mode would be worth doing in a CAIP-27-ish way?
- other agenda?
- PR #341
- review why array and not map or single-string
- duplicate keys not possible in a map, multiple values for a given caip might be useful (unknown unknowns)
- how close!?
- big picture: spreading this as a general-purpose approach?
- devrel resources or polling/outreach to the community to see what dapps think in partic
- timeline
- all hands on snaps launches (mobile staggered) so might not do much design

### 17 March

- 5792 update
- chainId still in there for one case
- al: i'm predicting people will implement
- MM chainId issue - we just check passed chainId against 1193 active chain, not thinking about the CAIP-25 API
- Jiexi - CAIP-294 amd extension_id
- Al: EVM-only multichain API is live! (and multi-VM on alt branch will be released in May, with Solana and a few other major alt-L1 Snaps live)
- demo at end of the hour if there's time? :muscle:
- OVerview of things in flight (longer-term, bigger things)
- 284 and friends
- [informational ERC](https://github.com/bumblefudge/ERCs/blob/bumblefudge/information-erc-overviewing-wallet-connections/ERCS/erc-xxxx.md) to bring eyes to all we're doing (including ^)
- Vandan: good input doc [here](https://github.com/MetaMask/metamask-improvement-proposals/blob/main/MIPs/mip-6.md)
- Snaps team focusing on Solana's wallet standard/adapter stuff; would be good to get other L1s to adopt CAIP-25/6963-style discovery instead of pulling a Solana Foundation each time
- Shorter-term asks and quick PRs?
- João still waiting on Pedro for [284](https://github.com/ChainAgnostic/CAIPs/pull/341) and [pedroid/caips#9](https://github.com/pedrouid/CAIPs/pull/9)
- happy to move next meeting if it means pedro-time
- Al: Standards-board in MM git org?
- 5792 <> CAIP-25 capabilities
- null-chain versus wildcard-chain/wallet_
- Al: maybe we need an informational CAIP or namespaces profile document that breaks down null- versus wildcard? threeway distinction between chain-specific, namespace/L1-specific, and wallet-level/meta. (seems like 0x00 conflates those last two)
- [ReOwn PR on the CAIP-25 examples of 5792 capabilities](https://github.com/ChainAgnostic/namespaces/pull/139/files) - waiting on ReOwn to finalize, maybe ask J Tavares?
- CSA sidebar - ENS canonical serializing and the 2-address CAIP-10 variant...

### 3 March

- agenda
- [draft normative EIP introducing newbies to the CAIP-25 cinematic universe](https://github.com/bumblefudge/ERCs/blob/bumblefudge/information-erc-overviewing-wallet-connections/ERCS/erc-xxxx.md)
- still needs:
- mention of 7710 and 7715 for delegations
- mention of 5792 and batching
- teaser about manifest v3/extension_id connections
- minutes
- CAIP 284/3?? - ping pedro on discord!
- EIP draft
- show ERC-focused folks how useful CAIP-25 is
- generalize design pattern a bit to encourage more namespaces to self-describe and adopt
- including L2s with custom RPCs and such?
- emphasize segmentation of connection?
- wallet design <> UX
- rollout and adoption once experimental snaps-CAIP25 sandbox is live
- focus on library authors first

### 6 Feb

- agenda
- [PR](https://github.com/pedrouid/CAIPs/pull/9) adding CAIP-314 (target by extension_id) prop to CAIP-294 (EIP-6963 generalized) object - ready to go? last change on object syntax? current PR has most-flexible (array of objects that [may contain](https://github.com/pedrouid/CAIPs/pull/9/files#diff-bded2509d96804b3c1d2e052d0d495456d078d09a1e1ca9fdb16ead1f5a8d233R165-R180) objects in `value`)
- realistic to allow for [multi-transport connections](https://github.com/pedrouid/CAIPs/pull/9#issuecomment-2539743797)?
- time to start informational-EIPing? how proceed?
- "transition off EIP-1193" as title?
- order of topics?
- EIP-1193 versus CAIP-25
- isomorphism of 5792 multichain `wallet_sendCalls` with CAIP-27 RPC calls over a multi-chain CAIP-25 connection
- `wallet_connect` informational EIP, or do that in a separate informational EIP?
- snaps and custom/L2-specific methods?
- current docs only show how to use L1-specific methods; maybe describe as a possibility?
- general gutcheck on standards situation, chain_id, etc?
- EIP-7715 - chainId namespacing of permissions, versus eip-1193 pattern has implicit chain "focus" in context versus CAIP-25 namespacing of chainId; corner cases?
- Pedro: Polyfill where needed until eip1193 dies; some people implement 7715 and 5792 _before_ CAIP25/27...
- Vandan: dapps and wallets both catching/defaulting when there is a missing or mismatching chainId in request; was this a half-step? Pedro: more like being realistic on 7715 getting adoption long before CAIP-25/27 transition...
- Jiexi (in absentia): eip155:NULL:0x versus eip155:0:0x1234...
- CAIP-27 error messages... any progress? PR?

### 20 Jan

- agenda
- maybe demo e2e prototype and test dapp? :muscle: :crossed_fingers:

### 6 Jan

- agenda
- adoption of 282+294/295/etc
- [informational] EIP explaining it in eth terms to eth/evm wallets?
- direct outreach?
- vandan and juan will chat separately and bring a draft to the group
- `target` formatting:
- jiexi: 1:1 uuid per entrypoint/connection metadata is problematic, thus my [comment with a multi-interface example on github](https://github.com/pedrouid/CAIPs/pull/9#issuecomment-2539743797)
- waiting for pedro input (pinged on discord)
- Al will update the thread on PRs on pedro's draft on GH
- misc cleanup before shipping and writing docs
- joao back tomorrow, cleanup largely in his todo list

### 9 Dec

- agenda
- Next time Pedro can make it:
- getting [CAIP282](https://github.com/ChainAgnostic/CAIPs/pull/282/files) merged and ready to start building on
- how can wallets work with [multichain sendCalls from 5792](https://github.com/ethereum/EIPs/pull/8771)
- reconcile 282 to 294?
- 294 w/ext_conn PR merged aligns ext_conn w/iFrames
- subtle difference: iFrame already has target-origin built in (observed from message) - [see Discovery section of 295](https://github.com/ChainAgnostic/CAIPs/pull/282/files#diff-944d288e72a1dc19eb566c3a56fb03233acda282e109c7f2e747aff27001a9edR50)
- target-origin XOR extension_id could both be in some metadata object? share a property?
- pedro: [extensionId and target-origin are both strings - why not put them in a shared object](https://github.com/ChainAgnostic/CAIPs/pull/282/files#r1880549034)
- jiexi: `target: { type: caip294; value: <1234>}`?
- consensus?
- relationship to 6963 - how closely do we need to align to 6963?
- pedro: the smaller the delta, the easier the sell
- walletData very similar to the advertisement object, it's more the protocol that changes (and can be dropped)
- eip1193 still supported (as legacy) in 6963; here, not even that
- iFrame postMessage workaround in 6963 stuck out more; 282 aligns more, so now even new transports could share the same basic flow (partic if all they need to connect is a new target. member!)
- Al: João take lead on the PRs?
- Pedro: Which other wallet will implement?
- Vandan (in chat): one question I had was whether we’ve considered submitting an EIP that kind of represents the evolution of EIP-1193 + EIP-3326 toward something that looks more like CAIP-25?

## 25 Nov (post-Bangkok)

- Agenda
- smart contract account devex
- how signal/handle multiple accounts if some are smart contracts or have diff capabilities than others
- provisioned by one dapp, not taken to other dapps easily in that form?
- 7702 (and 3074) --> long-lived smart accounts (at least for L2s)
- al: snaps <> smart contracts: i'd imagine SCs living inside or being related to specific snaps, altho ofA course there's a lot left to be fleshed out about the interfaces
- could a CAIP-27 call send a txn to be signed to an onchain signer? how signal account-capabilities per account?
- jesse: accounts deserve their own scope objects maybe? methods don't map directly to capabilities, but maybe permissioning specific accounts to, say, onchain calls (userOp methods) implies they're onchain accounts? maybe one euphemistic way of signaling would be to permission 4337 methods to specific accounts
- al: modify caip-10? where stick metadata
- jesse: wallet_getCapabilities (from EIP-5792) answer capabilities PER CHAIN ()
- how to share granular account info only when it's needed and/or once sufficient trust/meaningful consent has been achieved?
- could a user get a "proceed only if you trust" kind of warning? already warn when a wallet exposes any account, is it WORSE for exposing accounts' capabilities?
- bf: onchain wallets are so splintered, telling a dapp which methods they support fingerprints them really granularly in 2024; that's the fault of the EIP authors to date, tho, since each smart contract supports a unique snowflake combo of ABI sigs; hopefully that coheres over time
- al: well that is gonna take a while; in the meantime, warning to users is maybe the best we can do, since they're walking right into fingerprinting exposing anything about an onchain wallet
- more generally, fingerprinting/oversharing risk versus UX enablements
- longer-term solution: granular delegation/OCap model
- short-term: [implicit, AI-powered, SaaSy] trust registries might be easier to implement, dapps and wallets might just yolo it
- do erik or danf wanna come to the next meeting, or schedule a special one?
- bf: invite me as optional even if it's 2am my time!
- trust-registries figure _how_ in CAIP-25 mechanisms?
- al: MM internal plumbing in domain-model: show trusted errors & warnings for domains above a [policy-set] threshold? or above a lower one in wallet "dev mode"; internal wallet policies (and settings, and trust history) could trump API-queried registries, for ex
- sendcalls per-chain got broken in a PR (but they missed the example)
- https://github.com/ethereum/EIPs/pull/8771 - harder for a wallet to guarantee now
- canonical bridges would make this way more chill than actually executing on multiple L2s or EVM chains that aren't L2s...

## 11 Nov (Bangkok Monday)

- restaurant/bar meetup? need not be monday proper
- coordinate discord or telegram
- ReOwn event?
- whiteboard new EIP standards<>CASA standards? coordinate with DanF?
- EIP7715 EIP7710 EIP5792
- ERC669
- blog post
- bigger problem: momentum for AllWalletDevs and consensus-building; EIP-6963 was a good precedent; this is a bigger leap (or a harder pill to swallow within Eth space), tho, so maybe better to get non-Eth chains onboard
- tactical items
- user-rejected error code? yeah go for it 5003 - PR plz
- CAIP-27 rely explicitly on JSON 2.0 id for tracking/matching, not BF's nested objects proposal- all good, PR plz
- getSession and revokeSession shouldn't leak state if there's nothing to get or revoke?
- warnings in addition to errors
- Bf: RECOMMENDED or MAY preferred, but i'm not dogmatic here-- by analogy to the trusted codes, formatted the same way ideally
- discovery -
- action items
- [ ] - MM - PRs mentioned above
- [X] - BF - fix CASA jekyll TOC

## 28 Oct

- agenda
- demo Shane's test suite for CAIP25 and CAIP27?
- update on EIP 5792 and 7715 - should this stay interactive-only or could EIP-7715 persmissions be requested in a CAIP-25 req?
- hw: read [draft EIP-7715 text](https://github.com/ethereum/ERCs/pull/436/files)
- CAIP-27 responses
- multi-chain scopeObjects - killable? corner cases keep piling up...
- kill prefixes in `accounts[]`? chainId 0 comes to mind, but also chainId 1 authorized on L2s
- bangkok side events?
- [ipfs meetup sunday before](https://lu.ma/ipfs-bangkok)

## 14 Oct

- agenda
- CAIP-25 Warnings?
- CAIP-285 (revoke) and CAIP-312 should be returning null instead of using error messages
- dev ex - a slightly-malformed piece of a request shouldn't just be silently dropped nor break the whole connection; "standardized" warnings could be non-normative but still helpful
- ex: multiple namespaces, one of which has a chain-specific method not supported on that chain; avoid killing connection but find a way to send a warning to [trusted] dapps
- do dapps always log? do end-users get much out of a warning or a silent warning (say inside console)
- update on EIP 5792 and 7715 - should this stay interactive-only or could EIP-7715 persmissions be requested in a CAIP-25 req?
- hw: read [draft EIP-7715 text](https://github.com/ethereum/ERCs/pull/436/files)
- CAIP-27 responses
- multi-chain scopeObjects - killable? corner cases keep piling up...
- kill prefixes in `accounts[]`? chainId 0 comes to mind, but also chainId 1 authorized on L2s
- bangkok side events?
- [ipfs meetup sunday before](https://lu.ma/ipfs-bangkok)

## 30 Sept

- agenda
+ CAIP-282 - [current draft](https://github.com/ChainAgnostic/CAIPs/blob/bc4942857a8e04593ed92f7dc66653577a1c4435/CAIPs/caip-282.md)
- caip-282 - implementation happening soon!
- Popularizing and promoting standards?
- vandan proposed a standardization-landscape talk but it was rejected by programming committee!
- non-EVM support - convenience libraries? how get adopted?
- bf: only precedent is [caip](https://www.npmjs.com/package/caip) in NPM
- how interact with anza's wallet-standard?
- WC connects thru it, but it requires some hardcoding (capability declaration as env vars)
- [solana/caip25](https://namespaces.chainagnostic.org/solana/caip25) on namespaces has some language
- MM still figuring it out
- implementation feedback
- scopes[] containing just references versus whole caip-2s -
- accounts[]?
- ex. a method like `swapAssets(a, b)` could take references as params

## 16 Sept

- agenda?
- caip2 defined two different ways- creates [ugly merge case](https://github.com/ChainAgnostic/CAIPs/pull/301#issuecomment-2202290982)
- naming convention: jiexi's [PR](https://github.com/ChainAgnostic/CAIPs/pull/327)

What to do with the following ambiguous request:

requiredScopes: {
    'eip155': {
        references: ['1', '10', '1032', '0x00'], //<-- 0x00 is invalid acc to eip55
        methods: [
            'eth_sendTransaction',
            'eth_accounts',
            'eth_blockNumber',
            'eth_getBalance',
            'personal_sign',
        ],
        notifications: ['accountsChanged', 'chainChanged'],
    },
    'eip155:1032': {
        methods: ['l2SpecificMethod'],
        notifications: ['specialSnowflakeEvent'],
    },
},

Option 1: wallet cleans up request and sends "postel's law" response

sessionScopes: {
    'eip155': {
        scopes: ['1', '10'], //<-- 1032 removed to disambiguate
        methods: [
            'eth_sendTransaction',
            'eth_accounts',
            'eth_blockNumber',
            'eth_getBalance',
            'personal_sign',
        ],
        notifications: ['accountsChanged', 'chainChanged'],
    },
    'eip155:1032': {
        methods: [ //<-- methods moved from above
            'eth_sendTransaction',
            'eth_accounts',
            'eth_blockNumber',
            'eth_getBalance',
            'personal_sign',
            'l2SpecificMethod'
        ],
        notifications: ['accountsChanged', 'chainChanged', 'specialSnowflakeEvent'],
    },
},

Option 2: Throw error 5204 (everyone's allowed to do it, but what if they want to give the req the benefit of the doubt, postel-wise?)

Option 3: Be chill, let it ride (i.e. merge but don't tell the dapp you did so)

Option 4: Least privilege, NOT union-of-requests/additive

return

requiredScopes: {
    'eip155': {
        scopes: ['1', '10'], //<-- i.e. 1032 removed
        methods: [
            'eth_sendTransaction',
            'eth_accounts',
            'eth_blockNumber',
            'eth_getBalance',
            'personal_sign', 
        ],
        notifications: ['accountsChanged', 'chainChanged'],
    },
    'eip155:1032': { //<-- least authority, only what they _might_ have been requested
        methods: ['l2SpecificMethod'],
        notifications: ['specialSnowflakeEvent'],
    },
},

MM is breaking up `eip155` object into multiple single-chain namespaces anyways, that should probably be legalized explicitly (and the ambiguous case explained )

### PRs to refine/move to close

### Ongoing issues/topics

### Next Steps

- [X] BF will open a PR legalizing "merge requiredScopes" object?
- [X] separate or same PR to redefine 5203 as "reference invalid for this namespace";
- to ponder: should error messages maybe be more explicitly pick-and-choose, recycled as warnings instead of errors, etc.? or is that implicit in the implementation of any spec of this na?

## 4 Sept

### PRs to refine/move to close
### Ongoing issues/topics

- Error handling in CAIP-27
- sessionId and scope strictly redundant if `id`-tracking is more explicitly required/mandated behavior
- jiexi: could an id-free request be a kind of yolo request? bf: is that a notification? jiexi: no, a method without an id is valid, but no response is expected
- shane: link to the JSON-RPC spec to make it clear?
- nested error messages could be confusing - no need to have error embedded in an result, not very JSON-RPC ergonomic
- bf: can the PR that removes the nested errors also introduce an error code range? al: makes sense
- bf: are there any caip-27-specific errors worth throwing _at the protocol level_? al: unauthorized? that's already in the spec as an example (jiexi that error code comes from [eip-1193 errors](https://eips.ethereum.org/EIPS/eip-1193#provider-errors))
- anything bad about the 1193/25-27 analogy?
- jiexi: should there be an error for "no such scope" versus "that method not in the relevant scope.methods[]"?
- jiexi: doesn't 4100 come from EVM? might there be collisions in other RPC dictionaries? should we check for collisions, or at least try to pick a collision-unlikely range for novel CAIP-27 error messages?
- aaron: why assume "range of error codes" approach? bf: beats me, momentum? blindly following eip1193? :sweat:
- backlog? maybe we need to think what range is safe to pick and separately which errors are worth throwing
- no leak risk because getSession(); simplicity
- caip-25 errors - does spec make clear these errors aren't all mandatory? that some of these could be warnings within a live connection rather than a disconnect error
- keep it on backburner and bring up a PR to clarify language in future meeting?

### Next Steps

- [ ] bf will do a little RPC-docs error-handling survey for poops and giggles and post to Discord
- [ ] someone on team MM will update CAIP-27 to match leaner/one-layer id-based error/result returns and a little specification of behaviors around malformed ids, missing ids, etc
- [ ] someone on team MM to add error codes in a separate PRs (after a little thinking and research on error range design)
- [ ] further backlog: clarify error codes in CAIP-25
- [ ] 5301 needs to be clearer
- [ ] make clear that throwing every error isn't mandatory for all implementations; maybe suggest or sketch a warning flow within the connection/over it?

## 19 August

### PRs to refine/move to close
### Ongoing issues/topics

- [CAIPs#282](https://github.com/ChainAgnostic/CAIPs/pull/282/files) and [pedrouid/caips#8](https://github.com/pedrouid/CAIPs/pull/8/files) PR upstream of it
- pedro#8 merged-- will discuss 282 at next meeting he can attend
- [wallet:namespace pseudo-namespace](https://namespaces.chainagnostic.org/wallet/caip2) - help with the TODOs in test-cases and security considerations? brainstorm?
- Al: will discuss after a bit of prototyping, directionally good, PR example in when we're confident of them
- waiting on Hassan for [#323](https://github.com/ChainAgnostic/CAIPs/pull/323) (or [#320](https://github.com/ChainAgnostic/CAIPs/pull/320) if it makes sense to split the two updates)?) and [#319](https://github.com/ChainAgnostic/CAIPs/pull/319)
- small-group consensus
- abandoned hypotheses:
- scopeObject with multiple `scopes[]` would apply to all of them in parallel? nah
- no L1s/namespaces have been registered that don't use `chainId`s for the network that catches RPC calls
- generally chugging along implementation-wise
- eip-3770 chainId registry stuff
- main questions for Snaps team: how deep to nest? L4s wen?

### Next Steps

## 12 August

* high-level agenda
* making [CAIP-27](https://github.com/ChainAgnostic/CAIPs/pull/323) and [CAIP-319](https://github.com/ChainAgnostic/CAIPs/pull/319) only targetable by CAIP-2
- result-object and error-code topic that arose for 27 + 319
- ...profit?

### PRs to refine/move to close

- [CAIPs#319](https://github.com/ChainAgnostic/CAIPs/pull/319) - create wallet-->dapp JSON-RPC notification wrapper (CAIP-2-targeted)
- [CAIPs#323](https://github.com/ChainAgnostic/CAIPs/pull/323) - update dapp-->wallet JSON-RPC method-call wrapper to be CAIP-2-targeted
- supercedes [CAIPs#320](https://github.com/ChainAgnostic/CAIPs/pull/320) because _also_ makes sessionId optional
- [CAIPs#321](https://github.com/ChainAgnostic/CAIPs/pull/321) - errata about objects called array

### Ongoing issues/topics

- [ ] MM to discuss result-tier/error issues
- [ ] Hassan to review 319 and 323
- [ ] wallet namespace
- [ ] Al to find time that works for Hassan
- [ ] Jiexi will check out [wallet namespace status quo]()
- [ ] Pedro to respond to [282 comments](https://github.com/pedrouid/CAIPs/pull/8/files)

### Next Steps

## 29 July

- high-level agenda
* nits on [CAIP#285](https://github.com/ChainAgnostic/CAIPs/pull/285)
* 282 and friends

### PRs to refine/move to close

- [CAIP#285](https://github.com/ChainAgnostic/CAIPs/pull/285) - Are we there yet?
* one discussion topic: is [wallet_revokeSession a permissioned method](https://github.com/ChainAgnostic/CAIPs/pull/285#discussion_r1695117156)? it is worth making it explicit that bumble's mention of declaring it in `sessionScopes` is just announcing its support/availability?
* is `wallet_deleteSession` more cleanly antonymic?
* pedro: create:delete::grant:revoke?
* followup in async

### Ongoing issues/topics

* [CAIP#282](https://github.com/ChainAgnostic/CAIPs/pull/282/files) and [CAIP#308](https://github.com/ChainAgnostic/CAIPs/pull/308)
* al: mission-critical discovery of `extensionId` mechanism, orthogonal to CAIP282/EIP6963; browser can just show dapps the extensionIds of installed extensions and let that process go in parallel or instead of 6963-style interactive discovery
* how does 308 replace or become 294 and get folded into 282
* pedro: issues [296](https://github.com/ChainAgnostic/CAIPs/issues/296) (externally_connectable), [295](https://github.com/ChainAgnostic/CAIPs/issues/295) (iFrames) and [294](https://github.com/ChainAgnostic/CAIPs/issues/294) (dispatchEvent extensions)
* al: discovery (i.e. announcement of extensionId) still happens in a contentScript, not natively over browser/extension interface; pedro: literally still `dispatchEvent`? al: yup, discovered the same way as older extensions, just bootstraps to a different connect
* ergonomics and designing the discovery messages and the "optional object(s)" extending 6963
* announcement/discovery is what matters here; _how_ you bootstrap from there doesn't matter much
* one size fits all doesn't work across iFrames and extensionIds and classic
* shane: can scopes announcement be optional? security implications are pretty glaring if leaking this much info
* pedro: already is? SDKs detecting what kind of wallet to use is kinda necessary for good UX, not offering you a solana wallet when you connect to a hedera dapp...
* bumblefudge: namespace-wide scope objects better than caip-2s sounds more private and less useful to scanners/indexers/phishers...
* ongoing implementation feedback as MM implements; mismatches
* empty scope objects and typing, for example
* sidenote: arrays should be objects
* scheduling?
* next week no meeting, async better for now (MM team all can't make next week)
*

### Next Steps

* hassan will review the 285
* wallet namespace PR: vandan OOO, al will review; bf: no hurry on my side
* bumblefudge will open a PR fixing array/object typo and loosening "no empty requiredScopes and optionalScopes" requirement
* pedro will update 294 to incorporate today's discussion to discuss again in 2 week!

## 22 July

- bumblefudge [made a chart](https://hackmd.io/VLhYsoFhTmCaGQJg1DXv6w?view#Equivalence-chart) and had some [questions](https://hackmd.io/VLhYsoFhTmCaGQJg1DXv6w?view#Open-Questions) about [CAIP-285](https://github.com/ChainAgnostic/CAIPs/pull/285)
- [extensionId declaration needed](https://github.com/ChainAgnostic/CAIPs/pull/282#discussion_r1681712879)
- bf made a [counterproposal](https://github.com/ChainAgnostic/namespaces/pull/119) for `wallet:eip155` to be a special case of namespaces (CASA-wide, not just for CAIP-25), versus putting special-case logic into [CAIP-25 and CAIP-217](https://github.com/ChainAgnostic/CAIPs/pull/303)
- put CAIP25 req and res into ### test vectors with // annotations pointing to normrefs? i.e.

{
    "wallet:eip155" : {
        methods: "wallet_chainsChanged" // https://github.com/ethereum/execution-apis/main/
    },
    "wallet:bip122" : {
        methods: "btc_getAddresses" // https://wbip...
    }
}

## 15 July

- 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
- [X] - bf will [open a PR](https://github.com/ChainAgnostic/CAIPs/pull/307)
- 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
- [X] - bf will open a [counter-PR on namespaces](https://github.com/ChainAgnostic/namespaces/pull/119) to save time - @vandan keep welcome to keep elaborating this one in parallel and we can discuss both options next week
- 285
- newest version [here](https://github.com/ChainAgnostic/CAIPs/pull/285/files#diff-63b4c462a371eb5b690b488c31a58ec32bff8bd6ab10dab8aca0b99cbe3f75c5)
- 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](https://github.com/ChainAgnostic/CAIPs/pull/285/files) closely by next week!
- merge wordsmithing PRs and scopedProperties PR
- waiting on @hmalik88 for [https://github.com/ChainAgnostic/CAIPs/pull/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
- [X] - bf will [open a tracking issue](https://github.com/ChainAgnostic/CAIPs/issues/305) 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

## 8 July

- agenda
- major
- `scopedProperties` PR
- optional/minor
- jiexi's redundant scopeObject case (`eip155:1` + `eip155.scopes("1")` in same session)

## 1 July

- agenda
- housekeeping
- bumblefudge's small wildcard-update turned into a whole [terminology cleanup PR](https://github.com/ChainAgnostic/CAIPs/pull/289) that justifies a careful review-- thanks Jiexi!
- [scopedProperties PR](https://github.com/ChainAgnostic/CAIPs/pull/301) LFG (bonus eip155:0 examples as well)
- keep sessionProps for global
- CAIP-285<>CAIP-25 equivalences/flow parity
- most important
- al: [latest GH comment](https://github.com/ChainAgnostic/CAIPs/pull/285#issuecomment-2198782292)
- Pedro: overloading empty create_session call to double as revoke sounds good to remove;
- Pedro: Perhaps we could move to a more stateless model, where there are no delta-updates, just re-sets (with new or no sessionId)
- juan: my comment was that dapps still need to track connections by some arbitrary uuid anyways (whether for 6963 or via a relay like WC that is many diff concurrent connections on one domain (that of the relay))
- juan: a wallet could ignore the sessionId present in a request if it doesn't track connections by sessionId... i.e. if it's confident the request was for it
- juan: clarify what happens different if sessionId is present (what it means)
- pedro: "overwrite" semantics - if you receive a req with no sessionId, do you delete/revoke any existing ones from that counterparty? (juan: i think yes?)
- maybe it could be a SHOULD - "if you receive an update_session call with a sessionId, delete the existing connection just-in-case and create a new session to garbage-collect"
- pedro: happy to drop deltas and state transitions; delete and create again simpler
- al: requests to change (regardless of sessionId present or not) that get rejected-- stick to status quo, if persisted?
- Offchain methods scope nameing
- offchain methods for wallet<>dapp communications (pedro: but there are corner cases where dapp<>wallet methods still _need some onchain context_; methods that _read_ from chain without writing to chain should fall in this "offchain" bucket, which is better defined as the "non-mempool" bucket)
- here the "chainId 0" case comes in handy for authorizing L1-namespaced, i.e. `eip155:0` as scopeString for any ethereum-namespaced offchain methods
- Jeixi: maybe eip155 already has `0` but in other namespaces that use hashes or strings, maybe the `wallet:eip155` (`eip155:wallet` ?)
- `wallet` would then be a namespace and it's CAIP2 system would be an enum of other namespaces
- jeixi: this is more a wallet concern; aren't namespaces and txn formats and such governed by ACD-equivalents in each community? the wallet namespace might have a different governance anyways...
- “Wallet” scope (supporting cross namespace methods, truly namespace agnostic, more like browser-wallet interface than namespace-specific one)
- pedro: 3085 was more universal; 7715 very much an evm-namespaced method;
-
- Chris: CAIP-10<>ERC-55?

## 24 June

- agenda
- housekeeping
- bumblefudge's [wildcard PR](https://github.com/ChainAgnostic/CAIPs/pull/289/commits/0e0e7a42222de4a09084be0dffa057805463f614) needs a review!
- note: the PR also includes two unrelated commits, sorry
- updates on the [lifecycle-management RPC methods PR](https://github.com/ChainAgnostic/CAIPs/pull/285)?
- keep writing!
- updates on the [externally-connectable PR](https://github.com/adonesky1/CAIPs/pull/1/files)?
- sessionProperties +
- scopedProperties (`eip155:1` separate from `eip155`)
versus namespaceProperties (`eip155` would apply to any `eip155` objects)
- Snaps API <> offchain/chain-independent stuff
- scope strings versus
- addressing Snaps in a service registry?
- wildcard: "pull up any snaps that support `cardano` or `cardano:mainnet` "
- hassan: we're already planning on knowing which CAIP-2s each Snap "speaks" already
- non-protocol snaps wouldn't really NEED to go through CAIP-25
- snaps need to advertise the methods it supports somewhere? mapping to rpcDoc URL?
- Juan: `eip155:0.methods[]:wallet_addEthereumChain` might work?
- offchain/no-network chainId - alias across all namespaces makes sense implementationwise, even if "canonical form" can't be as tidy
- `chain` versus `network`: mental model nits
- Todos:
- [ ] pedro: fix my 282 typo, and split into two CAIPs?
- [ ] vandan: bikeshed internally [these naming options](https://github.com/ChainAgnostic/CAIPs/discussions/131#discussioncomment-9827143)

## 17 June

- agenda
- align on `wallet:` namespace versus `wallet_` methods
- `wallet_watchAsset` (first one???)
- explicit session RPCs rather than re-sending single CAIP25 RPC call over time with incremental changes
- different persistence models of authorization "config"
- new feature: fetch - dapp can check its persisted config against wallet's
- new feature: wallet-initiated events/notifs
- sessionId feature parity?
- mobile versus extension connection parity?
- shane: session parity needs to be out of scope for dapp devs, crucially
- pedro: 6963 intrtoduces the case of 2 wallets connected to one dapp in parallel
- pedro: uuids are the "key" that allows the partition
- pedro: sessionId and transportId actually distinct, don't always map 1:1
- alex: extension relying on "externally connectable"/manifest v3 API versus injected provider;
- extensions already partitioned by extension ID in "externally connectable", once we move to that we don't need to worry about injected providers race-conditioning
- pedro: but 6963 is still pertinent today, many many wallets are still injecting providers and not moving to externally-connectable/manifest v3?
- alex: maybe mark could speak to the partitioning of wallet<>dapp connections when multiple wallets are connected to one dapp?
- how do dapps manage and partition sessions?
- pedro: the sessionId only needs to be persisted insofar as dapps want to persist/prolong/rehydrate a session later-- it can ignore sessionIds if it's not persisting state
- mark: but we don't see any advantages to even making that a requirements on dapps?
- pedro: but even assuming mv3/ext-conn, doesn't the dapp need to persist the extensionId?
- pedro: what is refresh-case dev story? i.e., if end-user refreshes, what happens?
- alex: `provider_getSession` against the extensionId would rehydrate a broken session, in this model-- dev has one less footgun letting browser route this request
- pedro: but this is the same lifecycle, with the sessionId punted to the transport in one transport; the tradeoff might be that you can only allow one connection per transport
- pedro: because we DON'T limit to one connection, we need sessionId to allow multiplexing
- shane: the layering here is odd;
- pedro: but if you use extensionId as only/implicit sessionId, snaps can't partition a session with diff config and RPC connections; i think sessionIds might be useful for future user stories?
- alex: I think it would be good to hear Hassan and some of the Snaps devs views on this but I’ve tended to view it as desirable to have one “session” for the entire wallet connection inclusive of snaps; AFAIK CAIP-25/CAIP-27 is the way in which those requests are multiplexed, rather than separate sessions; But there might be some value to having partitioned _and attenuated_ sessions for individual snaps I suppose?
- circle back to _exactly how_ to make sessionId optional after the explicit RPCs are working, and CAIOP-282
- Mark: To clarify on the session ID point, we just wanted to avoid asking _dapps_ to store it. The wallet can definitely store it. We don’t need it to be deterministic, it can be random, that’s OK.
- CAIP-25<>[CAIP-282](https://github.com/ChainAgnostic/CAIPs/pull/282/files)
- pedro: backstory: solana/sui/BTC wallet standard was a step backwards from EIP-6963, locks that dev ecosystem into injecting providers forever because the standard ONLY work with injected providers
- CAIP-25 and CAIP-222 are two different ways of non-injected wallets connecting to dapps
- CAIP-282 triggers a CAIP-25
- why `window_postMessage`? because it's an old, bog-standard browser platform (iframes and extensions equally allowed); it's not an essential ingredient, and i'd love to hear alternatives,
- mark: i agree it's strictly better than `dispatch_event`; we were trying to understand if dapps had to know in advance _which_ of the three types of wallet it was speaking to; the way you describe it sounds like the dapp doesn't need to manage and probe three different interfaces.
- pedro: it's not strictly a 6963 alternative, more like a 6963 superset that works for wallet-adapter dapps as well
- pedro: note that 282 doesn't refer to `sessionId`s, it refers only to `uuids` (which could be extensionIds maybe?)
- possible edit: "once discovered, followup message can be sent otherwise (not just window_postMessage if a different interface was discovered)"
- mark: window_postMessage can only talk to an extension IFF that extension is running a content script IN that specific browser process, i.e. if it's already set up; pedro: that's great feedback, i was maybe assuming the content script and if mv3 is moving wallets away from that we probably need a more robust discovery mechanism or a more flexible discovery stage?
- shane: extensions accessed via externally connectable sidestep the v2 allowlist per-domain requirement
- shane: injecting scrips isn't the best security practice (or etiquette);
- gancho: What is the reasoning of scrapping the injected script for extension communication?
- Mark: Not so much scrapping it completely, but making it possible for users to disable it. So that we no longer strictly require the extension API permission allowing the modification of all webpages
- Alex: But many additional reasons: degrades page performance, overly expansive permissions are required (Shane: users must agree to modify every page they visit)
- mark: a more security-aware discovery section of this CAIP would be a good PR, beyond the mv2/mv3 distinction
- shane: in 282, there are two comm channel: discovery over window.addEventListener, and communications over window.postMessage - why need to add listener on another channel? Pedro: I think you found a typo in the examples, the examples are listening on dispatch, but the normative text says to listen on postMessage, you're right; the example should be in the same channel, `window.addEventListener(postMessage, ...)`
- pedro: sounds like we all agree discovery step could be more mv3-aware and multi-modal discovery that works for externally-connectable in addition to legacy
- pedro: one thing that comes up in a lot of my CAIP-25 feedback from implementers is: why `provider_`?
- isn't it basically a `wallet_` by now?
- vandan: +1, no objections to switching to `wallet_`
- shane: conflicts with `wallet` CAIP-104 namespace?
- bf: yes but we gotta kill that, maybe
- next steps
- [ ] alex: keep iterating lifecycle RPC methods
- bikeshedding welcome - naming is hard
- augment/escalate need to be distinct from revoke and partial_revoke/de-escalate?
- [ ] everyone: please add more comments to nudge [lifecycle RPC methods PR]() along
- [ ] pedro: fix my 282 typo, and split into two CAIPs?
- [ ] alex: there's a [PR already to extend CAIP-25 to be mv3-discoverable](https://github.com/adonesky1/CAIPs/pull/1/files) - chrome.runtime -based

## 10 June

- agenda recap/updates
- requiredScopes - still aligned
- connection metadata - still tinkering/designing
- new CAIP?
- Shane: `sessionProperties.{scopename}` is wierd devEx, since we explicitly do NOT want any sessionProps that aren't specific to one scope
- more explicit lifecycle RPC calls --> new CAIP(s)
- internal prelim draft [here](https://github.com/ChainAgnostic/CAIPs/pull/285/files)
- getPermissions (wallet caps) versus hybrid/onchain permissions - need to be ready for multiple possible futures and diff permissioning models
- one of the complications--in some proposed hybrid architectures, EOA could be one of many access points, or EOA could be a mandatory in-the-loop interface? radically diff assumptions/semantics for permissioning across those two types, and best not to deanon wallet by expressing that distinction to every dapp
- medium-term!
- wildcarded scope
- bumble still owes a PR!
- wallet-scoped method versus namespace-scoped methods - where to put `wallet_` functions that aren't really scopable to a chain but are only safe to deploy in one namespace
- Shane: `personal_sign` is a good example of a namespace-specific method that could have collisions in other namespaces
- bumble: what about the offchain CAIP2 we just quietly added 2 months ago? [here](https://namespaces.chainagnostic.org/eip155/caip10#special-case-of-eoa)
- jiexi: what about ::, null-chainId?
- bumble: but URN?
- alex: other namespaces will likely need this too, it shouldn't be a "special case" just for EVM? update CAIP-2 to consider this?
- bumble: I can write that PR
- alex: most urgent implementation question for us is how this works in EVM- we'll have a think on "chainId 0" approach
- `eip155` rename to `eth` namespace discussion - maybe need to timebox or defer? `bip122` versus `bitcoin` also?
- sessionId optionality
- bumble: still easier to think through the consequences if there's a fleshed-out alternative with explicit methods as fallback/failover
- agenda new items
- homework, takeaways, next steps
- [ ] bumble needs to figure out how splitting sessionProp into sessionProp and scopeMetadata could work spec-wise (backwards compat?) and implementation-wise
- [ ] MM team will think through internally the possibility of `eip155:0` as offchain/wallet_ scope object
- hassan: but why not `eip155:offchain`? alex: shouldn't it break validation anyways? if it's the same reference across all namespaces that might be a cool property
- [ ] bumble needs to review [alex's new CAIP](https://github.com/ChainAgnostic/CAIPs/pull/285/files) before next meeting
- [ ] bumble needs to update CAIP-2 and/or write net-new CAIP about offchain authorizations per namespaces
- [ ] bumble owes a PR to put at least a SHOULD against treating a namespace-wide CAIP217 with empty/no `chains` array as a wildcard

## 4 June

- recorded and transcribed
- Agenda - where are there still deltas?
- requiredScopes - kill or allow?
- alex: mark convinced me there MAY be a Snaps usecase for this later, but i'm open to other perspectives
- bumble: i like keeping it as a secret/undocumented option in both implementations until devs start needing it in future
- connection metadata - where put
- consensus evasive but might be a compromise that some of us can live with?
- alex: for the record, mapping between metadata and connection facts feels clunky; semantics of "all metadata in sessionProps" feels
- shane: won't other wallets approach this a lot like we do? is it too freeform, and worth standardizing in advance?
- bumble: i welcome a CAIP here! a standard mapping between CAIP-217 objects and the sessionProp object would make sense, no need to invite 10 reinventions of the wheel
- alex: we can take lead on that
- bumble: feel free to ask for my review as early and as often as you like!
- less consequential; can be worked out in later CAIP(s)
- sessionIds
- lifecycle of connections today is entirely thru MM RPCs; upgrading those incrementally could align more with the WC implementation's sessionId impl
- legacy dapps could get lost or bricked by the transition!
- proposal with new sessionId not being caught, unclear how that maps to a more explicit multi-RPC
- shane: sessions at transport layer, not within JSON-RPC :: you don't see TCP when you're sending and receiving HTTP
- shane: extensions use window.postMessage and window ports, not a sessionId within the RPC connection
- pedro's comment: doesn't break WC, just loosens the protocol/global CAIP-25 space
- hassan: olaf and my earlier conversations about sessionId weren't looking this far into the future or this granular
- multiple sessions per connection? unclear what the mental model will be here
- shane: making it optional is best for us, then we have both options!
- multiplexing sessions AND multiplexing chains would create chaos
- mark: i'm confused by what optional means? what is a session if it can't be identified? the rest of CAIP-25 feels confusing without it
- shane: if it's optional, you EITHER rely on transport layer to organize/constrain/lifecycle your connection OR you have an explicit variable inside the connection to do it - could still do both depending on usecase
- hassan: it's implicit in our legacy model by origin<>client tuple
- hassan: multiple sessions allows profiles or subsetted defaults, etc (DeFi usecase, tho?)
- erik (in the gh discussion): it's not much work to just generate and persist a UUID
- bumble: they could be optional, but i prefer they have a mapping from any equivalent/alternative for the sake of eventual convergence
- mark: i want to know what a session represents, let's get it on paper. extension might not need sessions but needs an equally definite signal for reinitiating
- lifecycles by additional method
- timeline/order-of-ops?
- bumble: ideally can we get session model and functionality of each lifecycle method on paper before making sessions optional? :D
- bikeshedding
- <> getPermissions ? (hybrid/on-chain permits)
- bumble: i need to know more than i do!
- mark: i'm not caught up either!
- alex: don't conflate it too much, there's also the onchain permissioning piece, these initiatives are pretty independent/parallel
- scopeObjects wildcard
- semantics?
- bumble probably owes a rephrase PR -- it's a carboncopy, not a wildcard!
- bumble: nudging devs away from it makes sense!
- namespaces names
- `eip155` for internal use raised eyebrows; internal alias possible but worth discussing if it's possible
- next steps
- bumble owes a PR on CAIP-217
- lifecycle docs (informal! not specs! just informational!)
- can be shared publicly or privately, all good, as long as juan and pedro/derek/wc see it
- explicit lifecycle methods after that

# Hiatus - Calls by request

(no notes could be found for these brief check-ins)

## 2023-10-04

### PRs to refine/move to close
### Ongoing issues/topics
- new CAIP idea: dapp suggesting snaps to wallets
- sessionProperties object could be extended by this
- refreshes or re-connects could change the permissions wallet gives to dapp
- pre-configs or defaults in wallet could be baseline for CAIP-25 (not how MM has been thinking about this, tho)
- altho we ARE going away from "chainswitching"/1-at-a-time mode; we want handshake/initial connect to expose multiple chains and addresses through our interal permission system
- have to consider the UX/flow for permissions per-dapp over time as opposed to upfront
- initial connection --> metamask pops up and asks for permissions (which accounts, which chains you have[, some more chains you don't which might be non-evm, which snaps that you already have installed, and... these snaps that you don't])
- even without a snap, need to name/ticker/block-explorer
- may be able to pull from ethereum-lists/chains, but a fallback/manual pass-in would be good
- need to ask wallet which snaps are enabled
- scopeObject variation - adding chains on the fly in CAIP-25 negotiation?
- does a scope's contents GET PARSED AND MAPPED to a set of possible snapIDs or do they INCLUDE them?
- what if snap suggestions or scope annotations lived in a sessionProperties?
- other CAIP-25 variation
- addEthereumChain required fields (need ticker for native coin, etc) for batching addEthChain

straw man - what if annotations lived OUTSIDE rather than inside scope objects tho:
- they don't change over the course of a session (and thus are truly sessionProperties)
- they can be dropped safely by any non-extensible wallet
- they can be processed before deciding which scopes are sessionScopes

{ 
    requiredScopes{
        "eip155:1": ...
    },
    optionalScopes{
        "eip155:12412": ...
    },
    sessionProperties {
        annotations: [
            "eip155:12412": {
                "suggestedSnaps": { "1234", "5678"}
                "networkConfig": [
                    "name": "example",
                    "rpc": "https://example.com/endpoint"
                ]
            }
        ]
    }
}

### Next Steps
- action items
- [X] bumble will open a PR to make the extension/feature discovery flags more explicit in 170
- [ ] hassan and alex will start a PR that adds snap suggestions and/or network config properties to scopeObjects

## 2023-07-19

### PRs to refine/move to close
- https://github.com/ChainAgnostic/CAIPs/pull/237
- spitballing discovery mechanics across L2s, custom wallets, and multichain contexts
- assumed versus implicit --> good direction, seems to work
- MM to discuss internally and bring interlocutors and/or corner cases in future meetings

### Ongoing issues/topics
- RPC docs - URL vs URI - service discovery field
- lockfile ecosystem - URLs for deps, but also SHA256 hashes (to detect a bump)
- analogy - URL + Hash? (dmitri's hashlink)
- typescript ecosystem - instead of URLs, just agree to type declarations (which can be written by anyone as long as two counterparties have the same ones)
- service discovery history -
- microsoft built a megaregistry... but people started distributing the entries without the registry (and hash of those entry-files)
- graphql API-API - service description API that all graphQL APIs support
- more per-method oriented (i.e. give me an OAS3 doc for each of your methods)
-

### Next Steps
- keep percolating on adoption of RPC-Docs <> EIP-6963
- PR#237
- [x] bumble to make address hmalik88's notes in a new commit

## 2023-05/06/07-*

(apologies for lapse of notetaking; work was impacted by leave, and happened mostly directly in github)

## 2023-04-12

### PRs to refine/move to close

- [PR#217 - CAIP-25-ify CAIP-27](https://github.com/ChainAgnostic/CAIPs/pull/217)
- bump to new group-scope semantics approach
- `accounts` - hard UX questions -
- how does wallet know whether to ask user for 1 or multiple addresses?
- usecases for exactly 1, 2 or more, etc...
* how wildcard?
* pedro: a flag in sessionProperties, maybe? that's how we got public keys in VMs that require it in addition to address... extension CAIPs could define sessionProperty key/val pairs over time
* hassan: how map to multiple scopeObjects?
- pedro: back to basics - keep itboth chainagnostic and multchain?
- responder provides accounts,
- Semantics - what is requester expecting back?
- Pedro: implicit requirement - 1 per scope?
- bumble: account must be valid within that scope (in curr draft)
- Pedro: EIP 1193 - multiple accounts exposable (unspecified behavior)
- 211 - some baby thrown out with the bathwater?
- rpcEndpoints <> wallet_ConnectChain - currency symbol, explorer URL, etc...
- maybe define the usecase better?
- should
- security -
- permissions not enforced on-chain?
- use-case definition
- how to request an account holding X?
- 25 should state more explicitly the statefulness/persistence assumptions
- 217 should be explicitly stateless -- just an expression of a scope periodt
- Next steps
- [X] clean up 217
- [X] bumble - clarify semantics on accounts array
- [X] bumble - clarify per-namespace constraints on account behavior
- [ ] clean up 211 - bumble
- [ ] new CAIP for constraints expression in request, whether in sessionProp and/or in sessScopes - Hassan?
- [ ] example: wallet contents
- [ ] example: 2 accounts or more, 1 acct only, etc

how wildcard?
...
"accounts": [*,*],
...

???

how add in attenuations? is it insane in sessionProperties?

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "provider_authorize",
  "params": {
    "requiredScopes": {
      "eip155": {
        "scopes": ["eip155:1", "eip155:137"],
        "methods": ["eth_sendTransaction", "eth_signTransaction", "eth_sign", "get_balance", "personal_sign"],
        "notifications": ["accountsChanged", "chainChanged"]
      },
      "eip155:10": {
        "methods": ["get_balance"],
        "notifications": ["accountsChanged", "chainChanged"]
      },
      "cosmos": {
        ...
      }
    },
    "optionalScopes":{
      "eip155:42161": {
        "methods": ["eth_sendTransaction", "eth_signTransaction", "get_balance", "personal_sign"],
        "notifications": ["accountsChanged", "chainChanged"]
    },
    "sessionProperties": {
      "expiry": "2022-12-24T17:07:31+00:00",
      "caip154-mandatory": "true",
      "minimum-contents": {
          "eip155:10": {
              "xDai": ">50"
          }
      }
    }         
  }
}

## 2023-03-29

### PRs to refine/move to close

- [PR#217 - CAIP-25-ify CAIP-27](https://github.com/ChainAgnostic/CAIPs/pull/217)
- bump to new group-scope semantics approach

### Ongoing issues/topics

- EIP-5749
- check in with Kyle
- 5749 - multi 1193, not multi-namespace at all
- Snaps - researching multiple options

### Next Steps

- [ ] - bumble will - break out scope CAIP in PR217
- new semantics - group-scopes and single-scopes
- [ ] - Hassan hold off on updating the openRPC doc until ^^
- [ ] - bumble will write error codes for

## 2023-03-15

### PRs to refine/move to close
- merge revamped [CAIP-27](https://github.com/ChainAgnostic/CAIPs/pull/217) ?
- [212](https://github.com/ChainAgnostic/CAIPs/pull/212/files#r1102531644) - seems GTG?
- [ ] Hassan will bump to newest syntax
- otherwise GTG
- [211](https://github.com/ChainAgnostic/CAIPs/pull/211/) ([preview](https://github.com/ChainAgnostic/CAIPs/blob/6748a7316ce6615f5bdd22a499819b8dde4b3f0e/CAIPs/caip-211.md))
- now with 100% less merge conflicts!
- error messages not done yet
- [ ] bumble will do this BY FRIDAY and tag hassan and kyle in it
- [ ] bumble will add a PR about link mutability for rpcDocuments (Security Considerations)
- see example below
- nits: should/will execution-api's RPC doc live somewhere more permanent-looking than github's raw content store?
- not a MM decision
- bumble will shut up

### Ongoing issues/topics
- Scope Objects fine-tuning
- whole-namescape scopes: are wallets obligated to honor them? can a wallet drop namescape-wide scope objects on principle?
- reconsider "no restruc" rule? should a wallet downscope a namespace-wide `requestedScope` to a chain-specific `sessionScope` rather than rejecting the connection?

//Example: wallet prefers a specific, older version of RPC document (to use a deprecated method, for ex.) but willing to use latest as back-up

//req:

"optionalScopes": {
    "eip155:1":{
        rpcDocuments: {https://raw.githubusercontent.com/ChainAgnostic/CAIPs/f466daa991eede2c3126625fa4e1ae5ea2009bc3/assets/CAIP-25/openrpc.json, https://raw.githubusercontent.com/ethereum/execution-apis/assembled-spec/refs-openrpc.json}    
    }
}

//res:
        
"sessionScopes": {
    "eip155:1":{
        rpcDocuments: {https://raw.githubusercontent.com/ethereum/execution-apis/assembled-spec/refs-openrpc.json}
    }
}

## 2023-03-01

- Meeting cancelled due to ETH Denver
- Async progress:
- finished 206 and merged it
- events --> notifs
- arrays/objects typos (text now matches examples)
- new error codes (error code 0 for all untrusted callers)
- new PR idea: adding implementation guidance with JS and/or TS code snippet for typing CAIP-25 objects --> HBM-88
- CAIP-27: bumble will write a PR
- chainId --> scope
- session BEFORE scope
- nesting of params inside params?
- session.scope.method(params)
- wallet namespace - pros and cons
- wallet_ methods in eip155 are unrelated
- wallet/caip211.md will be fun to write haha (CASA registry?)

## 2023-02-15

### PRs to refine/move to close

- [#206](https://github.com/ChainAgnostic/CAIPs/pull/206) - finalize what we discussed two weeks ago?
- preview [here]
- high-level sure; approval later today? (https://github.com/ChainAgnostic/CAIPs/blob/32c4a67de8ffb46b09b5722b30412bac5b726b9d/CAIPs/caip-25.md)
- [#207](https://github.com/ChainAgnostic/CAIPs/pull/207/files) -
- [#211](https://github.com/ChainAgnostic/CAIPs/pull/211) - are we aligned yet on CAIP-211 direction?
- scopes <- namespaces: SGTM
- whole-namescape scopes: obligation? can a wallet drop namescape-wide scope objects on principle?
- reconsider no restruc rule?
- how does a dapp suggest 1 or more tested snaps when there are multiple registered, some untested?
- protocol or data model?
- could a /.well-known/snaps_suggest.json
- dapp-triggered download suggestion? session-bound, not global/public?
- method (wallet calls dapp, dapp returns recommendations) versus JSONRPC notification (dapp authorized to send by CAIP25, throws recommendations over the fence whenever, possibly even page-specific recommendations)

### Ongoing issues/topics
- [#211](https://github.com/ChainAgnostic/CAIPs/pull/211) - are we aligned on
- [Session Definition]() - any progress or new ideas to discuss? any way I can help?

### Next Steps
- [ ] - Hassan will intro bumble to the designer of possible protocol/registry/etc for snap recommendation mechanism
- [ ] - Hassan to review 206 and 211 today for feedback, possible merge

## 2023-01-30

Intros
- bumble
- Hassan
- Shane (OpenRPC team at MM; //openAPI json-based language)
- https://github.com/ethereum/execution-apis

### PRs to refine/move to close
- Hassan: High level topics
1. chain authZ per namespace raises question: are we assuming methods are implemented same way on all chains of a namespace?
- do snaps service whole namespaces or just indiv chains? latter seeming more likely
- extensions (originally made for chain-id specific methods) folded into the keyed namespace design (`namespace`-wide authZs separate from `namespace:caip2` authZs)
2. how to respond to caller with recommendations if no installed snap can handle the required or requested chains?
- progressive authZ pattern better
3. permissions
- pedro - hard to understand what "permissions" means in the notes/threads
- snaps have a `package.json` equiv that includes its permissions relative to the MM host-client; openRPC URLs used in discovery (between snap and MM), via mechanisms modeled on `rpc.discover` precedent in JSON-RPC
- shane - methods === permissions or capabilities?
- pedro: EIP1193 parity -->
- shane: but non-EVM namespaces will have less standardized APIs, partic on node/client side...
- pedro: solana anecdote - try to make a standard where there isn't one yet; cosmos anecdote
- shane: but where are the method names defined? just applying the EIP ones? what's the execution APIs repo equiv for a cross-namespace snap?
- pedro: namespaces work!
- pedro: new CAIP-XXX could be the "static list of methods" CAIP, and profiling that in `namespaces` would help snap authors?
- pedro: but what about **offchain** capabilities and methods? what about IPFS, Verifiable Credentials, PGP, SSB, etc?
- shane: method names only work because they're static; what if a snap needs a method not registered here? can they just define their own openRPC documentation?
- pedro: couldn't reference for new/unknown RPC method/event defs be in request/response somehow? in sessionProperties, for ex?
- pedro: adding new methods/events the same way that someone proposed adding RPC endpoints to a given namespace object?
- pedro: including an optional per-namespace prop that links to a, e.g., an openRPC doc that anchors method names in case there aren't authorities publishing implicit static lists (like ethereum)
- `rpcEndpoints` - OPTIONAL array of endpoints
- needs to be in optional object
- Shane: Flashbots case... there are legit usecases for RPC prejudice
- Pedro: rpcEndpoints --> multiple new error codes (this wallet doesn't do any custom RPC, don't trust those RPCs, can't parse those RPCs, etc)

- `rpcDocuments` - OPTIONAL SHOULD/MUST url? require it to dereference to JSON that conforms to OpenRPC spec
- Pedro: needs a separate CAIP to define behavior here for profiles to work
- `capabilities` - string array
- separate CAIP?
4. Dan's use-case - conditional authorizations , e.g. account with balance > X
- pedro: recaps, UCANs, other authZ stringification schemes?
- pedro: string array to future proof?
- sessionProps equiv in each namespace object?
- shane: permission controller -
5. Events --> notifications?
- `notifications` (more proper by jsonRPC [nomenclature](https://www.jsonrpc.org/specification#notification))
- CAIP-27 is just CAIP-25 without an id (and not expecting a response/result)
- [ ] - new PR needed
- [CAIP-25](https://github.com/ChainAgnostic/CAIPs/pull/206) - added lots of non-normative text and made a few minor tweaks to address objections to going "Last Call"

### Ongoing issues/topics
- [CAIP-27](https://github.com/ChainAgnostic/CAIPs/pull/186)
- More discussion regarding CAIP-25?
- Pedro requested implementer feedback/reports
- Dan Finlay: Service discovery function <> UX "one-click" mechanism -
- addressed by new Privacy and Security sections?
-
- [CAIP-171](https://chainAgnostic.org/CAIPs/CAIP-171) - thoughts?
- do other serializations have to be round-trippable?
- should we be more specific about JSON serialization?

### Other business

### Next Steps
- next meeting - code snippets

## 2023-01-18

### PRs to refine/move to close
- none this week!

### Ongoing issues/topics
- [CAIP-27](https://github.com/ChainAgnostic/CAIPs/pull/186)
- More discussion regarding CAIP-25?
- Pedro requested implementer feedback/reports
- Dan Finlay: Service discovery function <> UX "one-click" mechanism

### Other business
- Hail the new WG Chair!

### Next Steps
- next meeting - code snippets

## 2022-12-05

### PRs to refine/move to close
- [alternate extension model PR#185](https://github.com/ChainAgnostic/CAIPs/pull/185/files)
- [idempotency edit](https://github.com/ChainAgnostic/CAIPs/pull/184)
- merged!
- [opt/req PR#187](https://github.com/ChainAgnostic/CAIPs/pull/187) - [Preview](https://github.com/ChainAgnostic/CAIPs/blob/b93bc01376dc4ec9b4d024f29923e22a799898f8/CAIPs/caip-25.md)
- `sessionProperties`
- `requiredNamespaces`, `optionalNamespaces`
- session --> `sessionNamespaces`
- merge conflicts
- sessionIdentifier --> sessionId

### Ongoing issues/topics
- [CAIP-27](https://github.com/ChainAgnostic/CAIPs/pull/186) - advise please on what would is needed
- Remaining Issues to ship CAIP-25
- [Accounts](https://github.com/ChainAgnostic/CAIPs/issues/144)
1. Are there account-free sessions? Are there account-required dapps or account-required sessions?
3. any error codes needed?
5. 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?
6. editorial PR needed to add `accounts` assumptions to CAIP-25 text?
- [Sessions](https://github.com/ChainAgnostic/CAIPs/issues/141)
- [wallet namespace](https://github.com/ChainAgnostic/CAIPs/issues/140)
- [Multiple Wallets](https://github.com/ChainAgnostic/CAIPs/issues/188)

### Next Steps

## 2022-11-22

- PRs
- idempotency - new [PR#184](https://github.com/ChainAgnostic/CAIPs/pull/184)
- extensions REMIX - new [PR#185](https://github.com/ChainAgnostic/CAIPs/pull/185)
- New proposal for a more aggressive CAIP-25 -

    "params": {
        "required":{
            eip155": {
                "chains": ["eip155:1", "eip155:137"],
                "methods": ["eth_sendTransaction", "eth_signTransaction", "eth_sign", "personal_sign"]
                "events": ["accountsChanged", "chainChanged"]
            },
            "eip155:10": {
                "methods": ["personal_sign"]
                "events": ["accountsChanged", "chainChanged"]
            },
            "cosmos": {
                ...
            }
        },
        "optional":{
            "eip155:10": {
                "methods": ["additional_novel_method"]
                "events": ["novel_event"]
            },
            "sessionVars" {
                "expiry": $timestamp
            }
        }
    },

result

{
  "id": 1,
  "jsonrpc": "2.0",
  "result": {
    "SessionIdentifier": "0xdeadbeef",
    "accounts": ["eip155:1:0xab16a96d359ec26a11e2c2b3d8f8b8942d5bfcdb"],
    "session": {
        eip155": {
            "chains": ["eip155:1", "eip155:137"],
            "methods": ["eth_sendTransaction", "eth_signTransaction", "eth_sign", "personal_sign"]
            "events": ["accountsChanged", "chainChanged"]
        },
        "eip155:10": {
            "methods": ["personal_sign"]
            "events": ["accountsChanged", "chainChanged", "novel_event"]
        },
        "cosmos": {
            ...
        }
        "sessionVars": {
            "expiry": $timestamp
        }
    }
  }
}

- issues
- accounts behavior
- next steps? wen ship?

## 2022-11-09

- PRs
+ [Olaf's PR on 25 and 27](https://github.com/ChainAgnostic/CAIPs/pull/171)
+ revive PR 170 - what props make sense?
+ iteration of 25 for session lifecycle
+ a flatter expression without the extensions model...

+ issues
+ decision on namespacing?
+ next steps

## 2022-10-26

### Establishing process
* Recording meetings
* Meeting scope
* `Olaf` - propose to make those general CASA meetings instead of only RPC
* Meeting cadence - currently ambigious between sources.
* Mismatch - every 4 weeks in reccurence / biweekly in event name
* `Olaf` - propose to make those every 2 weeks and relax as needed

### PRs to merge
- [Finally close 108](https://github.com/ChainAgnostic/CAIPs/pull/163) ??
- bonus: call it an authZ and close some issues
- continue discussing the extension (per namespace) versus flat (per chain) structure, new PR?

### Ongoing issues to discuss
- [accounts and sessions](https://github.com/ChainAgnostic/CAIPs/issues/144) - make assumptions and flows more explicit (swimlanes plz)
- [make sessions more explicit](https://github.com/ChainAgnostic/CAIPs/issues/141) - as part of call/response or otherwise?
- need a separate CAIP for expressing these as a data model if anything other than default?
- who sets default, dapp, wallet, browser, etc?
- session functions are part of WC model, called by [dapp](https://docs.walletconnect.com/2.0/specs/sign/session-namespaces)
- session events get logged in [wc multi-provider](https://github.com/WalletConnect/walletconnect-monorepo/tree/v2.0/providers/universal-provider#events)
- [rename](https://github.com/ChainAgnostic/CAIPs/issues/142) `handshake` to `authorization`?
- [async/idempotency](https://github.com/ChainAgnostic/CAIPs/issues/143) issue-- need to define a lifecycle for CAIP-25 events and sessions, i.e.,
- do successive calls refresh expiry if same values?
- define how successive calls add or subtract accounts, methods, events, and/or chains from the WCv2 object model
- how kill a session and "log out" explicitly?
- how nuke a session and "forget a dapp" explicitly?
- [wallet namespace idea](https://github.com/ChainAgnostic/CAIPs/issues/140)