Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve the UX of pairing a device #116

Open
1 of 4 tasks
pavlenex opened this issue Nov 25, 2024 · 4 comments
Open
1 of 4 tasks

Improve the UX of pairing a device #116

pavlenex opened this issue Nov 25, 2024 · 4 comments
Assignees
Milestone

Comments

@pavlenex
Copy link
Contributor

pavlenex commented Nov 25, 2024

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 dstrukt self-assigned this Nov 25, 2024
@dstrukt
Copy link
Member

dstrukt commented Nov 25, 2024

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
Copy link
Contributor Author

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

@dstrukt
Copy link
Member

dstrukt commented Nov 26, 2024

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

@pavlenex pavlenex added this to the 0.0.1 milestone Nov 29, 2024
@pavlenex
Copy link
Contributor Author

pavlenex commented Jan 24, 2025

Current state:

Screen.Recording.2025-01-24.at.13.18.39.mov

Suggested improvements:

  • Encryption backup page /settings/encryption
    • Clearly explain what encryption key is, what it does and how to back it up, essentially it's very similar to nsec concept in nostr imo, and I think our recommended way to store this would be similar to password - a password manager. Since they key itself is to complex to be written out

Image

  • Log in (pairing), this happens when you try to log in to the same account with a different device. This is something pretty common (Discord, Signal, WhatsApp, Telegram) all these messaging apps do have a way to pair devices. On our page we should communicate it in that direction. Biggest improvement here, and a low hanging fruit would be to explain where to find the encryption key (on another device and scan a QR or enter it manually if it's been backed up already)

Image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Backlog 🪵
Development

No branches or pull requests

2 participants