Optional swap service experience standardization

[saubyk]

1. Service nomenclature on the dashboard should be Swap Out or Loop Out depending on the service activated in the config. If both services are activated, the name on the dashboard can be generic and nomenclature can follow the brand, after user selects the service to execute the swap with.
2. Service selection on run time. RTL should not be selecting any service by default and that selection should be entirely user driven.
3. On the navigation, RTL will have a service menu at the same level as Lightning, to house swap services. The menu can be labeled as Service Add-ins. This menu should be enabled only when the user opts into activating any or every service option available.
4. Loop and Boltz will be placed as separate menu items under Service Add-ins, allowing service specific brand placements like infographic and service nomenclature on their respective pages.

[armurbalda]

Hi (I'm with the Boltz team),

1. ACK
2. ACK

3. On the navigation, RTL will have a service menu at the same level as Lightning, to house swap services. The menu can be labeled as Service Add-ins.

ACK

This menu should be enabled only when the user opts into activating any or every service option available.

That's where I have doubts/concerns. Where would that opt-in take place if not in the Service Add-ins menu itself? You previously mentioned via conf file, which I personally consider bad UX also via a yet separate Service Add-ins activation menu somewhere else (like in Settings is similarly bad UX. First and foremost bad for "discoverability" of the available services. Why not simply list all available services in the Service Add-ins menu and have it always there, either as Service Add-ins > Service Overview with a toggle to activate the service (default all off) OR better directly as e.g. Service Add-ins > Boltz / Service Add-ins > Loop which has the activation subpage with infographics, service description, fees etc all there. I believe most users would want to learn something about the service before activating it, that's the page they could do this and also activate the service.

4. Loop and Boltz will be placed as separate menu items under Service Add-ins, allowing service specific brand placements like infographic and service nomenclature on their respective pages.

ACK, just that your sceens show Boltz & Loop together in the Channel Withdrawal/Deposit pages. Could you clarify what kind of content you would envision to be placed in e.g. Service Add-ins > Boltz and where to place the actual Channel Withdrawal/Deposit menu once one or more services were activated?

Ty, we are thrilled working on this!

[peartobear]

Hi, (I'm from Boltz team as well)

Adding on to what @armurbalda described, I have taken the liberty to mock up a quick wireframe for, what in our humble opinion, would be the most optimal UX for RTL + Boltz flow. This also builds adequate primitives for RTL's potential future roadmap. Let us know what you make of it. We are looking forward to discuss this more on our Saturday call. Below I attempt to reason through the UX decisions I took in the mockup.

This menu should be enabled only when the user opts into activating any or every service option available.

Self custodial lightning tools are riddled with user experience friction. Solving it is another vector of value alignment between us two projects. Activating menu via config requires a notch higher familiarity with command line toolings and raises the bar to entry, so to speak. Hence the concerns from @armurbalda. We propose for RTL to have a separate "Swap Add-in" tab akin to a marketplace, as depicted:

This solves two issues:

• Your concerns regarding Boltz as an opt-in service instead of opt-out. By Installing Boltz Swaps, the user would be explicitly granting the consent.
• Future integrations with other LSPs will be a lot easier and it would fit in this UI construct of "Installing service add-ins", without additional user onboarding. Also, as for the Lightning Loop, when the user clicks on "install" - it will throw a popup detailing the configuration steps, which can then quickly be switched to Boltz like one-click install once they refactor Loop to REST architecture (to the best of our knowledge, they are planning to do so)

• Above is the detailed expanded flow of the card view - which follows the Material UI guidelines RTL is currently using. Following your suggestion, The "Swap Add-in" menu is not yet enabled and doesn't have (⬇️ ) expansion since none of the services are installed yet.

4. Loop and Boltz will be placed as separate menu items under Service Add-ins, allowing service-specific brand placements like infographic and service nomenclature on their respective pages.

• Now since Boltz add-in is installed here, the "Swap Add-in" menu is enabled. It houses "Swap Service" and potentially other categorized tabs in the future. This categorization allows for grouping tabs and avoids the clutter of having too many options like "Boltz" and "Loop" individually in the sidebar. Both Boltz and loop essentially serve the same purpose, albeit with a little different approach. Our UI bundling of "Depositing and Withdrawing" confirms to the widely accepted terminology that users are already familiar with. This generic bundling approach makes more sense to us as it reduces the cognitive overload, and we would love for you to give it an another thought.

That's just the gist of our thinking process behind the proposal. As a final thought: Having a smooth UX is the USP of Boltz. The fact that users can get up and running with LN channels as soon as they install RTL could be truly magical. And we hope to get this shipped together asap!

[Kixunil]

I disagree with turning RTL into software manager and everything else but kitchen sink. There are plenty of software managers already, it's their job to provide the appropriate user experience.

There are at least three bitcoin projects I know of that provide higher-level user experience:

• btcpayserver-docker
• Cryptoanachy Debian Repository (My project)
• nix-bitcoin

As a maintainer of one of them, I'll be happy to receive suggestions for UX improvements and PRs. I plan to create a UI similar to what you suggested for installing packages and node management. It will be separate from RTL or any other Bitcoin project in order to keep it clean. RTL is already packaged there as well as other things. (Although it broke for some weird reason, I'm going to fix it soon.)

Ultimately, installing RTL manually already requires editing configs etc, which is fine because users are not supposed to do it manually. :)