NIP42 authentication

[jeremyd]

any plans to support NIP42 auth?

[water783]

I think it is supported. Is it not working?

[jeremyd]

Oh, I was attempting to test it earlier. I setup 2 test accounts (but one was on amethyst) and I attempted regular DM, and NIP17 DM between them using this relay: auth.nostr1.com

The relay is setup to only allow AUTH'd connections from any pubkey, and is open to all the necessary kinds.. But it will not allow any events without an AUTH. I have run the same test with amethyst and it works there. I looked at your NIP list and assumed it just wasn't implemented yet.

[water783]

Thank you for pointing that out. I think I didn't implement it correctly. I'll handle it in these days.

[jeremyd]

No problem, let me know if I can help debug. You can use the auth relay if you want and let me know if you see any problems there and I can debug it.

[water783]

Are you using iOS? I have just updated the TestFlight version, you can have a try

[jeremyd]

I'm using android

On Wed, Jun 12, 2024, 5:12 PM water @.***> wrote:

Are you using iOS? I have just updated the TestFlight version, you can have a try

— Reply to this email directly, view it on GitHub https://github.com/0xchat-app/0xchat-core/issues/12#issuecomment-2164118880, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAA72BDF5VBUNEO6SWDO63ZHDPWLAVCNFSM6AAAAABJE53U4SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRUGEYTQOBYGA . You are receiving this because you authored the thread.Message ID: @.***>

[water783]

I just updated the APK. Feel free to give it a try!

https://github.com/0xchat-app/0xchat-app-main/releases/tag/v1.2.8-release

[jeremyd]

I tried 1.2.9, my relay is saying authentication is failed for the user. It should be allowing any user to authenticate maybe sig is wrong?

[jeremyd]

hm, weird, I duno maybe my relay is not working.. it doesn't work in amethyst now either. standby and i will attempt further debugging.

[jeremyd]

ok, i forgot i had the relay setup to only allow pubkeys from the list. now that I have them, amethyst is working, but when I use 0x my relay is saying "err challenge tag missing from auth response". There may be a bug in the challenge response from 0x?

[jeremyd]

I added your npub to the relay auth.nostr1.com if you want to try it

[water783]

I just tested this relay, and i can send DMs normally. @jeremyd

[water783]

Wait, I succeeded once, but others failed. Let me check

[water783]

i received notice: ["ERROR: bad msg: unknown cmd"], wss://auth.nostr1.com, what did it mean?

[jeremyd]

Did further testing:

I've seen this bad msg: unknown cmd, it also happens with amethyst. I believe it means strfry does not recognize a REQ or something like this, but I'm unsure what strfry is seeing in this case. Usually apps seem to still work.. Would be nice to track this down, I can possibly run with more debug logging, or if your client has debug of the request it was attempting to send that would be helpful.

The current behavior I'm seeing is that 0xChat looses it's socket connection when it is suspended (navigating to another app). When resume, it does not attempt to re-establish the connection and does not attempt to login.

So when I send messages to it, it only shows if I force quit 0xchat, and re-open (by swiping up on the running app manager). This way it establishes the connection, authenticates, and messages can be sent or received again.

A second thing I'm seeing, when I leave 0xChat open for a while (a few minutes), it seems to loose it's connection and attempt to re-auth, however the auth proxy is not receiving a proper challenge and saying "failed to validate AUTH event: challenge tag missing from auth response"

I've opened up the auth relay to anyone with a pubkey now so it will be easier to test. I'm unsure if this is my relay's implementation of auth, or the client or both... But I have done extensive testing with amethyst and coracle and those clients seem to be able to send nip17 back and forth reliably without having to force quit or anything.

[jeremyd]

Ah, I think I've found part of the bug, somehow the AUTH is getting past my proxy and strfry sees it and returns BAD MSG: unknown CMD. Ok, this could be bug on my side then because the proxy is supposed to be responding to those, not strfry. Strfry should not be seeing the AUTH req at all..

[jeremyd]

Oh, actually, this makes sense if the client is sending multiple AUTHs on a connection that is already authenticated... So, from the proxy perspective, this was working as designed.. However I can modify it to drop these and then strfry will not send out the errors which may be tripping up a client..

[jeremyd]

Well, this is very strange, when I use 0xChat, my internal NIP42 parsing library keeps saying "challenge tag missing from auth response", but as far as I can tell, the challenge tag appears to be there.. This doesn't happen with the other clients and yet I see no noticeable difference in the response from 0x. I will have to spend some time debugging this..

[jeremyd]

OH, ok, the challenge string that the relay is getting does not match the challenge it sent. Somehow 0xChat is sending a wrong challenge string back.. this is strange because it's still in the same UUID format.. Is 0xChat opening multiple websocket connections at the same time possibly? Each connection will have a unique challenge to that connection in this case and perhaps you are sending back a challenge string from a different connection.

[water783]

Thank you for your help. The tests on my side have passed. I have updated an APK. However, I was unable to reproduce the issue of reconnection that you mentioned. It might be related to different devices. I will continue to monitor this issue.

[water783]

https://github.com/0xchat-app/0xchat-app-main/releases/tag/v1.2.9-release

[jeremyd]

ok thank you, I was testing on the 1.2.9 apk if that helps.

[water783]

Are you using release2 APK, build 55?

[jeremyd]

mm, no I am using https://github.com/0xchat-app/0xchat-app-main/releases/tag/v1.2.9-release from 3 days ago. I may look at spinning up a build environment for android but for now I am just testing the releases you linked to.

[water783]

Ah, The version from three days ago has a bug with repeated auth requests. So i updated the APK.

[jeremyd]

oh, im confused, the releases page says the release was updated 3 days ago?

[jeremyd]

OHHH, i see you updated 10 hours ago with release2. ok i will try this next

[jeremyd]

Ok I just did a quick test with the new APK. It's working better now, however, there still seem to be connection issues when the app goes into the background or is open for too long. When I force close it, and open, it receives the new messages. Same for sending, sometimes if it's been in the background and then I try to send a new message, it says it sent, but it did not send. I believe the connections are closing, and re-opening on resume but the app tries to subscribe and use them without responding/sending a new AUTH.

Another question I had is, does 0xchat publish kind 10050 private relay list? Amethyst doesn't seem to be finding that, so it keeps defaulting back to kind4. (But I can still test nip17 by manually turning it back on).

[water783]

Regarding the connection issue, what phone are you using for testing?

We have not published the private relay list, why is Amethyst switching to NIP-4? I need to check it.

[jeremyd]

I'm using a pixel 6 pro with latest android 14. Yes amethyst needs that kind 10050 to automatically do nip17 (so does gossip). Possibly coracle too but I haven't confirmed that. I think all clients are starting to use it, at least those with nip17 support.

[water783]

Ahh thx, I will check it

[jeremyd]

I have discovered new information about how the current relay implementation is behaving. It is disconnecting after 120s due to PING messages getting swallowed up by the middleware. So, that means an app would need to re-connect, and this could be part of why things aren't working too well maintaining the connection. It's a good stress test for apps, but I will likely adjust the settings to make this much higher, say 30m+, maybe even higher. So, this means that whatever re-connection logic you have may be getting stalled out on the authing, and/or subscriptions not being re-subscribed when the disco happens.

Anyway, just fyi, I've been debugging the websockets on the relay with my NDK client.. NDK doesn't re-subscribe for example, but it does re-auth the connection on disco..

[water783]

Thank you for the information; it’s very helpful. We have a reconnection mechanism, and I don’t encounter this issue on my iOS device. However, I’m not sure why it doesn’t reconnect on your device. I need to further investigate the issue.

[jeremyd]

I fixed a bug on the relay. The relay was not sending ["OK", "1234", "false", "auth-required"] when receiving an event prior to auth. The sending of messages from 0xChat is working better now I think, and also the invalid challenge problem has gone away. Now the only problem I'm seeing is that it still does not receive new messages, when coming back from the app being suspended.

My test is as follows: I have 0xChat setup with a pubkey, that only has auth.nostr1.com in it's relay settings. I have Amethyst with a different pubkey, and same setting. I send a message from 0xChat, I switch to amethyst, I read the message. Then I send a message from amethyst, switch back to 0xChat, and it does not show the new message. However, when I force quit 0xChat (by swiping up on the application picker) and re-open it, it does show the message.

[water783]

I have fixed an issue with failing to receive DM messages, but I'm not sure if it's the same reason as yours. Let me test and see.

[jeremyd]

Hi @water783. I've deployed another round of bugfixes to the relay. I was mistakenly sending EOSE after the [REQ CLOSE "auth-required"] responses. I also was not responding properly to multiple AUTH responses. These are now fixed.

The general flow that this relay will perform (following NIP42 spec) is described here incase this is useful:

Initial connection. Relay sends AUTH challenge. If Client sends REQ or EVENT -> Relay re-sends AUTH challenge as well as [ok false "auth-required"] or [closed "auth-required"] in response to these until a successful AUTH response is received. Client sends AUTH response. Relay sends OK. Connection is established to the backend for normal relay REQ/EVENTs.

[water783]

Awesome, thanks for your work. I will recommend your relay server in our inbox version.

[jeremyd]

Cool, no problem. I tested the same version of 0xChat again with these changes but still seeing that in the background it looses connection. When I force quit and open it again, it works. Let me know when you have a new version and I can test that too.

[water783]

Sure, plan to release the inbox version next weekend.