feat(nwcp): add NIP-42 client AUTH support by satwise · Pull Request #38 · lnbits/nwcprovider

satwise · 2026-05-03T16:09:09Z

Problem

When a NIP-42-enabled relay sends ["AUTH", "<challenge>"], nwcprovider hits the catch-all raise Exception("Unknown message type") branch. The error is logged and no response is sent. The relay closes subscriptions because the challenge is never answered.

This makes nwcprovider completely incompatible with any relay that has nip42_auth = true.

When a NIP-42-enabled relay sends [AUTH, challenge], nwcprovider now responds with a signed kind-22242 event (relay URL + challenge tags). Previously the AUTH message type hit the catch-all raise Exception branch, causing an error log and no response. The relay then closed subscriptions because the challenge was never answered. Fix: add _on_auth_message handler and route msg[0]=AUTH to it in _on_message. Closes: (to be linked after PR filed) Ref: https://github.com/nostr-protocol/nips/blob/master/42.md

Copilot

Pull request overview

Adds NIP-42 client-side AUTH challenge handling to NWCServiceProvider so the provider can interoperate with relays that require ["AUTH", "<challenge>"] responses instead of failing with an “Unknown message type” exception.

Changes:

Route incoming relay "AUTH" messages to a dedicated handler.
Implement _on_auth_message to build/sign a kind 22242 auth event and send it back via ["AUTH", event].

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

        except Exception as e:
            logger.error("Error parsing event: " + str(e))


+        auth_event: dict = {
+            "kind": 22242,
+            "content": "",
+            "created_at": int(time.time()),
+            "tags": [
+                ["relay", self.relay],
+                ["challenge", challenge],
+            ],
+        }
+        self._sign_event(auth_event)


satwise · 2026-05-04T16:30:32Z

Dependency note — this PR is a blocker for newly-exposed NIPs on our Umbrel relay fork.

satwise/nostr-rs-relay (fork of scsibug/nostr-rs-relay) now advertises and partially enforces NIP-17 (private DMs), NIP-50 (full-text search), and NIP-59 (gift wrap) — all gated behind nip42_auth = true on the relay side. Full activation path:

✅ This PR (nwcprovider#38) — NWC client answers ["AUTH", challenge] so nwcprovider can authenticate against a NIP-42 relay
✅ nostrrelay#44 — server routes ["AUTH", signed_event] through _handle_event so auth pubkey is actually set

Finally closes LNBits platform GAP between NostrRelay & NWCprovider Extensions to monetize AI Agent subscriptions

Then: flip nip42_auth = true in config.toml on relay
Then: NIP-50 full-text search and NIP-17/59 delivery restrictions become fully operational

NIP-11 on wss://nostr.janx.com currently advertises NIPs [1,2,9,11,12,15,16,20,22,33,40,44,50,77]. NIP-17/42/59 are added to the advertisement once auth is enabled. All infrastructure is ready — so only this LNbits PR is the only remaining blocker to test a fully NIP enabled nostr-rs-relay-v0.9.1 as an LNbits user. Successful testing also offers an alternative to if the load gets too much for LNbits NostrRelay, which happened in my case.

Thank you for your kinds consideration.

DoktorShift · 2026-06-02T11:21:14Z

@satwise Thanks for this- clean fix, and it lines up nicely with the existing resubscribe logic so the auth-then-resubscribe flow should just work. Verified it against NIP-42 too: kind 22242, relay/challenge tags, and empty content all check ot 👍

Couple of small things:

When the relay rejects auth with ["OK", id, false, ...], right now we silently pass. Could we add a debug/warning log there? Makes diagnosing failures, for example a relay canonicalizing the URL differently than self.relay, way easier.
Any chance of a quick unit test for _on_auth_message? Something asserting it emits a valid signed 22242 with the right tags. Since this is hard to verify without a live NIP-42 relay, a test would give us confidence and guard that branch going forward.

Neither is a blocker on the logic, happy to merge either way, just nice-to-haves. 🙏

Implement stakeholder-requested relay auth/publish diagnostics. Changes: - Route incoming OK frames to _on_ok_message instead of ignoring them. - Log rejected OK responses at warning level with relay, event id, and relay reason. - Log accepted OK responses and malformed OK payloads at debug level. Validation summary (no package unit test added, per request): - Ad-hoc runtime validation confirmed AUTH response emits kind 22242 with relay/challenge tags and valid signature. - Log checks confirmed expected rejected/accepted/malformed OK diagnostics are emitted.

satwise · 2026-06-03T00:24:40Z

@satwise Thanks for this- clean fix, and it lines up nicely with the existing resubscribe logic so the auth-then-resubscribe flow should just work. Verified it against NIP-42 too: kind 22242, relay/challenge tags, and empty content all check ot 👍

Couple of small things:

When the relay rejects auth with ["OK", id, false, ...], right now we silently pass. Could we add a debug/warning log there? Makes diagnosing failures, for example a relay canonicalizing the URL differently than self.relay, way easier.

Any chance of a quick unit test for _on_auth_message? Something asserting it emits a valid signed 22242 with the right tags. Since this is hard to verify without a live NIP-42 relay, a test would give us confidence and guard that branch going forward.

Neither is a blocker on the logic, happy to merge either way, just nice-to-haves. 🙏

@DoktorShift thank you for your review and suggestions. I am happy to accommodate your requests. I implemented relay OK response handling so rejected publish/auth outcomes are now surfaced as warning logs with relay, event id, and reason, while accepted and malformed OK responses are captured at debug level for diagnostics.
Commit link: satwise@9c4543f

Included are the results of the unit-test validation you requested for the AUTH path:
auth_cmd: true
kind_22242: true
has_relay_tag: true
has_challenge_tag: true
signature_valid: true

Pertinent log results:

Relay wss://relay.example rejected event c1341902617ee50da3986ba71da490074e44f63d982db47958882e83c32dd84a: auth-required: challenge failed
Relay wss://relay.example accepted event c1341902617ee50da3986ba71da490074e44f63d982db47958882e83c32dd84a: stored
Received malformed OK message from relay wss://relay.example: ['OK']

Copilot AI review requested due to automatic review settings May 3, 2026 16:09

Copilot started reviewing on behalf of satwise May 3, 2026 16:09 View session

satwise mentioned this pull request May 3, 2026

feat(nostr-relay): nostr-rs-relay 0.8.1 → 0.9.0: NIP-42 auth gate, docker builder fork getumbrel/umbrel-apps#4786

Open

Copilot AI reviewed May 3, 2026

View reviewed changes

satwise mentioned this pull request May 3, 2026

Nip47 notifications #30

Open

DoktorShift requested review from DoktorShift, blackcoffeexbt and motorina0 May 12, 2026 23:16

motorina0 approved these changes May 25, 2026

View reviewed changes

DoktorShift approved these changes Jun 2, 2026

View reviewed changes

DoktorShift approved these changes Jun 3, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat(nwcp): add NIP-42 client AUTH support#38

feat(nwcp): add NIP-42 client AUTH support#38
satwise wants to merge 2 commits into
lnbits:mainfrom
satwise:feat/nip42-client-auth

satwise commented May 3, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

satwise commented May 4, 2026 •

edited

Loading

Uh oh!

DoktorShift commented Jun 2, 2026

Uh oh!

satwise commented Jun 3, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

		except Exception as e:
		logger.error("Error parsing event: " + str(e))

Conversation

satwise commented May 3, 2026

Problem

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

satwise commented May 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

DoktorShift commented Jun 2, 2026

Uh oh!

satwise commented Jun 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

satwise commented May 4, 2026 •

edited

Loading

satwise commented Jun 3, 2026 •

edited

Loading