mirror of
https://github.com/nostr-protocol/nips.git
synced 2025-12-09 08:38:50 +00:00
Compare commits
1 Commits
stream-ext
...
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"
|
||||
}
|
||||
```
|
||||
|
||||
7
51.md
7
51.md
@@ -60,7 +60,6 @@ Aside from their main identifier, the `"d"` tag, sets can optionally have a `"ti
|
||||
| Emoji sets | 30030 | categorized emoji groups | `"emoji"` (see [NIP-30](30.md)) |
|
||||
| Release artifact sets | 30063 | group of artifacts of a software release | `"e"` (kind:1063 [file metadata](94.md) events), `"a"` (software application event) |
|
||||
| App curation sets | 30267 | references to multiple software applications | `"a"` (software application event) |
|
||||
| Calendar | 31924 | a set of events categorized in any way | `"a"` (calendar event event) |
|
||||
| Starter packs | 39089 | a named set of profiles to be shared around with the goal of being followed together | `"p"` (pubkeys) |
|
||||
| Media starter packs | 39092 | same as above, but specific to multimedia (photos, short video) clients | `"p"` (pubkeys) |
|
||||
|
||||
@@ -104,9 +103,9 @@ Some clients have used these lists in the past, but they should work on transiti
|
||||
"kind": 30004,
|
||||
"tags": [
|
||||
["d", "jvdy9i4"],
|
||||
["title", "Yaks"],
|
||||
["image", "https://cdn.britannica.com/40/188540-050-9AC748DE/Yak-Himalayas-Nepal.jpg"],
|
||||
["description", "The domestic yak, also known as the Tartary ox, grunting ox, or hairy cattle, is a species of long-haired domesticated cattle found throughout the Himalayan region of the Indian subcontinent, the Tibetan Plateau, Gilgit-Baltistan, Tajikistan and as far north as Mongolia and Siberia."],
|
||||
["name", "Yaks"],
|
||||
["picture", "https://cdn.britannica.com/40/188540-050-9AC748DE/Yak-Himalayas-Nepal.jpg"],
|
||||
["about", "The domestic yak, also known as the Tartary ox, grunting ox, or hairy cattle, is a species of long-haired domesticated cattle found throughout the Himalayan region of the Indian subcontinent, the Tibetan Plateau, Gilgit-Baltistan, Tajikistan and as far north as Mongolia and Siberia."],
|
||||
["a", "30023:26dc95542e18b8b7aec2f14610f55c335abebec76f3db9e58c254661d0593a0c:95ODQzw3ajNoZ8SyMDOzQ"],
|
||||
["a", "30023:54af95542e18b8b7aec2f14610f55c335abebec76f3db9e58c254661d0593a0c:1-MYP8dAhramH9J5gJWKx"],
|
||||
["a", "30023:f8fe95542e18b8b7aec2f14610f55c335abebec76f3db9e58c254661d0593a0c:D2Tbd38bGrFvU0bIbvSMt"],
|
||||
|
||||
119
52.md
119
52.md
@@ -12,14 +12,23 @@ Unlike the term `calendar event` specific to this NIP, the term `event` is used
|
||||
|
||||
## Calendar Events
|
||||
|
||||
There are two types of calendar events represented by different kinds: _date-based_ and _time-based_ calendar events.
|
||||
There are two types of calendar events represented by different kinds: date-based and time-based calendar events. Calendar events are not required to be part of a [calendar](#calendar).
|
||||
|
||||
These tags are common to both types of calendar events:
|
||||
### Date-Based Calendar Event
|
||||
|
||||
This kind of calendar event starts on a date and ends before a different date in the future. Its use is appropriate for all-day or multi-day events where time and time zone hold no significance. e.g., anniversary, public holidays, vacation days.
|
||||
|
||||
#### Format
|
||||
|
||||
The format uses an _addressable event_ of `kind:31922`.
|
||||
|
||||
The `.content` of these events should be a detailed description of the calendar event. It is required but can be an empty string.
|
||||
|
||||
The list of tags are as follows:
|
||||
* `d` (required) a short unique string identifier. Generated by the client creating the calendar event.
|
||||
* `title` (required) title of the calendar event
|
||||
* `summary` (optional) brief description of the calendar event
|
||||
* `image` (optional) url of an image to use for the event
|
||||
* `start` (required) inclusive start date in ISO 8601 format (YYYY-MM-DD). Must be less than `end`, if it exists.
|
||||
* `end` (optional) exclusive end date in ISO 8601 format (YYYY-MM-DD). If omitted, the calendar event ends on the same date as `start`.
|
||||
* `location` (optional, repeated) location of the calendar event. e.g. address, GPS coordinates, meeting room name, link to video call
|
||||
* `g` (optional) [geohash](https://en.wikipedia.org/wiki/Geohash) to associate calendar event with a searchable physical location
|
||||
* `p` (optional, repeated) 32-bytes hex pubkey of a participant, optional recommended relay URL, and participant's role in the meeting
|
||||
@@ -27,31 +36,13 @@ These tags are common to both types of calendar events:
|
||||
* `r` (optional, repeated) references / links to web pages, documents, video calls, recorded videos, etc.
|
||||
|
||||
The following tags are deprecated:
|
||||
|
||||
* `name` name of the calendar event. Use only if `title` is not available.
|
||||
|
||||
Calendar events are _not_ required to be part of a [calendar](#calendar).
|
||||
|
||||
### Date-Based Calendar Event
|
||||
|
||||
This kind of calendar event starts on a date and ends before a different date in the future. Its use is appropriate for all-day or multi-day events where time and time zone hold no significance. e.g., anniversary, public holidays, vacation days.
|
||||
|
||||
It's an _addressable event_ of `kind:31922`.
|
||||
|
||||
The `.content` of these events SHOULD be a description of the calendar event.
|
||||
|
||||
Aside from the common tags, this also takes the following tags:
|
||||
|
||||
* `start` (required) inclusive start date in ISO 8601 format (YYYY-MM-DD). Must be less than `end`, if it exists.
|
||||
* `end` (optional) exclusive end date in ISO 8601 format (YYYY-MM-DD). If omitted, the calendar event ends on the same date as `start`.
|
||||
|
||||
Example:
|
||||
|
||||
```yaml
|
||||
```jsonc
|
||||
{
|
||||
"id": <32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>,
|
||||
"pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
|
||||
"created_at": <unix timestamp in seconds>,
|
||||
"created_at": <Unix timestamp in seconds>,
|
||||
"kind": 31922,
|
||||
"content": "<description of calendar event>",
|
||||
"tags": [
|
||||
@@ -59,17 +50,25 @@ Example:
|
||||
|
||||
["title", "<title of calendar event>"],
|
||||
|
||||
// dates
|
||||
// Dates
|
||||
["start", "<YYYY-MM-DD>"],
|
||||
["end", "<YYYY-MM-DD>"],
|
||||
|
||||
// location
|
||||
// Location
|
||||
["location", "<location>"],
|
||||
["g", "<geohash>"],
|
||||
|
||||
// participants
|
||||
// Participants
|
||||
["p", "<32-bytes hex of a pubkey>", "<optional recommended relay URL>", "<role>"],
|
||||
["p", "<32-bytes hex of a pubkey>", "<optional recommended relay URL>", "<role>"],
|
||||
|
||||
// Hashtags
|
||||
["t", "<tag>"],
|
||||
["t", "<tag>"],
|
||||
|
||||
// Reference links
|
||||
["r", "<url>"],
|
||||
["r", "<url>"]
|
||||
]
|
||||
}
|
||||
```
|
||||
@@ -78,22 +77,36 @@ Example:
|
||||
|
||||
This kind of calendar event spans between a start time and end time.
|
||||
|
||||
It's an _addressable event_ of `kind:31923`.
|
||||
#### Format
|
||||
|
||||
The `.content` of these events should be a description of the calendar event. It is required but can be an empty string.
|
||||
The format uses an _addressable event_ kind `31923`.
|
||||
|
||||
Aside from the common tags, this also takes the following tags:
|
||||
The `.content` of these events should be a detailed description of the calendar event. It is required but can be an empty string.
|
||||
|
||||
The list of tags are as follows:
|
||||
* `d` (required) a short unique string identifier. Generated by the client creating the calendar event.
|
||||
* `title` (required) title of the calendar event
|
||||
* `start` (required) inclusive start Unix timestamp in seconds. Must be less than `end`, if it exists.
|
||||
* `end` (optional) exclusive end Unix timestamp in seconds. If omitted, the calendar event ends instantaneously.
|
||||
* `start_tzid` (optional) time zone of the start timestamp, as defined by the IANA Time Zone Database. e.g., `America/Costa_Rica`
|
||||
* `end_tzid` (optional) time zone of the end timestamp, as defined by the IANA Time Zone Database. e.g., `America/Costa_Rica`. If omitted and `start_tzid` is provided, the time zone of the end timestamp is the same as the start timestamp.
|
||||
* `summary` (optional) brief description of the calendar event
|
||||
* `image` (optional) url of an image to use for the event
|
||||
* `location` (optional, repeated) location of the calendar event. e.g. address, GPS coordinates, meeting room name, link to video call
|
||||
* `g` (optional) [geohash](https://en.wikipedia.org/wiki/Geohash) to associate calendar event with a searchable physical location
|
||||
* `p` (optional, repeated) 32-bytes hex pubkey of a participant, optional recommended relay URL, and participant's role in the meeting
|
||||
* `l` (optional, repeated) label to categorize calendar event. e.g. `audiospace` to denote a scheduled event from a live audio space implementation such as cornychat.com
|
||||
* `t` (optional, repeated) hashtag to categorize calendar event
|
||||
* `r` (optional, repeated) references / links to web pages, documents, video calls, recorded videos, etc.
|
||||
|
||||
```yaml
|
||||
The following tags are deprecated:
|
||||
* `name` name of the calendar event. Use only if `title` is not available.
|
||||
|
||||
```jsonc
|
||||
{
|
||||
"id": <32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>,
|
||||
"pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
|
||||
"created_at": <unix timestamp in seconds>,
|
||||
"created_at": <Unix timestamp in seconds>,
|
||||
"kind": 31923,
|
||||
"content": "<description of calendar event>",
|
||||
"tags": [
|
||||
@@ -103,39 +116,54 @@ Aside from the common tags, this also takes the following tags:
|
||||
["summary", "<brief description of the calendar event>"],
|
||||
["image", "<string with image URI>"],
|
||||
|
||||
// timestamps
|
||||
["start", "<unix timestamp in seconds>"],
|
||||
["end", "<unix timestamp in seconds>"],
|
||||
// Timestamps
|
||||
["start", "<Unix timestamp in seconds>"],
|
||||
["end", "<Unix timestamp in seconds>"],
|
||||
|
||||
["start_tzid", "<IANA Time Zone Database identifier>"],
|
||||
["end_tzid", "<IANA Time Zone Database identifier>"],
|
||||
|
||||
// location
|
||||
// Location
|
||||
["location", "<location>"],
|
||||
["g", "<geohash>"],
|
||||
|
||||
// participants
|
||||
// Participants
|
||||
["p", "<32-bytes hex of a pubkey>", "<optional recommended relay URL>", "<role>"],
|
||||
["p", "<32-bytes hex of a pubkey>", "<optional recommended relay URL>", "<role>"],
|
||||
|
||||
// Labels (example using com.cornychat namespace denoting the event as an audiospace)
|
||||
["L", "com.cornychat"],
|
||||
["l", "audiospace", "com.cornychat"],
|
||||
|
||||
// Hashtags
|
||||
["t", "<tag>"],
|
||||
["t", "<tag>"],
|
||||
|
||||
// Reference links
|
||||
["r", "<url>"],
|
||||
["r", "<url>"]
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## Calendar
|
||||
|
||||
A calendar is a collection of calendar events, represented as a custom _addressable list_ event using kind `31924`. A user can have multiple calendars. One may create a calendar to segment calendar events for specific purposes. e.g., personal, work, travel, meetups, and conferences.
|
||||
A calendar is a collection of calendar events, represented as a custom replaceable list event using kind `31924`. A user can have multiple calendars. One may create a calendar to segment calendar events for specific purposes. e.g., personal, work, travel, meetups, and conferences.
|
||||
|
||||
### Format
|
||||
|
||||
The `.content` of these events should be a detailed description of the calendar. It is required but can be an empty string.
|
||||
|
||||
The format uses a custom replaceable list of kind `31924` with a list of tags as described below:
|
||||
* `d` (required) universally unique identifier. Generated by the client creating the calendar.
|
||||
* `title` (required) calendar title
|
||||
* `a` (repeated) reference tag to kind `31922` or `31923` calendar event being responded to
|
||||
|
||||
```yaml
|
||||
```json
|
||||
{
|
||||
"id": <32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>,
|
||||
"pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
|
||||
"created_at": <unix timestamp in seconds>,
|
||||
"created_at": <Unix timestamp in seconds>,
|
||||
"kind": 31924,
|
||||
"content": "<description of calendar>",
|
||||
"tags": [
|
||||
@@ -163,12 +191,13 @@ The RSVP MUST have an `a` tag of the event coordinates to the calendar event, an
|
||||
|
||||
The RSVP MAY tag the author of the calendar event it is in response to using a `p` tag so that clients can easily query all RSVPs that pertain to the author.
|
||||
|
||||
The RSVP is an _addressable event_ of `kind:31925`.
|
||||
### Format
|
||||
|
||||
The format uses an _addressable event_ kind `31925`.
|
||||
|
||||
The `.content` of these events is optional and should be a free-form note that adds more context to this calendar event response.
|
||||
|
||||
The list of tags is as follows:
|
||||
|
||||
The list of tags are as follows:
|
||||
* `a` (required) coordinates to a kind `31922` or `31923` calendar event being responded to.
|
||||
* `e` (optional) event id of a kind `31922` or `31923` calendar event being responded to.
|
||||
* `d` (required) universally unique identifier. Generated by the client creating the calendar event RSVP.
|
||||
@@ -176,11 +205,11 @@ The list of tags is as follows:
|
||||
* `fb` (optional) `free` or `busy`. Determines if the user would be free or busy for the duration of the calendar event. This tag must be omitted or ignored if the `status` label is set to `declined`.
|
||||
* `p` (optional) pubkey of the author of the calendar event being responded to.
|
||||
|
||||
```yaml
|
||||
```json
|
||||
{
|
||||
"id": <32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>,
|
||||
"pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
|
||||
"created_at": <unix timestamp in seconds>,
|
||||
"created_at": <Unix timestamp in seconds>,
|
||||
"kind": 31925,
|
||||
"content": "<note>",
|
||||
"tags": [
|
||||
|
||||
73
53.md
73
53.md
@@ -84,79 +84,6 @@ Event `kind:1311` is live chat's channel message. Clients MUST include the `a` t
|
||||
|
||||
Hosts may choose to pin one or more live chat messages by updating the `pinned` tags in the live event kind `30311`.
|
||||
|
||||
### Stream Raids
|
||||
|
||||
Event `kind:1312` is a live stream raid (redirect viewers to another stream).
|
||||
|
||||
Clients MUST include two `a` tags, one marked as `from` and the other marked as `to` which redirects viewers to a new live stream.
|
||||
The `content` MAY contain a raid message.
|
||||
|
||||
Clients SHOULD automatically redirect viewers from one stream to another.
|
||||
This is a similar function used on Twitch also called raids.
|
||||
|
||||
```jsonc
|
||||
{
|
||||
"kind": 1312,
|
||||
"tags": [
|
||||
["a", "30311:<Community event author pubkey>:<d-identifier of the community>", "<Optional relay url>", "from"],
|
||||
["a", "30311:<Community event author pubkey>:<d-identifier of the community>", "<Optional relay url>", "to"],
|
||||
],
|
||||
"content": "Zap this epic streamer!",
|
||||
// other fields...
|
||||
}
|
||||
```
|
||||
|
||||
### Stream Clips
|
||||
|
||||
Event `kind:1313` is a live stream clip.
|
||||
|
||||
A clip is a small video clip taken from the live stream used to highlight a specific memorable or entertaining part of the stream.
|
||||
|
||||
Clients MUST include one `a` tag which points to the live stream event which the clip was taken from.
|
||||
|
||||
Clients MUST include one `r` tag which is a URL pointing to the video clip file, preferably in MP4 format for maximum compatibility.
|
||||
|
||||
Clients MAY also include a message about the clip in the `title` tag.
|
||||
|
||||
```jsonc
|
||||
{
|
||||
"kind": 1313,
|
||||
"tags": [
|
||||
["a", "30311:<Community event author pubkey>:<d-identifier of the community>", "<Optional relay url>", "root"],
|
||||
["r", "https://example.com/my-clip.mp4"],
|
||||
["title", "Streamer gets rekt by bot!"]
|
||||
],
|
||||
"content": "",
|
||||
// other fields...
|
||||
}
|
||||
```
|
||||
|
||||
### Stream Timeout
|
||||
|
||||
Event `kind:1314` is a live chat moderation event that temporarily mutes a user from chatting.
|
||||
|
||||
Clients MUST include one or more `p` tags of the timed out users.
|
||||
|
||||
Clients MUST include a [NIP-40](./40.md) expiration timestamp which signals when the timeout will end.
|
||||
|
||||
Clients SHOULD enfore timeouts by disabling chat functions in their apps and not displaying any chat messages from the user during their timeout.
|
||||
|
||||
Clients SHOULD listen for timeout events published by the stream host.
|
||||
|
||||
Clients MAY include a reason for the timeout in the `content` field.
|
||||
|
||||
```jsonc
|
||||
{
|
||||
"kind": 1314,
|
||||
"tags": [
|
||||
["p", "<pubkey-of-muted-user>"],
|
||||
["expiration", "1747658333"]
|
||||
],
|
||||
"content": "Rude",
|
||||
// other fields...
|
||||
}
|
||||
```
|
||||
|
||||
## Use Cases
|
||||
|
||||
Common use cases include meeting rooms/workshops, watch-together activities, or event spaces, such as [zap.stream](https://zap.stream).
|
||||
|
||||
@@ -150,10 +150,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
|
||||
| `1063` | File Metadata | [94](94.md) |
|
||||
| `1068` | Poll | [88](88.md) |
|
||||
| `1111` | Comment | [22](22.md) |
|
||||
| `1311` | Live Stream Chat Message | [53](53.md) |
|
||||
| `1312` | Live Stream Raid | [53](53.md) |
|
||||
| `1313` | Live Stream Clip | [53](53.md) |
|
||||
| `1314` | Live Stream Timeout | [53](53.md) |
|
||||
| `1311` | Live Chat Message | [53](53.md) |
|
||||
| `1337` | Code Snippet | [C0](C0.md) |
|
||||
| `1617` | Patches | [34](34.md) |
|
||||
| `1621` | Issues | [34](34.md) |
|
||||
|
||||
Reference in New Issue
Block a user