mirror of
https://github.com/nostr-protocol/nips.git
synced 2025-12-08 16:18:50 +00:00
Compare commits
1 Commits
2a33cceff6
...
nip11clean
| Author | SHA1 | Date | |
|---|---|---|---|
|
cc38176820 |
254
11.md
254
11.md
@@ -6,7 +6,7 @@ Relay Information Document
|
||||
|
||||
`draft` `optional`
|
||||
|
||||
Relays 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.
|
||||
Relays 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.
|
||||
|
||||
When 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.
|
||||
|
||||
@@ -20,11 +20,9 @@ When a relay receives an HTTP(s) request with an `Accept` header of `application
|
||||
"contact": <administrative alternate contact>,
|
||||
"supported_nips": <a list of NIP numbers supported by the relay>,
|
||||
"software": <string identifying relay software URL>,
|
||||
"version": <string version identifier>
|
||||
"privacy_policy": <a link to a text file describing the relay's privacy policy>,
|
||||
"version": <string version identifier>,
|
||||
"terms_of_service": <a link to a text file describing the relay's term of service>,
|
||||
|
||||
|
||||
}
|
||||
```
|
||||
|
||||
@@ -35,11 +33,11 @@ Field Descriptions
|
||||
|
||||
### Name
|
||||
|
||||
A 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.
|
||||
A 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.
|
||||
|
||||
### Description
|
||||
|
||||
Detailed 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.
|
||||
Detailed 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.
|
||||
|
||||
### Banner
|
||||
|
||||
@@ -58,35 +56,29 @@ Icon is a compact visual representation of the relay for use in UI with limited
|
||||
|
||||
### Pubkey
|
||||
|
||||
An 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.
|
||||
An 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.
|
||||
|
||||
Relay operators have no obligation to respond to direct messages.
|
||||
|
||||
### Contact
|
||||
|
||||
An 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.
|
||||
An 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.
|
||||
|
||||
### Supported NIPs
|
||||
|
||||
As 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.
|
||||
As 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.
|
||||
|
||||
### Software
|
||||
|
||||
The relay server implementation MAY be provided in the `software` attribute. If present, this MUST be a URL to the project's homepage.
|
||||
The relay server implementation MAY be provided in the `software` attribute. If present, this MUST be a URL to the project's homepage.
|
||||
|
||||
### Version
|
||||
|
||||
The 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.
|
||||
|
||||
### Privacy Policy
|
||||
|
||||
The 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.
|
||||
The 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.
|
||||
|
||||
### Terms of Service
|
||||
|
||||
The relay owner/admin MAY choose to link to a terms of service document.
|
||||
|
||||
|
||||
The 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.
|
||||
|
||||
Extra Fields
|
||||
------------
|
||||
@@ -162,113 +154,7 @@ a specific niche kind or content. Normal anti-spam heuristics, for example, do n
|
||||
|
||||
- `created_at_upper_limit`: 'created_at' upper limit
|
||||
|
||||
- `default_limit`: The maximum returned events if you send a filter with the limit set to 0.
|
||||
|
||||
### Event Retention
|
||||
|
||||
There may be a cost associated with storing data forever, so relays
|
||||
may wish to state retention times. The values stated here are defaults
|
||||
for unauthenticated users and visitors. Paid users would likely have
|
||||
other policies.
|
||||
|
||||
Retention times are given in seconds, with `null` indicating infinity.
|
||||
If zero is provided, this means the event will not be stored at
|
||||
all, and preferably an error will be provided when those are received.
|
||||
|
||||
```jsonc
|
||||
{
|
||||
"retention": [
|
||||
{"kinds": [0, 1, [5, 7], [40, 49]], "time": 3600},
|
||||
{"kinds": [[40000, 49999]], "time": 100},
|
||||
{"kinds": [[30000, 39999]], "count": 1000},
|
||||
{"time": 3600, "count": 10000}
|
||||
],
|
||||
// other fields...
|
||||
}
|
||||
```
|
||||
|
||||
`retention` is a list of specifications: each will apply to either all kinds, or
|
||||
a subset of kinds. Ranges may be specified for the kind field as a tuple of inclusive
|
||||
start and end values. Events of indicated kind (or all) are then limited to a `count`
|
||||
and/or time period.
|
||||
|
||||
It is possible to effectively blacklist Nostr-based protocols that rely on
|
||||
a specific `kind` number, by giving a retention time of zero for those `kind` values.
|
||||
While that is unfortunate, it does allow clients to discover servers that will
|
||||
support their protocol quickly via a single HTTP fetch.
|
||||
|
||||
There is no need to specify retention times for _ephemeral events_ since they are not retained.
|
||||
|
||||
### Content Limitations
|
||||
|
||||
Some relays may be governed by the arbitrary laws of a nation state. This
|
||||
may limit what content can be stored in clear-text on those relays. All
|
||||
clients are encouraged to use encryption to work around this limitation.
|
||||
|
||||
It is not possible to describe the limitations of each country's laws
|
||||
and policies which themselves are typically vague and constantly shifting.
|
||||
|
||||
Therefore, this field allows the relay operator to indicate which
|
||||
countries' laws might end up being enforced on them, and then
|
||||
indirectly on their users' content.
|
||||
|
||||
Users should be able to avoid relays in countries they don't like,
|
||||
and/or select relays in more favorable zones. Exposing this
|
||||
flexibility is up to the client software.
|
||||
|
||||
```jsonc
|
||||
{
|
||||
"relay_countries": [ "CA", "US" ],
|
||||
// other fields...
|
||||
}
|
||||
```
|
||||
|
||||
- `relay_countries`: a list of two-level ISO country codes (ISO 3166-1 alpha-2) whose
|
||||
laws and policies may affect this relay. `EU` may be used for European Union countries. A `*` can be used for global relays.
|
||||
|
||||
Remember that a relay may be hosted in a country which is not the
|
||||
country of the legal entities who own the relay, so it's very
|
||||
likely a number of countries are involved.
|
||||
|
||||
|
||||
### Community Preferences
|
||||
|
||||
For public text notes at least, a relay may try to foster a
|
||||
local community. This would encourage users to follow the global
|
||||
feed on that relay, in addition to their usual individual follows.
|
||||
To support this goal, relays MAY specify some of the following values.
|
||||
|
||||
```jsonc
|
||||
{
|
||||
"language_tags": ["en", "en-419"],
|
||||
"tags": ["sfw-only", "bitcoin-only", "anime"],
|
||||
"posting_policy": "https://example.com/posting-policy.html",
|
||||
// other fields...
|
||||
}
|
||||
```
|
||||
|
||||
- `language_tags` is an ordered list
|
||||
of [IETF language tags](https://en.wikipedia.org/wiki/IETF_language_tag) indicating
|
||||
the major languages spoken on the relay. A `*` can be used for global relays.
|
||||
|
||||
- `tags` is a list of limitations on the topics to be discussed.
|
||||
For example `sfw-only` indicates that only "Safe For Work" content
|
||||
is encouraged on this relay. This relies on assumptions of what the
|
||||
"work" "community" feels "safe" talking about. In time, a common
|
||||
set of tags may emerge that allow users to find relays that suit
|
||||
their needs, and client software will be able to parse these tags easily.
|
||||
The `bitcoin-only` tag indicates that any *altcoin*, *"crypto"* or *blockchain*
|
||||
comments will be ridiculed without mercy.
|
||||
|
||||
- `posting_policy` is a link to a human-readable page which specifies the
|
||||
community policies for the relay. In cases where `sfw-only` is True, it's
|
||||
important to link to a page which gets into the specifics of your posting policy.
|
||||
|
||||
The `description` field should be used to describe your community
|
||||
goals and values, in brief. The `posting_policy` is for additional
|
||||
detail and legal terms. Use the `tags` field to signify limitations
|
||||
on content, or topics to be discussed, which could be machine
|
||||
processed by appropriate client software.
|
||||
- `default_limit`: The maximum returned events if you send a filter without a limit.
|
||||
|
||||
### Pay-to-Relay
|
||||
|
||||
@@ -288,82 +174,68 @@ Relays that require payments may want to expose their fee schedules.
|
||||
|
||||
### Examples
|
||||
|
||||
As of 25 March 2025 the following command provided these results:
|
||||
|
||||
```bash
|
||||
curl -H "Accept: application/nostr+json" https://jellyfish.land | jq
|
||||
```
|
||||
|
||||
```json
|
||||
```yaml
|
||||
~> curl -H "Accept: application/nostr+json" https://nostr.wine | jq
|
||||
{
|
||||
"name": "JellyFish",
|
||||
"description": "Stay Immortal!",
|
||||
"banner": "https://image.nostr.build/7fdefea2dec1f1ec25b8ce69362566c13b2b7f13f1726c2e4584f05f64f62496.jpg",
|
||||
"pubkey": "bf2bee5281149c7c350f5d12ae32f514c7864ff10805182f4178538c2c421007",
|
||||
"contact": "hi@dezh.tech",
|
||||
"software": "https://github.com/dezh-tech/immortal",
|
||||
"supported_nips": [
|
||||
1,
|
||||
9,
|
||||
11,
|
||||
13,
|
||||
17,
|
||||
40,
|
||||
42,
|
||||
59,
|
||||
62,
|
||||
70
|
||||
],
|
||||
"version": "immortal - 0.0.9",
|
||||
"relay_countries": [
|
||||
"*"
|
||||
],
|
||||
"language_tags": [
|
||||
"*"
|
||||
],
|
||||
"tags": [],
|
||||
"posting_policy": "https://jellyfish.land/tos.txt",
|
||||
"payments_url": "https://jellyfish.land/relay",
|
||||
"icon": "https://image.nostr.build/2547e9ec4b23589e09bc7071e0806c3d4293f76284c58ff331a64bce978aaee8.jpg",
|
||||
"retention": [],
|
||||
"contact": "wino@nostr.wine",
|
||||
"description": "A paid nostr relay for wine enthusiasts and everyone else.",
|
||||
"fees": {
|
||||
"subscription": [
|
||||
"admission": [
|
||||
{
|
||||
"amount": 3000,
|
||||
"period": 2628003,
|
||||
"unit": "sats"
|
||||
},
|
||||
{
|
||||
"amount": 8000,
|
||||
"period": 7884009,
|
||||
"unit": "sats"
|
||||
},
|
||||
{
|
||||
"amount": 15000,
|
||||
"period": 15768018,
|
||||
"unit": "sats"
|
||||
},
|
||||
{
|
||||
"amount": 28000,
|
||||
"period": 31536036,
|
||||
"unit": "sats"
|
||||
"amount": 18888000,
|
||||
"unit": "msats"
|
||||
}
|
||||
]
|
||||
},
|
||||
"icon": "https://image.nostr.build/30acdce4a81926f386622a07343228ae99fa68d012d54c538c0b2129dffe400c.png",
|
||||
"limitation": {
|
||||
"auth_required": false,
|
||||
"max_message_length": 70000,
|
||||
"max_subid_length": 256,
|
||||
"max_subscriptions": 350,
|
||||
"created_at_lower_limit": 94608000,
|
||||
"created_at_upper_limit": 300,
|
||||
"max_event_tags": 4000,
|
||||
"max_limit": 1000,
|
||||
"max_message_length": 524288,
|
||||
"max_subid_length": 71,
|
||||
"max_subscriptions": 50,
|
||||
"min_pow_difficulty": 0,
|
||||
"payment_required": true,
|
||||
"restricted_writes": true,
|
||||
"restricted_writes": true
|
||||
},
|
||||
"name": "nostr.wine",
|
||||
"payments_url": "https://nostr.wine/invoices",
|
||||
"pubkey": "4918eb332a41b71ba9a74b1dc64276cfff592e55107b93baae38af3520e55975",
|
||||
"software": "https://nostr.wine",
|
||||
"supported_nips": [ 1, 2, 4, 9, 11, 40, 42, 50, 70, 77 ],
|
||||
"terms_of_service": "https://nostr.wine/terms",
|
||||
"version": "0.3.3"
|
||||
}
|
||||
|
||||
~> curl -H "Accept: application/nostr+json" https://nostr.land | jq
|
||||
{
|
||||
"description": "[✨ NFDB] nostr.land family of relays (fi-01 [tiger])",
|
||||
"name": "[✨ NFDB] nostr.land",
|
||||
"pubkey": "52b4a076bcbbbdc3a1aefa3735816cf74993b1b8db202b01c883c58be7fad8bd",
|
||||
"software": "NFDB",
|
||||
"icon": "https://i.nostr.build/b3thno790aodH8lE.jpg",
|
||||
"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 ],
|
||||
"version": "1.0.0",
|
||||
"limitation": {
|
||||
"payment_required": true,
|
||||
"max_message_length": 65535,
|
||||
"max_event_tags": 2000,
|
||||
"max_content_length": 70000,
|
||||
"created_at_lower_limit": 0,
|
||||
"created_at_upper_limit": 2147483647,
|
||||
"default_limit": 500,
|
||||
"max_limit": 5000
|
||||
}
|
||||
"max_subscriptions": 200,
|
||||
"auth_required": false
|
||||
},
|
||||
"payments_url": "https://nostr.land",
|
||||
"fees": {
|
||||
"subscription": [
|
||||
{
|
||||
"amount": 4000000,
|
||||
"unit": "msats",
|
||||
"period": 2592000
|
||||
}
|
||||
]
|
||||
},
|
||||
"terms_of_service": "https://nostr.land/terms"
|
||||
}
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user