update syntax and example after 5792 syntax changes

[bumblefudge]

Updated the 5792 wallet_getCapabilities equivalence spec language and examples of eip155/caip25.md following the introduction of the "chainId 0" convention in Alex Forshtat's PR on 5792 here.

Eyes from ReOwn (@jakubuid @pedrouid) and MM Snaps (@adonesky1 @vandan @ffmcgee725) appreciated so I can update the commit-specific link in 5792 before final call!

[bumblefudge]

@llbartekll @jakubuid @pedrouid + anyone else following 5792 prototyping at ReOwn - approvey approvey before 5792 goes to last call so I can update the commit-specific link IN EIP-5792?

[jakubuid]

@llbartekll @jakubuid @pedrouid + anyone else following 5792 prototyping at ReOwn - approvey approvey before 5792 goes to last call so I can update the commit-specific link IN EIP-5792?

@bumblefudge before merging, according to the last 5792 updates (https://github.com/ethereum/EIPs/pull/9529/files#diff-7a494500c37dc4b57613207d62874322198a4ced215f4a0457a0af908bb6364eR353) can we add example of "atomic": true being sent in sessionProperties/scopedProperties?

[jakubuid]

@llbartekll @jakubuid @pedrouid + anyone else following 5792 prototyping at ReOwn - approvey approvey before 5792 goes to last call so I can update the commit-specific link IN EIP-5792?

@bumblefudge before merging, according to the last 5792 updates (https://github.com/ethereum/EIPs/pull/9529/files#diff-7a494500c37dc4b57613207d62874322198a4ced215f4a0457a0af908bb6364eR353) can we add example of "atomic": true being sent in sessionProperties/scopedProperties?

E.g. in scopedProperties:

caip2:{
       "atomic":{
           "supported":true
        }
   }

CC @llbartekll

[bumblefudge]

OK i just added it in the commit above to match the open PR you linked to, although I'm still confused why the other capabilties are: { "supported": true } and atomic is true ! I opened a "change request" on that PR to be notified if it was just an oversight and the author updates the PR

[llbartekll]

@llbartekll @jakubuid @pedrouid + anyone else following 5792 prototyping at ReOwn - approvey approvey before 5792 goes to last call so I can update the commit-specific link IN EIP-5792?

@bumblefudge before merging, according to the last 5792 updates (https://github.com/ethereum/EIPs/pull/9529/files#diff-7a494500c37dc4b57613207d62874322198a4ced215f4a0457a0af908bb6364eR353) can we add example of "atomic": true being sent in sessionProperties/scopedProperties?

E.g. in scopedProperties:

caip2:{
       "atomic":{
           "supported":true
        }
   }

CC @llbartekll

@bumblefudge should this be allowed?:

caip2:{
    caip10A: {
       "atomic":{
           "supported":true
        }
     }
   caip10B: {
       "atomic":{
           "supported":false
        }
     }
   }

[bumblefudge]

should this be allowed?:

lol no that was a typo on my part, thank you for not making me feel more embarassed than I need to

[jakubuid]

should this be allowed?:

lol no that was a typo on my part, thank you for not making me feel more embarassed than I need to

the point is that we need an address (caip10), because wallets can have many addresses on given chain and some of them could support atomic batches and the others not

[bumblefudge]

we need an address (caip10), because wallets can have many addresses on given chain and some of them could support atomic batches and the others not

Oh sorry, I missed that part. EIP-5792 only allows this to be set per-chain, and leaves it up to the wallet to manage which addresses on that chain can do it, and whether or not "from" address in the batch is one it controls (and is an onchain-address). so maybe the solution here is to leave this complexity OUT of the examples in the CAIP-25 profile, but include a solution/workaround in the WC docs, e.g. multiple namespaces for the same chain (with different addresses) where one returns true and one returns false for atomicity?

[jakubuid]

we need an address (caip10), because wallets can have many addresses on given chain and some of them could support atomic batches and the others not

Oh sorry, I missed that part. EIP-5792 only allows this to be set per-chain, and leaves it up to the wallet to manage which addresses on that chain can do it, and whether or not "from" address in the batch is one it controls (and is an onchain-address). so maybe the solution here is to leave this complexity OUT of the examples in the CAIP-25 profile, but include a solution/workaround in the WC docs, e.g. multiple namespaces for the same chain (with different addresses) where one returns true and one returns false for atomicity?

The 5792 wallet_getCapabilities request allows a dapp to specify the address on which it needs the capabilities: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-5792.md#wallet_getcapabilities-example-parameters

In CAIP-25 handshake, the wallet can define 5792 capabilities in front for all of the addresses it supports, hence the thinking is that scopedProperties can be used for that as @llbartekll suggested:

caip2:{
    caip10A: {
       "atomic":{
           "supported":true
        }
     }
   caip10B: {
       "atomic":{
           "supported":false
        }
     }
   }

It should be convenient for wallets to do it this way

multiple namespaces for the same chain (with different addresses) where one returns true and one returns false for atomicity?

I'm not sure if I follow how that structure would look like but I'm open for any suggestions

[bumblefudge]

oh god you're totally right, i forgot that the REQUEST specifies a wallet, and optionally chains, and the response specifies chains (with the per-address implicit). yeah modeling this inside CAIP-25 (where addresses are properties of namespaces) is... always going to be a little lossy/chaotic. forgive me for complicating things but I think the EIP5792 exchange

req:
getCaps( address1, [chainX, chainY])
res:
chainX: {
   <caps>
}, chainY: {
   <caps>
}

as a CAIP-25 handshake would be more accurate to translate as:

req:
...
"eip155:chainX": {
...
"eip155:chainY": {
...
"sessionProperties": {
   <caps>
}
res:
eip155:chainX: {
  addresses: [address1]
...
eip155:chainY: {
  addresses: [address1]
...
scopedProperties: {
   eip155:chainX: {
      <caps>
   }
}

(risky/potentially broken if multiple addresses are being requested) or

req:
...
"eip155:chainX": {
...
"eip155:chainY": {
...
"sessionProperties": {
   <caps>
}
res:
eip155:chainX: {
  addresses: [address1]
...
eip155:chainY: {
  addresses: [address1]
...
scopedProperties: {
   "eip155:chainX": {
      "eip:155:chainX:address1": {
          <caps>
      }
   }
}

(more faithfully roundtrip-translateable, less risky of malforming, but extremely verbose).

although it's repetitive, I actually prefer the second of the two options I just gave, because the capabilities are being expressed PER ADDRESS inside of a namespace object (and repeated for every chain that address operates on, unless it's a 0x00/sessionProperties cap available on any eip155). that is, at least, the functional complete-equivalent of the EIP5792 model. i don't like the idea of just throwing CAIP-10 partitions into scopedProperties, because each entry in sessionProperties is specified to map to a scope (i.e. a "namespace" in Reown SDK terms) and some implementations (like I believe MM's) would just drop them if they were keyed to anything else. does that make sense?

[jakubuid]

oh god you're totally right, i forgot that the REQUEST specifies a wallet, and optionally chains, and the response specifies chains (with the per-address implicit). yeah modeling this inside CAIP-25 (where addresses are properties of namespaces) is... always going to be a little lossy/chaotic. forgive me for complicating things but I think the EIP5792 exchange

req:
getCaps( address1, [chainX, chainY])
res:
chainX: {
   <caps>
}, chainY: {
   <caps>
}

as a CAIP-25 handshake would be more accurate to translate as:

req:
...
"eip155:chainX": {
...
"eip155:chainY": {
...
"sessionProperties": {
   <caps>
}
res:
eip155:chainX: {
  addresses: [address1]
...
eip155:chainY: {
  addresses: [address1]
...
scopedProperties: {
   eip155:chainX: {
      <caps>
   }
}

(risky/potentially broken if multiple addresses are being requested) or

req:
...
"eip155:chainX": {
...
"eip155:chainY": {
...
"sessionProperties": {
   <caps>
}
res:
eip155:chainX: {
  addresses: [address1]
...
eip155:chainY: {
  addresses: [address1]
...
scopedProperties: {
   "eip155:chainX": {
      "eip:155:chainX:address1": {
          <caps>
      }
   }
}

(more faithfully roundtrip-translateable, less risky of malforming, but extremely verbose).

although it's repetitive, I actually prefer the second of the two options I just gave, because the capabilities are being expressed PER ADDRESS inside of a namespace object (and repeated for every chain that address operates on, unless it's a 0x00/sessionProperties cap available on any eip155). that is, at least, the functional complete-equivalent of the EIP5792 model. i don't like the idea of just throwing CAIP-10 partitions into scopedProperties, because each entry in sessionProperties is specified to map to a scope (i.e. a "namespace" in Reown SDK terms) and some implementations (like I believe MM's) would just drop them if they were keyed to anything else. does that make sense?

Makes sense to me and I also prefer the second option 🙏 Can you update the PR with the example? I'll ping the Reown team to review and we should aim to merge it this week!

[llbartekll]

oh god you're totally right, i forgot that the REQUEST specifies a wallet, and optionally chains, and the response specifies chains (with the per-address implicit). yeah modeling this inside CAIP-25 (where addresses are properties of namespaces) is... always going to be a little lossy/chaotic. forgive me for complicating things but I think the EIP5792 exchange

req:
getCaps( address1, [chainX, chainY])
res:
chainX: {
   <caps>
}, chainY: {
   <caps>
}

as a CAIP-25 handshake would be more accurate to translate as:

req:
...
"eip155:chainX": {
...
"eip155:chainY": {
...
"sessionProperties": {
   <caps>
}
res:
eip155:chainX: {
  addresses: [address1]
...
eip155:chainY: {
  addresses: [address1]
...
scopedProperties: {
   eip155:chainX: {
      <caps>
   }
}

(risky/potentially broken if multiple addresses are being requested) or

req:
...
"eip155:chainX": {
...
"eip155:chainY": {
...
"sessionProperties": {
   <caps>
}
res:
eip155:chainX: {
  addresses: [address1]
...
eip155:chainY: {
  addresses: [address1]
...
scopedProperties: {
   "eip155:chainX": {
      "eip:155:chainX:address1": {
          <caps>
      }
   }
}

(more faithfully roundtrip-translateable, less risky of malforming, but extremely verbose).

although it's repetitive, I actually prefer the second of the two options I just gave, because the capabilities are being expressed PER ADDRESS inside of a namespace object (and repeated for every chain that address operates on, unless it's a 0x00/sessionProperties cap available on any eip155). that is, at least, the functional complete-equivalent of the EIP5792 model. i don't like the idea of just throwing CAIP-10 partitions into scopedProperties, because each entry in sessionProperties is specified to map to a scope (i.e. a "namespace" in Reown SDK terms) and some implementations (like I believe MM's) would just drop them if they were keyed to anything else. does that make sense?

maybe 2 options should be allowed? option 1 if wallet supports given capabilities for all the addresses and option 2 for granular approach.

[jakubuid]

@llbartekll @bumblefudge Should we update the example with the 1st and 2nd approaches and merge this week?

to allow in response:

scopedProperties: {
   eip155:chainX: {
      <caps>
   }
}

or

scopedProperties: {
   "eip155:chainX": {
      "eip:155:chainX:address1": {
          <caps>
      }
   }
}

[bumblefudge]

Looks good to me, just wondering if you want to include the changes just added to 5792

oh man it never ends! does this work? it's a little far-fetched as an example, but i wanted the reader to notice the heirarchy/override stuff.

[jakubuid]

Hey folks, can we merge it shortly? What's missing?

[bumblefudge]

Approved out-of-band by @obstropolos