Support adding hotspot using (dynamic) QR-code

[timcooijmans]

Can we add a way to replicate the add_gateway behaviour over BLE with a "dynamic” QR-code to the app? So:

1. Arguments for gateway-signed transaction come from some source (manual-input of owner-address + some values, think of management-dashboard either remote or on the hotspot itself)
2. Gateway(= miner currently) creates gateway-signed transaction (just like over BLE)
3. Transaction is presented as QR-Code to app
4. QR-code is scanned by app
5. Details are confirmed by user in app
6. Transaction is signed by app

[BenoitDuffez]

The Helium app could have a link for step 1 to be:

https://vendor.desired.url/?address=XXX

Where XXX would be the Helium wallet address. This would allow the user to avoid copy/paste or type its wallet address (convenience and error avoidance).
It would be up to the vendor to submit a PR on the Helium app to put the desired URL, and also up to the vendor to handle the URL so that the user is guided through the onboarding process.

Once the vendor specific onboarding (e.g. step 2) is done, the vendor specific code should send back the transaction to the Helium app in a standard way (step 3).

The QR code idea is very good. It could contain:

helium://onboard?txn=XXX

where XXX is the transaction. If we take the example of the DIY documentation:

With your Miner, you will want to issue the following command:
miner txn add_gateway owner=YOURWALLET
The command has base64 encoded output:
CrQBCiEBUan9QkkHYl0SdEn8YB+bwV3BrFjQi+aZagK1JE7z3HASIQCeOSBaMKkT23wHI+IHE3pxUu1pKx368C7ICDC0fB
oCPSJHMEUCIQDzkSfX3Gv568QZidGL1V1w0m/2QSTRYrBE1qC++oG3wQIgAT7UnqLoLIJjJ5aoC3iAmcoUDnG7B09O9nQi
oTp/ZRQqIQHjoSohWDrb6kLVXHXlLznNNX43ZjjPoJrP7XiwXGmyjUAB

Then the URL would be:

helium://onboard?txn=CrQBCiEBUan9QkkHYl0SdEn8YB+bwV3BrFjQi+aZagK1JE7z3HASIQCeOSBaMKkT23wHI+IHE3pxUu1pKx368C7ICDC0fBoCPSJHMEUCIQDzkSfX3Gv568QZidGL1V1w0m/2QSTRYrBE1qC++oG3wQIgAT7UnqLoLIJjJ5aoC3iAmcoUDnG7B09O9nQioTp/ZRQqIQHjoSohWDrb6kLVXHXlLznNNX43ZjjPoJrP7XiwXGmyjUAB

The transaction could be converted to base64url for URL safety:

helium://onboard?txn=CrQBCiEBUan9QkkHYl0SdEn8YB-bwV3BrFjQi-aZagK1JE7z3HASIQCeOSBaMKkT23wHI-IHE3pxUu1pKx368C7ICDC0fBoCPSJHMEUCIQDzkSfX3Gv568QZidGL1V1w0m_2QSTRYrBE1qC--oG3wQIgAT7UnqLoLIJjJ5aoC3iAmcoUDnG7B09O9nQioTp_ZRQqIQHjoSohWDrb6kLVXHXlLznNNX43ZjjPoJrP7XiwXGmyjUAB

This would allow the Helium app to onboard a QR code, but also accept cross-apps links (e.g. from vendor app to helium app, or from website to helium app).

This URL format could also potentially accept other actions in the future (should Helium want that), for example:

# pay to recipient
helium://pay?addr=b58_recipient
# pay 123456.789 HNT to recipient
helium://pay?addr=b58_recipient&amount=123456.789
# burn 42 HNT to DC at address
helium://burn?addr=b58_recipient&amount=42

Steps 4-6 are handled by the Helium app, including sanity check, signature verification or other input validation, as well as user confirmation of the desired transaction.

Should that be required / requested by Helium, some other metadata could be added to the helium://onboard URL, such as &message=Thank+you or &label=Vendor+Gateway+Model+915+S+plus+lite or whatever other info that would be interesting to show the user when confirming (step 5).

edit 2021-05-05: initial post had base58 instead of base64url

[abhay]

I think this works pretty well. The one recommendation I'd have would be to consider base64url instead of base58 but I don't have a strong feeling.

I wonder how these URLs fit into the existing QR code scanning infrastructure we have in the app.

cc: @allenan @tyler-whitman @matthewcarlreetz

[timcooijmans]

I'm perfectly fine with having the link in step 1, just make it non mandatory (so just scanning the QR-code or using the app-link directly also works).

Agree with @abhay let's use base64url-encoding (that is more commonly used and it's trivial convert to and from base64)

[timcooijmans]

Now that I think of it a bit more @BenoitDuffez I have some questions/considerations regarding Step 1:

• How does the user pick provisioning over Bluetooth or via "QR-code". We for example would have hotspots that only support Bluetooth and hotspots that only support "QR-code". Do we let the user pick Manufacturer and then Model? Or do we keep it more general with "Provision over Bluetooth" and "Provision using Manufacturers website/app"
• Maybe optionally, add another QR-code to be printed on the hotspot itself, that contains: https://vendor.desired.url/?onboarding=XXX. This QR-code can then be scanned by the Helium app, it matches the URL against the list of vendors in the app and then redirects to https://vendor.desired.url/?address=XXX&onboarding=XXX to allow for even easier onboarding.

[BenoitDuffez]

Of course, I used base58 but meant base64url. Thank you for the correction.

For step 1 if you have different flows depending on the hardware model, in my opinion it makes sense to have vendor choice, and then model (model A uses standard BLE flow, model B uses link, model C uses QR scan).

As far as Kerlink is concerned we'd have only one way to onboard our gateways, so the model selection step is useless.

That would be

• start app
• add hotspot: which vendor?
  • helium/rak/etc => BLE
  • vendor A => open https://helium.vendor-a.com/onboard?address=XXX
  • vendor B => open QR scanner
  • vendor C => which model?
    • model C1 => BLE
    • model C2 => QR scanner

etc

[cokes518]

The divergent onboarding flow will start after selecting a manufacturer, but I can see a world where you're presented with Bluetooth pairing instructions, and a secondary option to onboard via QR code, which gives makers flexibility to support both bluetooth-enabled and not-enabled gateways.

I'm a fan of this new direction. We already have expanded how the app processes QR codes with this feature: #423 and can easily adapt and expand that to onboarding.

[BenoitDuffez]

QR code scanning requires the user to use a computer and fiddle around to find the IP address or the host name of the gateway on the LAN, which is very bad in terms of UX for step 1. Redirecting to an URL instead allows to onboard only with phone, and if said URL is captured by another app, it allows to use mDNS and a very nice UX.

Please consider using a custom scheme URL to finish the onboarding as it allows the user to avoir the use of a computer and the IP lookup.

[BenoitDuffez]

@cokes518 hi Coco, what's the latest on this topic? Can you support QR code scanning? Can you support app linking with a custom scheme? How can I help?

[cokes518]

@BenoitDuffez The app doesn't support QR onboarding yet, but this is the general direction that the app will support: https://docs.helium.com/mine-hnt/hotspot-makers/hotspot-qr-onboarding/

If you can help generate a QR code, the team can start work off of that.

App linking is not an issue, we're happy to review PRs and support wherever needed.

[BenoitDuffez]

Not sure I understand what help you need with "generate a QR code"? Do you mean something like that?

$ echo CrQBCiEBUan9QkkHYl0SdEn8YB+bwV3BrFjQi+aZagK1JE7z3HASIQCeOSBaMKkT23wHI+IHE3pxUu1pKx368C7ICDC0fBoCPSJHMEUCIQDzkSfX3Gv568QZidGL1V1w0m/2QSTRYrBE1qC++oG3wQIgAT7UnqLoLIJjJ5aoC3iAmcoUDnG7B09O9nQioTp/ZRQqIQHjoSohWDrb6kLVXHXlLznNNX43ZjjPoJrP7XiwXGmyjUAB \
  | base64 -d \
  | qrencode -8 -o qr.png

This gives the following QR:

[BenoitDuffez]

Maker's web dashboard provides internet connectivity instructions to the user, gathers gateway signature, owner signature, and generates the add_gateway transaction and embeds the transaction in a QR Code

I'm confused, only the wallet owner may sign the transaction, and the Maker does not have access to it.

I'm assuming that the QR code contains the transaction signed only by the miner, and the app then needs to sign it with the user wallet and then submits it for final signature/blockchain submission.

Can you confirm that the Maker will not gather the owner signature?

[shawaj]

Can you confirm that the Maker will not gather the owner signature?

That seems like the best way. I.e. the actual signing from the owners wallet and submission to blockchain is done only after scanning the QR code from the miner.

And from the screenshots on that page it appears like that was the suggestion. Maybe just wrong in the text?

[BenoitDuffez]

Hi @matthewcarlreetz are you close to completion? I'd like to add our Hotspot in the list so I'd rather wait until it's merged to do so. Let me know. Thanks

[matthewcarlreetz]

Hi @BenoitDuffez . The PR is ready, just one last minute thing to add... We are planning to put QR onboarding behind a feature flag so that Helium and makers can test before going live to everyone. I'm getting started on that work right now.

[BenoitDuffez]

OK good. I started to work on adding our hotspots to the app, not sure how it would be convenient for you to do that? I could fork your feature branch and commit to this. Any other way would be fine for me too.

[matthewcarlreetz]

OK good. I started to work on adding our hotspots to the app, not sure how it would be convenient for you to do that? I could fork your feature branch and commit to this. Any other way would be fine for me too.

I think the best way would be to fork this branch so you can create your maker files. I should be merging this branch within the next day. Once it goes in you could rebase or cherry-pick and make a PR into main.

[BenoitDuffez]

Awesome thanks.

[BenoitDuffez]

one more thing @matthewcarlreetz, I saw that the app supports links with the helium:// scheme, and it seems that it supports helium://add_gateway/address and address is actually parsed as the add gateway transaction. Can you tell me the format of the expected transaction? I don't know react/ts that much and I couldn't figure out how it is parsed. I tried by sending the transaction in base64 but it crashed the app (index out of range: 5 + 33 > 33).
Thanks

[BenoitDuffez]

I found about the transaction decode failure: thrown by protobuf, caused by a wrong transaction data being parsed on my end (base64 instead of base64url).