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
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
[x] 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
[x] bumble needs to review alex's new CAIP before next meeting
[x] bumble needs to update CAIP-2 and/or write net-new CAIP about offchain authorizations per namespaces
[x] bumble owes a PR to put at least a SHOULD against treating a namespace-wide CAIP217 with empty/no chains array as a wildcard
sessionProperties.{scopename}is wierd devEx, since we explicitly do NOT want any sessionProps that aren't specific to one scopewallet_functions that aren't really scopable to a chain but are only safe to deploy in one namespacepersonal_signis a good example of a namespace-specific method that could have collisions in other namespaceseip155rename toethnamespace discussion - maybe need to timebox or defer?bip122versusbitcoinalso?eip155:0as offchain/wallet_ scope objecteip155:offchain? alex: shouldn't it break validation anyways? if it's the same reference across all namespaces that might be a cool propertychainsarray as a wildcard