Nostr Web Client

NIP-42 seems to be designed mostly around preventing users from requesting DMs that aren’t theres and other niche use cases when the masses just want private relays. It’s the much more obvious application.

Blake 2y ago

Yep. Happy to contribute if we open a GitHub issue.

I think it needs refinement before striving for more adoption. A new NIP is an alternative, however likely a harder route and just noise… when we can cover way more use cases by amending 42.

I’ve been using a slight modification for web app logins. The only real difference is I send the same event by POST, and call the relay Tag origin, as it’s more generic. Only issue is for browser extension UX that kind is called Relay Auth… which is weird to hear for a webapp.

Reply to this note

Please Login to reply.

Discussion

Mazin 2y ago

I agree we can amend 42 to work, thats the plan. We think using a jwt header is probably the best solution but just sending the encoded kind 22242 would be tolerable (without a challenge string).

Should have something for you to look at soon.

Mazin 2y ago

We will support it in its current form either way though. If you don’t send us the header during connection, we’ll send an AUTH request on connect. If you do, we’ll skip it.

Mazin 2y ago

Had a telegram chat with the gate keepers, pretty clear this isn’t happening. Going to accept NIP-42 as it is for now. We wasted enough time on this today.

Blake 2y ago

NIP-7 has some discussion two. I don’t need the generic sign function anymore, but we still need a consistent way to support web app login from extensions. An alternative is Nostr Connect - but I think simple extension support is required too. A suggestion was clicking an extension to sign in, but it has limitations too.

My POC works fine and is simple, however perhaps using JWT is a better approach long term and something to spec up. @mazin, you’re still planning relay login to customise pubkey preferences? Happy to collaborate on this too.

https://gist.github.com/blakejakopovic/b0065b9327c48c148bfe989c08137ba1

https://github.com/nostr-protocol/nips/issues/373

https://github.com/nostr-protocol/nips/issues/353

THE MAX 2y ago

Excellent discussion 💜

Mazin 2y ago

Yes, we will still need to support some type of user login to change settings.

I guess I’ll just use a similar sign an event flow as you until they come up with something better. I can send you the JWT we came up with (and other header ideas) but I was told explicitly NIP-42 is “easy to implement” and more auth options leads to “protocol bloat”.

I’ll be working on that this week.

Mazin 2y ago

JWT is a little messy (we discovered) because there isn’t a standard alg for schnorr, so you end up having to do your own validation anyway.

Another idea was just the base64 encoded NIP-42 event (no challenge string) as a header. Then I got lectured about MITM attacks 😂

Blake 2y ago

I played with JWT today, and it’s not the best fit for use. Hadn’t implemented it before.

I really only wanted a 20,0XX kind defined and basic JSON event. Then browser extensions can tell you that you are signing a “WebApp login” event instead of “Unknown”. I also use an “origin” tag, as opposed to “relay”.

A suggestion to optionally include the users preferred relays in the login JSON event as tags was a good idea for any server side rendering - however not something I need at present. And extension relays and kind 10002 don’t sync, so that’s another issue.

DASHU 2y ago

I think i had support nip42, but i haven't test it. 😅