search

nostr-protocol / nips

Nostr Implementation Possibilities
2.39k stars 582 forks source link

nip46: simple public key login using `kind:10046` #1578

Open fiatjaf opened 1 week ago

fiatjaf commented 1 week ago

This vastly simplifies the bunker:// flow while also making it easy for the user on every other front possibly -- and brings back NIP-05 login, but in a simpler, more generic way.

pablof7z commented 1 week ago

brilliant and super simple with a phenomenal UX.

staab commented 1 week ago

No secret means the connection wouldn't be authorized, which would still require using nostrconnect:// or auth_url right?

pablof7z commented 1 week ago

No secret means the connection wouldn't be authorized, which would still require using nostrconnect:// or auth_url right?

Any authentication, yes, could be a nostrconnect, auth_url, or anything out of band like going to a console and saying "yes, I allow this pubkey"

mikedilger commented 1 week ago

When the bunker gets a connection request, it needs to find out from the user whether that is them or an imposter.

The "optional" secret was a means by which the bunker could know it was them (only they saw the secret, given to them via the bunker interface). In that way, the bunker doesn't need user approval on connection... and some bunkers don't ask for user approval for any operation either.

In this new scheme, although not specified (more of a per-bunker detail) the bunker would need to ask the user if this was them or not. In the case of two temporally adjacent requests, the user probably needs some piece of information that they can use to be sure this is them and not an imposter.

nostrband commented 1 week ago

In this new scheme, although not specified (more of a per-bunker detail) the bunker would need to ask the user if this was them or not. In the case of two temporally adjacent requests, the user probably needs some piece of information that they can use to be sure this is them and not an imposter.

I agree. If auth_url flow is used by bunker to confirm the connection then secret is not strictly necessary, but then it's a web-bunker and it's much better served by the nostrconnect:// flow.

This is an improvement upon older nip05 flow because npub/nprofile can be used and bunker doesn't need to maintain it's own nip05. But the secret should also be solved, i.e. client could show the secret to user and bunker do the same and both ask user to verify.

pablof7z commented 1 week ago

This is an improvement upon older nip05 flow because npub/nprofile can be used and bunker doesn't need to maintain it's own nip05. But the secret should also be solved, i.e. client could show the secret to user and bunker do the same and both ask user to verify.

the bunker was never supposed to maintain it's own nip05!! if I use _@f7z.io as my nip05 I just stick the nip46 config in my own nostr.json, not get another nip05 just for logging in, that's insane.

fiatjaf commented 1 week ago

Would it be ok if I just modified this PR to say that this flow assumes an auth_url will be used so the user can click to authorize?

staab commented 1 week ago

Would it be ok if I just modified this PR to say that this flow assumes an auth_url will be used so the user can click to authorize?

You should, that seems like an essential part of the flow to me. The user has to authenticate with the bunker somehow.

nostrband commented 1 week ago

if I use _@f7z.io as my nip05 I just stick the nip46 config in my own nostr.json, not get another nip05 just for logging in, that's insane.

Most people don't control their nip05 file, so they used user@nsec.app to log in, no one ever said this felt 'insane'.

nostrband commented 1 week ago

Would it be ok if I just modified this PR to say that this flow assumes an auth_url will be used so the user can click to authorize?

I am not strictly against nip05/npub login, but nostrconnect flow is so much better UX. You can check how it works in nostr.band with nostr-login widget. You show a list of bunkers fetched from relays, pre-generate nostrconnect strings with proper relays for each of them, user just needs to click on an icon of their bunker, then confirm the connection in a popup, and that's it. It works with web bunkers and apps like Amber. The implementation and UX are much simpler, no need to announce your remote_signer_pubkey on nostr.

I thought bunker-url and this flow would make sense for advanced bunkers like nak etc that can't handle nostrconnect:// URIs and can't serve auth_url. But if you make auth_url required then I don't see why someone would prefer this flow (copy-paste/type nip05/npub and confirm in a popup, only web) to nostrconnect flow (click on signer and confirm in a popup, web and Amber). This just increases the "number of ways of doing the same thing", see adjacent discussion here: https://github.com/nostr-protocol/nips/pull/1557#issuecomment-2474721687

Is there something I'm missing?

greenart7c3 commented 1 week ago

The pr looks good to me

@nostrband in my opnion the nostrconnect flow should be the following: Show the uri defaulting the relay to the signer default relay but let the user change the relay. Users choosing relays is better because most of the current nostr relays have a 300 to 600 ms ping This is when the app doesn't require the user to have a specific relay to use the app like ditto instances

nostrband commented 1 week ago

let the user change the relay

That can be advanced option.

Users choosing relays is better because most of the current nostr relays have a 300 to 600 ms ping

I disagree. Bunker knows better which relay works well for nip46, precisely bcs most other relays are overloaded. Besides, a bunker can be built into the relay, in which case any other relay just won't work. Letting users choose (and regret) is fine, but it's the bunker that should set the preferred one.