mirror of
https://github.com/nostr-protocol/nips.git
synced 2025-12-09 00:28:51 +00:00
Compare commits
2 Commits
contradict
...
reaction-t
| Author | SHA1 | Date | |
|---|---|---|---|
|
23b069d469 | ||
|
|
1b86a40df4 |
4
01.md
4
01.md
@@ -78,8 +78,8 @@ This NIP defines 3 standard tags that can be used across all event kinds with th
|
||||
- The `e` tag, used to refer to an event: `["e", <32-bytes lowercase hex of the id of another event>, <recommended relay URL, optional>, <32-bytes lowercase hex of the author's pubkey, optional>]`
|
||||
- The `p` tag, used to refer to another user: `["p", <32-bytes lowercase hex of a pubkey>, <recommended relay URL, optional>]`
|
||||
- The `a` tag, used to refer to an addressable or replaceable event
|
||||
- for an addressable event: `["a", "<kind integer>:<32-bytes lowercase hex of a pubkey>:<d tag value>", <recommended relay URL, optional>]`
|
||||
- for a normal replaceable event: `["a", "<kind integer>:<32-bytes lowercase hex of a pubkey>:", <recommended relay URL, optional>]` (note: include the trailing colon)
|
||||
- for an addressable event: `["a", <kind integer>:<32-bytes lowercase hex of a pubkey>:<d tag value>, <recommended relay URL, optional>]`
|
||||
- for a normal replaceable event: `["a", <kind integer>:<32-bytes lowercase hex of a pubkey>:, <recommended relay URL, optional>]`
|
||||
|
||||
As a convention, all single-letter (only english alphabet letters: a-z, A-Z) key tags are expected to be indexed by relays, such that it is possible, for example, to query or subscribe to events that reference the event `"5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"` by using the `{"#e": ["5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"]}` filter. Only the first value in any given tag is indexed.
|
||||
|
||||
|
||||
24
17.md
24
17.md
@@ -21,7 +21,7 @@ Kind `14` is a chat message. `p` tags identify one or more receivers of the mess
|
||||
"tags": [
|
||||
["p", "<receiver-1-pubkey>", "<relay-url>"],
|
||||
["p", "<receiver-2-pubkey>", "<relay-url>"],
|
||||
["e", "<kind-14-id>", "<relay-url>"] // if this is a reply
|
||||
["e", "<kind-14-id>", "<relay-url>", "reply"] // if this is a reply
|
||||
["subject", "<conversation-title>"],
|
||||
// rest of tags...
|
||||
],
|
||||
@@ -31,13 +31,7 @@ Kind `14` is a chat message. `p` tags identify one or more receivers of the mess
|
||||
|
||||
`.content` MUST be plain text. Fields `id` and `created_at` are required.
|
||||
|
||||
An `e` tag denotes the direct parent message this post is replying to.
|
||||
|
||||
`q` tags MAY be used when citing events in the `.content` with [NIP-21](21.md).
|
||||
|
||||
```json
|
||||
["q", "<event-id> or <event-address>", "<relay-url>", "<pubkey-if-a-regular-event>"]
|
||||
```
|
||||
Tags that mention, quote and assemble threading structures MUST follow [NIP-10](10.md).
|
||||
|
||||
Kind `14`s MUST never be signed. If it is signed, the message might leak to relays and become **fully public**.
|
||||
|
||||
@@ -57,7 +51,7 @@ Kind `14`s MUST never be signed. If it is signed, the message might leak to rela
|
||||
["file-type", "<file-mime-type>"],
|
||||
["encryption-algorithm", "<encryption-algorithm>"],
|
||||
["decryption-key", "<decryption-key>"],
|
||||
["decryption-nonce", "<decryption-nonce>"],
|
||||
["decryptiion-nonce", "<decryption-nonce>"],
|
||||
["x", "<the SHA-256 hexencoded string of the file>"],
|
||||
// rest of tags...
|
||||
],
|
||||
@@ -74,16 +68,16 @@ Kind 15 is used for sending encrypted file event messages:
|
||||
- `content`: The URL of the file (`<file-url>`).
|
||||
- `x` containing the SHA-256 hexencoded string of the file.
|
||||
- `size` (optional) size of file in bytes
|
||||
- `dim` (optional) size of the file in pixels in the form `<width>x<height>`
|
||||
- `blurhash`(optional) the [blurhash](https://github.com/woltapp/blurhash) to show while the client is loading the file
|
||||
- `thumb` (optional) URL of thumbnail with same aspect ratio (encrypted with the same key, nonce)
|
||||
- `dim` (optional) size of file in pixels in the form `<width>x<height>`
|
||||
- `blurhash`(optional) the [blurhash](https://github.com/woltapp/blurhash) to show while the file is being loaded by the client
|
||||
- `thumb` (optional) url of thumbnail with same aspect ratio
|
||||
- `fallback` (optional) zero or more fallback file sources in case `url` fails
|
||||
|
||||
Just like kind 14, kind `15`s MUST never be signed.
|
||||
|
||||
## Chat Rooms
|
||||
|
||||
The set of `pubkey` + `p` tags defines a chat room. If a new `p` tag is added or a current one is removed, a new room is created with a clean message history.
|
||||
The set of `pubkey` + `p` tags defines a chat room. If a new `p` tag is added or a current one is removed, a new room is created with clean message history.
|
||||
|
||||
Clients SHOULD render messages of the same room in a continuous thread.
|
||||
|
||||
@@ -91,7 +85,7 @@ An optional `subject` tag defines the current name/topic of the conversation. An
|
||||
|
||||
## Encrypting
|
||||
|
||||
Following [NIP-59](59.md), the **unsigned** `kind:14` & `kind:15` chat messages must be sealed (`kind:13`) and then gift-wrapped (`kind:1059`) to each receiver and the sender individually.
|
||||
Following [NIP-59](59.md), the **unsigned** `kind:14` & `kind:15` chat message must be sealed (`kind:13`) and then gift-wrapped (`kind:1059`) to each receiver and the sender individually.
|
||||
|
||||
```jsonc
|
||||
{
|
||||
@@ -173,7 +167,7 @@ The main limitation of this approach is having to send a separate encrypted even
|
||||
|
||||
Clients implementing this NIP should by default only connect to the set of relays found in their `kind:10050` list. From that they should be able to load all messages both sent and received as well as get new live updates, making it for a very simple and lightweight implementation that should be fast.
|
||||
|
||||
When sending a message to anyone, clients must then connect to the relays in the receiver's `kind:10050` and send the events there but can disconnect right after unless more messages are expected to be sent (e.g. the chat tab is still selected). Clients should also send a copy of their outgoing messages to their own `kind:10050` relay set.
|
||||
When sending a message to anyone, clients must then connect to the relays in the receiver's `kind:10050` and send the events there, but can disconnect right after unless more messages are expected to be sent (e.g. the chat tab is still selected). Clients should also send a copy of their outgoing messages to their own `kind:10050` relay set.
|
||||
|
||||
## Examples
|
||||
|
||||
|
||||
4
23.md
4
23.md
@@ -60,7 +60,3 @@ References to other Nostr notes, articles or profiles must be made according to
|
||||
"id": "..."
|
||||
}
|
||||
```
|
||||
|
||||
### Replies & Comments
|
||||
|
||||
Replies to `kind 30023` MUST use [NIP-22](./22.md) `kind 1111` comments.
|
||||
2
55.md
2
55.md
@@ -484,8 +484,6 @@ If the user chose to always reject the event, signer application will return the
|
||||
|
||||
# Usage for Web Applications
|
||||
|
||||
You should consider using [NIP-46: Nostr Connect](46.md) for a better experience for web applications. When using this approach, the web app can't call the signer in the background, so the user will see a popup for every event you try to sign.
|
||||
|
||||
Since web applications can't receive a result from the intent, you should add a modal to paste the signature or the event json or create a callback url.
|
||||
|
||||
If you send the callback url parameter, Signer Application will send the result to the url.
|
||||
|
||||
250
66.md
250
66.md
@@ -1,250 +0,0 @@
|
||||
# NIP-66: Relay Discovery and Liveness Monitoring
|
||||
|
||||
`draft` `optional`
|
||||
|
||||
You want to find relays. You may want to discover relays based on criteria that's up to date. You may even want to ensure that you have a complete dataset. You probably want to filter relays based on their reported liveness.
|
||||
|
||||
In its purest form:
|
||||
|
||||
```json
|
||||
{
|
||||
"kind": 30166,
|
||||
"created_at": 1722173222,
|
||||
"content": "{}",
|
||||
"tags": [
|
||||
[ "d", "wss://somerelay.abc/" ]
|
||||
],
|
||||
"pubkey": "<pubkey>",
|
||||
"sig": "<signature>",
|
||||
"id": "<eventid>"
|
||||
}
|
||||
```
|
||||
|
||||
This event signals that the relay at `wss://somerelay.abc/` was reported "online" by `<pubkey>` at timestamp `1722173222`. This event **MAY** be extended upon to include more information.
|
||||
|
||||
## Kinds
|
||||
`NIP-66` defines two (2) event kinds, `30166` and `10166`
|
||||
|
||||
| kind | name | description |
|
||||
|-------|----------------------------|-----------------------------------------------------------------------------------------|
|
||||
| [30166](#k30166) | Relay Discovery | An addressable event that is published by a monitor when a relay is online |
|
||||
| [10166](#k10166) | Relay Monitor Announcement | An RE that stores data that signals the intent of a pubkey to monitor relays and publish `30166` events at a regular _frequency_ |
|
||||
|
||||
## Ontology
|
||||
- `Relay Operator`: someone who operates a relay
|
||||
- `Monitor`: A pubkey that monitors relays and publishes `30166` events at the frequency specified in their `10166` event.
|
||||
- `Ad-hoc Monitor`: A pubkey that monitors relays and publishes `30166` events at an irregular frequency.
|
||||
- `Monitor Service`: A group or individual that monitors relays using one or more `Monitors`.
|
||||
- `Check`: a specific data point that is tested or aggregated by a monitor.
|
||||
|
||||
## `30166`: "Relay Discovery" <a id="k30166"></a>
|
||||
|
||||
### Summary
|
||||
`30166` is a `NIP-33` addressable event, referred to as a "Relay Discovery" event. These events are optimized with a small footprint for protocol-level relay Discovery.
|
||||
|
||||
### Purpose
|
||||
Discovery of relays over nostr.
|
||||
|
||||
### Schema
|
||||
|
||||
#### Content
|
||||
`30166` content fields **SHOULD** include the stringified JSON of the relay's NIP-11 informational document. This data **MAY** be provided for informational purposes only.
|
||||
|
||||
#### `created_at`
|
||||
The `created_at` field in a NIP-66 event should reflect the time when the relay liveness (and potentially other data points) was checked.
|
||||
|
||||
#### `tags`
|
||||
|
||||
##### Meta Tags (unindexed)
|
||||
- `rtt-open` The relay's open **round-trip time** in milliseconds.
|
||||
- `rtt-read` The relay's read **round-trip time** in milliseconds.
|
||||
- `rtt-write` The relay's write **round-trip time** in milliseconds.
|
||||
|
||||
_Other `rtt` values **MAY** be present. This NIP should be updated if there is value found in more `rtt` values._
|
||||
|
||||
##### Single Letter Tags (indexed)
|
||||
- `d` The relay URL/URI. The `#d` tag **must** be included in the `event.tags[]` array. Index position `1` **must** be the relay websocket URL/URI. If a URL it **SHOULD** be [normalized](https://datatracker.ietf.org/doc/html/rfc3986#section-6). For relays not accessible via conventional means but rather by an npub/pubkey, an npub/pubkey **MAY** be used in place of a URL.
|
||||
```json
|
||||
[ "d", "wss://somerelay.abc/"]
|
||||
```
|
||||
|
||||
- `n`: Network
|
||||
```json
|
||||
[ "n", "clearnet" ]
|
||||
```
|
||||
|
||||
- `T`: Relay Type. Enumerated [relay type](https://github.com/nostr-protocol/nips/issues/1282) formatted as `PascalCase`
|
||||
```json
|
||||
["T", "PrivateInbox" ]
|
||||
```
|
||||
|
||||
- `N`: Supported Nips _From NIP-11 "Informational Document" `nip11.supported_nips[]`_
|
||||
```json
|
||||
[ "N", "42" ]
|
||||
```
|
||||
|
||||
- `R`: Requirements _NIP-11 "Informational Document" `nip11.limitations.payment_required`, `nip11.limitations.auth_required` and/or any other boolean value within `nip11.limitations[]` that is added in the future_
|
||||
```json
|
||||
[ "R", "payment" ],
|
||||
[ "R", "auth" ],
|
||||
```
|
||||
Since the nostr protocol does not currently support filtering on whether an indexed tag **is** or **is not** set, to make "public" and "no auth" relays discoverable requires a `!` flag
|
||||
|
||||
```json
|
||||
[ "R", "!payment" ], //no payment required, is public
|
||||
[ "R", "!auth" ], //no authentication required
|
||||
```
|
||||
|
||||
- `t`: "Topics" _From NIP-11 "Informational Document" `nip11.tags[]`_
|
||||
```json
|
||||
[ "t", "nsfw" ]
|
||||
```
|
||||
|
||||
- `k`: Accepted/Blocked Kinds [`NIP-22`]
|
||||
```json
|
||||
[ "k", "0" ],
|
||||
[ "k", "3" ],
|
||||
[ "k", "10002" ]
|
||||
```
|
||||
|
||||
or for blocked kinds
|
||||
|
||||
```json
|
||||
[ "k", "!0" ]
|
||||
[ "k", "!3" ],
|
||||
[ "k", "!10002" ]
|
||||
```
|
||||
|
||||
- `g`: `NIP-52` `g` tags (geohash)
|
||||
```json
|
||||
[ "g", "9r1652whz" ]
|
||||
```
|
||||
|
||||
- `30166` **MAY** be extended with global tags defined by other NIPs that do no collide with locally defined indices, including but not limited to: `p`, `t`, `e`, `a`, `i` and `l/L`.
|
||||
|
||||
#### Robust Example of a `30166` Event
|
||||
_Relay was online, and you can filter on a number of different tags_
|
||||
```json
|
||||
{
|
||||
"id": "<eventid>",
|
||||
"pubkey": "<monitor's pubkey>",
|
||||
"created_at": "<created_at [some recent date ...]>",
|
||||
"signature": "<signature>",
|
||||
"content": "{}",
|
||||
"kind": 30166,
|
||||
"tags": [
|
||||
["d","wss://some.relay/"],
|
||||
["n", "clearnet"],
|
||||
["N", "40"],
|
||||
["N", "33"],
|
||||
["R", "!payment"],
|
||||
["R", "auth"],
|
||||
["g", "ww8p1r4t8"],
|
||||
["p", "somehexkey..."],
|
||||
["l", "en", "ISO-639-1"],
|
||||
["t", "nsfw" ],
|
||||
["rtt-open", 234 ]
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## `10166`: "Relay Monitor Announcement" Events <a id="k10166"></a>
|
||||
|
||||
### Summary
|
||||
`10166` is a replacable event herein referred to as "Relay Monitor Announcement" events. These events contain information about a publisher's intent to monitor and publish data as `30166` events. This event is optional and is intended for monitors who intend to provide monitoring services at a regular and predictable frequency.
|
||||
|
||||
### Purpose
|
||||
To provide a directory of monitors, their intent to publish, their criteria and parameters of monitoring activities. Absence of this event implies the monitor is ad-hoc and does not publish events at a predictable frequency, and relies on mechanisms to infer data integrity, such as web-of-trust.
|
||||
|
||||
### Schema
|
||||
|
||||
#### Standard Tags
|
||||
|
||||
- `frequency` The frequency **in seconds** at which the monitor publishes events. A string-integer at index `1` represents the expected frequency the monitor will publish `30166` events. There should only be `1` frequency per monitor.
|
||||
|
||||
```json
|
||||
[ "frequency", "3600" ]
|
||||
```
|
||||
|
||||
- `timeout` (optional) The timeout values for various checks conducted by a monitor. Index `1` is the monitor's timeout in milliseconds. Index `2` describes what test the timeout is used for. If no index `2` is provided, it is inferred that the timeout provided applies to all tests. These values can assist relay operators in understanding data signaled by the monitor in _Relay Discovery Events_.
|
||||
```json
|
||||
[ "timeout", "2000", "open" ],
|
||||
[ "timeout", "2000", "read" ],
|
||||
[ "timeout", "3000", "write" ],
|
||||
[ "timeout", "2000", "nip11" ],
|
||||
[ "timeout", "4000", "ssl" ]
|
||||
```
|
||||
|
||||
#### Indexed Tags
|
||||
- `c` "Checks" **SHOULD** be a lowercase string describing the check(s) conducted by a monitor. Due to the rapidly evolving nature of relays, enumeration is organic and not strictly defined. But examples of some checks could be websocket `open/read/write/auth`, `nip11` checks, `dns` and `geo` checks, and and any other checks the monitor may deem useful.. Other checks **MAY** be included. New types of checks **SHOULD** be added to this NIP as they are needed.
|
||||
```json
|
||||
[ "c", "ws" ],
|
||||
[ "c", "nip11" ],
|
||||
[ "c", "dns" ],
|
||||
[ "c", "geo" ],
|
||||
[ "c", "ssl" ],
|
||||
```
|
||||
|
||||
- `g`: `NIP-52` `g` tags (geohash)
|
||||
```json
|
||||
[ "g", "9r1652whz" ]
|
||||
```
|
||||
|
||||
- Any other globally defined indexable tags **MAY** be included as found necessary.
|
||||
|
||||
### Other Requirements
|
||||
Monitors **SHOULD** have the following
|
||||
- A published `0` (NIP-1) event
|
||||
- A published `10002` (NIP-65) event that defines the relays the monitor publishes to.
|
||||
|
||||
### Robust Example of a `10166` Event
|
||||
```json
|
||||
{
|
||||
"id": "<eventid>",
|
||||
"pubkey": "<monitor's pubkey>",
|
||||
"created_at": "<created_at [some recent date ...]>",
|
||||
"signature": "<signature>",
|
||||
"content": "",
|
||||
"tags": [
|
||||
|
||||
[ "timeout", "open", "5000" ],
|
||||
[ "timeout", "read", "3000" ],
|
||||
[ "timeout", "write", "3000" ],
|
||||
[ "timeout", "nip11", "3000" ],
|
||||
|
||||
[ "frequency", "3600" ],
|
||||
|
||||
[ "c", "ws" ],
|
||||
[ "c", "nip11" ],
|
||||
[ "c", "ssl" ],
|
||||
[ "c", "dns" ],
|
||||
[ "c", "geo" ]
|
||||
|
||||
[ "g", "ww8p1r4t8" ]
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## Methodology
|
||||
|
||||
### Monitors
|
||||
1. A _Relay Monitor_ checks the liveness and potentially other attributes of a relay.
|
||||
|
||||
2. _Relay Monitor_ publishes a kind `30166` note when a relay it is monitoring is online. If the monitor has a `10166` event, events should be published at the frequency defined in their `10166` note.
|
||||
|
||||
_Any pubkey that publishes `30166` events **SHOULD** at a minimum be checking that the relay is available by websocket and behaves like a relay_
|
||||
|
||||
### Clients
|
||||
1. In most cases, a client **SHOULD** filter on `30166` events using either a statically or dynamically defined monitor's `pubkey` and a `created_at` value respective of the monitor's published `frequency`. If the monitor has no stated frequency, other mechanisms should be employed to determine data integrity.
|
||||
|
||||
2. _Relay Liveness_ is subjectively determined by the client, starting with the `frequency` value of a monitor.
|
||||
|
||||
3. The liveness of a _Relay Monitor_ can be subjectively determined by detecting whether the _Relay Monitor_ has published events with respect to `frequency` value of any particular monitor.
|
||||
|
||||
4. The reliability and trustworthiness of a _Relay Monitor_ could be established via web-of-trust, reviews or similar mechanisms.
|
||||
|
||||
## Risk Mitigation
|
||||
|
||||
- When a client implements `NIP-66` events, the client should have a fallback if `NIP-66` events cannot be located.
|
||||
|
||||
- A `Monitor` or `Ad-hoc Monitor` may publish erroneous `30166` events, intentionally or otherwise. Therefor, it's important to program defensively to limit the impact of such events. This can be achieved with web-of-trust, reviews, fallbacks and/or data-aggregation for example.
|
||||
37
73.md
37
73.md
@@ -9,37 +9,26 @@ External Content IDs
|
||||
There are certain established global content identifiers such as [Book ISBNs](https://en.wikipedia.org/wiki/ISBN), [Podcast GUIDs](https://podcastnamespace.org/tag/guid), and [Movie ISANs](https://en.wikipedia.org/wiki/International_Standard_Audiovisual_Number) that are useful to reference in nostr events so that clients can query all the events assosiated with these ids.
|
||||
|
||||
|
||||
`i` tags are used for referencing these external content ids, with `k` tags representing the external content id kind so that clients can query all the events for a specific kind.
|
||||
`i` tags are used for referencing these external content ids, with `k` tags representing the external content id kind so that clients can query all the events for a specific kind.
|
||||
|
||||
## Supported IDs
|
||||
|
||||
| Type | `i` tag | `k` tag |
|
||||
| --- | --- | --- |
|
||||
| URLs | "`<URL, normalized, no fragment>`" | "web" |
|
||||
| Hashtags | "#`<topic, lowercase>`" | "#" |
|
||||
| Geohashes | "geo:`<geohash, lowercase>`" | "geo" |
|
||||
| Books | "isbn:`<id, without hyphens>`" | "isbn" |
|
||||
| Podcast Feeds | "podcast:guid:`<guid>`" | "podcast:guid" |
|
||||
| Podcast Episodes | "podcast:item:guid:`<guid>`" | "podcast:item:guid" |
|
||||
| Podcast Publishers | "podcast:publisher:guid:`<guid>`" | "podcast:publisher:guid" |
|
||||
| Movies | "isan:`<id, without version part>`" | "isan" |
|
||||
| Papers | "doi:`<id, lowercase>`" | "doi" |
|
||||
| Type | `i` tag | `k` tag |
|
||||
|- | - | - |
|
||||
| URLs | "`<URL, normalized, no fragment>`" | "`<scheme-host, normalized>`" |
|
||||
| Hashtags | "#`<topic, lowercase>`" | "#" |
|
||||
| Geohashes| "geo:`<geohash, lowercase>`" | "geo" |
|
||||
| Books | "isbn:`<id, without hyphens>`" | "isbn" |
|
||||
| Podcast Feeds | "podcast:guid:`<guid>`" | "podcast:guid" |
|
||||
| Podcast Episodes | "podcast:item:guid:`<guid>`" | "podcast:item:guid" |
|
||||
| Podcast Publishers | "podcast:publisher:guid:`<guid>`" | "podcast:publisher:guid" |
|
||||
| Movies | "isan:`<id, without version part>`" | "isan" |
|
||||
| Papers | "doi:`<id, lowercase>`" | "doi" |
|
||||
|
||||
---
|
||||
|
||||
## Examples
|
||||
|
||||
### Webpages
|
||||
|
||||
For the webpage "https://myblog.example.com/post/2012-03-27/hello-world" the "i" and "k" tags are:
|
||||
|
||||
```jsonc
|
||||
[
|
||||
["i","https://myblog.example.com/post/2012-03-27/hello-world"],
|
||||
["k", "web"]
|
||||
]
|
||||
```
|
||||
|
||||
### Books:
|
||||
|
||||
- Book ISBN: `["i", "isbn:9780765382030"]` - https://isbnsearch.org/isbn/9780765382030
|
||||
@@ -67,3 +56,5 @@ Each `i` tag MAY have a url hint as the second argument to redirect people to a
|
||||
`["i", "podcast:item:guid:d98d189b-dc7b-45b1-8720-d4b98690f31f", https://fountain.fm/episode/z1y9TMQRuqXl2awyrQxg]`
|
||||
|
||||
`["i", "isan:0000-0000-401A-0000-7", https://www.imdb.com/title/tt0120737]`
|
||||
|
||||
|
||||
|
||||
13
89.md
13
89.md
@@ -74,19 +74,6 @@ Using a `k` tag(s) (instead of having the kind of the `d` tag) provides:
|
||||
|
||||
Multiple tags might be registered by the app, following NIP-19 nomenclature as the second value of the array.
|
||||
|
||||
No contradictory hints can appear. Apps should not publish handlers with the same `platform:type` duple.
|
||||
|
||||
For example: an event with:
|
||||
|
||||
```jsonc
|
||||
["web", "https://.../path1/<bech32>", "nevent"],
|
||||
["web", "https://.../path2/<bech32>", "nevent"],
|
||||
```
|
||||
|
||||
where the `web` + `nevent` duple is duplicated with contradictory values is invalid and clients SHOULD ignore it.
|
||||
|
||||
Applications that have different URLs should use different `kind:31990` to announce the different URLs that should be used per kind.
|
||||
|
||||
A tag without a second value in the array SHOULD be considered a generic handler for any NIP-19 entity that is not handled by a different tag.
|
||||
|
||||
# Client tag
|
||||
|
||||
18
README.md
18
README.md
@@ -80,7 +80,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
|
||||
- [NIP-62: Request to Vanish](62.md)
|
||||
- [NIP-64: Chess (PGN)](64.md)
|
||||
- [NIP-65: Relay List Metadata](65.md)
|
||||
- [NIP-66: Relay Discovery and Liveness Monitoring](66.md)
|
||||
- [NIP-68: Picture-first feeds](68.md)
|
||||
- [NIP-69: Peer-to-peer Order events](69.md)
|
||||
- [NIP-70: Protected Events](70.md)
|
||||
@@ -127,10 +126,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
|
||||
| `20` | Picture | [68](68.md) |
|
||||
| `21` | Video Event | [71](71.md) |
|
||||
| `22` | Short-form Portrait Video Event | [71](71.md) |
|
||||
| `30` | internal reference | [NKBIP-03] |
|
||||
| `31` | external web reference | [NKBIP-03] |
|
||||
| `32` | hardcopy reference | [NKBIP-03] |
|
||||
| `33` | prompt reference | [NKBIP-03] |
|
||||
| `40` | Channel Creation | [28](28.md) |
|
||||
| `41` | Channel Metadata | [28](28.md) |
|
||||
| `42` | Channel Message | [28](28.md) |
|
||||
@@ -190,7 +185,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
|
||||
| `10050` | Relay list to receive DMs | [51](51.md), [17](17.md) |
|
||||
| `10063` | User server list | [Blossom][blossom] |
|
||||
| `10096` | File storage server list | [96](96.md) |
|
||||
| `10166` | Relay Monitor Announcement | [66](66.md) |
|
||||
| `13194` | Wallet Info | [47](47.md) |
|
||||
| `17375` | Cashu Wallet Event | [60](60.md) |
|
||||
| `21000` | Lightning Pub RPC | [Lightning.Pub][lnpub] |
|
||||
@@ -217,11 +211,10 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
|
||||
| `30023` | Long-form Content | [23](23.md) |
|
||||
| `30024` | Draft Long-form Content | [23](23.md) |
|
||||
| `30030` | Emoji sets | [51](51.md) |
|
||||
| `30040` | Curated Publication Index | [NKBIP-01] |
|
||||
| `30041` | Curated Publication Content | [NKBIP-01] |
|
||||
| `30040` | Modular Article Header | [NKBIP-01] |
|
||||
| `30041` | Modular Article Content | [NKBIP-01] |
|
||||
| `30063` | Release artifact sets | [51](51.md) |
|
||||
| `30078` | Application-specific Data | [78](78.md) |
|
||||
| `30166` | Relay Discovery | [66](66.md) |
|
||||
| `30267` | App curation sets | [51](51.md) |
|
||||
| `30311` | Live Event | [53](53.md) |
|
||||
| `30315` | User Statuses | [38](38.md) |
|
||||
@@ -252,9 +245,8 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
|
||||
[cornychat-slideset]: https://cornychat.com/datatypes#kind30388slideset
|
||||
[cornychat-linkset]: https://cornychat.com/datatypes#kind31388linkset
|
||||
[joinstr]: https://gitlab.com/1440000bytes/joinstr/-/blob/main/NIP.md
|
||||
[NKBIP-01]: https://wikistr.com/nkbip-01*fd208ee8c8f283780a9552896e4823cc9dc6bfd442063889577106940fd927c1
|
||||
[NKBIP-02]: https://wikistr.com/nkbip-02*fd208ee8c8f283780a9552896e4823cc9dc6bfd442063889577106940fd927c1
|
||||
[NKBIP-03]: https://wikistr.com/nkbip-03*fd208ee8c8f283780a9552896e4823cc9dc6bfd442063889577106940fd927c1
|
||||
[NKBIP-01]: https://wikistr.com/nkbip-01
|
||||
[NKBIP-02]: https://wikistr.com/nkbip-02
|
||||
[blossom]: https://github.com/hzrd149/blossom
|
||||
[Tidal-nostr]: https://wikistr.com/tidal-nostr
|
||||
|
||||
@@ -384,4 +376,4 @@ All NIPs are public domain.
|
||||
|
||||
<a align="center" href="https://github.com/nostr-protocol/nips/graphs/contributors">
|
||||
<img src="https://contrib.rocks/image?repo=nostr-protocol/nips" />
|
||||
</a>
|
||||
</a>
|
||||
|
||||
Reference in New Issue
Block a user