Title: _Wallet__Connect_EIP
Category: Web

Author: ligi
Date: 2018-07-23T10:17:08.804Z

In the context of https://discuss.walletconnect.org/t/qr-code-data-format/14 - I am thinking about a (Wallet) Connect EIP and would love to gather some Ideas/Feedback.
The EIP will be based on 831.
As the ERC-831 prefix I would suggest “connect”

walletconnect is a bit too long imho - the longer the QR code gets the harder it gets to scan.
wc would also be an idea - but it has a bit of a shitty () connotation   (maybe we ignore this as it is mostly seen by computers and not humans)
connect is a bit broader - and not as opinionated - could be used for other use-cases in the future also

to encode the shared key I would suggest using base64 - which is easy to parse and saves some bytes compared to the hex encoding (also for making the QR code easier to scan) We should be open to updates from symetric to asymetric here also. Especially when these URLs are not only used for QR-Codes but also for Intents (think connecting a native Android dapp to a Wallet on the same device)
So I would suggest the following URL format:
“ethereum” “:”  “connect-” sessionID  “@” version “?” parameters
as parameters (taken from the current state of the art):
dappName
bridgeURL
symKey
Feedback/Ideas welcome!

Author: pedrouid
Date: 2018-07-23T10:35:37.706Z

Maybe “wc” prefix isn’t so bad since it will be mostly viewed by devices and not humans, saving a few characters for displaying the QR code
Also agree that base64 should be used instead of the current hex encoding for the shared key
Regarding symmetric and asymmetric keys, I still think that at least for mobile-to-desktop is best to keep it symmetric but maybe it isn’t secure enough for mobile-to-mobile. However we need to balance user experience with security because WalletConnect is first and foremost a UX improvement to current implementations
Perhaps we should also save a few characters on the parameter names:

dapp
bridge
key

Author: ligi
Date: 2018-07-23T10:45:32.156Z

Sounds great! Totally happy with shortening to dapp and bridge. With key I lean to keeping symKey to be able to distinguish later on when asymetric keys might be used. Also thinking about it a bit more: why would asymetric crypto here lead to worse UX in this case? I think this could be done without the user even noticing here …

Author: ligi
Date: 2018-07-24T12:04:04.877Z

As a follow-up from here: https://discuss.walletconnect.org/t/ideas-for-decentralizing-the-bridge-server/15/4 :
We really should care for changes in the transport layer. In the end I think PSS and/or whisper might an ideal fit here. When using these protocols IMHO we do not even need to add the keys to the URLs then as these protocols care for the encryption. Maybe we do not even need a session-id - but just generate an private  per session and use the public key as the session-id.
kindly inviting @jarradhope as I know he is very interested in it: https://twitter.com/jarradhope/status/1021489103186092032
EDIT: this way we could also get really easy to scan QR-Codes:
Selection_097405×401 8.03 KB
this is the QR-code for:
ethereum:wc-0x381e247bef0ebc21b6611786c665dd5514dcc31f@2?name=tester&pss

Author: ligi
Date: 2018-07-25T08:51:24.192Z

Idea - why don’t we use the very same scheme already today? So instead of the current sessionId we use the public key/address of the session’s private key. So the url would currently look like:
ethereum:wc-0x381e247bef0ebc21b6611786c665dd5514dcc31f@1?name=tester&bridge=bridge.mydapp.org
and as soon as PSS or whisper gets usable the URL just changes to:
ethereum:wc-0x381e247bef0ebc21b6611786c665dd5514dcc31f@2?name=tester&pss
or
ethereum:wc-0x381e247bef0ebc21b6611786c665dd5514dcc31f@2?name=tester&whisper

Author: dpyro
Date: 2018-07-27T23:11:40.117Z

Why not use checksummed addresses?
Should there be support for ENS-style addresses?
Also string@ patterns seems to be used for user information in URI examples I’ve already seen such as username/password or email name. I could see it being used to pass an account name or private key in a connect URI. Why not use something like &v=2 instead?

Author: ligi
Date: 2018-07-28T01:54:18.513Z

Why not use checksummed addresses?

You mean ERC-55? QR codes already do error correction - not yet sure how it would help

Should there be support for ENS-style addresses?

why - these addresses would only live for the session - not sure why they should support ENS

Also string@ patterns seems to be used for user information in URI examples I’ve already seen such as username/password or email name. I could see it being used to pass an account name or private key in a connect URI. Why not use something like &v=2 instead?

I do not see the advantage yet - can you elaborate? I like @version as e.g. @2 is shorter than v=2  Also the version should always be there - the private key might not be.

Author: pedrouid
Date: 2018-08-15T13:23:02.676Z

I’ve created an EIP for this
https://github.com/ethereum/EIPs/issues/1328
@ligi would love your review on it!

Author: pedrouid
Date: 2019-01-29T17:12:26.401Z

@ligi I have created a PR for updating this EIP to match the changes we discussed on the WalletConnect forum


github.com/ethereum/EIPs








Update EIP-1328


master ← pedrouid:patch-2



          opened 05:10PM - 29 Jan 19 UTC




            pedrouid
          



+10
-11






**Updating EIP-1328 WalletConnect Standard URI Format**

Changes being reviewe…d on linked discussion thread before merging and tech spec still in progress






Still updating the technical specification on the WalletConnect documentation to describe all details of the new protocol version v1.0.0-beta
I will ping on this thread by the end of the day

Author: pedrouid
Date: 2019-01-30T16:13:14.699Z

Here is the first draft of the WalletConnect v1.0.0-beta tech spec, still needs polishing but it should provide a clear enough picture


github.com


WalletConnect/walletconnect-docs/blob/v1.0.0-beta/tech-spec.md
# Technical Specification

## Introduction

WalletConnect is an open protocol for connecting Dapps to Wallets. The motivation behind it came from the lack of user-friendly solutions for user to use Wallets without browser extensions. In order to solve this it was designed to not require any software or hardware requirements from the user to connect a Wallet to a Dapp. The design is mostly tailored to mobile wallets but it could definitely support desktop wallets as well. The protocol relies that both the Dapp and the Wallet use the WalletConnect Client SDK and connect to a Bridge server that will relay the communications. The communication is initiated with a standard URI format that contains the topic of the connection request, a symmetric key used to decrypt the payload and the bridge server url.

## Core Architecture

The architecture consists essentially on a websocket server (Bridge) between two peers (Dapp and Wallet) that use the Client SDK. 

### Requesting Connection

The initiator is the first peer that requests the connection (Dapp) by posting an encrypted payload using one-time topic used for handshake only with the connection request details to the Bridge Server and using the WalletConnect Standard URI format ([EIP-1328](https://eips.ethereum.org/EIPS/eip-1328)) passes the required parameters to establish the connection: (handshake) topic, bridge (url) and (symmetric) key. 

```javascript
// Syntax

request       = "wc" ":" topic [ "@" version ][ "?" parameters ]
topic         = STRING
version       = 1*DIGIT


  This file has been truncated. show original

Author: SamWilsn
Date: 2022-05-13T18:12:24.450Z

Let me prefix this (as I often do) by saying I don’t know anything about WebDev. That said, would it make sense to also support web+wc: as a scheme? That would be compatible with Navigator.registerProtocolHandler.

Author: ligi
Date: 2022-05-14T00:58:09.958Z

As I think the wallet should not be in the browser context but outside the current solution is more to my liking. But no extreme strong opinion - if you can come up with a real use-case that is possible after switching to it (“also support” is not as easy I think as you can only use one URL nicely)

Author: SamWilsn
Date: 2022-05-14T01:11:32.265Z

The Sequence wallet is probably the only use case I know of at the moment, and even they have a browser extension. In addition to web+, ext+ could also work well with WebExtension’s protocol_handlers.

Author: ligi
Date: 2022-05-14T05:09:13.852Z

That both sounds like “wallet in the context of the browser” to me. And I also think we should rather walk away from browser extensions rather than going more in that direction. But just my 2WEI.

Author: SamWilsn
Date: 2022-05-14T16:27:27.490Z

I don’t disagree about migrating away from extension/web wallets, but they do exist today, and having one library/platform that works for all wallet styles makes it easier for users to switch to the less popular options (like external program wallets.)