Added ⚡️ content to Onboarding > Backups

[sbddesign]

⚡️ See Deploy Preview

This is for #516. I added LN content to the following pages:

• Onboarding > Backing up a recovery phrase
  • Automatic cloud backup
  • Manual Backup

I am trying to shift this from talking about backing up a "recovery phrase" to the more general term "wallet backup", which includes the recovery phrase, channel state, and other details. If we're good with this, then I will push another commit to this PR which updates many page permalinks.

[Bosch-0]

As mentioned on the Google doc, I think we should be pushing for the use of descriptors for backing up of derivation paths / fingerprints / xpubs.

See me and Stephen's discussion here: https://docs.google.com/document/d/1y19VskiZcm6AXO1fVECr2ze_xTehyz4GtGs4zzheKLU/edit?disco=AAAARAZp3lk

[sbddesign]

What do some other people think?

On the one hand, I don't have anything against output descriptors. They seem like a very useful way of formatting data for many different types of outputs. It makes sense for there to be a common format many wallets understand.

On the other hand, I don't know that I want to get deep into engineering recommendations. With this section, we're proposing that developers and product designers think critically about their backup process -- that they should build it so that the user doesn't have to manually back stuff up. If the engineers want to encode their backup data inside of a JSON object, an output descriptor, or some other format, it could all result in the same good UX.

Perhaps I'm overthinking this one?

[sbddesign]

Ok, I listened to Andrew Chow and Thunderbiscuit talk about output descriptors in Atlanta this past week. I've been descriptor-pilled. However, my stance is that we should only recommend descriptors with public key information be included in printable templates and never descriptors with private key information. IMHO, printers are a huge attack surface and a private key should never pass through one.

@Bosch-0 See the "Printable Template" recommendation box for a mention of descriptors, as well as the link to the printable template which includes a QR code descriptor. This is the only context under which I can currently imagine a user being directly exposed to a descriptor.

[Bosch-0]

Yep that suggestion looks great and love the template :)! Glad you got descriptor-pilled 😆 Chow and Thunder would of explained it a lot more eloquent that me. Yep any private key info should never touch a printer / go over the air in any way shape or form

[GBKS]

As you discussed in the Google Doc comments, descriptors are messy for users to write down, and if you want to avoid printers, then the QR code approach is also not useful (IMHO, the template should likely not contain any pre-filled information at all) .

I have a larger question here. Do we consider the focus of this page (and the Onboarding section in general) to be Lightning-first? If so, does the "piece of paper" backup method even have a place, since it can never be used for channel backups? If not, should we move that to a different section (an on-chain wallet case study)? Or is there a good reason to keep paper backups even if users still need to do a file-based backup for channels (ending up with two backup methods to keep track of)?

[sbddesign]

@GBKS

if you want to avoid printers, then the QR code approach is also not useful

To clarify, I am proposing using a descriptor QR which contains things like the derivation path, xPub, and fingerprint, but not a private key. Therefore, that could pass safely through a printer. Such a QR code would not replace the recovery phrase. The purpose would be so that the user does not need to do things like select their derivation path and verify the fingerprint.

I have a larger question here. Do we consider the focus of this page (and the Onboarding section in general) to be Lightning-first? If so, does the "piece of paper" backup method even have a place, since it can never be used for channel backups?

That's a good question. For a mobile LN wallet, I'm always in favor of the cloud backup approach, so I think that should be considered the primary method of backup.

Or is there a good reason to keep paper backups even if users still need to do a file-based backup for channels (ending up with two backup methods to keep track of)?

The only reason I can imagine why the paper wallet (or any form of manual backup) would be useful is if the user somehow loses access to their cloud backup. They could use the recovery phrase to restore on-chain funds, and if also reclaim their lightning funds after channels are force closed.

I acknowledge that's not an ideal user flow; I'm just saying it's possible. Is that a salient enough use-case to keep it here?

[GBKS]

Works for me. We just need to be clear about it.

[Bosch-0]

Awesome work @sbddesign! Left a few comments but nothing major :)

[pavlenex]

Just a few nits. This is great work so far, I do like the additions. @danielnordh this may be a PR that requires your attention, as it may shape how we think about PKM in the PKM section.

[GBKS]

Forgot to mention one thing that could be a future addition. I think the term "Fingerprint" is misleading. Everyone will automatically think of their IRL fingerprint (especially when seeing the icon) and wonder what that's about. We should clarify this and ideally come up with a better term (and icon).

[GBKS]

Also, need to add the redirect info, as the page and URL were changed (from guide/onboarding/backing-up-a-recovery-phrase.md to guide/onboarding/backing-up-a-wallet.md).

[GBKS]

And we should change the page description to get away from the recovery phrase focus. It currently reads Handling recovery phrases during onboarding.