Status-react: Support universal QR code scanner

[hesterbruikman]

Problem

Follow up on PR #10729 that was fixed #10690

This issue enabled scanning 1:1 chats, but did not yet included support for public chat or dapp scanning. A universal scanner can resolve this.

Universal scanner has existed in the past, but was removed from V1 in order to simplify the action list under the plus-button. At the time there was no design to give the Universal QR code scanner a more appropriate place

Implementation

UI position for QR code scanner should follow Figma design

Chat

• [ ] If user scans public chat universal link like https://join.status.im/markets open public chat
• [ ] If user scans universal links with status ENS name, open 1:1 chat
• [ ] If user scans universal link with ENS name with other domain, open 1:1 chat
• [ ] If user scans other user profile key, open 1:1 chat
• [ ] If user scans universal link with own profile chat key, open dialog with copy Title: "That's you" Body: "To start a chat choose someone else"
• [ ] If user scans universal link with other user chat key, open 1:1 chat

Wallet

• [ ] If users scans wallet address open Wallet > Send > To field includes address

dapps

• [ ] If user scans universal link with Dapp (https://join.status.im/b/ens.domains) open dapp in browser

Error

• [ ] If user scans invalid values, dialog: "Unable to read this code"

Acceptance Criteria

Above behavior

Notes

Future Steps

Automatically open Send transaction doesn't always make sense when scanning an address. The user might actually scan to send a tx request in payment scenarios. This might need updating in the future. Currently, Send transaction is the most frequently used use case

[hesterbruikman]

@churik @errorists would love to get your 👀 on this to check if all use cases are covered. @flexsurfer I believe you worked on the Universal QR code reader in the past. What would need to happen to bring it back?

@errorists do you think the universal QR code reader should eventually replace dedicated QR code readers? There could be a benefit in getting relevant error messages and e.g. prevent adding a chat key as wallet address when sending a transaction or vice versa trying to start a chat with a wallet address. At the same time, different behavior can be confusing. Would love to hear your thoughts on how to get the best of both worlds

[3esmit]

https://join.status.im/markets

https://join.status.im/b/ens.domains

This should not be essentially https, if it depends on the join.status.im server, then this hurts the following Principles:

• II. Censorship resistance: Easy to block server.
• IV. Privacy: Server know too much.
• VII. Decentralization: Not decentralized.

I see that this is intended as a backwards compatibility with web2, however, when the QR Code is presented in the screen, it's already being generated somewhere (such as by join.status.im server or Status App), and it would be read in Status App, in the Universal QR Code scanner proposed here.

Therefore, https is not a URI of content inside Status Network, instead is a URL pointing to the server that generates the QR Code with Status Network URIs or Ethereum.

For Ethereum specifics, I suggest:
Falling into ERC-831:

• ethereum:pay-: ERC-681, opens payment wall with default account;
• ethereum:tx-: ERC-2400, checks and display transaction (offer link to view in etherscan).
• ethereum:app- ERC-TBD, opens a etheruem based DApp;

For Status specifics, I suggest:

• status:#channel: a public channel;
• status:@0x"68 bytes": a pubkey (private chat);
• status:@anything.eth: resolve a pubkey (private chat);

It's important that we have everything as URIs, because this would help a lot in future interoperability with other systems that should know that something is inside Status Network.

For non URI or ambiguous reads, Status should auto detect:

e.g.:

• 0x+20 bytes = probably is a wallet address, and probably user wants to pay to this address, goto ERC-681 flow.
• 0x+32 bytes = probably is a transaction id, check if a pending or confirmed transaction exists with that hash: goto ERC-2400 flow; else error.
• [ENS domain] = check resolver -> if resolver have pubkey and address, ask user (private chat or ERC-681?); else if resolver have pubkey: goto chat flow; else if resolver have address: goto ERC-681 flow; else error.
• 0x+68 bytes = probably is a public key, probably user wants to open a private chat, goto private chat flow.

[hesterbruikman]

Great points @3esmit. We're missing a Uri scheme to capture this structure and direct use: https://github.com/status-im/specs/issues/112

Would like to separate the discussion on a URI scheme from this issue, which is to implement a universal QR code scanner only

[churik]

Tested universal code scanner + existing QR code scanners from chat view, wallet view, bootnode, mailserver QR code scanner on IOS 13 and Android 10

Awesome work!