Replacing DappName with HTML Meta tags


#1

Instead of using the DappName provided with the Browser SDK, it could simply pass the URL of the current webpage to the URI generated for the QRCode. Then the Wallet SDK would be responsible for fetching the information from this webpage directly including metatags commonly used for socialmedia, webpage title and a favicon. This implementation would look similar to the current Privacy Mode that Metamask uses for the EIP-1102. Despite chrome extensions having more integral access to the webpage contents, this is still an improvement over the DappName current implementation.


#2

Unsure about this. Should not be tightly coupled and assumed dApps are always websites. Yes currently most dApps are websites. But dApps don’t have to be websites.


#3

What if Dapp metadata followed a schema that the browser SDK default to return the url but native dapps could overwrite this using a different SDK, nativeDapp SDK

The schema could look like this

{
    "url": <String>,
    "name": <String>,
    "logo": <String>
}

It could be encoded in base64 for shortening the URI

The browser SDK would simply fill the url parameter to keep the QR code resolution easily readable but nativeDapp SDK would fill the name and logo parametrs instead. Native Dapps would use deep links or universal links which woudln’t have a strict length restriction

So for the Example Dapp hosted at example.walletconnect.org. We would follow the schema as follows:

{
    "url": "https://example.walletconnect.org"
}

Which it encode to base64 as

eyJ1cmwiOiJodHRwczovL2V4YW1wbGUud2FsbGV0Y29ubmVjdC5vcmcvIn0=

Then we could add replace the name parameter in the ERC-1328 as dapp and it would look something like this

ethereum:wc-8a5e5bdc-a0e4-4702-ba63-8f1a5655744f@1?dapp=eyJ1cmwiOiJodHRwczovL2V4YW1wbGUud2FsbGV0Y29ubmVjdC5vcmcvIn0&bridge=https%3A%2F%2Fbridge.walletconnect.org&symKey=KzpSTk1pezg5eTJRNmhWJmoxdFo6UDk2WlhaOyQ5N0U=

#4

This technically would move the dappName inside the schema and we could additionally add an ethereum address to allow it to be used with ETH Registry in the future


#5

I think the url’s get way to long this way. This makes the QR codes really badly scanable. I would rather shorten the QR codes.
I would rather prefer if this data gets submitted when creating the session (encrypted so it is not visible to the bridge)


#6

I would argue that the length is still reasonable and doesnt produce an unscannable QR Code.

Also the URI is never shared with the Bridge at any point. It’s always been secret between the Dappp and the Wallet hence why it includes the symKey for encryption of the payloads

I think this is a good solution that fairs much better than the dappName in a multitude of scenarios. Besides it more closely resembles what Metamask currently achieves with it’s on implementation of Privacy Mode


#7

it’s not unscannable - but it is worse in scanning. Also in some cases you cannot display it then anymore - e.g. on some consoles - already hitting limits there with the current size.
And I see no reason yet to not upload it to the bridge server. You need to create a session anyway - why not add it as (encrypted) payload there? The call is done and it is minimal additional payload.


#8

Actually you are right! We could have a pre-session data exchange that allows the Dapp to submit an encryptedPayload with Dapp metadata.

More important than replacing the DappName with HTML Metatags is the DappName should be removed from the URI competely and passed through the bridge encrypted.

[EDIT]
This would actually be sensible to POST to the bridge as a session request at the same HTTP request that the DApp fetches the sessionId. Already compatible with the current architecture, it could easily fit in with the v0.8.x update


Initial call on session creation