You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
The text was updated successfully, but these errors were encountered:
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. 😄
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.
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.
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.
The text was updated successfully, but these errors were encountered: