Oddbean

Meet the latest Nostr-Login widget release! Nostr-Login has become a very powerful window.nostr provider (as of v1.3.0). Just drop the nostr-login script into your web app, and your users will be able to login with extension, with Nostr Connect, in read-only mode, sign up with OAuth-style flow, switch accounts, etc. Your app just calls window.nostr, the rest is handled by nostr-login. Here is a short demo where I login with Nostr Connect, and then add a read-only account, and then switch between them. You can try it in action on https://nostr.band https://v.nostr.build/POD38.mp4 App devs, if the only option you're giving your users is "Login with extension" (or even "Paste your nsec") then maybe it's time for an upgrade. The more options for people to log in, the more your app is used! Learn more on how to set up nostr-login at https://github.com/nostrband/nostr-login For other "login with Nostr" options, check out https://nostrlogin.org

There are 2 things that bother me about nip-46. 1. If we are going to have the added rtl of relaying encrypted messages, why cant we just contact signing servers directly? Add a signing server url to the nip-05 spec, then perform a real oauth2 sign-in, and communicate with the signing server directly? In fact there would be no need to contact relays at all here. In signer devs just need to build HTTP servers, and don't have to fuss with relay and maintaining connections etc. We can even use another layer of encryption if we want to. I'm aware of some of the security tradeoff with exposing a signing server, but I believe it's worth reducing complexity for. 2. It's still using nip-04 even though we all agree its deprecated at best.

That is indeed something that will eventually bite us. Do you have any ideas about how that could be fixed with nip46, without switching to a new protocol? Maybe nip46 relay could require nip42 auth and only serve you the events that match your identity?

Nip46 is far from perfect indeed. To your points: 1. Nip46 server can be built into a relay, so you would be "just contacting signing server directly" to save one roundtrip. Not sure there is any practical difference btw HTTP and WS, aside from less experience with WS for most devs. The most important stuff you lose without a relay is: - you can't run your nip46 server behind NAT without a relay in the middle, so even if you had some server you owned (Umbrel etc) it would require a complex port forwarding etc setup to host keys on it, and you'd expose your server to the wide internet and then hope it's not getting hacked, etc. - you can't build a client-side solution like nsec.app where you don't need to own a server to self-host your nip46 signer Essentially, adding a relay REMOVES a lot of complexity for practical self-hosted use and adoption. And if you wanted to save on round-trips, there will be nip46 signers built into relays. 2. Nip04 use sucks, we will need to upgrade at some point. Do you think we should start asap?

A more complete argument I opened yesterday. https://github.com/nostr-protocol/nips/issues/1207 > Nip04 use sucks, we will need to upgrade at some point. Do you think we should start asap? Yes I have removed support for it in my noscrypt library but will be adding it back later for compatibility. Truns out AES doesnt actually seem to be the most portable. https://github.com/VnUgE/noscrypt/tree/develop

I'm skeptical about most of the Pros listed: > Multiple keypairs/identities are not needed - that's just implementation detail, like generating tokens in oauth etc > Access tokens are only useful for authorization and are generally short-lived, they don't leak any permanent information. - not sure which parts of nip46 leak anything, can you provide details? > Signer events are now "private" between clients and signers, and can't leak user activity such as note decryption when opening a new client. - this one is valid concern > No relay, no relay to trust - most nip46 providers will host their own relay for many reasons, and even if they use a third-party relay - they will only recommend one they trust, so if you trust a provider, you probably trust the relay > Http attack surface is well understood - need more details and maybe examples here > CORS could possibly be used as a security advantage for web clients - need details and ideas of where and how > Reduces signing server dev complexity - you won't implement oauth yourself, you'll use a library, but then you can just use a library to implement nip46 > Full OAuth2 and identity management infrastructure already exists - which of them could I start using tomorrow to use with Coracle or Snort on mobile? This might be true for corporate world, not much for individuals > Since clients connect directly, network/http requests can be audited easily - audited for what? all requests are signed, the only thing lacking with nip46 is peer's IP address, which is only useful for privacy violations of good users, since bad people hide their IP anyway > Reduces client complexity and deprecated encryption spec - you will use a library in both cases, so complexity is comparable. nip04 is bad, agreed.

I appreciate your feedback and I intend to revisit this with better scrutiny when I a little more time read & think, as I still believe a direct-to-signer model like this would be ideal. > not sure which parts of nip46 leak anything, can you provide details? If the encryption keypair ever leaks, event sniffers that stored your previous messages will be able to decrypt them in the future. This simply isn't a concern if they can't be sniffed in the first-place. I think I'm mostly arguing surface area here, since dms are using the same encryption anyway, its more about the possibly leaky keypair. I think I saw you mention nip42. Were still trusting relay servers to follow the rules, and with signers I want an option that can avoid that if possible. I think relay servers should pretty much be trusted as dumb databases. Also, I am rolling my own OAuth2 but it's part of my web framework to your point actually.