Oddbean new post about login | logout not working either. I apologize for being pedantic and repetitive here.. But using modals and/or popups is the always way for hell and makes it for worst UX, harder integration and less consistent app design.
I agree, but what else do you suggest?
My fav UX flow is: 1) myapp.com show a "login with nsec" button 2) click redirects the whole page to https://use.nsec.app/auth (or some other handle in place of "auth" 3) there it shows all my identities, I pick one and that makes a callback to myapp.com/callback?event=.... No modals, no popups and no mandatory custom login button with style that does not match the one on myapp.com. It is s nice to provide a convenient styled button.. but not for all situations. That's also easier than having to remember "username@nsec.app", or whatever identity I am using this week, or whatever provider I am using this week: is it "nsec.com? .app? .gov? .nostr?" I think that should also be easier to implement for both you - auth service provider or javascript plugin provider, and me using them.
What if your provider is not on nsec.app, but nostr.me or lume.nu? What if you want to log in with your extension? What if you have your self-hosted bunker running on your machine? I don't think the styled button is for all situations, it's mostly for small apps that don't care very much about having a super nice onboard flow.
Sure, but here we are talking about 2 things here 1. the nsec.app flow (or any other provider) which IMO should provide a leaner option - specifically with no modals and no popups. 2. the styled button to "bind them all" has a different purpose and yes, provide great utility as a drop-in solution. So yes, my "objections" is mostly to the modals/popups in nsec.app flow. I still owe @brugeman a proper github issue about that. In respect of the window.nostr.js button UX I would argue that in the Standard Oauth user click on the familiar Google icon, does not have to type in your email address. But yes, how would the Login button know which provider to call without the address? Then maybe an option to just "pick a provider" and show a list would be nice, I guess.
I don't think we should have 'login with nsec.app' buttons or any other provider-specific naming/branding deployed by apps. People are kind of used to remembering and entering their email to sign in to apps, so entering nip05 should not be a huge friction, it's very familiar. The @domain part can be auto-completed based on a published list of providers to simplify things. Popups can be avoided - you can redirect users to auth_url instead of showing a popup. The question of callback_url remains, there is no standard for it out there, if you're ready to advocate for it you can join the new-nip46 discussion on github. Btw I will also try showing auth_url in an iframe, not popup - should provide more control over how it looks and behaves. You feedback was noted and I have issues for it on our github.
thanks @brugeman I will check the nip46 discussion. I am curious to see what is the "question" around the callback_url. If oauth flows work perfectly with no popups/iframe/modals, I am positive we can build that way as well. And I do not advocate for removal of the input field, I say that as we have 1/2 providers now, having a click-click solution that just work is a good idea, rather than forcing user to insert the "email" all the time. And @fiatjaf yes there has been a time that we had 40 oauth providers and a couple "bind-them-all" buttons... And almost all were doing the popup thing. It was even cool. The early Web2.0 era. But what about oauth now? Most website offer 2/3 oauth + email field, and all oauth-flow are pure redirects. Because offers consistent navigation (impossible with popups), does not require to load resources from external websites (which is a bit NO for me both as user and developer), and I think a more clear UI and probably more secure overall. Also we do not have 68 now, or even 6. We have 1, maybe 2. Designing for 68 is not future proof, is over-engineering. Ok, thanks for listening guys really appreciate the conversation. Now I'll go back to damn frontend testing setup - the hardest thing of hard things 😉
