Remote connection to LianaLite's backend (Liana Connect): wallet creation flow

[darosior]

We've been cooking a new service, a dumbed-down version of Liana as a web application which we named "Liana Lite". This web application which does all the Bitcoin-related logic, from the updating of the wallet state from the network to the crafting and listing of transactions. Essentially if Liana Lite is the equivalent of the liana-gui here for the web app, the backend is the equivalent of a remote lianad.

An alternative to implementing additional backends for lianad (#56) could be for the GUI to connect to this backend instead of running a lianad. At the obvious cost of privacy this gives the user:

1. A much simplified experience (no need to manage a bitcoind anymore, no IBD, ..);
2. A unified experience for users of multi-parties wallets (typically a company using a multisig would have the PSBTs they create and the labels they set always sync'ed with each other);
3. Private wallet information only accessible behind auth (similarly to encrypting the wallet using a password);
4. Access to future services we could offer through this account on our platform (typically, a timelocked recovery managed by a partner).

Flow

This does not change anything for existing wallets. For now, an already created wallet cannot be changed to be remote (and vice-versa).

When creating a new wallet on a fresh Liana install a new first screen is introduced. It lets the user either log in, sign up or create a local wallet. If the local wallet option is chosen we proceed as we do today. If they log into an account, the same installer flow as today is presented but they can only create a mainnet or signet wallet and the bitcoind configuration steps are removed.

If the user logs in to an account, the GUI does not even start a lianad at all. It just connects to the remote backend.

When creating a new wallet on an existing Liana install (for instance they already had a Bitcoin wallet and now they create a Signet, or they just delete their Bitcoin wallet to re-create it), when clicking on "install Liana on a new network", if the user is not already logged in, have a new screen to let them log in before proceeding with the installer. Then it's the same as above.

For now, if a user is connected we always use the remote backend. Evenually we could let connected users create local wallets.

When opening up an existing wallet, if selecting a network which was set up with a remote backend and the user is not already logged in, the user needs to log in. This can typically be as a modal instead of a whole new screen.

Authentication

That's the annoying part. First of all we don't want passwords. It can seem nice at first as not requiring too many moving parts, but in practice any secure use of password would already require a separate software. There is a few possibilities offered by our auth service provider (unfortunately WebAuthn with Ledger's FIDO2 app isn't one of them). For the web application we use a magic link sent by email. As the magic link is tied to the session which required it, it's not a viable option for a desktop app.

I believe the least bad alternative here is to use an OTP sent by email. To sign up the user fills his email address and needs to confirm it. When logging in he fills his email address, receive an OTP pin by email which he needs to copy paste on his Liana GUI (or let's say read from his mobile phone and type in the GUI).

The authentication token would be available for some time and i expect it'd be stored by the GUI. Let's say it's valid for a day. An annoying think is the GUI will have to handle re-connections for when the auth token expires.

Design

For the new login screen introduced in the installer i think we should have a horizontal separation (let's say with a bar) with on the one side a text input for the user to enter his email and log in as well as a "sign up" button. And on the other side a "Create a local wallet (no account required)".

For the rest i'm not sure.

[darosior]

Edouard points out a couple endpoints need to be added or adapted on the API to be at feature parity with lianad.

[nondiremanuel]

To keep track of the update on this topic, we had an internal discussion in which the functional flow was re-discussed. In the following schema a summary of what was the result of the brainstorming:

Some points that don't emerge from the schema but that are important to mention for the creation process:

• For the "create a new wallet" flow, the descriptor backup step will be after the choice of network - but before the start of bitcoind and IBD in case of liana managed node.
• In the same screen (or else?), for the Liana Connect choice, in small (maybe like the "share xpub" thing in the landing page) we should have a "share wallet"/"invite other participants"/whatever. This is to give the possibility to invite other partecipants
• If an email is already used, we should propose to use a different email, as the user wants to connect with the newly created wallet.

As we discussed last week, I created #1176 specific for the "Add/Join existing wallet" flow, while we will keep this for the modification of the creation part (while there is a separate one on the backend repo for the BE).
@edouardparis let me know if this is okay or if you prefer other way, thanks.

[nondiremanuel]

As part of the discussion we are having in #1223, we should probably talk about UX/UI also for the step in which the user chooses between Liana Connect and using his own backend (core or electrum).

If I understood correctly, the current implementation is something like:

Trying to put myself in the shoes of an average user, I see some criticality with this:

• "Choose Backend" (title): what does this mean? Backend is not a word that I suppose is commonly used by non-technical people. This could lead to confusion and make them drop the onboarding process
• It's not clear at first sight what is the difference between the two options: one has "Liana" logo, the other "Liana Connect" which doesn't tell much. To know what I need to choose I need to go through two non-trivial walls of text and I could still be confused about the implications of each choice.
• There is no default option: I think it's good practice to guide the user towards the most common / easy / whatever-criteria-we-want-to-use option when needing to select a non-trivial choice. I believe that in this case, the default should be Liana Connect, the most accessible for someone that is not able to technically evaluate the implications of the two.

My personal proposal to overcome such frictions, would be to have something like the following very high-level mockup:

In something like this, we would have:

• Liana Connect by default. The choice of using their own backend would become less visible and so less likely. To go to the next step of having your own backend, in fact, you would need to click on a secondary option (which could also be a secondary button or something else). This is of course relevant strategically, so I would defer to @kloaec and @darosior on how much we want to push for Liana Connect. I believe it makes the UX smoother while allowing advanced users to keep the possibility of configuring their own solution, but I also understand the possible counter-arguments.
• Short explanation of the implications of Liana Connect, without mentioning that they need to choose a "backend". The wording is of course a draft and could be better. I believe we should have some way a user can understand deeply the implications in terms of privacy elsewhere, so I would add a "i" or something with ideally a link to the website that explains the tradeoffs (maybe the v7 blogpost initially?)

This would be valid for the same step in the addition of an existing wallet (#1176)

What do you think?

[nondiremanuel]

After the discussion we had offline, at this step we should have two options:

• One to connect to the user's own backend ("node" for the user). The choice between local bitcoind, managed bitcoind or electrum will be done in the following step and it's part of the other previous mentioned PR.
• One to connect to our remote "node"

I imagine the content of the page to be something similar to the following screen taken from the new design:

@edouardparis what do you think? Any other info required?

[edouardparis]

To be clear, the login form will be after that the user clicks on Select in a new step ?

[nondiremanuel]

Yes, in the design example it would. Do you think it's better to keep it at the previous step?

[edouardparis]

Both are fine for me, I just wanted to make it clear.