This commit brings a separation of concerns for the UI components involved in dApp interactions.
Issue: The UI components depend on the WalletConnectService and also on its dependencies like DAppsRequestHAndler. As a result the UI components have a hard dependency on the WalletConnect specifics and are incompatible with BC. This results in duplication of logic.
Issue: The UI components operate on WalletConnect specific JSON object. E.g. session objects, session proposal etc. As a result the UI is built around the WalletConnect message format.
Issue: The UI components operate on ListModel items received through functions and stored internally. Any change in the model would result in a crash.
Solution: Remove the WalletConnectService dependency from DAppsWorkflow. The DAppsWorkflow now operates with models, signals and functions. This is the first step in the broader refactoring. Moving the logic into the service itself will allow us to further refactor the WC and BC.
How does it work now:
Dependencies - The UI components have a dependency on models. SessionRequestsModel and DAppsModel.
Pairing - The pairing is initiated in the UI. On user input a pairingValidationRequested signal is emitted and the result is received as a function pairingValidated. If the url is valid the UI requests a pairingRequested. When the WalletConnectService is refactored we can go further and request only pairingRequested and to receive a pairingResult call as a function with the result. In the current implementation on pairingRequested we'll receive a connectDApp request.
Connecting dApps - The flow is initiated with connectDApp function. This call currently contains all the needed info as args. In the next step it could be replaced with a ConnectionRequests model. The connectDApp call triggered a connection popup if we're not currently showing one to the user. If we're currently showing one it will be queued (corner case). The connection can be accepted with connectionAccepted and rejected with connectionDeclined. Once the connection is accepted we're expecting a result connectionSuccessful or connectionFailed. The connectionSuccessful also expects a new id for the established connection.
Signing - The signing flow orbits around the SessionRequestsModel. Each item from the model will generate a popup showing the sign details to the user. Sign can be accepted or rejected using signRequestAccepted or signRequestRejected. No response is currently expected. The model is expected to remove the sign request item.
WalletConnect cannot operate on shared cookies in between accounts. This commit will split the cookies and cache in different folders with the user public key as folder name.
Add a new NetworkChecker QObject to StatusQ to be used in checking
internet connection status. This is used by the WebEngineLoader
to only allow loading of web pages when there is an active internet
to cover for a corner case on MacOS where the internet connection is
not reestablished if the WebEngineView was loaded without an active
internet connection.
Closes: #15598, #15806
Implement infrastructure and integration with status-go to support
general session requests
Supported methods:
- personal_sign
- eth_signTypedData_v4
depends on status-go change that exposes the signing methods
Also
- support hex or utf8 encoding for personal_sign
- format the typed data for display in the modal
Tests are disabled for now, as they are crashing on CI
Close: #14927
Trigger authentication with identity of the request
Track the authentication using the identity and allow only once
Add tests for the new functionality
Minor improvements around the code
Closes#15018
For start support showing sign message only
Support rejecting the request
Storybook integration
Add disabled tests for the main logic and sanity UI tests.
They crash on CI only and work locally on mac. Postponed finding out why
for now.
Closes: #14927
Abstract WalletConnectSDK to make it testable
Implement WC service pairing test
Bring back DAppsWorkflow tests back to life and add a pair modal test
Updates: #14927
Implement the initial Pairing user workflow and disconnect option for
the first session.
Also
- rename pairing modal accordingly (`PairWCModal.qml`) to make room for the proper
`ConnectDAppModal.qml`
- basic tests for service helpers
- update storybook to reflect the new user workflows
Closes#14607
Alex Jbanca
Stefan