Fix CI and implement NIP-42 AUTH support for NIP-70 protected events

[zk-bits]

This PR implements NIP-42 authentication support in the context of NIP-70 protected events, continuing the work originally started by @fiatjaf in #137.

Changes

NIP-42 Implementation (original work by @fiatjaf)

• Implements NIP-42 AUTH message handling
• Adds authentication support for NIP-70 protected events
• [Include any specific implementation details from the actual code changes if you know them]

CI/Build Fixes

• Updated GitHub Actions workflows to v4 (resolves build failures in original PR)
• Added build-essential package to ubuntu.yml workflow dependencies
• Updated Docker build actions (docker/login-action, docker/setup-qemu-action, docker/setup-buildx-action) to v3
• All CI checks now passing for both amd64 and arm64 platforms

Background

PR #137 introduced NIP-42 AUTH support but had CI failures that prevented merging. The workflow files needed updates to newer action versions and missing build dependencies.

Credit

Original NIP-42 implementation: @fiatjaf (#137)
CI fixes: @zk-bits

Related Issues

• Closes Implement nip 42 client authentication #47 (if this fully implements NIP-42 client authentication)
• Supersedes implement NIP-42 AUTH support in the context of NIP-70 protected events #137

Testing

• ✅ Ubuntu build successful
• ✅ Multi-platform Docker builds (linux/amd64, linux/arm64) successful
• ✅ All CI checks passing

[hoytech]

Looks reasonable, but here are some notes:

• AuthStatus is stored as a pointer in connIdToAuthStatus and does not appear to ever be deleted, implying a memory leak. Instead it should be stored by value, and removed from the map when a connection is closed.
• I see the intent of the std::pow() calculation for the challenge, and it's probably "good enough" in most cases. However, there are some edge cases like when a relay is restarted, the connId space is re-used. Personally I would generate the challenge randomly. Fortunately, I have a library specifically designed for this purpose: https://github.com/hoytech/session-token-cpp
• The default strfry.conf is actually generated programmatically during build from the golpe config. It can actually be copied out of the build/ directory. I notice this wasn't done because the value in strfry.conf is different from the default.
• It seems to always fail to accept all non-protected events with blocked: only protected events accepted. This is pretty clearly a bug?
• Related to previous: Should there be some way to control the relay's AUTH mode? I can think of at least 4 states: 1) No AUTH, all events accepted, 2) No AUTH, reject all protected events (current default), 3) AUTH enabled, protected events must be authed, other events normal, 4) AUTH enabled, only accepts authed events
• Some of the previous modes could be implemented through plugins. The auth status should be exposed to write policy plugins.

Don't worry about implementing the above points, I will do that. However, some of the points above could benefit from some discussion.

[fiatjaf]

Thank you for catching my bugs, I'm sorry about them.

• It seems to always fail to accept all non-protected events with blocked: only protected events accepted. This is pretty clearly a bug?

Yeah, this wasn't in the original PR, I don't think it makes any sense, it smells like vibecoded slop.

• Related to previous: Should there be some way to control the relay's AUTH mode? I can think of at least 4 states: 1) No AUTH, all events accepted, 2) No AUTH, reject all protected events (current default), 3) AUTH enabled, protected events must be authed, other events normal, 4) AUTH enabled, only accepts authed events

I think:

• 1 is wrong, should be a forbidden state or at least heavily discouraged.
• 2 could be an option, but I can't imagine that anyone would want it.
• 3 should be the default.
• 4 I also don't think makes sense as a blank policy, AUTH or not doesn't mean much without context, if relays want to implement custom or dynamic whitelists they can do it with plugins.

The auth status should be exposed to write policy plugins.

Yes, it's a good point that the authenticated state should be exposed to plugins, but I actually don't think it is super necessary for most things. If the relay is already ensuring that events with a "-" are published by their author, then plugins can just look if that tag exists and assume the event was published by an authenticated user.

[hoytech]

I merged this. Thank you!