Closed garantor closed 2 years ago
Yes, we already started to look at the WalletConnect v2 for months to update pyWalletConnect. The v2 is very different from v1, and we don't have so much free time to do the update.
Most of the differences, and the work, is to write the crypto primitives dedicated for v2. In practice that means add the relevent methods into the crypto file. I'm not sure if the cryptography lib can handle the "DJB cr.yp.to NaCl" algos used by v2. But the pyNaCl library using libsodium can definitely do that. The other part of changes is the message processing data exchange, so changes or update in the client part, and to make message such as CAIP-27 format. The pairing is much more complex, because bi-directional.
this is great to hear, I am not an expert in this field but if there is anything I can help with, I would be happy to do so.
thanks and wishing you the best of luck
Some days ago, we added v2 compatibility on this library. It is experimental, not fully stable, and with limited capability. It works only using the wafu official bridge relay, and with some chain id formats.
The class method constructor WCClient.from_wc_uri( wc_uri_str )
now allows the use of v2 URI as input argument. In that instance, it uses the v2 standard to interact with the dapp (through the wafu bridge).
New methods to WCClient were added:
.set_project_id( project_id )
: set the WalletConnect project id. This is mandatory to use a project id when
using WC v2 with the official wafu bridge relay.
set_wallet_metadata( wallet_metadata )
Optional. If not provided, when v2, it sends the default pyWalletConnect metadata as wallet identification. See the WalletConnect standard for the object format.
The next immediate work can be to track of multiple encrypted channels keys and topics id, so it can send the session closing message into the right destination, using the right encryption. See https://github.com/bitlogik/pyWalletConnect/blob/master/pywalletconnect/client.py#L588
In v1 we added an auto-disconnection, which is substantially useful. But the v2 implementation designed is for now basic, as a starting point. And it seems the closing session message is not sent to the right channel. Because WCv2 introduced multiples channels (where the next address is computed by ECDH), and this adds some complexity. For now only one channel is maintained. The best option might be to add some new attribute to the WCv2Client class such as session_channel_id, sessions_keys,.. to keep in memory the useful channels and their respective encrypted tunnel object.
Is there any plans to make the version compatible with V2 ? What is needed to make this present version compatible with walletconnect V2 ?