Status-react: QR codes don't work for ENS names

Created on 10 Feb 2020  路  5Comments  路  Source: status-im/status-react

While working on updates to https://get.status.im/ in https://github.com/status-im/universal-links-handler/issues/17 we discovered that opening of ENS names like jakubgs, jakubgs.eth, or jakubgs.stateofus.eth does not work via QR code, only for chat keys, like so:
https://get.status.im/user/0x0461f576da67dc0bca9888cdb4cb28c80285b756b324109da94a081585ed6f007cf00afede6b3ee5638593674fee100b590318fc7bdb0054b8dd9445acea216ad2

For anything else it responds with:

Unable to read this code
Please enter or scan a valid chat key or username

This feature was apparently introduced in https://github.com/status-im/status-react/pull/9811 and based on my tests with the PR build it did work then, but only for bare usernames, ENS names, and chat keys. By "bare" I mean without the status-im://user/ prefix. Not sure if that's intended but that's how it was done.

Right now it appears the only method working is a bare chat key.

ENS names bug

All 5 comments

According to @Serhy this works in the Nightly, so it looks like we didn't include the changes in release/1.0.x branch. @flexsurfer is that intentional?

Even so, I think QR code scanning should also accept the status-im://user/{NAME} form as well.

intentional, yes

In relation to https://github.com/status-im/universal-links-handler/issues/25 I think we need to decide on a standard way for handling QR codes. Otherwise if the QR code contains whatever then the App can't know if it's #whatever channel or it's whatever.stateofus.eth user. I propose 2 ways:

  1. Use the status-im:// format in QR codes so it's contents are:

    • status-im://chat/public/whatever or

    • status-im://user/whatever

  2. Always provide full ENS name, and always prefix chat names with #:

    • whatever.stateofus.eth

    • #whatever

The former is easier to handle, but the latter is more concise and gives smaller QR codes.
In theory we could handle both cases, but consider the former one more canonical.

Closing this as the related issue has been implemented/fixed.

Was this page helpful?
0 / 5 - 0 ratings