Nostr Web Client

Seems crazy steep considering I wrote a stand-alone websocket for NIP42 without any examples or even working clients to test it on in about one hour.

…but if that’s what it takes I’m open to it 😂

Blake 2y ago

I think you’re best to split it per app. Likely different authors for the PRs.

What’s the spec?

* add enable AUTH toggle option to settings

* for each AUTH event, sign an AUTH response and publish to that relay.

One issue with the spec is that is doesn’t seem to specify if an AUTH challenge (specifically the first one) is blocking - can you still read/write before responding with an AUTH response? Do you need to queue up all other requests until you first send AUTH?

I think the answer is it depends. The spec likely needs clarification around this.

Here is likely where you’d inject an AUTH response in Damus.

https://github.com/damus-io/damus/blob/02fc065005738abbc84fe8102a48a0e0903f8624/damus/Nostr/RelayPool.swift#L252

Reply to this note

Please Login to reply.

Discussion

Blake 2y ago

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.

Mazin 2y ago

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.

Mazin 2y ago

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.

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. 😅