Andriod camera not working to scan QR code for Remote node setup

[bitsam]

Andriod camera not working to scan QR code for Remote node setup

Description

Unable to setup Remote node on Raspiblitz

Expected Behavior

QR code should have detected

Actual Behavior

nothing happens, do I have to click the Paste button to take a photo? When clicking paste, the error unsupported connection format.

Possible Fix

a place to type or copy paste the url would be nice

Steps to Reproduce

Context

Unable to use the App

Your Environment

Raspiblitz 1.6

• Zap version: _ 0.3.1 beta
• Android version: _11 RBP2
• Device: _Google Pixel 3
• LND Version: _11

[michaelWuensch]

Hi, thanks for the report.
Have you tried to move the phone forward and backwards while scanning? The code does not necessarily have to fit exactly into the brighter square. On my phone it works mostly better if it is actually smaller than the square.
Most likely though the problem is the combination of the QR-Code scanner library we use and your phone.
We already had the same problem of scanning very dense codes with the samsung S10 if I recall correct.

The paste button pastes a string from your clipboard. It is like an alternative to scanning.
So to fix your problem, you can paste the connect string and it should work.

If you have an idea on how to make more obvious what the paste button does, please let us know.

To fix Zap to be able to scan it we either have to use a different QR-code scanner implementation or we might work on a less dense connect QR-code version. (#203 )

One more cause of the problem could be that not the whole QR-code is shown as it is not fitting in the screen. If you do not have a border arround the code on all 4 sides, this might be the problem.

[Kixunil]

Some more ideas to improve QR code scanning:

• Disable TLS verification entirely for onion connections (onion is already encrypted and authenticated!) and remove TLS cert/fingerprint entirely
• Try using upper case encoding for optimized QR codes (similar to what LN invoices and bech32 addresses do)
• If IP address is used convert it to raw 4 bytes and then encode with bech32
• Shorten the schema (e.g. lnconn:)
• Exploit the fact that lengths of some fields are known, so no need to put separators around them (sha256 sum of certificate has constant size, v3 onion addresses too, I think, IP addresses...)
• Use of a helper server that can give you macaroon if you authenticate with a simpler, shorter key (128 bits is enoug)

[michaelWuensch]

@Kixunil
Thanks for your Input. We will consider it when updating lndconnect.
If we actually use a hash of the certificate I think we are already having a density that is acceptable.
From there on we are trying to find a balance between ease of implementation and efficiancy.