@Michele has developed a prototype of a simple android app that bridges Keycard with WalletConnect. For those who don’t know WalletConnect, it’s an open protocol for dApps (typically on a desktop non-web3 browser) to connect to a wallet (running on a mobile usually).
Here’s a video of this demo:
You can see a user (@michele ) using a dApp (here HelioWallet) with a desktop non-web3 browser: - Pair the dApp with Keycard.
This happens by scanning a QR code + tapping the card + entering the card pin. Easy. - Interacts with the dApp and create a tx.
Here the dapp is a wallet, the user just decides to send some Eth - Keycard app shows the tx that is being asked to be signed - The user taps the card - The dApp gets the signed transaction
By the way, there’s a set of simple features on this app that makes it a cool and lightweight companion for Keycard, among which: initializing the card, importing or creating a secret in the card, change pin/puk/painring code of a card, and manage pairing slots of the card. Full list here.
Why does it matter?
Keycard and Walletconnect ecosystems can grow synergies
Here is the current list of dapps supporting Walletconnect WalletConnect
New dApps will be incentivized to integrate Walletconnect because Keycard is supported, and Keycard will benefit (more sales) from any new WalletConnect dApp
This solves the overall problem of how to use Keycard with a desktop
We’ve been thinking about his problem for a long time now, and were facing two issues mostly: this needs a supplementary hardware (a usb reader), this needs to download some supplementary software on the desktop (which is a pain).
Using Walletconnect is an elegant solution to this problem, isn’ it ?
This creates new partnerships opportunities
Examples: - A dEx could issue its own branded keycard to its users.
dEx like to integrate with hardware wallets, because they need a wallet to work with, and they need it to be secure. Keycard differentiator here compared to other hardware wallets is that it offers a very strong hardware security together with a super cost efficient price. In volume, it could be offered to users.
This is an opportunity to sell more keycards and grow the ecosystem.
These Keycard can be used with Status too. - a dApp wants to create awareness by distributing keycard with its own brand in the real world
Keycard becomes a simple wallet (or identity) for any dApp to distribute in the physical world, without the user needing to pre-own a wallet
user gets the card, taps it on his phone, this downloads the walletconnect app, user can initalize his card and he’s ready to go on his desktop browser
This partially solves the problem of a Status user that want to use a dApp with its Status account on a desktop
Let’s say you’re a Status user, you’ve set-up your first crypto account with Status, and are regularly using
Partially because:
-it’s only for those users that have their Status account on a Keycard
-they could already do so by setting up metamask (by typing his mnemonic in Metamask for instance
-at some point we might have wallet connect or something similar in Status (Ricardo’s proposition here)
What’s next?
If we go further with this project
From a product standpoint
We need to build a UX
We need to port it to iOS
We’ve got a number of features we could implement to have a full fledged (but light) Keycard companion app, see here
From a partnership standpoint, as said, this opens up several opportunities that we should pursue with dApps
first with dApps that already integrate with WalletConnect, they’re an immediate target
then for dApps that we feel would gain from integrating with Keycard+WalletConnect (I’d say online decentralized wallets like MEW or Heliowallet, and dEXs in a first step)
what privacy concern are there exactly? Reading the specifications, it looks like the payload encryption key is exchanged over the QRcode, so my understanding is that the bridge server cannot decrypt the messages sent, am I understanding it wrong? Since we are mostly talking of transactions, these will be posted to the blockchain anyway.
Regarding the centralization, yeah, that’s a compromise. What I find very good however is that the URL of the bridge server is in the QRCode, which means you (as dApp developer) can use alternative bridge servers (or run your own) if you want.
the bridge server has encrypted messages that it shuffles around, not your transactions. Transactions are then submitted as usual by the client app.
Also the server where the dApp is hosted also has your IP and it is also an unknown server and unless you run a dApp browser with a geth node, Infura also knows all your transactions associated to your IP.
If the problem is the IP and you are really concerned you are using a VPN (or two) anyway.
I think it is clear that there always is a compromise between privacy and convenience. Depending on how much weight you give to you privacy you decide what tools are acceptable to you and how much privacy you are willing to trade for convenience. IMO, WalletConnect does not really add much in terms of privacy risk.
Yes thats true, all apps are still web2, and we use web2 infura, but all these on our wall of shame, i mean do we really want to develop web2 app for keycard , it looks like wrong direction?
Walletconnect seems to not enforce their webserver, I think it should be possible to not use the webserver and instead connect directly to user’s PC, or better, use something like whisper.
Yeah I tried that out, it is great! We wanted to have a relatively simple tool that is dedicated to Keycard and allows to perform all card operations, including the less common ones like unblocking PIN, replacing keys, changing all credentials, etc.
And sorry, since this is still an experiment more than a project, I didn’t have time to write a README and mention usage of your libraries! Without them, this would have taken way longer to implement!
Hey @ligi , welcome, very good to have you around.
Regarding the use of a webserver (centralized) in WalletConnect, Status could start using it as it is for now, but we would have to solve that to fit Status Principles. I noticed WalletConnect architecture accept different protocols, but they are not yet developed, right?
This awesome! I’m glad to see these discussions on WalletConnect by the Status community.
The current protocol version (v1.0) doesn’t have any transport agreement between the two clients but it’s the goal of v2.0 to be transport-agnostic and allow the handshake procedure to establish the preferred transport between the two parties.
Alternatively we could simplify the v2.0 to use a single p2p solution in replacement of the Bridge server but ideally we should allow backwards-compatibility with Bridge servers as a fallback at least.
One picture is worth 1000 words right ?
To illustrate all the above: here’s Uniswap ‘connect’ screen. With this prototype one can directly use his Keycard with Uniswap in his desktop browser
) using a dApp (here HelioWallet) with a desktop non-web3 browser: