Improve the UX of pairing a device

[pavlenex]

The current process for pairing new devices to the BTCPay App using encryption keys is pretty solid, but could benefit from very minor improved UX for clarity. I am opening this issue in favor of #80 so we could discuss straightforward UX improvements we could make

Below is an explanation of the current workflow and suggestions for enhancements.

Device Hierarchy:

TLDR: Pairing a different device to an existing device allows you to get access to all data without having to run a lightning node. Imagine scenario where a single company deploys several POS, where a primary one always runs a node.

A "Master/Slave" architecture is used:

• Primary Device: Runs the Lightning node, handles backup states, and is responsible for generating and tracking wallets.
• Secondary Devices: Connect to the primary device, download backup states, and facilitate data access without running a full Lightning node.
• End to end encryption ensures BTCPay server the app is connecting to has no access to the data

Workflow

Best way to understand this is to try it out yourself. Instead of running Dev All profile, run Dev All With Second app.

1. Deploy BTCPay app with Dev All With Second app profile
2. You will get 1 BTCPay Server and 2 Apps
3. Register and invite user to BTCPay Server
4. From one App log in the user (this becomes master/primary)
5. Open the second app and try to log in the same user as you did in step 3.
6. You will notice a screen where you need

Encryption Key Usage:

Encryption is derived from the wallet seed mnemonic, so there is no need for separate backups of the encryption key itself. Backing up the wallet seed ensures access to the encryption key. However we still don't have the UX for backups.

Security Considerations:

• End-to-end encryption ensures backup data (wallet, UTXOs, Lightning state) is secure.
• If the encryption key QR code is scanned, access is still gated by authentication with the BTCPay instance to prevent unauthorized access to funds.

Limitations:

• No key rotation mechanism is currently implemented, as the perceived benefits of key rotation for this use case are minimal, and we'll not be prioritizing this as agreed with @Kukks

Desired Workflow

1. User logs in with a device that's already master, we provide a screen saying hey, pair a device! To pair a device, go to XYZ of your primary device and scan a QR or enter it manually.
2. In the Settings, instead of Security > Encryption key we should showcase Pair a device UX that Signal has and avoid too much buzzwords because at the end of the day this QR is used just to pair a secondary device and shouldn't be confused with a private mnemonic key, even though if user backed up mnemonic they can just enter it to regain access to the device.

Concrete UX Enhancements

• Consider Master and slave naming to Primary and Secondary for clarity
• Research Signal/Telegram UX for pairing a device
• Rename the concept of encryption key to device pairing
• When user tries to log in in another device, we should communicate where they can actually find a pairing key on the master device

Screen.Recording.2024-11-25.at.11.51.42.mov

[dstrukt]

ACK to the above, i think we had already discussed renaming Encryption Key -> Pairing Device, but it was nACK'd in the past, can't recall why, but think it's much more clear.

[pavlenex]

I am unsure of it being nacked, @Kukks himself proposed this UX here #80

[dstrukt]

Oh perhaps I misremembered - awesome, glad we all agree!