mirror of
https://github.com/nostr-protocol/nips.git
synced 2025-12-09 00:28:51 +00:00
Compare commits
9 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
fc323706fa | ||
|
|
8231c8e1e9 | ||
|
|
01926e3da2 | ||
|
|
c91098af86 | ||
|
|
936befbf9b | ||
|
|
e42aae6184 | ||
|
|
cd09e6c9d8 | ||
|
|
42370a3d30 | ||
|
|
ed128aef46 |
6
47.md
6
47.md
@@ -107,7 +107,7 @@ The content of notifications is encrypted with [NIP04](https://github.com/nostr-
|
||||
## Nostr Wallet Connect URI
|
||||
**client** discovers **wallet service** by scanning a QR code, handling a deeplink or pasting in a URI.
|
||||
|
||||
The **wallet service** generates this connection URI with protocol `nostr+walletconnect://` and base path it's hex-encoded `pubkey` with the following query string parameters:
|
||||
The **wallet service** generates this connection URI with protocol `nostr+walletconnect://` and base path its hex-encoded `pubkey` with the following query string parameters:
|
||||
|
||||
- `relay` Required. URL of the relay where the **wallet service** is connected and will be listening for events. May be more than one.
|
||||
- `secret` Required. 32-byte randomly generated hex encoded string. The **client** MUST use this to sign events and encrypt payloads when communicating with the **wallet service**.
|
||||
@@ -175,7 +175,7 @@ Request:
|
||||
Response:
|
||||
|
||||
For every invoice in the request, a separate response event is sent. To differentiate between the responses, each
|
||||
response event contains a `d` tag with the id of the invoice it is responding to, if no id was given, then the
|
||||
response event contains a `d` tag with the id of the invoice it is responding to; if no id was given, then the
|
||||
payment hash of the invoice should be used.
|
||||
|
||||
```jsonc
|
||||
@@ -247,7 +247,7 @@ Request:
|
||||
Response:
|
||||
|
||||
For every keysend in the request, a separate response event is sent. To differentiate between the responses, each
|
||||
response event contains an `d` tag with the id of the keysend it is responding to, if no id was given, then the
|
||||
response event contains a `d` tag with the id of the keysend it is responding to; if no id was given, then the
|
||||
pubkey should be used.
|
||||
|
||||
```jsonc
|
||||
|
||||
32
51.md
32
51.md
@@ -54,7 +54,8 @@ Aside from their main identifier, the `"d"` tag, sets can optionally have a `"ti
|
||||
| Kind mute sets | 30007 | mute pubkeys by kinds<br>`"d"` tag MUST be the kind string | `"p"` (pubkeys) |
|
||||
| Interest sets | 30015 | interest topics represented by a bunch of "hashtags" | `"t"` (hashtags) |
|
||||
| Emoji sets | 30030 | categorized emoji groups | `"emoji"` (see [NIP-30](30.md)) |
|
||||
| Release artifact sets | 30063 | groups of files of a software release | `"e"` (kind:1063 [file metadata](94.md) events), `"i"` (application identifier, typically reverse domain notation), `"version"` |
|
||||
| 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) |
|
||||
|
||||
### Deprecated standard lists
|
||||
|
||||
@@ -117,22 +118,39 @@ Some clients have used these lists in the past, but they should work on transiti
|
||||
"pubkey": "d6dc95542e18b8b7aec2f14610f55c335abebec76f3db9e58c254661d0593a0c",
|
||||
"created_at": 1695327657,
|
||||
"kind": 30063,
|
||||
"content": "Release notes in markdown",
|
||||
"tags": [
|
||||
["d", "ak8dy3v7"],
|
||||
["i", "com.example.app"],
|
||||
["version", "0.0.1"],
|
||||
["title", "Example App"],
|
||||
["image", "http://cdn.site/p/com.example.app/icon.png"],
|
||||
["d", "com.example.app@0.0.1"],
|
||||
["e", "d78ba0d5dce22bfff9db0a9e996c9ef27e2c91051de0c4e1da340e0326b4941e"], // Windows exe
|
||||
["e", "f27e2c91051de0c4e1da0d5dce22bfff9db0a9340e0326b4941ed78bae996c9e"], // MacOS dmg
|
||||
["e", "9d24ddfab95ba3ff7c03fbd07ad011fff245abea431fb4d3787c2d04aad02332"], // Linux AppImage
|
||||
["e", "340e0326b340e0326b4941ed78ba340e0326b4941ed78ba340e0326b49ed78ba"] // PWA
|
||||
["e", "340e0326b340e0326b4941ed78ba340e0326b4941ed78ba340e0326b49ed78ba"], // PWA
|
||||
["a", "32267:d6dc95542e18b8b7aec2f14610f55c335abebec76f3db9e58c254661d0593a0c:com.example.app"] // Reference to parent software application
|
||||
],
|
||||
"content": "Example App is a decentralized marketplace for apps",
|
||||
"sig": "a9a4e2192eede77e6c9d24ddfab95ba3ff7c03fbd07ad011fff245abea431fb4d3787c2d04aad001cb039cb8de91d83ce30e9a94f82ac3c5a2372aa1294a96bd"
|
||||
}
|
||||
```
|
||||
|
||||
### An _app curation set_
|
||||
|
||||
```jsonc
|
||||
{
|
||||
"id": "d8037fa866eb5acd2159960b3ada7284172f7d687b5289cc72a96ca2b431b611",
|
||||
"pubkey": "78ce6faa72264387284e647ba6938995735ec8c7d5c5a65737e55130f026307d",
|
||||
"sig": "c1ce0a04521c020ae7485307cd86285530c1f778766a3fd594d662a73e7c28f307d7cd9a9ab642ae749fce62abbabb3a32facfe8d19a21fba551b60fae863d95",
|
||||
"kind": 30267,
|
||||
"created_at": 1729302793,
|
||||
"content": "My nostr app selection",
|
||||
"tags": [
|
||||
["d", "nostr"],
|
||||
["a", "32267:7579076d9aff0a4cfdefa7e2045f2486c7e5d8bc63bfc6b45397233e1bbfcb19:com.example.app1"],
|
||||
["a", "32267:045f2486c7e5d8bc63bfc6b45397233e1bbfcb197579076d9aff0a4cfdefa7e2:net.example.app2"],
|
||||
["a", "32267:264387284e647ba6938995735ec8c7d5c5a6f026307d78ce6faa725737e55130:pl.code.app3"]
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## Encryption process pseudocode
|
||||
|
||||
```scala
|
||||
|
||||
88
91.md
Normal file
88
91.md
Normal file
@@ -0,0 +1,88 @@
|
||||
NIP-91
|
||||
======
|
||||
|
||||
Extension Negotiation
|
||||
---------------------
|
||||
|
||||
`draft` `optional`
|
||||
|
||||
This NIP defines a method for clients to negotiate new features with relays.
|
||||
|
||||
## Extension Names
|
||||
|
||||
Each extension has a **extension name** that can uniquely identify the extension. Currently the following formats are recommended:
|
||||
- `nip/XX-<description>`: For extensions that are standardized in NIPs. Experimental extensions are recommended to have a unique description to not conflict.
|
||||
- `<namespace>/<extension>`: For extensions standardized by an independent body. The namespace should uniquely identify the standardizing body for this extension with a DNS name. (example: `example.com/example-extension`)
|
||||
|
||||
Any extension name outside this list MUST NOT be used.
|
||||
|
||||
## Extension Offers
|
||||
|
||||
The relay may send a extension offer as a `EN-OFFER` message. The client SHOULD NOT send any messages relating to extension negotiation until it receives an `EN-OFFER`.
|
||||
```jsonc
|
||||
[
|
||||
"EN-OFFER",
|
||||
{
|
||||
"example.com/example-extension": {...},
|
||||
"nip-XX-example-extension": {...}
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
The first entry MUST be an object, with the keys being extension names, and the values being objects. The format of the object is left to the specification of the specific extension.
|
||||
|
||||
A extension offer can be sent multiple times in a connection, such as to update availability based off of their [NIP-42](./42.md) authentication status.
|
||||
|
||||
Clients SHOULD be able to handle extension offers being able to be withdrawn, and should treat them as if it was a `EN-SHUTDOWN` if they were in use.
|
||||
|
||||
Certain extensions, such as extensions to REQs, may not need negotiation. This is up to the extension specification.
|
||||
|
||||
## Extension Requests
|
||||
|
||||
A client may request a extension offered by the relay be enabled with the `EN-REQUEST` message:
|
||||
```jsonc
|
||||
[
|
||||
"EN-REQUEST",
|
||||
"example.com/example-extension",
|
||||
{...}
|
||||
]
|
||||
```
|
||||
|
||||
The first entry MUST be the extension name, and the second entry MUST be a extension-dependent object for the extension enable request.
|
||||
|
||||
The relay SHOULD respond with a `EN-OK` or `EN-ERROR` message:
|
||||
```jsonc
|
||||
[
|
||||
"EN-OK",
|
||||
"example.com/example-extension",
|
||||
{...}
|
||||
]
|
||||
```
|
||||
```jsonc
|
||||
[
|
||||
"EN-ERROR",
|
||||
"example.com/example-extension",
|
||||
"improper extension request data"
|
||||
]
|
||||
```
|
||||
|
||||
In both messages, the first entry MUST be the extension name. The second entry depends on the type:
|
||||
- `EN-OK`: Response data for the extension negotiation. After this message, the extension can be used.
|
||||
- `EN-ERROR`: An error message.
|
||||
|
||||
An error message SHOULD start with a single-word prefix, followed by a colon (:) and space character, and a human readable message. The following types are defined:
|
||||
- `error`: An internal error has occurred in the relay.
|
||||
- `not-offered`: The extension was not offered. This may happen due to a `EN-REQUEST` being sent at the same time as a new `EN-OFFER`.
|
||||
- `bad-data`: The client has sent improper extension negotiation data.
|
||||
|
||||
## Extension Cancel
|
||||
|
||||
The relay or client may stop the usage of the extension any time with a `EN-CANCEL` message:
|
||||
```jsonc
|
||||
[
|
||||
"EN-CANCEL",
|
||||
"example.com/example-extension"
|
||||
]
|
||||
```
|
||||
|
||||
After this message, the sending party will no longer accept and send new extension messages, and the receiver should not continue attempting to use the extension functionality.
|
||||
@@ -285,8 +285,8 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
|
||||
| `l` | label, label namespace | -- | [32](32.md) |
|
||||
| `L` | label namespace | -- | [32](32.md) |
|
||||
| `m` | MIME type | -- | [94](94.md) |
|
||||
| `p` | pubkey (hex) | relay URL, petname | [01](01.md), [02](02.md) |
|
||||
| `P` | pubkey (hex) | -- | [57](57.md) |
|
||||
| `p` | pubkey (hex) | relay URL, petname | [01](01.md), [02](02.md), [22](22.md) |
|
||||
| `P` | pubkey (hex) | -- | [22](22.md), [57](57.md) |
|
||||
| `q` | event id (hex) | relay URL, pubkey (hex) | [18](18.md) |
|
||||
| `r` | a reference (URL, etc) | -- | [24](24.md), [25](25.md) |
|
||||
| `r` | relay url | marker | [65](65.md) |
|
||||
|
||||
Reference in New Issue
Block a user