ERC: Web 3 QR Code Scanning API

[petejkim]

Preamble

EIP: <to be assigned>
Title: Web 3 QR Code Scanning API
Author: Peter Jihoon Kim <pete@cipherbrowser.com>
Type: Standard Track
Category: ERC
Status: Draft / Discussion
Created: 2018-03-24

Simple Summary

This Web 3 API makes it possible for Web3 DApps to scan QR Codes.

Abstract

The browser implementing this API should present a dialog to scan the QR code and return a promise that resolves when a QR-code is successfully scanned. The API looks for QR codes containing Ethereum addresses by default, but optionally takes in a regular expression object as an argument to allow for scanning arbitrary text.

Motivation

Entering lengthy strings of text such as Ethereum addresses is difficult and error-prone, especially on mobile devices.

Example Use Cases

• A DApp that can needs to scan Ethereum addresses
• An event-ticketing DApp that lets people check in by scanning tickets
• An airdrop DApp that allows people to redeem tokens by scanning vouchers

Specification

scanQRCode(match?: RegExp): Promise<string>

Experimental Implementation

Cipher Browser 1.3.3 and above (available on both Google Play and iOS App Store) have an experimental QR code scanning API for Web 3 DApps. In Cipher's current implementation, the API resides within the window.web3.currentProvider object, but something like window.web3Ext.scanQRCode() might be better. Please make suggestions.

window.web3.currentProvider.scanQRCode(match?: RegExp): Promise<string>

Examples

Example 1 (Scan Ethereum Addresses):

window.web3.currentProvider
  .scanQRCode()
  .then(data => {
    console.log('QR Scanned:', data)
  })
  .catch(err => {
    console.log('Error:', err)
  })

Example 2 (Scan custom text):

window.web3.currentProvider
  .scanQRCode(/^mydapp:.+$/)
  .then(data => {
    console.log('QR Scanned:', data)
  })
  .catch(err => {
    console.log('Error:', err)
  })

Links

• Demo Video (YouTube)
• Example DApp, usable on Cipher Browser >=1.3.3 (Source)

Revisions

• 2018/03/24: Initial Draft + Experimental Implementation in Cipher Browser

Copyright

Copyright and related rights waived via CC0.

[vikmeup]

Nice work @petejkim! Thanks for moving this forward!

I would propose to add an option to make sure it is available in the current provider.

isScanQRAvailable: Promise<boolean>

Sounds like an easy feature to add/support, I will make sure to have this support on Trust Wallet in the next few weeks.

[aunyks]

This is solid!

[yarrumretep]

This is a great idea @petejkim - thanks for putting it out there.

[wighawag]

Great idea,
I agree though that it should not be in web3.currentProvider
Maybe it could be in web3.ext or something to keep everyting in the web3 object but allowing extension

regarding naming and default behavior :
I think the default behavior should be scanning any data as opposed to ethereum address
We could add a function scanEthereumAddressQR or scanEthereumDataQR for having the method check for validity following #681

@vikmeup I like that. It is better than testing for the existence of the function. Any reason why make it a promise ? is it because ensuring there is a camera can be asynchronous ?
Making it a boolean would make it backward compatible with web3 browser that do not support it since they would return undefined. I would call it "isScanQRSupported" since it could be unavailable if the video stream is blocked by another app and not because it is not supported by the web3 browser itself
And If we have to deal with camera not being available, we could deal with it in the error

[vikmeup]

@wighawag, for Trust provider I been using provider-engine and all the calls were async, just followed that pattern, but I like sync approach tho!

Question!
After thinking for a few days, I could not come up with good use cases where dApps might need this functionality, here are my updated thoughts!
What If each mobile browser implements functionality for QR Scanning from navigation bar? that's all!
In the real world, you scan QR code and you are redirected to the specific page to complete registration/form.

But if we implement using web3, this will make adoption very low (since every dApp need to implement it) and much hard to use, instead of just using the example above.

[austintgriffith]

I've implemented QR code reading for game matching in https://cryptogs.io and it works for both Cipher Browser and Trust Wallet. I wanted to answer @vikmeup on why a Dapp would ever want to have this functionality:
It's really nice to have as a call to action to suggest to users that now is the time to use the scanner.

For instance, in my app, when the user gets to the point where she can create a new game or join an existing one, in Cipher there is a nice QR code icon indicating that they can click it to join a game via QR code.

Of course, the user can pull the QR code reader down in the Trust Wallet menu system and it works there too, but it's just nice to be able to signal to a user when they should use the QR code reader.

Why not have the QR reader in your native menu system, but also build in scanQRCode()?

Props to both @petejkim and @vikmeup for moving fast on this, I'm already using it and it's great.

[alexvandesande]

I'm not sure I understand the scenario here. *Apps should not care how their requested transaction is completed only that it is completed. As such, an app should not care that something will be shown as a QR code or sent via private api. In my opinion the correct way should be:

• An app makes a web3 request

or..

• An app calls an ethereum payment link EIP: Payment request URL specification #681

Then the the browser will open the transaction window. In that window it can either show a direct payment option (if the browser has funds) OR it can add an option to show it as a QR Code, or any other format it so desires.

[yvesmessy]

This would be a great feature when it comes to real estate especially. Any dApps that have to go with wallet based user identification. Any word on the latest here? /Would love to contribute

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.