-
Notifications
You must be signed in to change notification settings - Fork 90
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement nip 42 client authentication #47
Comments
I assume you mean for the stream and sync commands. Yes, this is a good idea, and I'll add to the TODO list. 👍 |
Uhm, I had not thought of strfry as a client here. I will update the issue. |
Ahh sorry my bad, for some reason I thought we already had a ticket about the relay-side of NIP-42 so this was something different. I agree strfry should have AUTH support. A couple people have told me they are working on it, but I haven't heard any updates recently. |
Hello, just now realizing this was here. I'm working closely with a credentialed and experienced CPP dev to implement this. I'm a credentialed backend dev in my own right, but not for CPP. So I hired out, and am overseeing the implementation and communicating with community as needed. Primarily: I'm active in the strfry telegram, ensuring the context and expectations around the NIP-42 implementation are known and agreed upon. Of course, we will all be able to evaluate during the PR process as well. Trying to maximize this feature for everyone's needs. We are close to delivering, we have strfry issuing and verifying AUTHs, now mostly working out the plugin interface. This was supposed to come sooner, but my contractor was struggling to use existing clients to test NIP-42 against his local builds in a VM. As such, I built a reference implementation of NIP-42 into my nostr-kit library. This reference implementation was based on NIP-42 spec itself, and verified to work as expected in the latest release of This verified implementation in nostr-kit (against the spec itself and against I expect to have a PR ready by end of August. |
Welcoming any feedback that can be given to help us shape or refine an “ideal plugin” for NIP-42. |
I think it would be good to open a work-in-progress pull request to signal to others that you are working on it and to allow preliminary feedback and questions. I see you are implementing details beyond the pure auth and it makes sense to feel out what to do with the auth once it's implemented. A PR would also allow to describe what the changes provide although that should ultimately go into the documentation. |
I am also very much interested in have NIP-42 in strfry. Looks like it's been a while since people last posted. Where is this at? @tannerdsilva can you share whatever code you've already built? |
@tannerdsilva commented:
Here's a possible block to add to strfry.conf:
|
@shawndearmond this looks really good, I really appreciate this input. This has been a dormant initiative for a while but I recently picked this back up and have found a lot of traction. I am encouraged with how this project has picked back up and hope we can submit a PR in the very near future. ATM we are working with your config spec for our initial implementation. Thanks for the jumpstart. |
Awesome. Thank you @tannerdsilva ! Please let me know if there's anything I can do to help. I'm no C++ developer, unfortunately. |
Please implement client auth as defined in nip 42. This is also needed for #17.
I am primarily interested in my relay requiring auth at some point. Only serve REQ from
But ... as clients don't support nip42, the very first step is to let users auth without caring with which key they auth and maybe notify them that auth failed without consequences, to get client devs moving on this topic.
As mentioned in the comments below, full nip-42 support could also mean support for sync and stream.
The text was updated successfully, but these errors were encountered: