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.
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 sessionIds, 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
[ ] @pedrouid : fix my 282 typo, and split into two CAIPs?
wallet:namespace versuswallet_methodswallet_watchAsset(first one???)provider_getSessionagainst the extensionId would rehydrate a broken session, in this model-- dev has one less footgun letting browser route this requestwindow_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,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.sessionIds, it refers only touuids(which could be extensionIds maybe?)window.addEventListener(postMessage, ...)provider_?wallet_by now?wallet_walletCAIP-104 namespace?chrome.runtime-based lines-- maybe start there and think about how 282 and 6963 could coexist with externally-connectable extension wallets?