René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Add NIP-11 relay metadata support","articleBody":"## Feature Request: NIP-11 Relay Metadata Support\n\nCurrently, JSS implements NIP-01 (basic relay), NIP-07 (browser extensions), and NIP-98 (HTTP Auth), but does not implement **NIP-11** (Relay Information Document).\n\n### What is NIP-11?\n\nNIP-11 allows relays to advertise their capabilities, supported NIPs, limitations, and administrative contact information to clients. When a relay receives an HTTP request with `Accept: application/nostr+json` header to the WebSocket URL, it should return a JSON document with relay metadata.\n\n### Current Behavior\n\n```bash\ncurl -H \"Accept: application/nostr+json\" https://example.com/relay\n# Returns 404\n```\n\n### Expected Behavior\n\n```bash\ncurl -H \"Accept: application/nostr+json\" https://example.com/relay\n# Returns JSON metadata:\n{\n  \"name\": \"My JSS Relay\",\n  \"description\": \"JavaScript Solid Server with Nostr relay\",\n  \"pubkey\": \"...\",\n  \"supported_nips\": [1, 7, 98],\n  \"software\": \"https://github.com/JavaScriptSolidServer/JavaScriptSolidServer\",\n  \"version\": \"0.0.76\",\n  ...\n}\n```\n\n### Why This Matters\n\n- **Discoverability**: Relay aggregators like nostr.watch, nostr.info, and NIP-66 monitors rely on NIP-11 to discover and list relays\n- **Client compatibility**: Many Nostr clients check NIP-11 to understand relay capabilities before connecting\n- **Standards compliance**: NIP-11 is the standard way relays advertise themselves in the Nostr ecosystem\n\n### Design Concerns\n\n**Note:** The NIP-11 design of using content negotiation to multiplex HTTP and WebSocket on the same URL is arguably suboptimal. It would be cleaner to serve metadata at dedicated endpoints like:\n- `/.well-known/nostr-relay.json` (follows well-known conventions)\n- `/relay.json` or `/nip11.json` (explicit and simple)\n\nHowever, for ecosystem compatibility, implementing the standard NIP-11 conneg approach is necessary. JSS could potentially serve metadata at **both** the standard conneg endpoint and a cleaner alternative endpoint.\n\n### Proposed Implementation\n\n1. Detect HTTP requests with `Accept: application/nostr+json` to `/relay` (or configured `--nostr-path`)\n2. Return JSON metadata instead of attempting WebSocket upgrade\n3. Include relevant fields:\n   - `name`, `description`, `pubkey` (admin contact)\n   - `supported_nips`: `[1, 7, 98]` (and others JSS implements)\n   - `software`: Repository URL\n   - `version`: JSS version\n   - Limitation fields: `max_message_length`, `max_subscriptions`, etc.\n4. Optionally also serve at `/.well-known/nostr-relay.json` for better DX\n\n### References\n\n- [NIP-11 Specification](https://github.com/nostr-protocol/nips/blob/master/11.md)\n- [nostr.watch](https://nostr.watch/) - Primary relay aggregator\n- [NIP-66](https://github.com/nostr-protocol/nips/blob/master/66.md) - Relay discovery (builds on NIP-11)","author":{"url":"https://github.com/melvincarvalho","@type":"Person","name":"melvincarvalho"},"datePublished":"2026-01-16T23:06:14.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/94/JavaScriptSolidServer/issues/94"}