nip46: simple public key login using kind:10046

[fiatjaf]

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]

brilliant and super simple with a phenomenal UX.

[staab]

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

[pablof7z]

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]

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]

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]

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 [email protected] 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]

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]

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]

if I use [email protected] 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 [email protected] to log in, no one ever said this felt 'insane'.

[nostrband]

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: #1557 (comment)

Is there something I'm missing?

[greenart7c3]

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]

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.