redesign of attached wallet page

[huumn]

It's unclear how exactly to improve it, but some of the feedback I've received is people expecting to see logos for specific wallets rather than the protocol name.

[riccardobl]

What if we keep the current page the same for manual/advanced setup, and we add an additional wizard page where the user can chose specific wallets by name/logo and then run a guided setup that ultimately ends up setting one or more attached wallet?

If we make a setup specific to the wallet providers we can, for example, use their apis to grab ln-addresses when we can't generate a scoped receiver nwc tokens or at least tell the user exactly what we need and link to relevant documentation.

[huumn]

I like the idea of wizard skip/"bypass" to just see a wall of wallets. Good idea.

[ekzyis]

What if we keep the current page the same for manual/advanced setup, and we add an additional wizard page where the user can chose specific wallets by name/logo and then run a guided setup that ultimately ends up setting one or more attached wallet?

If we make a setup specific to the wallet providers we can, for example, use their apis to grab ln-addresses when we can't generate a scoped receiver nwc tokens or at least tell the user exactly what we need and link to relevant documentation.

I had the following in mind which I think is similar but differs in detail. The major difference is wallets vs protocols:

1. We only show wallets (currently: LNbits, Blink, LND, CLN, phoenixd), no protocols (currently: NWC, LNURL, WebLN¹) when you visit /settings/wallets

Stackers want to attach wallets, not protocols. They aren't necessarily aware what protocols their wallets support. It has happened multiple times that stackers thought their wallet is not supported because it wasn't shown even though their wallet supports lightning addresses.

This means we need to show as many wallets as possible so stackers can find their wallet. We can probably limit ourselves to the most popular ones first and add any other wallet on request.

I think that we mixed wallets with protocols is becoming a problem. It was a good idea to start with protocols to cover as many wallets as possible at once but we then added "wallets" that are actually wallets. We now need to consider the difference between wallets and protocols in our UI and code.

2. If you click on a wallet, a wallet wizard will start

Wallet wizards include specific guides. A wallet wizard only configures this wallet, not any other "wallet". So if a wallet supports NWC and lightning addresses, this will configure NWC and lightning address only for this wallet.

The reason for this is that it would again be confusing if you configure Blink but then another "wallet" is also suddenly configured if you entered your Blink lightning address and finish the wizard. Additionally, another (real) wallet could also add a lightning address. Should we then show two separate "lightning address wallets"? I don't think so.

That's also another reason why we shouldn't show protocols as wallets since multiple wallets can implement the same protocol. At that point, it becomes clear that protocols aren't wallets and not distinguishing between them in the UI and code becomes messy.

3. If a user cannot find a wallet they have, they will be shown available protocols and can suggest us to add their wallet to the first page

Here we can show protocols again. These protocols can be configured multiple times and will each create a new wallet. So instead of actually configuring a protocol, it's more like you create a new wallet for that protocol first and then configure that custom/unknown wallet. I think that's how we meant to use protocols as wallets.

They can then name this wallet and also suggest to us to add it to the first page.

---

On a side note, I started to mess with the wallet page a bit. I noticed the badges are in the way of logos and they don't make it easy to get an overview of send vs recv wallets anyway. This is why I created #1506 but I realized that we could show icons instead of badges for send+recv. These icons can then also be used instead of the status indicator to show separate status for send vs recv.

Here's my first draft for wallets with logos:

Unfortunately, the phoenixd SVG does not contain the name. The name is rendered as text on their page. Need to add the name manually in some way.

Footnotes

1. I am not sure if LNC is a protocol or a wallet. Afaik, it can only be used with LND so maybe it should be part of LND's configuration for sending anyway? ↩

[riccardobl]

I agree with all your points, and I've been thinking further about how to design and implement the wizard system only from a UX and Dev perspective.

I find the current wallet attachment modular system quite effective, so I’ve been thinking how we could adopt a similar approach for wizards. The idea would be to allow stackers to express their guides into wizards, with minimal programming knowledge, while keeping the system flexible. Here’s what I’ve come up with so far:

The modules would be exactly like wallet attachments, with some key differences:

1, authors: same as with zaps for guides, we could reward creators with sats if their wallet wizard is used.
2. markdown field type: to support long-form text, images, etc.. To present detailed instructions and point users precisely to where to find the values.
3. multi-step flow: instead of a single fields field, to not overwhelm the user with too much info all at once, we break the flow into multiple steps, each step with its fields.
4. async functions for fields arrays: instead of a static array, we use an async function that returns an array of fields. So we can run code between steps to simplify some processes for the user when possible (e.g., using provider APIs to fetch data as needed). Each step would have access to values from previous steps, to transform data as needed.
5. final step for attachments and status: the last step would handle attachments and output the final status.

Using this "fantasy" wizard system, I’ve converted this Coinos guide as an example:

(The final step is in pseudo-code, but should be able to use the current wallet attachment system)

export const name = 'coinos'
export const authors = ['supratic']
export const icon = 'https://coinos.io/icons/logo.svg'
export const description = '[Coinos](https://coinos.io/) wallet'

export const steps = {
  SignUp: async (steps, wallets) => [
    {
      name: 'Sign Up',
      type: 'markdown',
      value: `
            Create a Coinos account on https://Coinos.io/register, fyi... it's KYC free, 
            so no question asked on signup apart username and password. 
            You can have it fully anonymous, clicking on the 🎲 and it will generate a random username for you. 
            Make sure your password is secure.
        `
    }
  ],
  NWC: async (steps, wallets) => [
    {
      name: 'Get NWC',
      type: 'markdown',
      value: `
            Once you have your [email protected] account...
            ![image](https://imgprxy.stacker.news/R1tVUU8XIXA5s0rqoL6d3x4syJDnq4r_BXgdqvDGfyM/rs:fit:1920:1080/aHR0cHM6Ly9tLnN0YWNrZXIubmV3cy81MzMxMQ)
            ... expand the details.
            ![image](https://imgprxy.stacker.news/G9oqobqhSGEt37-sq7LStJqtJ880QSEYCEX8aD-sdig/rs:fit:1920:1080/aHR0cHM6Ly9tLnN0YWNrZXIubmV3cy81MzMxMw)
            Then copy the Nostr Wallet Connect url and paste it below
        `
    },
    {
      name: 'nwcAddr',
      label: 'Input the NWC url',
      type: 'text',
      placeholder: 'nostr+walletconnect://...',
      autoComplete: 'off'
    }
  ],
  lnAddress: async (steps, wallets) => [
    {
      name: 'Get LN Address',
      type: 'markdown',
      value: `
            Once you have your [email protected] account...
            ![image](https://imgprxy.stacker.news/R1tVUU8XIXA5s0rqoL6d3x4syJDnq4r_BXgdqvDGfyM/rs:fit:1920:1080/aHR0cHM6Ly9tLnN0YWNrZXIubmV3cy81MzMxMQ)
            ... expand the details.
            ![image](hhttps://imgprxy.stacker.news/jnrYBUi4dmYkO4SpDuJcc6Ww9D7GfIHTN_o8nuKvCn0/rs:fit:1600:900/aHR0cHM6Ly9tLnN0YWNrZXIubmV3cy81MzMxMg)
            Then copy that lightning address and paste it below.
        `
    },
    {
      name: 'lnAddr',
      label: 'Input the Lightning Address',
      type: 'text',
      placeholder: '[email protected]',
      autoComplete: 'off'
    }
  ],
  Connecting: async (steps, wallets) => {
    try {
      await wallets.connect(
        'nwc', // connector
        { // fields
          nwcUrl: steps.NWC.nwcAddr.value
        },
        'coinos' // label/provider name
      )
      await wallets.connect(
        'lightning-address', // connector
        { // fields
          address: steps.lnAddress.lnAddr.value
        },
        'coinos' // label/provider name
      )
      return {
        name: 'Connected!',
        type: 'markdown',
        value: `
            You have successfully connected your Coinos wallet!
        `
      }
    } catch (e) {
      return {
        name: 'Error',
        type: 'markdown',
        value: `
            There was an error connecting your Coinos wallet. Please try again.
            
            Error: ${e.message}
          `
      }
    }
  }
}

[riccardobl]

I am not sure if LNC is a protocol or a wallet. Afaik, it can only be used with LND so maybe it should be part of LND's configuration for sending anyway? ↩

I think there is some grey area in this distinction.

LNC is a protocol imo, but if there was an LNCHub.io provider that gives out LNC tokens, in that case LNCHub.io would be considered as wallet and would have its wizard with a guide to tell the user how to signup and get the relevant LNC tokens or we could also have also a Generic LNC wallet that just tells the user which commands it needs to run.

Another case is Blink, it is a wallet, but also a proprietary protocol, since it has its own graphql apis, so we should implement it both as an attachment and as a wizard.

Imo we should keep the attachment nomenclature for everything that needs to have a specific protocol code, being it proprietary (blink) or a public standard (LNC, NWC). And then add wallet providers with their own wizards.

This distinction would look like this

provider	attachment
Coinos	NWC, lnaddress
Blink	Blink
Stripe	Stripe, lnaddress(?)
AlbyHub	NWC
Voltage	CLN, LND, LNC

and so on.

If a provider supports more than one attachment for the same thing (eg. voltage), we can have a step in the wizard with a <select> field, to let the user pick one.

Imo the wallet/provider besides the setup should be just a relation in the database, eg. 'this attachment id' and 'this attachment id' are a "wallet" for the provider 'coinos'