The addition of Monero as a supported coin results in a problem with QR codes in the OpenBazaar desktop client because Monero addresses are considerably longer than the addresses of the coins supported so far: Normal Monero addresses are 95 characters long, and so-called integrated addresses even 106 characters. Example of a Monero address:
There are 2 places in the OpenBazaar desktop client where QR codes are generated and displayed. (A 3rd one for donations does not matter for the issue at hand.)
The first place is the ReceiveMoney view as part of the wallet. The code line in question:
type specifies the overal size of the whole QR code, size is the size of the dots, and Q is the ECC level, where Q gives a redundancy of about 25%, meaning 25% of the dots could come in wrong when scanning the code and the content would still read correctly.
The qrCodeText method prepends the name of the coin to the address. In the case of BTC the QR code thus encodes something like this:
The type and the level parameters together decide how many characters those QR codes can encode. You can consult the tables on this page. Look for the Version List 1-10 button, and use the Binary column in the table, not the Alphanumeric column, because with characters like : and ? we go beyond mere letters and digits.
So how many characters do we need for Monero? If we want to play it safe, i.e. allow for the longer integrated addresses, allow for large amounts of XMR, and throw in 5 extra characters for spare, e.g. for being able to go from monero: to monero:// as some wallets may prefer without going over the question of QR codes all over again, we arrive at 118 characters for a receiving QR code and 144 for a purchase payment QR code.
If we stick with ECC level Q we need to up from type 6 to 9 for receiving and from 8 to 10 for purchase payment.
If we lower the ECC level from Q to M (about 15% redundancy instead of 25%) we only need to go up from 6 to 7 for receiving, and we can even stay with 8 for purchase payment.
I think lowering the ECC level is perfectly ok for our use case, mostly reading QR codes with smartphone cameras off PC screens, where everything is neat and sharp. See also the comment about those levels from here:
L is selected for dirt-free environments, M is most common, and Q & H should be used in factory environments where the QR Code label is subject to wear and tear.
If we stick with level Q some optical changes are needed in the views to accommodate the considerably larger QR codes, or the size of the dots needs a reduction from 5 to 4.
Personally, I propose to lower the ECC level to M and just make the receiving QR code a little bigger (type 7 instead of 6).
The addition of Monero as a supported coin results in a problem with QR codes in the OpenBazaar desktop client because Monero addresses are considerably longer than the addresses of the coins supported so far: Normal Monero addresses are 95 characters long, and so-called integrated addresses even 106 characters. Example of a Monero address:
There are 2 places in the OpenBazaar desktop client where QR codes are generated and displayed. (A 3rd one for donations does not matter for the issue at hand.)
The first place is the
ReceiveMoneyview as part of the wallet. The code line in question:typespecifies the overal size of the whole QR code,sizeis the size of the dots, andQis the ECC level, whereQgives a redundancy of about 25%, meaning 25% of the dots could come in wrong when scanning the code and the content would still read correctly.The
qrCodeTextmethod prepends the name of the coin to the address. In the case of BTC the QR code thus encodes something like this:The second place is the
Paymentview for purchases. The code line in question:Here an
amountparameter is added. An example for an encoded text:The
typeand thelevelparameters together decide how many characters those QR codes can encode. You can consult the tables on this page. Look for the Version List 1-10 button, and use the Binary column in the table, not the Alphanumeric column, because with characters like:and?we go beyond mere letters and digits.So how many characters do we need for Monero? If we want to play it safe, i.e. allow for the longer integrated addresses, allow for large amounts of XMR, and throw in 5 extra characters for spare, e.g. for being able to go from
monero:tomonero://as some wallets may prefer without going over the question of QR codes all over again, we arrive at 118 characters for a receiving QR code and 144 for a purchase payment QR code.If we stick with ECC level
Qwe need to up from type 6 to 9 for receiving and from 8 to 10 for purchase payment.If we lower the ECC level from
QtoM(about 15% redundancy instead of 25%) we only need to go up from 6 to 7 for receiving, and we can even stay with 8 for purchase payment.I think lowering the ECC level is perfectly ok for our use case, mostly reading QR codes with smartphone cameras off PC screens, where everything is neat and sharp. See also the comment about those levels from here:
L is selected for dirt-free environments, M is most common, and Q & H should be used in factory environments where the QR Code label is subject to wear and tear.
If we stick with level
Qsome optical changes are needed in the views to accommodate the considerably larger QR codes, or the size of the dots needs a reduction from 5 to 4.Personally, I propose to lower the ECC level to
Mand just make the receiving QR code a little bigger (type 7 instead of 6).