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

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

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 …

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.

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?

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.

# 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