clone

every nostr nip as a chapter of an illustrated, early-2000s printed game manual

main
nip.guide / site / nips / 11.html
11.html 25.8K
1<!DOCTYPE html>2<html lang="en">3<head>4<meta charset="utf-8">5<meta name="viewport" content="width=device-width, initial-scale=1">6<title>NIP-11 - Relay Information Document — Nostr Instruction Manual</title>7<meta name="description" content="NIP-11: the relay information document. How a relay describes its name, limits, supported NIPs, and payment rules as JSON over plain HTTP.">8<link rel="preload" href="../assets/fonts/michroma-400-latin.woff2" as="font" type="font/woff2" crossorigin>9<link rel="preload" href="../assets/fonts/exo2-var-latin.woff2" as="font" type="font/woff2" crossorigin>10<link rel="preload" href="../assets/fonts/sairacondensed-600-latin.woff2" as="font" type="font/woff2" crossorigin>11<link rel="preload" href="../assets/fonts/sairacondensed-700-latin.woff2" as="font" type="font/woff2" crossorigin>12<link rel="preload" href="../assets/fonts/sairacondensed-500-latin.woff2" as="font" type="font/woff2" crossorigin>13<link rel="preload" href="../assets/fonts/sharetechmono-400-latin.woff2" as="font" type="font/woff2" crossorigin>14<link rel="preload" href="../assets/fonts/exo2-400i-latin.woff2" as="font" type="font/woff2" crossorigin>15<link rel="icon" href="../assets/favicon.svg" type="image/svg+xml">16<link rel="stylesheet" href="../assets/manual.css">17</head>18<body>1920<svg width="0" height="0" style="position:absolute">21 <defs>22 <marker id="arr" markerWidth="9" markerHeight="9" refX="7" refY="4.5" orient="auto">23 <path d="M1,1 L8,4.5 L1,8 Z" fill="#f26a00"/>24 </marker>25 <marker id="arrb" markerWidth="9" markerHeight="9" refX="7" refY="4.5" orient="auto">26 <path d="M1,1 L8,4.5 L1,8 Z" fill="#2e5f9e"/>27 </marker>28 </defs>29</svg>3031<div class="page">32 <span class="staple s1"></span><span class="staple s2"></span>3334 <header class="band">35 <a class="logo" href="../index.html">NOSTR<b>▸</b>PROTOCOL MANUAL</a>36 <span class="booklet-note">Chapter 11 - Relay Ops</span>37 </header>38 <nav class="tabs">39 <a href="../index.html">Contents</a>40 <a href="#overview" class="on">Overview</a>41 <a href="#spec">Spec</a>42 <a href="#examples">Examples</a>43 <a href="#history">History</a>44 </nav>4546 <div class="chapter">47 <div class="nipno" data-n="11">11</div>48 <div class="titles">49 <div class="kicker">Nostr Implementation Possibility - Hex № 11</div>50 <h1>Relay Information Document</h1>51 <p class="sub">A small JSON document a relay hands out over plain HTTP: its name, its limits, the NIPs it supports, and how to pay it.</p>52 </div>53 </div>5455 <main class="spread">56 <div class="main">5758 <h2 class="bar" id="overview"><span class="num">1</span> Overview</h2>59 <p>A client needs to know things about a relay before it trusts it. Does the relay accept large events? Does it require payment? Which NIPs does it support? This NIP answers those questions.</p>60 <p>A relay may publish a <strong>relay information document</strong>. This is a JSON object that describes the relay. Clients fetch it with a plain HTTP request, at the exact same URI they use for the relay's WebSocket connection.</p>61 <p>The document is optional field by field. A relay fills in only what it wants to share. A client must ignore any field it does not recognize, so the format can grow without breaking old clients.</p>6263 <div class="box hint">64 <span class="tag">Hint!</span>65 <p>Think of this document as a relay's box art and spec sheet. Read it before you connect, so your client can set expectations for message size, payment, and authentication ahead of time.</p>66 </div>6768 <figure class="diagram">69 <div class="frame">70 <svg viewBox="0 0 560 170" role="img" aria-label="Client sends an HTTP GET request with an Accept header for application/nostr+json; relay responds with a JSON information document">71 <rect class="d-actor" x="20" y="60" width="120" height="50" rx="8"/>72 <text class="d-actor-label" x="80" y="89" text-anchor="middle">Client</text>73 <rect class="d-actor" x="420" y="60" width="120" height="50" rx="8"/>74 <text class="d-actor-label" x="480" y="89" text-anchor="middle">Relay</text>75 <path class="d-msg d-flow" d="M142,72 C240,50 320,50 418,72"/>76 <text class="d-label" x="280" y="42" text-anchor="middle">GET / — Accept: application/nostr+json</text>77 <path class="d-msg blue d-flow" d="M418,98 C320,120 240,120 142,98"/>78 <text class="d-label" x="280" y="140" text-anchor="middle">200 OK — JSON information document</text>79 <circle r="4" fill="#f26a00">80 <animateMotion dur="2.6s" repeatCount="indefinite" path="M142,72 C240,50 320,50 418,72"/>81 </circle>82 <circle r="4" fill="#2e5f9e">83 <animateMotion dur="2.6s" begin="1.3s" repeatCount="indefinite" path="M418,98 C320,120 240,120 142,98"/>84 </circle>85 </svg>86 </div>87 <figcaption>Fig. 11-1 — <b>The fetch flow.</b> One plain HTTP request and response. No WebSocket upgrade, no signed event.</figcaption>88 </figure>8990 <h2 class="bar" id="spec"><span class="num">2</span> Fetching the Document</h2>91 <p>A relay exposes one WebSocket URI, as defined in <a href="01.html">NIP-01</a>. The information document lives at that same URI. A client asks for it with an ordinary HTTP or HTTPS request, not a WebSocket upgrade.</p>92 <p>The client sets one required header:</p>93 <div class="tscroll"><table class="ref">94 <caption>Request requirement</caption>95 <tr><th>Header</th><th>Value</th><th>Purpose</th></tr>96 <tr><td class="btn">Accept</td><td><code>application/nostr+json</code></td><td>Tells the relay this is a request for the information document, not a WebSocket upgrade.</td></tr>97 </table></div>98 <p>When a relay receives a matching request, it should return the JSON document below.</p>99100 <div class="crt">101 <div class="titlebar">Wire format - relay information document</div>102<pre>{103 <span class="k">"name"</span>: <span class="c">&lt;string identifying the relay&gt;</span>104 <span class="k">"description"</span>: <span class="c">&lt;string with detailed information&gt;</span>105 <span class="k">"banner"</span>: <span class="c">&lt;link to a banner image, .jpg or .png&gt;</span>106 <span class="k">"icon"</span>: <span class="c">&lt;link to a square icon image&gt;</span>107 <span class="k">"pubkey"</span>: <span class="c">&lt;administrative contact pubkey&gt;</span>108 <span class="k">"self"</span>: <span class="c">&lt;relay's own pubkey&gt;</span>109 <span class="k">"contact"</span>: <span class="c">&lt;administrative alternate contact&gt;</span>110 <span class="k">"supported_nips"</span>: <span class="c">&lt;list of NIP numbers supported by the relay&gt;</span>111 <span class="k">"software"</span>: <span class="c">&lt;string identifying relay software, a URL&gt;</span>112 <span class="k">"version"</span>: <span class="c">&lt;string version identifier&gt;</span>113 <span class="k">"terms_of_service"</span>: <span class="c">&lt;link to a terms of service document&gt;</span>114}</pre>115 </div>116117 <p>Any field may be omitted. A client must ignore any field in the response it does not understand. This keeps old clients working when new fields are added later.</p>118119 <div class="box warn">120 <span class="tag">Warning!</span>121 <p>A relay must accept CORS requests. It must send the <code>Access-Control-Allow-Origin</code>, <code>Access-Control-Allow-Headers</code>, and <code>Access-Control-Allow-Methods</code> headers. Without these, a web-based client cannot fetch the document from a browser.</p>122 </div>123124 <h2 class="bar" id="fields"><span class="num">3</span> Top-Level Fields</h2>125 <p>Ten fields describe the relay itself, its operator, and its software. All are optional strings, URLs, or a pubkey, unless noted otherwise.</p>126 <div class="tscroll"><table class="ref">127 <caption>Top-level field reference</caption>128 <tr><th>Field</th><th>Type</th><th>Rule</th></tr>129 <tr><td class="btn">name</td><td>string</td><td>Short relay name for client UI. Keep it under 30 characters, or a client may truncate it.</td></tr>130 <tr><td class="btn">description</td><td>string</td><td>Plain-text detail about the relay. Use no markup and no line-wrap formatting. Separate paragraphs with a blank line. No length limit.</td></tr>131 <tr><td class="btn">banner</td><td>URL</td><td>Link to a banner image, in <code>.jpg</code> or <code>.png</code> format. Shows the relay's brand to non-technical users.</td></tr>132 <tr><td class="btn">icon</td><td>URL</td><td>Link to a compact icon image. Used in tight UI spaces, such as a relay-list view. A square image is recommended.</td></tr>133 <tr><td class="btn">pubkey</td><td>hex pubkey, 64 chars</td><td>Administrative contact. A client may send this pubkey an encrypted direct message (<a href="17.html">NIP-17</a>) to report abuse, file a bug, or ask for help. The operator has no obligation to reply.</td></tr>134 <tr><td class="btn">self</td><td>hex pubkey, 64 chars</td><td>The relay's own identity, kept separate from its administrator. The relay may respond using events published under this key.</td></tr>135 <tr><td class="btn">contact</td><td>string</td><td>Alternate contact, for the same purpose as <code>pubkey</code>. Should be a URI, such as a <code>mailto:</code> or <code>https:</code> link. A Nostr DM to <code>pubkey</code> is the preferred method.</td></tr>136 <tr><td class="btn">supported_nips</td><td>array of integers</td><td>NIP numbers the relay implements, for example <code>[1, 9, 11]</code>. Do not advertise NIPs that are client-side only. Clients may ignore this field.</td></tr>137 <tr><td class="btn">software</td><td>URL</td><td>Link to the relay software's project homepage.</td></tr>138 <tr><td class="btn">version</td><td>string</td><td>Software version or commit identifier. The format is defined by the relay implementation.</td></tr>139 <tr><td class="btn">terms_of_service</td><td>URL</td><td>Link to a terms-of-service document.</td></tr>140 </table></div>141142 <h3>pubkey vs. self vs. contact</h3>143 <p>These three fields look similar but answer different questions. <code>pubkey</code> identifies a human administrator to message. <code>self</code> identifies the relay software acting as its own Nostr identity. <code>contact</code> is a fallback address, such as an email link, for when a Nostr DM is not practical.</p>144145 <h2 class="bar" id="limitation"><span class="num">4</span> Server Limitations</h2>146 <p>The <code>limitation</code> object lists practical limits the relay enforces. A client should expect a request that exceeds these limits to be rejected or to fail immediately.</p>147148 <div class="tscroll"><table class="ref">149 <caption><code>limitation</code> object - sub-fields</caption>150 <tr><th>Field</th><th>Type</th><th>Rule</th></tr>151 <tr><td class="btn">max_message_length</td><td>integer</td><td>Max bytes of incoming JSON the relay will decode and act on. Measured on the UTF-8 serialized string, from <code>[</code> to <code>]</code>. This is also the WebSocket frame size limit, and it caps the maximum event size.</td></tr>152 <tr><td class="btn">max_subscriptions</td><td>integer</td><td>Max number of active subscriptions on one connection. An authenticated client with a paid relationship to the relay may get a higher limit.</td></tr>153 <tr><td class="btn">max_limit</td><td>integer</td><td>The relay clamps every filter's <code>limit</code> value to this number, usually silently. Narrow the filter's time range to check for more results beyond it.</td></tr>154 <tr><td class="btn">max_subid_length</td><td>integer</td><td>Max length of a subscription ID string.</td></tr>155 <tr><td class="btn">max_event_tags</td><td>integer</td><td>Max number of elements in an event's <code>tags</code> array.</td></tr>156 <tr><td class="btn">max_content_length</td><td>integer</td><td>Max Unicode characters in an event's <code>content</code> field. After JSON encoding the byte count may be larger, and <code>max_message_length</code> still applies.</td></tr>157 <tr><td class="btn">min_pow_difficulty</td><td>integer</td><td>Minimum proof-of-work difficulty (<a href="13.html">NIP-13</a>) required on new events. The relay rejects events below this difficulty.</td></tr>158 <tr><td class="btn">auth_required</td><td>boolean</td><td>The relay requires <a href="42.html">NIP-42</a> authentication before a new connection may do anything else. Even when <code>false</code>, specific actions may still require it.</td></tr>159 <tr><td class="btn">payment_required</td><td>boolean</td><td>The relay requires payment before a new connection may perform any action.</td></tr>160 <tr><td class="btn">restricted_writes</td><td>boolean</td><td>The relay requires some condition before it accepts events — for example a pubkey allow-list, or a specific kind. Set this only when clients are expected to know the policy in advance. Ordinary anti-spam heuristics do not qualify.</td></tr>161 <tr><td class="btn">created_at_lower_limit</td><td>integer</td><td>Lower bound accepted for an event's <code>created_at</code> timestamp.</td></tr>162 <tr><td class="btn">created_at_upper_limit</td><td>integer</td><td>Upper bound accepted for an event's <code>created_at</code> timestamp.</td></tr>163 <tr><td class="btn">default_limit</td><td>integer</td><td>Number of events the relay returns for a filter sent without a <code>limit</code> attribute.</td></tr>164 </table></div>165166 <div class="box tech">167 <span class="tag">Tech Note</span>168 <p>Earlier drafts of this NIP also defined <code>retention</code>, <code>relay_countries</code>, <code>language_tags</code>, a content-classification <code>tags</code> field, and <code>posting_policy</code>. A 2026-02-14 revision, titled in the source history "partially remove bloat that no one cares about," dropped all five from the specification. The current <code>11.md</code> does not define them, so this manual does not document them as active fields. See §7 Version History.</p>169 </div>170171 <h2 class="bar" id="payments"><span class="num">5</span> Pay-to-Relay</h2>172 <p>A relay that requires payment may publish its fee schedule so clients can display it.</p>173 <div class="tscroll"><table class="ref">174 <caption>Pay-to-relay fields</caption>175 <tr><th>Field</th><th>Type</th><th>Rule</th></tr>176 <tr><td class="btn">payments_url</td><td>URL</td><td>Page where a user can pay the relay.</td></tr>177 <tr><td class="btn">fees.admission</td><td>array of <code>{amount, unit}</code></td><td>One-time cost to join the relay.</td></tr>178 <tr><td class="btn">fees.subscription</td><td>array of <code>{amount, unit, period}</code></td><td>Recurring cost. <code>period</code> is the billing interval, in seconds.</td></tr>179 <tr><td class="btn">fees.publication</td><td>array of <code>{kinds, amount, unit}</code></td><td>Cost to publish specific event kinds. <code>kinds</code> lists the kind numbers the fee applies to.</td></tr>180 </table></div>181 <div class="crt">182 <div class="titlebar">Example - fees object</div>183<pre>{184 <span class="k">"payments_url"</span>: <span class="s">"https://relay.example.com/payments"</span>,185 <span class="k">"fees"</span>: {186 <span class="k">"admission"</span>: [{ <span class="k">"amount"</span>: 1000000, <span class="k">"unit"</span>: <span class="s">"msats"</span> }],187 <span class="k">"subscription"</span>: [{ <span class="k">"amount"</span>: 5000000, <span class="k">"unit"</span>: <span class="s">"msats"</span>, <span class="k">"period"</span>: 2592000 }],188 <span class="k">"publication"</span>: [{ <span class="k">"kinds"</span>: [4], <span class="k">"amount"</span>: 100, <span class="k">"unit"</span>: <span class="s">"msats"</span> }]189 }190}</pre>191 </div>192193 <figure class="diagram">194 <div class="frame">195 <svg viewBox="0 0 580 220" role="img" aria-label="The same relay URI serves two protocols: a WebSocket upgrade for NIP-01 event flow, and a plain HTTP request with an Accept header for the NIP-11 information document">196 <rect class="d-actor" x="15" y="86" width="110" height="48" rx="8"/>197 <text class="d-actor-label" x="70" y="115" text-anchor="middle">Client</text>198 <rect class="d-actor" x="215" y="86" width="150" height="48" rx="8"/>199 <text class="d-actor-label" x="290" y="110" text-anchor="middle">Relay</text>200 <text class="d-note" x="290" y="126" text-anchor="middle">one URI, wss://relay…</text>201 <rect class="d-actor" x="440" y="10" width="130" height="48" rx="8"/>202 <text class="d-actor-label" x="505" y="34" text-anchor="middle">WebSocket</text>203 <text class="d-note" x="505" y="50" text-anchor="middle">NIP-01 event flow</text>204 <rect class="d-actor" x="440" y="162" width="130" height="48" rx="8"/>205 <text class="d-actor-label" x="505" y="186" text-anchor="middle">Info document</text>206 <text class="d-note" x="505" y="202" text-anchor="middle">this NIP, NIP-11</text>207 <path class="d-msg d-flow" d="M127,100 C170,90 190,90 213,96"/>208 <path class="d-msg blue d-flow" d="M127,120 C170,130 190,130 213,124"/>209 <path class="d-msg d-flow" d="M367,98 C400,70 415,50 438,36"/>210 <text class="d-label" x="410" y="66" text-anchor="middle">Upgrade: websocket</text>211 <path class="d-msg blue d-flow" d="M367,122 C400,150 415,170 438,184"/>212 <text class="d-label" x="410" y="158" text-anchor="middle">Accept: nostr+json</text>213 </svg>214 </div>215 <figcaption>Fig. 11-2 — <b>One URI, two protocols.</b> The relay tells the two requests apart by header, not by path.</figcaption>216 </figure>217218 <h2 class="bar" id="examples"><span class="num">6</span> Worked Example</h2>219 <p>The transcript below shows a full round trip: the HTTP request with the required header, and the JSON response. Orange lines go to the relay. Blue lines come from the relay.</p>220 <div class="crt">221 <div class="titlebar">HTTP session - https://relay.example.com</div>222<pre><span class="c">-- Client requests the information document --</span>223<span class="send">→ GET / HTTP/1.1</span>224<span class="send">→ Host: relay.example.com</span>225<span class="send">→ Accept: application/nostr+json</span>226227<span class="c">-- Relay responds --</span>228<span class="recv">← HTTP/1.1 200 OK</span>229<span class="recv">← Content-Type: application/nostr+json</span>230<span class="recv">← Access-Control-Allow-Origin: *</span>231<span class="recv">← Access-Control-Allow-Headers: *</span>232<span class="recv">← Access-Control-Allow-Methods: GET</span>233<span class="recv">←</span>234<span class="recv">← {235 "name": "wine relay",236 "description": "A paid nostr relay for wine enthusiasts and everyone else.",237 "pubkey": "4918eb332a41b71ba9a74b1dc64276cfff592e55107b93baae38af3520e5597",238 "contact": "wino@relay.example.com",239 "supported_nips": [1, 2, 4, 9, 11, 40, 42, 50, 70, 77],240 "software": "https://git.example.com/relay-software",241 "version": "0.3.3",242 "terms_of_service": "https://relay.example.com/terms",243 "limitation": {244 "max_message_length": 524288,245 "max_subscriptions": 50,246 "max_limit": 1000,247 "max_subid_length": 71,248 "max_event_tags": 4000,249 "auth_required": false,250 "payment_required": true,251 "restricted_writes": true,252 "created_at_lower_limit": 94608000,253 "created_at_upper_limit": 300254 },255 "payments_url": "https://relay.example.com/invoices",256 "fees": {257 "admission": [{ "amount": 18888000, "unit": "msats" }]258 }259 }</span></pre>260 </div>261 <p>A relay with a smaller feature set may return far fewer fields. This response is still valid:</p>262 <div class="crt">263 <div class="titlebar">Example - minimal information document</div>264<pre>{265 <span class="k">"name"</span>: <span class="s">"a small free relay"</span>,266 <span class="k">"pubkey"</span>: <span class="s">"52b4a076bcbbbdc3a1aefa3735816cf74993b1b8db202b01c883c58be7fad8b"</span>,267 <span class="k">"software"</span>: <span class="s">"NFDB"</span>,268 <span class="k">"supported_nips"</span>: [1, 2, 9, 11, 40],269 <span class="k">"version"</span>: <span class="s">"1.0.0"</span>,270 <span class="k">"limitation"</span>: { <span class="k">"payment_required"</span>: false, <span class="k">"auth_required"</span>: false }271}</pre>272 </div>273274 <h2 class="bar" id="history"><span class="num">7</span> Version History</h2>275 <p>Notable changes to NIP-11, newest first:</p>276 <ul class="patchnotes">277 <li><span class="ver">2026</span><span class="when">2026-06-13</span>Reformatted every code fence in the document from <code>jsonc</code> to <code>yaml</code>, repo-wide.</li>278 <li><span class="ver">2026</span><span class="when">2026-02-14</span>Removed <code>retention</code>, <code>relay_countries</code>, <code>language_tags</code>, the content-classification <code>tags</code> field, and <code>posting_policy</code> as unused "bloat."</li>279 <li><span class="ver">2025</span><span class="when">2025-11-17</span>Added the <code>self</code> field, letting a relay maintain an identity independent from its administrator.</li>280 <li><span class="ver">2025</span><span class="when">2025-04-21</span>Added <code>terms_of_service</code>, alongside a privacy-policy field later removed in the 2026-02-14 cleanup.</li>281 <li><span class="ver">2025</span><span class="when">2025-04-13</span>Removed an older max-filters mechanism; added <code>max_limit</code> and <code>default_limit</code>, and refreshed the worked examples.</li>282 <li><span class="ver">2024</span><span class="when">2024-11-04</span>Added the <code>banner</code> field, and renamed the earlier <code>image</code> field to <code>icon</code>.</li>283 <li><span class="ver">2023</span><span class="when">2023-11-18</span>Added <code>restricted_writes</code> to <code>limitation</code>, and clarified it excludes ordinary anti-spam heuristics.</li>284 <li class="minor"><span class="ver">2023</span><span class="when">2023-08-20</span>Removed a <code>min_prefix</code> mention after prefix search was dropped from <a href="01.html">NIP-01</a>; added <code>created_at</code> lower/upper limits to <code>limitation</code>.</li>285 <li><span class="ver">2023</span><span class="when">2023-03-18</span>nostr.wine proposed the extensions that became <code>limitation</code> and <code>fees</code>: server limits and a pay-to-relay fee schedule.</li>286 <li class="minor"><span class="ver">2022</span><span class="when">2022-11-23</span>Made CORS support mandatory: relays must answer CORS preflight requests.</li>287 <li><span class="ver">Origin</span><span class="when">2022-05-01</span>fiatjaf published the first version in the newly migrated <code>nostr-protocol/nips</code> repository.</li>288 </ul>289290 <div class="credits">291 <h3 class="cardhead">Original Proposal - Credits</h3>292 <table>293 <tr><td>Author</td><td>fiatjaf</td></tr>294 <tr><td>First commit</td><td>2022-05-01 — “migrate nips from main nostr repo.”</td></tr>295 <tr><td>Status</td><td><span class="chip draft">draft</span> <span class="chip">optional</span> — a relay may implement it; nothing in <a href="01.html">NIP-01</a> requires it</td></tr>296 <tr><td>Source</td><td><a href="https://github.com/nostr-protocol/nips/blob/master/11.md">11.md on GitHub</a> - <a href="https://github.com/nostr-protocol/nips/commits/master/11.md">full change history</a></td></tr>297 </table>298 </div>299300 <h2 class="bar"><span class="num">8</span> See Also</h2>301 <ul>302 <li><a href="01.html">NIP-01</a> — defines the WebSocket URI this document is fetched from, and the base event/filter protocol it describes.</li>303 <li><a href="13.html">NIP-13</a> — proof of work; source of the difficulty number in <code>min_pow_difficulty</code>.</li>304 <li><a href="17.html">NIP-17</a> — private direct messages; how a client reaches the relay operator at its <code>pubkey</code> field.</li>305 <li><a href="42.html">NIP-42</a> — client authentication; what <code>auth_required</code> is asking for.</li>306 <li><a href="65.html">NIP-65</a> — relay list metadata; how a user tells others which relays to use, a separate concern from what one relay reports about itself.</li>307 <li><a href="86.html">NIP-86</a> — relay management API; a read/write control channel, compared to this read-only information document.</li>308 </ul>309 </div>310311 <aside>312 <div class="cartridge">313 <div class="inner">314 <h3 class="cardhead">Spec Card</h3>315 <div class="lights"><span class="led on"></span><span class="led on"></span><span class="led on"></span></div>316 <dl>317 <dt>Status</dt><dd><span class="chip draft">draft</span><span class="chip">optional</span></dd>318 <dt>Defines</dt><dd>relay info document - Accept: application/nostr+json</dd>319 <dt>Kind(s)</dt><dd>none - HTTP document, not an event</dd>320 <dt>Requires</dt><dd><a href="01.html">NIP-01</a> - same URI as the WebSocket</dd>321 <dt>Transport</dt><dd>HTTP(S) GET - JSON object</dd>322 <dt>Crypto</dt><dd>secp256k1 pubkey fields, optional</dd>323 <dt>First commit</dt><dd>2022-05-01</dd>324 <dt>Last updated</dt><dd>2026-06-13</dd>325 </dl>326 </div>327 </div>328 </aside>329 </main>330331 <nav class="navbtns">332 <a href="10.html">◀ NIP-10: Text Notes and Threads</a>333 <a href="12.html">NIP-12: Generic Tag Queries ▶</a>334 </nav>335336 <footer class="pagefoot">337 <a href="../index.html">Nostr Protocol Manual</a>338 <span class="pageno">NIP 11 / F4</span>339 </footer>340</div>341342<script src="../assets/webmcp.js" defer></script>343</body>344</html>