{"id":"44031f2796ada5e7a864facc2de659fbf7bc925a7b1a64af3fe39a44913bb9e0","pubkey":"2b39b4ffe62933df970e19366c22c1e092f953f83fcfed754e0f04d5a3b459f9","created_at":1781353189,"kind":30817,"tags":[["d","nip-11"],["title","NIP-11: Relay Information Document"],["summary","The JSON document a relay serves over HTTP to describe itself: its name, its contacts, the NIPs it supports, its limits and its policies."],["s","draft"],["t","nostr"],["t","nip"],["alt","A specification: NIP-11: Relay Information Document"],["client","openspecs-import"],["published_at","1651402137"],["proxy","https://github.com/nostr-protocol/nips/blob/656cecc7c0a815b6a2b218d3b5d6f078b3f4dbab/11.md","web"],["x","0592cf4eb5891f60ae4c7dc815c21bd23d18404cbe21615c7e6c26d75c8cce30"]],"content":"NIP-11\n======\n\nRelay Information Document\n--------------------------\n\n`draft` `optional` `relay`\n\nRelays may provide server metadata to clients to inform them of capabilities, administrative contacts, and various server attributes. This is made available as a JSON document over HTTP, on the same URI as the relay's websocket.\n\nWhen a relay receives an HTTP(s) request with an `Accept` header of `application/nostr+json` to a URI supporting WebSocket upgrades, they SHOULD return a document with the following structure.\n\n```json\n{\n  \"name\": <string identifying relay>,\n  \"description\": <string with detailed information>,\n  \"banner\": <a link to an image (e.g. in .jpg, or .png format)>,\n  \"icon\": <a link to an icon (e.g. in .jpg, or .png format>,\n  \"pubkey\": <administrative contact pubkey>,\n  \"self\": <relay's own pubkey>,\n  \"contact\": <administrative alternate contact>,\n  \"supported_nips\": <a list of NIP numbers supported by the relay>,\n  \"software\": <string identifying relay software URL>,\n  \"version\": <string version identifier>,\n  \"terms_of_service\": <a link to a text file describing the relay's term of service>\n}\n```\n\nAny field may be omitted, and clients MUST ignore any additional fields they do not understand. Relays MUST accept CORS requests by sending `Access-Control-Allow-Origin`, `Access-Control-Allow-Headers`, and `Access-Control-Allow-Methods` headers.\n\nField Descriptions\n------------------\n\n### Name\n\nA relay may select a `name` for use in client software. This is a string, and SHOULD be less than 30 characters to avoid client truncation.\n\n### Description\n\nDetailed plain-text information about the relay may be contained in the `description` string. It is recommended that this contain no markup, formatting or line breaks for word wrapping, and simply use double newline characters to separate paragraphs. There are no limitations on length.\n\n### Banner\n\nTo make nostr relay management more user friendly, an effort should be made by relay owners to communicate with non-dev non-technical nostr end users. A banner is a visual representation of the relay. It should aim to visually communicate the brand of the relay, complementing the text `Description`. [Here is an example banner](https://image.nostr.build/232ddf6846e8aea5a61abcd70f9222ab521f711aa545b7ab02e430248fa3a249.png) mockup as visualized in Damus iOS relay view of the Damus relay.\n\n### Icon\n\nIcon is a compact visual representation of the relay for use in UI with limited real estate such as a nostr user's relay list view. Below is an example URL pointing to an image to be used as an icon for the relay. Recommended to be squared in shape.\n\n```yaml\n{\n  \"icon\": \"https://nostr.build/i/53866b44135a27d624e99c6165cabd76ac8f72797209700acb189fce75021f47.jpg\",\n  // other fields...\n}\n```\n\n### Pubkey\n\nAn administrative contact may be listed with a `pubkey`, in the same format as Nostr events (32-byte hex for a `secp256k1` public key).  If a contact is listed, this provides clients with a recommended address to send encrypted direct messages (See [NIP-17](nostr:naddr1qvzqqqrcvypzq2eeknl7v2fnm7tsuxfkds3vrcyjl9fls070a465urcy6k3mgk0eqqrxu6ts95cnwr4j8fh)) to a system administrator. Expected uses of this address are to report abuse or illegal content, file bug reports, or request other technical assistance.\n\nRelay operators have no obligation to respond to direct messages.\n\n### Self\n\nA relay MAY maintain an identity independent from its administrator using the `self` field, which MUST be a 32-byte hex public key. This allows relays to respond to requests with events published either in advance or on demand by their own key.\n\n### Contact\n\nAn alternative contact may be listed under the `contact` field as well, with the same purpose as `pubkey`.  Use of a Nostr public key and direct message SHOULD be preferred over this. Contents of this field SHOULD be a URI, using schemes such as `mailto` or `https` to provide users with a means of contact.\n\n### Supported NIPs\n\nAs the Nostr protocol evolves, some functionality may only be available by relays that implement a specific `NIP`.  This field is an array of the integer identifiers of `NIP`s that are implemented in the relay. Examples would include `1`, for `\"NIP-01\"` and `9`, for `\"NIP-09\"`.  Client-side `NIPs` SHOULD NOT be advertised, and can be ignored by clients.\n\n### Software\n\nThe relay server implementation MAY be provided in the `software` attribute. If present, this MUST be a URL to the project's homepage.\n\n### Version\n\nThe relay MAY choose to publish its software version as a string attribute. The string format is defined by the relay implementation. It is recommended this be a version number or commit identifier.\n\n### Terms of Service\n\nThe relay owner/admin MAY choose to link to a terms of service document.\n\nExtra Fields\n------------\n\n### Server Limitations\n\nThese are limitations imposed by the relay on clients. Your client\nshould expect that requests exceed these *practical* limitations\nare rejected or fail immediately.\n\n```yaml\n{\n  \"limitation\": {\n    \"max_message_length\": 16384,\n    \"max_subscriptions\": 300,\n    \"max_limit\": 5000,\n    \"max_subid_length\": 100,\n    \"max_event_tags\": 100,\n    \"max_content_length\": 8196,\n    \"min_pow_difficulty\": 30,\n    \"auth_required\": true,\n    \"payment_required\": true,\n    \"restricted_writes\": true,\n    \"created_at_lower_limit\": 31536000,\n    \"created_at_upper_limit\": 3,\n    \"default_limit\": 500\n  },\n  // other fields...\n}\n```\n\n- `max_message_length`: the maximum number of bytes for incoming JSON that the relay\nwill attempt to decode and act upon. When you send large subscriptions, you will be\nlimited by this value. It also effectively limits the maximum size of any event. Value is\ncalculated from `[` to `]` after UTF-8 serialization (so some unicode characters\nwill cost 2-3 bytes). It is equal to the maximum size of the WebSocket message frame.\n\n- `max_subscriptions`: total number of subscriptions that may be\nactive on a single websocket connection to this relay. Authenticated clients with a (paid) relationship to the relay\nmay have higher limits.\n\n- `max_subid_length`: maximum length of subscription id as a string.\n\n- `max_limit`: the relay server will clamp each filter's `limit` value to this number.\nThis means the client won't be able to get more than this number\nof events from a single subscription filter. This clamping is typically done silently\nby the relay, but with this number, you can know that there are additional results\nif you narrow your filter's time range or other parameters.\n\n- `max_event_tags`: in any event, this is the maximum number of elements in the `tags` list.\n\n- `max_content_length`: maximum number of characters in the `content`\nfield of any event. This is a count of unicode characters. After\nserializing into JSON it may be larger (in bytes), and is still\nsubject to the `max_message_length`, if defined.\n\n- `min_pow_difficulty`: new events will require at least this difficulty of PoW,\nbased on [NIP-13](nostr:naddr1qvzqqqrcvypzq2eeknl7v2fnm7tsuxfkds3vrcyjl9fls070a465urcy6k3mgk0eqqrxu6ts95cnxapkth2), or they will be rejected by this server.\n\n- `auth_required`: this relay requires [NIP-42](nostr:naddr1qvzqqqrcvypzq2eeknl7v2fnm7tsuxfkds3vrcyjl9fls070a465urcy6k3mgk0eqqrxu6ts956ryv4r3t9) authentication\nto happen before a new connection may perform any other action.\nEven if set to False, authentication may be required for specific actions.\n\n- `payment_required`: this relay requires payment before a new connection may perform any action.\n\n- `restricted_writes`: this relay requires some kind of condition to be fulfilled to\naccept events (not necessarily, but including `payment_required` and `min_pow_difficulty`).\nThis should only be set to `true` when users are expected to know the relay policy before trying\nto write to it -- like belonging to a special pubkey-based whitelist or writing only events of\na specific niche kind or content. Normal anti-spam heuristics, for example, do not qualify.\n\n- `created_at_lower_limit`: 'created_at' lower limit\n\n- `created_at_upper_limit`: 'created_at' upper limit\n\n- `default_limit`: The maximum returned events if you send a filter without a `limit`.\n\n### Pay-to-Relay\n\nRelays that require payments may want to expose their fee schedules.\n\n```yaml\n{\n  \"payments_url\": \"https://my-relay/payments\",\n  \"fees\": {\n    \"admission\": [{ \"amount\": 1000000, \"unit\": \"msats\" }],\n    \"subscription\": [{ \"amount\": 5000000, \"unit\": \"msats\", \"period\": 2592000 }],\n    \"publication\": [{ \"kinds\": [4], \"amount\": 100, \"unit\": \"msats\" }],\n  },\n  // other fields...\n}\n```\n\n### Examples\n\n```yaml\n~> curl -H \"Accept: application/nostr+json\" https://nostr.wine | jq\n{\n  \"contact\": \"wino@nostr.wine\",\n  \"description\": \"A paid nostr relay for wine enthusiasts and everyone else.\",\n  \"fees\": {\n    \"admission\": [\n      {\n        \"amount\": 18888000,\n        \"unit\": \"msats\"\n      }\n    ]\n  },\n  \"icon\": \"https://image.nostr.build/30acdce4a81926f386622a07343228ae99fa68d012d54c538c0b2129dffe400c.png\",\n  \"limitation\": {\n    \"auth_required\": false,\n    \"created_at_lower_limit\": 94608000,\n    \"created_at_upper_limit\": 300,\n    \"max_event_tags\": 4000,\n    \"max_limit\": 1000,\n    \"max_message_length\": 524288,\n    \"max_subid_length\": 71,\n    \"max_subscriptions\": 50,\n    \"min_pow_difficulty\": 0,\n    \"payment_required\": true,\n    \"restricted_writes\": true\n  },\n  \"name\": \"nostr.wine\",\n  \"payments_url\": \"https://nostr.wine/invoices\",\n  \"pubkey\": \"4918eb332a41b71ba9a74b1dc64276cfff592e55107b93baae38af3520e55975\",\n  \"software\": \"https://nostr.wine\",\n  \"supported_nips\": [ 1, 2, 4, 9, 11, 40, 42, 50, 70, 77 ],\n  \"terms_of_service\": \"https://nostr.wine/terms\",\n  \"version\": \"0.3.3\"\n}\n\n~> curl -H \"Accept: application/nostr+json\" https://nostr.land | jq\n{\n  \"description\": \"[✨ NFDB] nostr.land family of relays (fi-01 [tiger])\",\n  \"name\": \"[✨ NFDB] nostr.land\",\n  \"pubkey\": \"52b4a076bcbbbdc3a1aefa3735816cf74993b1b8db202b01c883c58be7fad8bd\",\n  \"software\": \"NFDB\",\n  \"icon\": \"https://i.nostr.build/b3thno790aodH8lE.jpg\",\n  \"supported_nips\": [ 1, 2, 4, 8, 9, 10, 11, 13, 14, 15, 16, 17, 18, 19, 21, 22, 23, 24, 25, 27, 28, 30, 31, 32, 34, 35, 36, 37, 38, 39, 40, 42, 44, 46, 47, 48, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 64, 65, 68, 69, 71, 72, 73, 75, 78, 84, 88, 89, 90, 92, 99 ],\n  \"version\": \"1.0.0\",\n  \"limitation\": {\n    \"payment_required\": true,\n    \"max_message_length\": 65535,\n    \"max_event_tags\": 2000,\n    \"max_subscriptions\": 200,\n    \"auth_required\": false\n  },\n  \"payments_url\": \"https://nostr.land\",\n  \"fees\": {\n    \"subscription\": [\n      {\n        \"amount\": 4000000,\n        \"unit\": \"msats\",\n        \"period\": 2592000\n      }\n    ]\n  },\n  \"terms_of_service\": \"https://nostr.land/terms\"\n}\n```\n","sig":"486eca640bafb0637b3417e0d0243e7a1476e52616bcc92edf6f5e4b64ef9f648e80fd21c3d56133f385be4be13709a216aed78dc9e8a56263d99c0123d02c6a"}