Metamask air-gaped wallet discussion

[soralit]

For the discussion about air gaped wallet gradually moves out of scope of original PR: MetaMask/metamask-extension#6267, we can talk about it in this discussion.

[AndreasGassmann]

Thanks for opening this discussion.

In the original issue, I opened the question of which QR format should be used for communication between MetaMask and offline Signers. The 2 contestants are bc-ur and UOS. I will quote my reply here to get the discussion started:

Is there a comparison between both bc-ur and UOS? Regarding performance, features and available tooling?

At AirGap we have been using our own custom multi-qr implementation for a couple of years now. It is similar to UOS in that it allows you to split the data up into multiple parts if necessary, and have the other party combine the parts to get the full payload.

However, there is a big problem with this. If one QR is missed, the user has to wait for a "full roundtrip" again until the missed QR is shown again. This is a problem for larger payloads. We have a use-case where we do a batch transaction with our apps that results in about 200 QR codes. Scanning those consistently can be very tricky, depending on the device. With iPhones the success rate is basically 100%, but especially older Android phones often drop QRs, making it a cumbersome process. The bc-ur standard (we were not involved in designing that standard) addresses this by randomising the parts that are contained in the QRs after the initial set.

In AirGap, we will most likely add support for bc-ur because of bitcoin and UOS because of polkadot. So we will support either standard and it doesn't really matter which route MetaMask / Ethereum is going. However, I do feel like bc-ur does have some clear advantages.

I could even see a combination of the two. We could use bc-ur as the encoding format for QR codes, but the underlying structure of the data could still be as defined in UOS. Only the multipart section would have to be removed and the payload could be passed into bc-ur, which handles the fragmentation of the data into QR codes.

[soralit]

In my opinion, bc-ur provides a more generic way to encode any data into fragments, while UOS is more specific to ethereum/substrate.

BC-UR takes some advantages:

1. We can define our business-based ur types
2. UR2.0 supports fountain code which can fix QR missing problem.
3. It has a lot of tools we can directly use.

Also we can get some benefits from UOS that how we struct an ethereum payload.

[aaronisme]

@AndreasGassmann any ideas from your side ?

[soralit]

Besides, in QR point of view, BC-UR is designed to use alphanumeric mode([A-Z][0-9][ $%*+-./:]) of QR Code while UOS is using binary mode(ISO 8859-1 charset).
One single QR can contains at most 4296 characters in alphanumeric mode or 2953 characters in binary mode.

[AndreasGassmann]

Sorry for the late reply.

1. We can define our business-based ur types
2. UR2.0 supports fountain code which can fix QR missing problem.
3. It has a lot of tools we can directly use.

Completely agree with all points here.

Besides, in QR point of view, BC-UR is designed to use alphanumeric mode([A-Z][0-9][ $%*+-./:]) of QR Code while UOS is using binary mode(ISO 8859-1 charset).
One single QR can contains at most 4296 characters in alphanumeric mode or 2953 characters in binary mode.

I remember reading in some bc-ur discussion that the alphanumeric encoding was chosen because some (popular) QR scanners don't support or work well with binary mode. As I know the BlockchainCommons team, they probably did some thorough research, so I'm inclined to just go their way.

What's your preference here?

---

Is there anything that speaks against combining the two?

1. Use the structure of UOS (without splitting) to create the binary
2. Define a ur type called uos or similar, which takes the raw UOS binary as an input
3. The result is a standard bc-ur output (with better QR splitting)

This would be flexible because it would be compatible with potential extensions/changes to the current UOS format, but takes advantage of the better QR format.

[aaronisme]

I think we can combine UOS and UR together, defined an UOS like-wise UR type