fix(router): NIP-11 being served only on root instead of relay path

[sagar-h007]

Description

This PR fixes an issue where the NIP-11 relay information document was only being served at the root (/) of the domain, even when the relay itself was configured on a different path (for example /v1).

Specifically, this PR introduces the following changes:

• Adds a top-level request interceptor that checks for Accept: application/nostr+json.
• Routes matching requests to the NIP-11 handler regardless of the path.
• Updates the NIP-11 handler to use flexible header matching (includes instead of strict equality).
• Normalizes header checks to avoid issues with compound or case variations.

Related Issue

#381

Motivation and Context

According to the NIP-11 spec, the relay metadata should be available on the same URI that handles the WebSocket connection. In practice, this means a relay at wss://domain.com/v1 should expose its NIP-11 document at https://domain.com/v1, not just at https://domain.com/.

Previously, WebSocket upgrades in Nostream were effectively path-agnostic, while Express routes were explicitly bound to /. As a result, requests like GET /v1 with Accept: application/nostr+json returned a 404 instead of the expected NIP-11 response. This change keeps the fix minimal while aligning behavior more closely with the NIP-11 spec and how relays are typically exposed behind proxies or path prefixes.

How Has This Been Tested?

Tested locally by verifying that NIP-11 is now correctly served on the relay path (e.g., /v1). Verified that the existing behavior on the root (/) remains unchanged and that the updated handler successfully processes requests from real-world clients sending compound Accept headers.

Test run:

curl -H "Accept: application/nostr+json" http://localhost:8008/v1

Types of changes

• Non-functional change (docs, style, minor refactor)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my code changes.
• All new and existing tests passed.

[cameri]

Can you elaborate a bit why we can't use a strict equality check here?

[sagar-h007]

@cameri The Accept header isn’t always a single value, it often contains multiple types (sometimes with q-values), like:
application/nostr+json, application/json;q=0.9, /;q=0.8
With a strict equality check, this would fail even though the client clearly supports application/nostr+json.
Using .includes() avoids that issue and works better with how content negotiation is actually used in practice.

[sagar-h007]

@theAnuragMishra I was offline/sleeping , so let’s not pretend this was some real-time back-and-forth.

If you have a technical concern, point it out clearly and we can discuss it. Random shots about “AI hacks” don’t really help move the PR forward.

If something in the approach is wrong, explain what and why. Otherwise this just adds noise instead of anything useful.

[cameri]

@sagar-h007 Do not engage with him.
Let's stay focused.

Can you check if the accepts package is installed and available? If so it's better to use it to check if a type is present in the accept header. The existing check and yours are still both naive because a value of q=0 would mean anything but that.
If the accepts package is not installed we might need to add it as a production dependency. If express is available, I think it's already included.

[sagar-h007]

Good catch,The current check is still naive and ignores q-values (like q=0). I’ll switch to using accepts for proper content negotiation, assuming it’s already available via Express. If not, I’ll add it.

[cameri]

Do you mind rebasing your PR on top of the main branch?

[cameri]

@sagar-h007 Please fix the linting issues.