feat: create a simple Sign API example on top of the WS client
Description
This change adds Sign API framework, and a simple example client to demonstrate pairing and session creation capabilities.
This change introduces the following functionality:
- Sign API payload serializable/deserializable data types
- Payload encryption and decryption
- Session Diffie-Hellman key derivation
- Pairing URI parsing
- Simple WS based client
Resolves #47
How Has This Been Tested?
- [x] Use example client to pair and establish the session with an example DApp:
- Click on "Goerli" and then "connect"
- In a new pop-up, click "New Pairing"
- Copy the Pairing URI
- In the terminal,
cd path/to/WalletConnectRust-.../WalletConnectRust$ cargo run --example session "<copied URI>"- DApp should now display the session window - In the DApp click disconnect
- [x] Unittests (partial)
Due Diligence
- [ ] Breaking change
- [x] Requires a documentation update
- [ ] Requires a e2e/integration test update
TODO
- [x] Typed errors instead of unnamed anyhow errors
- [ ] More unittests
- [ ] Implement Core Pairing API. Not related to Sign API, but makes sense to add.
- [ ] Add relevant information to
README.md - [x] Better documentation, code comments and function descriptions
- [x]
crypto/session.rsrefactor
Additional information
WCv2 uses layered approach. The relay protocol messages (currently only IRN, but there might be other in future), are used to carry the useful payload. In terms of this change the useful payload is Sign API messages.
Useful materials: https://specs.walletconnect.com/2.0/specs/clients/core/pairing https://specs.walletconnect.com/2.0/specs/clients/sign/session-proposal
https://specs.walletconnect.com/2.0/specs/servers/relay/relay-server-rpc https://specs.walletconnect.com/2.0/specs/clients/sign/rpc-methods
@heilhead , apologies for names dropping! The repository doesn't look very active, so this is my attempt to get some attention to the PR. Would you please be able to give this change a quick review, or maybe assign someone? Thanks!
Hi @silvestrst-crypto, thanks for the PR! Sorry we didn't see it earlier. We'll try to review it in the next few days hopefully.
gentle ping
@silvestrst-crypto Hey! Apologies for not getting back with the review, as I'm on holidays right now.
@xDarksome @farazdagi @chris13524 Can one of you guys please have a look at this?
@silvestrst-crypto can you please also share your use case of how you're intending of using this? 🙏
From your todo list, I'd consider typed errors + Readme update + probably a bit more unit tests for this PR. Anything else, let's tackle as separate PRs.
Thank you guys for your reviews! I will hopefully aim to go through the comments properly tomorrow and fix them up.
@silvestrst-crypto can you please also share your use case of how you're intending of using this? 🙏
We have an internal Rust project, where we are planning on using WalletConnect v2 to do DeFI operations, which is the main reason for tackling the Sign API at this point :slightly_smiling_face:
First of all, thanks for the contribution! We really appreciate it 🥇
Second, can you add a section to the root README for the
sign_apicrate? We also need to add a warning to that; the Rust team doesn't work on the client SDKs so the amount of rigor here is far less than e.g. our JavaScript, Kotlin, or Swift SDKs have gone through. Those SDKs are also continually improved with new features and fixes, so the Rust version will likely not be getting any of these updates unless a community member contributes it. This could change in the future if there is sufficient interest in the Rust SDK, but for now we cannot dedicate resources to keep this maintained. Can you add a note to the readme like:Warning: this Rust Sign API SDK is community-maintained and may be lacking features and stability or security fixes that other versions of the Sign API SDK receive. We strongly recommend using the JavaScript or other Sign API SDKs instead.
Good idea, I understand, thanks!
In the latest push I have:
- added simple serialization/deserialization unittests for the parameters
- done significant
ProposeNamespacesrefactor and added unittests - renamed
NamespacestoProposeNamespacesand moved them together withSettleNamespacesunder their own sub-foleders inshred_types - Fixed up TTL for
session_request, it'sunix_timestamp_in_secs()+ TTL
In the latest push:
- I have moved
sessionexample intosign_apicrate
In the latest push:
- Added README.md to the
sign_apicrate - Rebased my changes on upstream main
Hi @silvestrst-crypto, thank you for your hard work on this PR 💪 . I was wondering if you had made any progress addressing the feedback from my colleagues and if you'd like to continue working on this issue?
Hi @nopestack , lately I am quite busy, so put it on hold, but if anyone is planning on using it, I can slowly start moving it forward in spare time. Thanks!
@nopestack I think it is best to move this code to an isolated repo, and depend on wallet-connect-rust . I think this would speed up development and I'm willing to help. Besides, I do not think the maintainers have interest in merging this.
Marking this as draft in the meantime as work is paused and we cannot prioritize it at the moment. Worth revisiting it later @xDarksome @chris13524