It also lacks the option for a client to request an AUTH challenge if one has never been sent.
Maybe AUTH is only needed for write, yet a clients can’t ask for a challenge before they first write. They’d have to auth even just to read - which isn’t ideal privacy wise. Unless your relay requires auth to read - again possible.
I did mean separate bounties for each app of course.
Yes, the spec is an absolute nightmare and totally unclear. It should also have an option to be in a header and not force us to open the websocket connection first.
We are simply providing an AUTH challenge in connect and will not respond to any REQs or EVENTs until you answer the auth. You have 10 minutes to respond or we drop your connection. It is trivial to modify this to do whatever it is clients prefer provided they have an implementation for us to test.
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.
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.
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.
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.
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.
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
Excellent discussion 💜
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.
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 😂
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.
I think i had support nip42, but i haven't test it. 😅
