Automatically switch apps when dApp asks for signing

[nop33]

Subtasks

Android

• [X] 1. Automatically switch to the mobile app when clicking the WalletConnect connect button in a mobile browser dApp
  • This was implemented by using wc as the scheme of our mobile app (see Expo docs) so that our app shows in the Android app selector when clicking on the "Connect" button in the dApp's WalletConnect modal. We also used useURL of expo-linking (see Expo docs) to parse the WalletConnect URI and pair.
• [x] 2. Automatically switch back to the mobile browser after successfully connecting to the dApp through WalletConnect
  • Rainbow handles this by calling the goBack func of the @react-navigation/native package, but this has the side-effect that if you connect to a desktop browser dApp, the mobile wallet will go to the background after connecting (there's no separate behavior between mobile and desktop browser connections)
  • Metamask has the correct behavior: If connected to a mobile browser dApp, it switches back to it. If connected to a desktop browser dApp, it just displays the toast message. I noticed an issue, however, with OpenSea. OpenSea requests the user to sign a message right after connecting with WalletConnect. In some cases, Metamask would switch back to the mobile browser after connecting with WalletConnect and it wouldn't switch back to Metamask to sign the message automatically.
  • Based on the above, we have a choice to make:
    1. Do we simply display a success message that says "Success, you can go back to your browser" and not try to automatically switch to the mobile browser (after detecting whether we connected to a desktop browser dApp or a mobile browser dApp)? This simple solution has the benefit that (i) It is simple and consistent with the (new) iOS behavior and (ii) if the dApp requests a signature right after connecting, we won't fall into the same issue that Metamask has. This behavior is mentioned as a "common pattern" by the WalletConnect docs .

       The common pattern of establishing a connection between a mobile wallet and a mobile application is the following: ... .5. User returns to Dapp manually

    2. Do we try to switch back to the mobile browser dApp, replicating Metamask's behavior? Confusingly, this is also recommended by the WalletConnect docs:

       In the case of mobile browser dapps and native Android wallets communication, we recommend moving wallets into the background after both approving and rejecting sessions or approving and rejecting requests to persist smooth deep-link UX.

• [x] 3. Automatically switch to the mobile app when mobile browser dApp requests for approval
  • This is a common pattern, mentioned by the WalletConnect docs:

    Similar pattern happens when Dapp wants to send a signing request to wallet: ... .2. User is redirected automatically to already connected wallet

• [x] 4. Automatically switch back to the mobile browser after approving/rejecting
  • Same as in (2)

iOS

• [ ] 1. Automatically switch to the mobile app when clicking the WalletConnect connect button in a mobile browser dApp

  iOS has some more caveats to the integration but we ensure to make it as straightforward as possible. Since its operating system is not designed to handle multiple applications subscribing to the same deep linking schema, we've designed the QRCode Modal to list supporting wallets on our Explorer and target specific deep links or universal links for each wallet.

  To add your own wallet to the Explorer, login to your WalletConnect Cloud account.

• [x] 2. Automatically switch back to the mobile browser after successfully connecting to the dApp through WalletConnect
  • This seems to not be possible after iOS 17: https://github.com/rainbow-me/rainbow/issues/5172
  • Metamask displays a toaster message that says "Please check the application"
  • Rainbow displays a dismissable bottom modal that reads "Go back to your browser"
• [ ] 3. Automatically switch to the mobile app when mobile browser dApp requests for approval
• [x] 4. Automatically switch back to the mobile browser after approving/rejecting
  • Same as in (2): Not possible after iOS 17.

Description

1. When connecting to the Uniswap dApp through WalletConnect in a mobile browser and trying to make a swap, Metamask, Rainbow, and Argent, all pop up to sign the request from the dApp (the user doesn't have to manually switch apps).
2. When the request is signed or rejected, the browser app is brought back to focus. EDIT: On iOS 17 this is not the case anymore.

Related issues

Related to alephium/alephium-frontend#95

Related resources

• https://docs.walletconnect.com/web3wallet/mobileLinking
• https://docs.expo.dev/guides/linking
• https://docs.expo.dev/guides/deep-linking/
• https://reactnavigation.org/docs/deep-linking/

[mvaivre]

That would be much better than the in-browser wallet IMO, as you can keep the browser state independent from the app state.

[diomark]

You're mentioning a second issue that I know I was experiencing but didn't report - that after signing, you stay in the wallet. (it really should popup wallet to sign, then go back to browser after)

[MaudSimon]

Adding a feedback on this issue as I think it's relevant for prioritization: "this ONE issue though means I keep using kiwi browser (with extention wallet loaded) for dapps instead of the mobile wallet as it works smoother".

[diomark]

The main issue is that when you sign something from chrome/mobile, nothing happens.. you have to know to switch manually to wallet and confirm the signing request that's there - and once you do, manually switch back..

It should popup the wallet on signing request and go back to the dapp/chrome tab when done signing

[nop33]

Thanks for the feedback both of you. We'll prioritise the task accordingly!

[nop33]

Regarding (3) on Android.

The WalletConnect docs say:

To receive signing request in your Wallet, you'll need to initialize Kotlin SDK with the Redirect object where you pass a deep link that redirects to your wallet when it comes to receiving signing request from Dapp.

val redirect = "kotlin-wallet-wc://request" //should be unique for your wallet

Instead of the Kotlin SDK we are using the @walletconnect/sign-client package. When initializing the SignClient we can pass a redirect object that can have 2 props: native and/or universal. This is what Rainbow and Metamask use respectively:

// Rainbow
redirect: {
  native: 'rainbow://wc',
  universal: 'https://rnbwapp.com/wc'
}

// Metamask
redirect: {
  native: 'metamask://',
  universal: 'https://metamask.app.link/'
}

As expected, the custom schemes are also part of the respective AndroidManifest.xml files:

• Rainbow
• Metamask

They also register wc as a custom scheme, like we do.

I tried registering the alephium scheme, but I haven't managed to make it work yet. I can verify that the alephium scheme is correctly registered because the app comes to focus when I run

bunx uri-scheme open alephium:// --android

It also works if I run

adb shell am start -W -a android.intent.action.VIEW -d "alephium://" org.alephium.wallet

In the Kotlin example mentioned in the WalletConnect docs, I see that the redirect prop they use is:

kotlin-web3wallet:/request

The interesting thing about this is:

1. It uses a single /
2. kotlin-web3wallet is not registered as a scheme in the AndroidManifest file, but it is mentioned in:
   1. https://github.com/WalletConnect/WalletConnectKotlinV2/blob/master/sample/wallet/src/main/kotlin/com/walletconnect/sample/wallet/ui/Web3WalletNavGraph.kt#L147
   2. https://github.com/WalletConnect/WalletConnectKotlinV2/blob/master/sample/wallet/src/main/res/navigation/nav_graph.xml#L18-L20

[mvaivre]

Wonderful research!

I'd go with the simplest option: "Simply display a success message that says "Success, you can go back to your browser" and not try to automatically switch to the mobile browser".

This has many advantages:

• We avoid any edge cases related to OS behaviours, dApp behaviours etc.
• We inform the user properly instead of letting her in the dark
• The flow will be consistent in both iOS and Android

This flow is used in many payments apps btw, like twint in CH.

WDYT? We can talk more about that tmr.

[nop33]

I agree. That will take care of tasks (2) and (4) for both Android and iOS.

We still need to figure out (1) for iOS and and (3) for both Android and iOS.

[nop33]

This article makes me think that the redirect might need to be set on the dApp side as well... https://medium.com/@felipe.aga/how-to-use-walletconnect-with-react-native-ffe76d88566

[nop33]

To solve the point (1) for iOS, I've been working on registering our mobile wallet app to the WalletConnect Explorer, but I am stuck at this step. "Alephium" is not listed in the supported chains:

Click here to see screenshots


Maybe we need to register our chain?

If you don't see your chain listed in this list, then you will need to create an issue in GitHub to to get the process started. You can do so by clicking here. Once your chain is added to this list, wallets & dapps will be able to indicate support for your chain via WalletConnect's Cloud. https://docs.walletconnect.com/advanced/multichain/overview https://docs.walletconnect.com/cloud/chains/overview

[nop33]

@mvaivre I moved this to the following release. However, there doesn't seem to be a high demand for the remaining subtasks (iOS-related). Besides, as the commend above mentions, we need to first register our app with WC Cloud. I propose we de-prioritize this task until it's really needed by our community (basically remove it from our milestones for now and focus on other tasks).

[nop33]

ping @mvaivre

[nop33]

We need to re-prioritize this issue due to popular demand.