Implement nip 42 client authentication about strfry

[shawndearmond]

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?

[hoytech]

I assume you mean for the stream and sync commands. Yes, this is a good idea, and I'll add to the TODO list. 👍

[Giszmo]

Uhm, I had not thought of strfry as a client here. I will update the issue.

[hoytech]

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.

[tannerdsilva]

@Giszmo @hoytech

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 nostr-rs-relay, the only known relay implementation of 42 (as far as I know).

This verified implementation in nostr-kit (against the spec itself and against nostr-rs-relay) has now been used to build NIP-42 into strfry. You can see it here.

I expect to have a PR ready by end of August.

[tannerdsilva]

Welcoming any feedback that can be given to help us shape or refine an “ideal plugin” for NIP-42.

[Giszmo]

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.

[shawndearmond]

@tannerdsilva commented:

Welcoming any feedback that can be given to help us shape or refine an “ideal plugin” for NIP-42.

1. NIP-42 should be configurable in the .conf so it can be enabled or disabled. Many clients don't support it yet.
2. Setting to AUTH all connections and store the result so the value can be used later on, such as...
3. The AUTH status and associated npub should be available to Event-sifter plugins so that complex conditions can be built to allow writing and reading.
4. Event-sifter plugins should be able to trigger AUTH requests from the relay to the client. Maybe even get the result, and then continue with the sifting.
5. Setting to NOT allow Kind 4 DMs to be read by anybody who has not AUTH'd as either the sender or receiver of the DM.

Here's a possible block to add to strfry.conf:

auth {
    # Enable NIP-42 authentication
    enable = true

    # Authenticate all connections.
    all = true

    # Require authentication to do anything.
    require = false

    # Event Kinds requiring NIP-42 authentication to write. Example: {0, 3, 4, 6-8, 5000-7000}
    kinds = {}

    # Restrict reading NIP-04 (kind 4) DMs to only the sender and receiver
    protectDirectMessages = false
}

[tannerdsilva]

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

[shawndearmond]

Awesome. Thank you @tannerdsilva !

Please let me know if there's anything I can do to help. I'm no C++ developer, unfortunately.