Optimistic WebLN Recommentations

[Kodylow]

Is your feature request related to a problem? Please describe.
We've been putting Stacker.News in Fedi for the last few months and have gathered some recommendations on improving the WebLN integration that I can mostly summarize as treating WebLN optimistically: there are a couple places where you can remove clicks for login & payments that would increase user interactions but also address some of the drop off we see with non-bitcoiners using the app for the first time in Fedi.

Optimistic WebLN reflects a couple things, since there's a 2 step check for webln.

1. window.webln is present/defined: If the user has webln present, Stacker.News should immediately try to call "window.webln.enable()". Both Alby and Fedi support this flow where when the User first lands on the site they'll see a prompt of whether to enable WebLN on the site, which sets window.webln.isEnabled to True. If the user accepts, you can use that isEnabled check for login and payments to remove a step.

2. window.webln.isEnabled === true: If the user has enabled webln, then you can optimistically use it instead of flipping to the QR code screen for login or payment. Currently it flips to that screen then the user has to click on the QR code to activate the webLN logic. like so:

after clicking:

We've seen this specific click cause drop off for many Fedi users. They click "Login" or "Pay" then don't realize they have to click the QR code.

Describe the solution you'd like
On initial splash, stacker.news should check if window.webln is defined, and if so try to enable it. Once enabled, webln should be optimistically used for Login and Zaps/Payments instead of directing to the QR screen with multiple options. The 2 places this can be best implemented are on hitting the Login button and hitting the Zap button. That shouldn't redirect at all, the user should just stay on the screen and complete the interaction via webLN popup. If that interaction fails, continue to the normal QR code screen flow for them to pick up with the other options.

On hitting login, if webLn is enabled it should immediately call login with lightning logic.

Describe alternatives you've considered
This shouldn't get in the way of normal flows, it should just use webln optimistically. If you plan to add more nostr support you can apply this same optimism to NIP-07 signers and NWC, if the user has that present on the browser then it should be used optimistically before presenting a bunch of options.

[ekzyis]

Hey, thanks for the detailed ticket!

I agree, the optimistic behavior that you described is also the behavior we'd like to see. Our code interacting with external wallets is still rough on the edges.

I also think there was some downgrade regarding WebLN when I refactored our WebLN code in #749. I dropped usage of window.webln since that's also what bitcoin-connect did (it was my "inspiration"). I guess that's why this no longer works as you described? Not sure if it ever worked that way though, I think we always showed QR codes but they were automatically paid or prompted the wallet when we were still using window.webln. No need to click on them. Now that only happens when a wallet is attached in the wallet settings:

I am currently working on wallet UX anyway so I will add this to my list.

Thanks again!

PS: As mentioned in #953, can you share more details about this:

We've been putting Stacker.News in Fedi for the last few months

this sounds pretty cool but I actually have no idea what you are talking about. 😄

[Kodylow]

can you shoot me your discord and I'll shoot you an invite so you can test it out? I'm @Kodylow on discord

[ekzyis]

Sent you a friend request on discord

[ekzyis]

Sorry, I just realized I still didn't fix this but I have not forgotten about it!

Regarding:

1. window.webln is present/defined: If the user has webln present, Stacker.News should immediately try to call "window.webln.enable()". Both Alby and Fedi support this flow where when the User first lands on the site they'll see a prompt of whether to enable WebLN on the site, which sets window.webln.isEnabled to True. If the user accepts, you can use that isEnabled check for login and payments to remove a step.

@huumn, iirc, we discussed that the Alby popup can be intrusive. I agree. For example, it's quite annoying that every time I visit primal.net, I immediately am asked to unlock my wallet. Maybe I don't want to do anything that would need my wallet and just browse around? It got so annoying that I keep my Alby extension disabled such that I can conditionally enable it myself when I need it.

I believe with the changes in #1243, we can add WebLN as a wallet. It will have no configuration fields, it will only have a checkbox and validation will basically only be typeof window.webln !== "undefined".

If this wallet was enabled, sendPayment will call webln.enable() webln.sendPayment and so forth. No need to show QR codes anymore just like with the other wallets. This would handle this:

2. window.webln.isEnabled === true: If the user has enabled webln, then you can optimistically use it instead of flipping to the QR code screen for login or payment. Currently it flips to that screen then the user has to click on the QR code to activate the webLN logic. like so:

Additionally, when we show QR codes, we can additionally conditionally render a button that would enable this wallet if window.webln is present since it requires only opt-in, no configuration.

I think this would be the best of both worlds: no intrusive unnecessary prompts while still making webln accessible (no need to manually enable it first since we can detect the presence when one might want to enable it).

To make it less confusing for non-technical users, we can also name it Alby which would be a redirect to the WebLN config page which other WebLN wallets can reuse. This is related to adding Mutiny as a wallet even though it would just reuse the NWC configuration page.