Skip to content

[BUG] Nip-11 seems to be served on root domain, not on relay_url #381

Closed

Description

@MegalithicBTC

Feel free to close this if I'm confused.

The NIP-11 spec (https://github.com/nostr-protocol/nips/blob/master/11.md#relay-information-document )
... says that...

Relays may provide server metadata... This is made available as a JSON document over HTTP, on the same URI as the relay's websocket. )

Operative text here is "on the same URI as the relay's websocket"

So I THINK that means if my relay_url is set to...

wss://mydomain.com/v1

Then the Nip-11 data should be accessible like ....

curl -i   -H "Accept: application/nostr+json"   https://some-domain.com/v1

But so far I am finding this not to be the case with Nostream. The Nip-11 data is instead accessible on the ROOT of the domain

curl -i   -H "Accept: application/nostr+json"   https://some-domain.com

Activity

  1. theAnuragMishra commented on Apr 8, 2026

    @theAnuragMishra

    yeah should be available on /v1.

  2. sagar-h007 commented on Apr 8, 2026

    @sagar-h007
    Contributor

    @cameri I’d like to take this on.

    From what I understand, the NIP-11 spec says the relay metadata should be served on the same URI that handles the WebSocket connection, not just the root domain. 
    Right now it looks like Nostream always serves it at /, even when the relay is configured with a path like /v1, which feels inconsistent with that expectation.

    Rough plan

    • First, trace how the NIP-11 response is currently wired up and where the HTTP handler is mounted
    • Then check how the relay_url path (like /v1) is handled for WebSocket upgrades
    • Update the routing so that:
      -- Requests with Accept: application/nostr+json on the relay path return the NIP-11 document
      -- Instead of defaulting everything to the root endpoint
    • Make sure this still works properly behind reverse proxies and doesn’t break existing setups

    Goal

    Have NIP-11 served on whatever path the relay actually lives on, so something like /v1 behaves correctly instead of only /.
    If I’m misunderstanding how Nostream is intentionally handling this, happy to adjust before diving in.

  3. theAnuragMishra commented on Apr 8, 2026

    @theAnuragMishra

    @sagar-h007 I have started my work on this. It would be better if you picked another one for your ai to plan out :)

  4. sagar-h007 commented on Apr 8, 2026

    @sagar-h007
    Contributor

    @theAnuragMishra the issue isn’t even assigned, so there’s no reason to block others from picking it up.I’ve already looked into it and I’m wrapping up the changes. I’ll be opening a PR shortly.
    If you’ve already done meaningful work, feel free to share it.

  5. assigned and unassigned on Apr 8, 2026
  6. cameri commented on Apr 18, 2026

    @cameri
    Owner

    Thank you @sagar-h007 !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions