upleb.uk

Public git repos — served from a NIP-34 GRASP relay at git.upleb.uk

summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--11.md251
1 files changed, 62 insertions, 189 deletions
diff --git a/11.md b/11.md
index 26b5c26..b49fa44 100644
--- a/11.md
+++ b/11.md
@@ -6,7 +6,7 @@ Relay Information Document
6 6
7`draft` `optional` `relay` 7`draft` `optional` `relay`
8 8
9Relays 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. 9Relays 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.
10 10
11When 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. 11When 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.
12 12
@@ -22,8 +22,7 @@ When a relay receives an HTTP(s) request with an `Accept` header of `application
22 "supported_nips": <a list of NIP numbers supported by the relay>, 22 "supported_nips": <a list of NIP numbers supported by the relay>,
23 "software": <string identifying relay software URL>, 23 "software": <string identifying relay software URL>,
24 "version": <string version identifier>, 24 "version": <string version identifier>,
25 "privacy_policy": <a link to a text file describing the relay's privacy policy>, 25 "terms_of_service": <a link to a text file describing the relay's term of service>
26 "terms_of_service": <a link to a text file describing the relay's term of service>,
27} 26}
28``` 27```
29 28
@@ -34,11 +33,11 @@ Field Descriptions
34 33
35### Name 34### Name
36 35
37A 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. 36A 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.
38 37
39### Description 38### Description
40 39
41Detailed 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. 40Detailed 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.
42 41
43### Banner 42### Banner
44 43
@@ -57,7 +56,7 @@ Icon is a compact visual representation of the relay for use in UI with limited
57 56
58### Pubkey 57### Pubkey
59 58
60An 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](17.md)) to a system administrator. Expected uses of this address are to report abuse or illegal content, file bug reports, or request other technical assistance. 59An 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](17.md)) to a system administrator. Expected uses of this address are to report abuse or illegal content, file bug reports, or request other technical assistance.
61 60
62Relay operators have no obligation to respond to direct messages. 61Relay operators have no obligation to respond to direct messages.
63 62
@@ -67,29 +66,23 @@ A relay MAY maintain an identity independent from its administrator using the `s
67 66
68### Contact 67### Contact
69 68
70An 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. 69An 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.
71 70
72### Supported NIPs 71### Supported NIPs
73 72
74As 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. 73As 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.
75 74
76### Software 75### Software
77 76
78The relay server implementation MAY be provided in the `software` attribute. If present, this MUST be a URL to the project's homepage. 77The relay server implementation MAY be provided in the `software` attribute. If present, this MUST be a URL to the project's homepage.
79 78
80### Version 79### Version
81 80
82The 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. 81The 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.
83
84### Privacy Policy
85
86The relay owner/admin MAY choose to link to a privacy policy document, which describes how the relay utilizes user data. Data collection, data usage, data retention, monetization of data, and third party data sharing SHOULD be included.
87 82
88### Terms of Service 83### Terms of Service
89 84
90The relay owner/admin MAY choose to link to a terms of service document. 85The 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.
91
92
93 86
94Extra Fields 87Extra Fields
95------------ 88------------
@@ -167,112 +160,6 @@ a specific niche kind or content. Normal anti-spam heuristics, for example, do n
167 160
168- `default_limit`: The maximum returned events if you send a filter without a `limit`. 161- `default_limit`: The maximum returned events if you send a filter without a `limit`.
169 162
170### Event Retention
171
172There may be a cost associated with storing data forever, so relays
173may wish to state retention times. The values stated here are defaults
174for unauthenticated users and visitors. Paid users would likely have
175other policies.
176
177Retention times are given in seconds, with `null` indicating infinity.
178If zero is provided, this means the event will not be stored at
179all, and preferably an error will be provided when those are received.
180
181```jsonc
182{
183 "retention": [
184 {"kinds": [0, 1, [5, 7], [40, 49]], "time": 3600},
185 {"kinds": [[40000, 49999]], "time": 100},
186 {"kinds": [[30000, 39999]], "count": 1000},
187 {"time": 3600, "count": 10000}
188 ],
189 // other fields...
190}
191```
192
193`retention` is a list of specifications: each will apply to either all kinds, or
194a subset of kinds. Ranges may be specified for the kind field as a tuple of inclusive
195start and end values. Events of indicated kind (or all) are then limited to a `count`
196and/or time period.
197
198It is possible to effectively blacklist Nostr-based protocols that rely on
199a specific `kind` number, by giving a retention time of zero for those `kind` values.
200While that is unfortunate, it does allow clients to discover servers that will
201support their protocol quickly via a single HTTP fetch.
202
203There is no need to specify retention times for _ephemeral events_ since they are not retained.
204
205### Content Limitations
206
207Some relays may be governed by the arbitrary laws of a nation state. This
208may limit what content can be stored in clear-text on those relays. All
209clients are encouraged to use encryption to work around this limitation.
210
211It is not possible to describe the limitations of each country's laws
212and policies which themselves are typically vague and constantly shifting.
213
214Therefore, this field allows the relay operator to indicate which
215countries' laws might end up being enforced on them, and then
216indirectly on their users' content.
217
218Users should be able to avoid relays in countries they don't like,
219and/or select relays in more favorable zones. Exposing this
220flexibility is up to the client software.
221
222```jsonc
223{
224 "relay_countries": [ "CA", "US" ],
225 // other fields...
226}
227```
228
229- `relay_countries`: a list of two-level ISO country codes (ISO 3166-1 alpha-2) whose
230 laws and policies may affect this relay. `EU` may be used for European Union countries. A `*` can be used for global relays.
231
232Remember that a relay may be hosted in a country which is not the
233country of the legal entities who own the relay, so it's very
234likely a number of countries are involved.
235
236
237### Community Preferences
238
239For public text notes at least, a relay may try to foster a
240local community. This would encourage users to follow the global
241feed on that relay, in addition to their usual individual follows.
242To support this goal, relays MAY specify some of the following values.
243
244```jsonc
245{
246 "language_tags": ["en", "en-419"],
247 "tags": ["sfw-only", "bitcoin-only", "anime"],
248 "posting_policy": "https://example.com/posting-policy.html",
249 // other fields...
250}
251```
252
253- `language_tags` is an ordered list
254 of [IETF language tags](https://en.wikipedia.org/wiki/IETF_language_tag) indicating
255 the major languages spoken on the relay. A `*` can be used for global relays.
256
257- `tags` is a list of limitations on the topics to be discussed.
258 For example `sfw-only` indicates that only "Safe For Work" content
259 is encouraged on this relay. This relies on assumptions of what the
260 "work" "community" feels "safe" talking about. In time, a common
261 set of tags may emerge that allow users to find relays that suit
262 their needs, and client software will be able to parse these tags easily.
263 The `bitcoin-only` tag indicates that any *altcoin*, *"crypto"* or *blockchain*
264 comments will be ridiculed without mercy.
265
266- `posting_policy` is a link to a human-readable page which specifies the
267 community policies for the relay. In cases where `sfw-only` is True, it's
268 important to link to a page which gets into the specifics of your posting policy.
269
270The `description` field should be used to describe your community
271goals and values, in brief. The `posting_policy` is for additional
272detail and legal terms. Use the `tags` field to signify limitations
273on content, or topics to be discussed, which could be machine
274processed by appropriate client software.
275
276### Pay-to-Relay 163### Pay-to-Relay
277 164
278Relays that require payments may want to expose their fee schedules. 165Relays that require payments may want to expose their fee schedules.
@@ -291,82 +178,68 @@ Relays that require payments may want to expose their fee schedules.
291 178
292### Examples 179### Examples
293 180
294As of 25 March 2025 the following command provided these results: 181```yaml
295 182~> curl -H "Accept: application/nostr+json" https://nostr.wine | jq
296```bash
297curl -H "Accept: application/nostr+json" https://jellyfish.land | jq
298```
299
300```json
301{ 183{
302 "name": "JellyFish", 184 "contact": "wino@nostr.wine",
303 "description": "Stay Immortal!", 185 "description": "A paid nostr relay for wine enthusiasts and everyone else.",
304 "banner": "https://image.nostr.build/7fdefea2dec1f1ec25b8ce69362566c13b2b7f13f1726c2e4584f05f64f62496.jpg",
305 "pubkey": "bf2bee5281149c7c350f5d12ae32f514c7864ff10805182f4178538c2c421007",
306 "contact": "hi@dezh.tech",
307 "software": "https://github.com/dezh-tech/immortal",
308 "supported_nips": [
309 1,
310 9,
311 11,
312 13,
313 17,
314 40,
315 42,
316 59,
317 62,
318 70
319 ],
320 "version": "immortal - 0.0.9",
321 "relay_countries": [
322 "*"
323 ],
324 "language_tags": [
325 "*"
326 ],
327 "tags": [],
328 "posting_policy": "https://jellyfish.land/tos.txt",
329 "payments_url": "https://jellyfish.land/relay",
330 "icon": "https://image.nostr.build/2547e9ec4b23589e09bc7071e0806c3d4293f76284c58ff331a64bce978aaee8.jpg",
331 "retention": [],
332 "fees": { 186 "fees": {
333 "subscription": [ 187 "admission": [
334 {
335 "amount": 3000,
336 "period": 2628003,
337 "unit": "sats"
338 },
339 {
340 "amount": 8000,
341 "period": 7884009,
342 "unit": "sats"
343 },
344 { 188 {
345 "amount": 15000, 189 "amount": 18888000,
346 "period": 15768018, 190 "unit": "msats"
347 "unit": "sats"
348 },
349 {
350 "amount": 28000,
351 "period": 31536036,
352 "unit": "sats"
353 } 191 }
354 ] 192 ]
355 }, 193 },
194 "icon": "https://image.nostr.build/30acdce4a81926f386622a07343228ae99fa68d012d54c538c0b2129dffe400c.png",
356 "limitation": { 195 "limitation": {
357 "auth_required": false, 196 "auth_required": false,
358 "max_message_length": 70000, 197 "created_at_lower_limit": 94608000,
359 "max_subid_length": 256, 198 "created_at_upper_limit": 300,
360 "max_subscriptions": 350, 199 "max_event_tags": 4000,
200 "max_limit": 1000,
201 "max_message_length": 524288,
202 "max_subid_length": 71,
203 "max_subscriptions": 50,
361 "min_pow_difficulty": 0, 204 "min_pow_difficulty": 0,
362 "payment_required": true, 205 "payment_required": true,
363 "restricted_writes": true, 206 "restricted_writes": true
207 },
208 "name": "nostr.wine",
209 "payments_url": "https://nostr.wine/invoices",
210 "pubkey": "4918eb332a41b71ba9a74b1dc64276cfff592e55107b93baae38af3520e55975",
211 "software": "https://nostr.wine",
212 "supported_nips": [ 1, 2, 4, 9, 11, 40, 42, 50, 70, 77 ],
213 "terms_of_service": "https://nostr.wine/terms",
214 "version": "0.3.3"
215}
216
217~> curl -H "Accept: application/nostr+json" https://nostr.land | jq
218{
219 "description": "[✨ NFDB] nostr.land family of relays (fi-01 [tiger])",
220 "name": "[✨ NFDB] nostr.land",
221 "pubkey": "52b4a076bcbbbdc3a1aefa3735816cf74993b1b8db202b01c883c58be7fad8bd",
222 "software": "NFDB",
223 "icon": "https://i.nostr.build/b3thno790aodH8lE.jpg",
224 "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 ],
225 "version": "1.0.0",
226 "limitation": {
227 "payment_required": true,
228 "max_message_length": 65535,
364 "max_event_tags": 2000, 229 "max_event_tags": 2000,
365 "max_content_length": 70000, 230 "max_subscriptions": 200,
366 "created_at_lower_limit": 0, 231 "auth_required": false
367 "created_at_upper_limit": 2147483647, 232 },
368 "default_limit": 500, 233 "payments_url": "https://nostr.land",
369 "max_limit": 5000 234 "fees": {
370 } 235 "subscription": [
236 {
237 "amount": 4000000,
238 "unit": "msats",
239 "period": 2592000
240 }
241 ]
242 },
243 "terms_of_service": "https://nostr.land/terms"
371} 244}
372``` 245```