Oddbean

It works! Signed in using artur@nsec.app on mobile nostr:nevent1qqs89mm4apvplslmratwptmw96pcdzqgfygaa82vpwhpf2dd4xk0mtspz3mhxue69uhhyetvv9ujumn0wd68ytnzvupzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vaqvzqqqqqqysf3hsw

Sorry, no proof. It's not working well :( First there were nsec.app's popup showing up and disappearing. I've fixed that, apologies. Now window.nostr.js doesn't notice the actual reply after auth_url popup is shown and I confirm, reply to 'connect' is delivered but nothing happens (still on login screen). I have to retry connecting (enter nip05, click connect), and since the same local key is reused the perms are already assigned, no auth_url is sent and then it gets through. Also the modal doesn't fit the screen on mobile. Also Logout should probably clear the local key, otherwise it's not really logout.

That key has permissions granted. If it stays anyone can relogin in the app without me confirming, or can copy the key from localstore and reuse in other apps and devices. I click logout on a public pc to make sure noone from this pc can access my account.

I see, but this sounds like a broken design. If you depend on the app to keep keys safe then how is this any better than just pasting your nsec there and hoping for the best? I think the full logout can only happen at the bunker side somehow.

I think it's a common action for logout button to clear local session info - cookies, token etc. Client might ask the server to destroy the token too if that's supported, but client should act in the interest of user and do it's best to destroy the session info locally. Well at least that's how I always thought about it.

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.

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 😉

Thanks for the heads up! Indeed I forgot is has to be published by bunker key and have proper nip05. Published, now visible in window.nostr.js and other places. Also nostrapp.link didn't have nip05 editable field for apps, added - nip46 providers can now use this app to publish their nip89 announcements.