Nostr login on the web works just fine if you're using nsec. Using extensions and keys work fine too, but they add an unknown level of complexity for newbies. They don't do that.

Reply to this note

Please Login to reply.

Discussion

Extensions add complexity … and also … bugs and inconsistency. Extensions don’t always work as expected on mobile. UX is broken … on top of being “complicated”.

Pasting nsec around (while always a reliable login) is not great for a number of reasons.

Mobile web login will be fixed once the UX is : “login once on web and stay logged in across apps”. No extensions. No compromised nsec. No hassle.

HTTP auth (NIP 98) … is an interesting approach. So a user (somehow) authenticates their nsec with a web client (still haven’t fixed this part) and this client then lays an auth cookie in the user’s browser which can be validated by other clients? And what about when these other clients request “additional” permissions not covered by the cookie? Seems tricky to handle Nostr auth without actual live access (somehow) to the nsec for signing…?

https://github.com/nostr-protocol/nips/blob/master/98.md

See reply to derek above

Yup i wrote this demo in js last year since there was only a C# sharp demo. There are actually 2 repos and it makes sense from the backend. Can also use nip42 auth afaik.

https://github.com/bitkarrot/NIP98-js-client

Legend.

Aww. Its all for good fun 💜🥳

She is.

What does it mean to have “auth”?

Well … it means the browser user who claims to be pubkey actually is in possession of the private key. Nothing more.

So, how does this work?

> “- redirect to another site with auth”

Well … it means that the “other site” can use “auth” to allow CRUD operations within the “black box” of their “other server”. Nothing more.

This is usefull for black box apps to interoperate alongside Nostr, but NOT for “sign Nostr events across sites with a single login” solving for the mobile login problem.

Am I missing something?