[FEAT] Return error when publishing with no relay connections

[BenGWeeks]

Description

When an extension (like nostrmarket) publishes an event via nostrclient's internal websocket, nostrclient currently accepts the event even if there are no relay connections configured or active.

This makes it impossible for the calling extension to know if the message was actually delivered to any relays.

Current Behavior

1. Extension sends event to nostrclient via internal WS
2. nostrclient accepts the event (internal WS is open)
3. Event goes nowhere because no relays are configured
4. Extension thinks message was sent successfully

Proposed Behavior

When publish_nostr_event is called and there are no active relay connections:

• Return an error response indicating no relays available
• Or expose a status endpoint that extensions can query to check relay connectivity

Use Case

In nostrmarket (#134), we want to show users when their direct messages failed to send. We can detect when nostrclient's websocket is completely unavailable, but not when nostrclient is running with zero relay connections.

Related

• [BUG] Messages component does not show errors when nostrclient is not available nostrmarket#134 - Show failed messages with resend option
• feat: show failed messages with resend option nostrmarket#145 - PR implementing message failure detection

[BenGWeeks]

Following up on this — I've found a broader issue beyond the "no relay connections" case.

Even when relays are connected and events are successfully published upstream, Nostrclient does not forward OK responses back to the client. I verified this by connecting directly via WebSocket to my Nostrclient endpoint:

• REQ (subscriptions) → works, events returned ✅
• EVENT (publish) → no OK response returned ❌

Looking at the source code in router.py, the _nostr_to_client() method only forwards subscription events, EOSE, and NOTICE — it does not forward OK responses from upstream relays.

This breaks any NIP-47 (NWC) client that publishes an event and waits for an OK acknowledgement. In my case, the @getalby/sdk throws a Nip47PublishError because it never receives OK, even though the payment was actually processed successfully. This is problematic, because users see an error and may retry, causing double payments.

The user in #40 resolved the same "failure to publish" issue by switching from Nostrclient to the Nostr Relay extension, which properly implements NIP-01 OK responses.

Could OK response forwarding be added to _nostr_to_client()? This would make Nostrclient compatible with NWC workflows.

[alltheseas]

As nostrclient serves as a relay proxy, nip-01 states that:

OK messages MUST be sent in response to EVENT messages received from clients

Also the CLOSED nip-01 requirement reads:

CLOSED messages MUST be sent in response to a REQ when the relay refuses to fulfill it.

It would be great if nostrclient fixes the first, or ideally both 🙏