Test on https://example.walletconnect.org/ With Trust Wallet
If it is safe, we should consider to add this feature.
Yeah it’s a standard that enables the same UX of login with WeChat. Very good concept to bridge between mobile and web or even as an additional security step.
Reposted from a related Telegram chat:
hboon:
“Now visit any of the dapps that have integrated with WalletLink (listed below, with more on the way)”
This is also how WalletConnect works, right? The Dapps has to explictly support WalletConnect/WalletLink.
What I suggested earlier was to build an extension like MetaMask, but instead of holding the wallet keys in the extension, delegate that (and signing) to the mobile apps.
Dapps don’t have to do any work to add support.
(I haven’t thought through this completely, but it sounds like it would work).
Victor:
Yes, yours is better for DApp dev but not good UX for user, they have to install one more extension
hboon:
Ah, right of course. But the pitch would be, “You already have our mobile app. Now, Install 1 browser extension and you can access any dapp with it”.
Yes, similarly for other wallet apps. It seems so much harder and fragile to get each Dapp to add support. web3 itself is already quite fragile.
Coinbase has been pushing their own standard, WalletLink.
How does it compare? They have it open-source. Both allow connect and sign transactions, with WalletLink also allowing multiple and also persistent connections with dapps that users don't need to sign in again all the time.
(Article) New Coinbase Product Links Mobile Wallet With Dapps
Coinbase created WalletLink to connect its mobile wallet with dapps on desktop browsers. The goal is for Coinbase wallet users to use decentralized applications more easily, without having to copy and paste addresses or use browser extensions.Users will scan a QR code that will connect their mobile wallet with integrated dapps, and they’ll confirm transactions via a ping on their phones.
Some were quick to point out that WalletConnect offers the same service and works with any wallet, to which Coinbase employees responded that their product is open source and for everyone to use, and that they tried to make it easier to integrate than WalletConnect. Competition usually helps a free market, and Coinbase has 30 million users, so the news is likely positive for the space.
User flow
Depends on how you define safe.
If you refer to secure communication, then yes, practically† they do.
If you refer to the safety of your tokens, no, that's not their job because WalletConnect doesn't work on the token layer (TokenScript does). WalletConnect leaves it to the wallet to decide whether a transaction is safe to sign - it has no token-knowledge. It works similarly to today's Trezor. A Trezor does not know if you are sending your house away in a transaction or just a Christmas gift.
But I would say we go with it anyway because Wallet connect uses a layered approach and allows us to add new capacities (through additional RPC calls) should we want token layer APIs. WC has only defined blockchain layer APIs by default and they are considerate enough to prefix every such API with eth_ like eth_signTypedData)
The protocol uses a bridge server to pass communication between a dapp and a wallet, and it defined a set of RPC calls that can go through the bridge. The bridge server acts like a proxy server, except it explicitly intended not to be able to learn what's in the data being passed, therefore allowing it to be 'outsourced' to a 3rd party if the dapp website doesn't want to do the forwarding. It seems they recommend using a 3rd party which simplifies the architect but increases availability and opens itself to DDoS, but site owner concerned with these can always set up their own, as it is opensource.
† By saying "practically," I mean this: they used an explicit session encryption key instead of the mainstream Diffie-hellman key. Therefore, allowing a few attack models if the adversary can see the QR code or predict the key used in it. But because today everything is done through https - another layer of encryption - the harm is minimal. Here are some attack models:
-
If the person who owns the 3rd party "bridge server" can also see the QR code, he can eavesdrop or fake a transaction for the wallet user to sign. I don't think the bridge server owner would do this, but the adversary may not be the owner - might just someone who hacked into the bridge server. Still, he has to see the QR code, so this attack is improbable.
-
If, before the real wallet owner scans the QR code, an adversary scanned it instead, then the adversary gets the connection. However, without introducing TokenNegotiation (TokenScript feature), this is practically harmless because the current model binds user session with user's Ethereum address (while in TokenNegotiation this is negotiable). By "binds", I mean that the first thing user does with wallet connect is authenticate, so the adversary simply logs in to the server using his address instead of the user he is trying to impersonate. But since we already know this danger, we might either restrict the use of wallet-connect to the scenario that a session is bind to an ethereum address, or try to amend it in TokenNegotiation design instead of changing the wallet-connect protocol itself.