mirror of
https://github.com/nostr-protocol/nips.git
synced 2025-12-09 00:28:51 +00:00
Compare commits
3 Commits
canonical-
...
semisol/eo
| Author | SHA1 | Date | |
|---|---|---|---|
|
10d8a749e9 | ||
|
|
053d07e0ef | ||
|
|
46f8133cd4 |
2
04.md
2
04.md
@@ -1,4 +1,4 @@
|
||||
> __Warning__ `unrecommended`: deprecated in favor of [NIP-17](17.md)
|
||||
> __Warning__ `unrecommended`: deprecated in favor of [NIP-44](44.md)
|
||||
|
||||
NIP-04
|
||||
======
|
||||
|
||||
26
11.md
26
11.md
@@ -37,7 +37,7 @@ Detailed plain-text information about the relay may be contained in the `descrip
|
||||
|
||||
### 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-04`) 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.
|
||||
|
||||
@@ -60,30 +60,6 @@ The relay MAY choose to publish its software version as a string attribute. The
|
||||
Extra Fields
|
||||
------------
|
||||
|
||||
### Virtual Relays
|
||||
|
||||
Some relays want to expose "virtual" addresses to the same underlying dataset or other types of weird functionality. A basic example is a relay that may serve all notes under its `/` path, but only Italian notes under its `/it` path and only Japanese notes under its `/jp` path. In this case clients may use the virtual (`/jp` etc) paths when browsing the relay, for example; but in other situations, like when selecting relays for building a feed for some specific profile, clients should just want to connect to `/`.
|
||||
|
||||
```json
|
||||
{
|
||||
"virtual_path": {
|
||||
"is": true,
|
||||
"canonical": "/",
|
||||
"alternatives": [
|
||||
{"path": "/jp", "description": "only stuff in Japanese"},
|
||||
{"path": "/it", "description": "only stuff in Italian"},
|
||||
{"path": "/fr", "description": "whatever"},
|
||||
{"path": "/pt", "description": "blergh"}
|
||||
]
|
||||
},
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
- `is`: this is `true` when the current path queried is a virtual path.
|
||||
- `canonical`: this is the path that should be used when the client doesn't care about the virtual.
|
||||
- `alternatives`: optionally, if a relay wants to announce its virtual paths, this may be useful sometimes.
|
||||
|
||||
### Server Limitations
|
||||
|
||||
These are limitations imposed by the relay on clients. Your client
|
||||
|
||||
164
17.md
164
17.md
@@ -1,164 +0,0 @@
|
||||
NIP-17
|
||||
======
|
||||
|
||||
Private Direct Messages
|
||||
-----------------------
|
||||
|
||||
`draft` `optional`
|
||||
|
||||
This NIP defines an encrypted direct messaging scheme using [NIP-44](44.md) encryption and [NIP-59](59.md) seals and gift wraps.
|
||||
|
||||
## Direct Message Kind
|
||||
|
||||
Kind `14` is a chat message. `p` tags identify one or more receivers of the message.
|
||||
|
||||
```js
|
||||
{
|
||||
"id": "<usual hash>",
|
||||
"pubkey": "<sender-pubkey>",
|
||||
"created_at": now(),
|
||||
"kind": 14,
|
||||
"tags": [
|
||||
["p", "<receiver-1-pubkey>", "<relay-url>"],
|
||||
["p", "<receiver-2-pubkey>", "<relay-url>"],
|
||||
["e", "<kind-14-id>", "<relay-url>", "reply"] // if this is a reply
|
||||
["subject", "<conversation-title>"],
|
||||
...
|
||||
],
|
||||
"content": "<message-in-plain-text>",
|
||||
}
|
||||
```
|
||||
|
||||
`.content` MUST be plain text. Fields `id` and `created_at` are required.
|
||||
|
||||
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**.
|
||||
|
||||
## 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 clean message history.
|
||||
|
||||
Clients SHOULD render messages of the same room in a continuous thread.
|
||||
|
||||
An optional `subject` tag defines the current name/topic of the conversation. Any member can change the topic by simply submitting a new `subject` to an existing `pubkey` + `p`-tags room. There is no need to send `subject` in every message. The newest `subject` in the thread is the subject of the conversation.
|
||||
|
||||
## Encrypting
|
||||
|
||||
Following [NIP-59](59.md), the **unsigned** `kind:14` chat message must be sealed (`kind:13`) and then gift-wrapped (`kind:1059`) to each receiver and the sender individually.
|
||||
|
||||
```js
|
||||
{
|
||||
"id": "<usual hash>",
|
||||
"pubkey": randomPublicKey,
|
||||
"created_at": randomTimeUpTo2DaysInThePast(),
|
||||
"kind": 1059, // gift wrap
|
||||
"tags": [
|
||||
["p", receiverPublicKey, "<relay-url>"] // receiver
|
||||
],
|
||||
"content": nip44Encrypt(
|
||||
{
|
||||
"id": "<usual hash>",
|
||||
"pubkey": senderPublicKey,
|
||||
"created_at": randomTimeUpTo2DaysInThePast(),
|
||||
"kind": 13, // seal
|
||||
"tags": [], // no tags
|
||||
"content": nip44Encrypt(unsignedKind14, senderPrivateKey, receiverPublicKey),
|
||||
"sig": "<signed by senderPrivateKey>"
|
||||
},
|
||||
randomPrivateKey, receiverPublicKey
|
||||
),
|
||||
"sig": "<signed by randomPrivateKey>"
|
||||
}
|
||||
```
|
||||
|
||||
The encryption algorithm MUST use the latest version of [NIP-44](44.md).
|
||||
|
||||
Clients MUST verify if pubkey of the `kind:13` is the same pubkey on the `kind:14`, otherwise any sender can impersonate others by simply changing the pubkey on `kind:14`.
|
||||
|
||||
Clients SHOULD randomize `created_at` in up to two days in the past in both the seal and the gift wrap to make sure grouping by `created_at` doesn't reveal any metadata.
|
||||
|
||||
The gift wrap's `p`-tag can be the receiver's main pubkey or an alias key created to receive DMs without exposing the receiver's identity.
|
||||
|
||||
Clients CAN offer disappearing messages by setting an `expiration` tag in the gift wrap of each receiver or by not generating a gift wrap to the sender's public key
|
||||
|
||||
## Publishing
|
||||
|
||||
Kind `10050` indicates the user's preferred relays to receive DMs. The event MUST include a list of `relay` tags with relay URIs.
|
||||
|
||||
```js
|
||||
{
|
||||
"kind": 10050,
|
||||
"tags": [
|
||||
["relay", "wss://inbox.nostr.wine"],
|
||||
["relay", "wss://myrelay.nostr1.com"],
|
||||
],
|
||||
"content": "",
|
||||
//...other fields
|
||||
}
|
||||
```
|
||||
|
||||
Clients SHOULD publish kind `14` events to the `10050`-listed relays. If that is not found that indicates the user is not ready to receive messages under this NIP and clients shouldn't try.
|
||||
|
||||
## Relays
|
||||
|
||||
It's advisable that relays do not serve `kind:14` to clients other than the ones tagged in them.
|
||||
|
||||
It's advisable that users choose relays that conform to these practices.
|
||||
|
||||
Clients SHOULD guide users to keep `kind:10050` lists small (1-3 relays) and SHOULD spread it to as many relays as viable.
|
||||
|
||||
## Benefits & Limitations
|
||||
|
||||
This NIP offers the following privacy and security features:
|
||||
|
||||
1. **No Metadata Leak**: Participant identities, each message's real date and time, event kinds, and other event tags are all hidden from the public. Senders and receivers cannot be linked with public information alone.
|
||||
2. **No Public Group Identifiers**: There is no public central queue, channel or otherwise converging identifier to correlate or count all messages in the same group.
|
||||
3. **No Moderation**: There are no group admins: no invitations or bans.
|
||||
4. **No Shared Secrets**: No secret must be known to all members that can leak or be mistakenly shared
|
||||
5. **Fully Recoverable**: Messages can be fully recoverable by any client with the user's private key
|
||||
6. **Optional Forward Secrecy**: Users and clients can opt-in for "disappearing messages".
|
||||
7. **Uses Public Relays**: Messages can flow through public relays without loss of privacy. Private relays can increase privacy further, but they are not required.
|
||||
8. **Cold Storage**: Users can unilaterally opt-in to sharing their messages with a separate key that is exclusive for DM backup and recovery.
|
||||
|
||||
The main limitation of this approach is having to send a separate encrypted event to each receiver. Group chats with more than 100 participants should find a more suitable messaging scheme.
|
||||
|
||||
## Implementation
|
||||
|
||||
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.
|
||||
|
||||
## Examples
|
||||
|
||||
This example sends the message `Hola, que tal?` from `nsec1w8udu59ydjvedgs3yv5qccshcj8k05fh3l60k9x57asjrqdpa00qkmr89m` to `nsec12ywtkplvyq5t6twdqwwygavp5lm4fhuang89c943nf2z92eez43szvn4dt`.
|
||||
|
||||
The two final GiftWraps, one to the receiver and the other to the sender, are:
|
||||
|
||||
```json
|
||||
{
|
||||
"id":"2886780f7349afc1344047524540ee716f7bdc1b64191699855662330bf235d8",
|
||||
"pubkey":"8f8a7ec43b77d25799281207e1a47f7a654755055788f7482653f9c9661c6d51",
|
||||
"created_at":1703128320,
|
||||
"kind":1059,
|
||||
"tags":[
|
||||
[ "p", "918e2da906df4ccd12c8ac672d8335add131a4cf9d27ce42b3bb3625755f0788"]
|
||||
],
|
||||
"content":"AsqzdlMsG304G8h08bE67dhAR1gFTzTckUUyuvndZ8LrGCvwI4pgC3d6hyAK0Wo9gtkLqSr2rT2RyHlE5wRqbCOlQ8WvJEKwqwIJwT5PO3l2RxvGCHDbd1b1o40ZgIVwwLCfOWJ86I5upXe8K5AgpxYTOM1BD+SbgI5jOMA8tgpRoitJedVSvBZsmwAxXM7o7sbOON4MXHzOqOZpALpS2zgBDXSAaYAsTdEM4qqFeik+zTk3+L6NYuftGidqVluicwSGS2viYWr5OiJ1zrj1ERhYSGLpQnPKrqDaDi7R1KrHGFGyLgkJveY/45y0rv9aVIw9IWF11u53cf2CP7akACel2WvZdl1htEwFu/v9cFXD06fNVZjfx3OssKM/uHPE9XvZttQboAvP5UoK6lv9o3d+0GM4/3zP+yO3C0NExz1ZgFmbGFz703YJzM+zpKCOXaZyzPjADXp8qBBeVc5lmJqiCL4solZpxA1865yPigPAZcc9acSUlg23J1dptFK4n3Tl5HfSHP+oZ/QS/SHWbVFCtq7ZMQSRxLgEitfglTNz9P1CnpMwmW/Y4Gm5zdkv0JrdUVrn2UO9ARdHlPsW5ARgDmzaxnJypkfoHXNfxGGXWRk0sKLbz/ipnaQP/eFJv/ibNuSfqL6E4BnN/tHJSHYEaTQ/PdrA2i9laG3vJti3kAl5Ih87ct0w/tzYfp4SRPhEF1zzue9G/16eJEMzwmhQ5Ec7jJVcVGa4RltqnuF8unUu3iSRTQ+/MNNUkK6Mk+YuaJJs6Fjw6tRHuWi57SdKKv7GGkr0zlBUU2Dyo1MwpAqzsCcCTeQSv+8qt4wLf4uhU9Br7F/L0ZY9bFgh6iLDCdB+4iABXyZwT7Ufn762195hrSHcU4Okt0Zns9EeiBOFxnmpXEslYkYBpXw70GmymQfJlFOfoEp93QKCMS2DAEVeI51dJV1e+6t3pCSsQN69Vg6jUCsm1TMxSs2VX4BRbq562+VffchvW2BB4gMjsvHVUSRl8i5/ZSDlfzSPXcSGALLHBRzy+gn0oXXJ/447VHYZJDL3Ig8+QW5oFMgnWYhuwI5QSLEyflUrfSz+Pdwn/5eyjybXKJftePBD9Q+8NQ8zulU5sqvsMeIx/bBUx0fmOXsS3vjqCXW5IjkmSUV7q54GewZqTQBlcx+90xh/LSUxXex7UwZwRnifvyCbZ+zwNTHNb12chYeNjMV7kAIr3cGQv8vlOMM8ajyaZ5KVy7HpSXQjz4PGT2/nXbL5jKt8Lx0erGXsSsazkdoYDG3U",
|
||||
"sig":"a3c6ce632b145c0869423c1afaff4a6d764a9b64dedaf15f170b944ead67227518a72e455567ca1c2a0d187832cecbde7ed478395ec4c95dd3e71749ed66c480"
|
||||
}
|
||||
```
|
||||
|
||||
```json
|
||||
{
|
||||
"id":"162b0611a1911cfcb30f8a5502792b346e535a45658b3a31ae5c178465509721",
|
||||
"pubkey":"626be2af274b29ea4816ad672ee452b7cf96bbb4836815a55699ae402183f512",
|
||||
"created_at":1702711587,
|
||||
"kind":1059,
|
||||
"tags":[
|
||||
[ "p", "44900586091b284416a0c001f677f9c49f7639a55c3f1e2ec130a8e1a7998e1b"]
|
||||
],
|
||||
"content":"AsTClTzr0gzXXji7uye5UB6LYrx3HDjWGdkNaBS6BAX9CpHa+Vvtt5oI2xJrmWLen+Fo2NBOFazvl285Gb3HSM82gVycrzx1HUAaQDUG6HI7XBEGqBhQMUNwNMiN2dnilBMFC3Yc8ehCJT/gkbiNKOpwd2rFibMFRMDKai2mq2lBtPJF18oszKOjA+XlOJV8JRbmcAanTbEK5nA/GnG3eGUiUzhiYBoHomj3vztYYxc0QYHOx0WxiHY8dsC6jPsXC7f6k4P+Hv5ZiyTfzvjkSJOckel1lZuE5SfeZ0nduqTlxREGeBJ8amOykgEIKdH2VZBZB+qtOMc7ez9dz4wffGwBDA7912NFS2dPBr6txHNxBUkDZKFbuD5wijvonZDvfWq43tZspO4NutSokZB99uEiRH8NAUdGTiNb25m9JcDhVfdmABqTg5fIwwTwlem5aXIy8b66lmqqz2LBzJtnJDu36bDwkILph3kmvaKPD8qJXmPQ4yGpxIbYSTCohgt2/I0TKJNmqNvSN+IVoUuC7ZOfUV9lOV8Ri0AMfSr2YsdZ9ofV5o82ClZWlWiSWZwy6ypa7CuT1PEGHzywB4CZ5ucpO60Z7hnBQxHLiAQIO/QhiBp1rmrdQZFN6PUEjFDloykoeHe345Yqy9Ke95HIKUCS9yJurD+nZjjgOxZjoFCsB1hQAwINTIS3FbYOibZnQwv8PXvcSOqVZxC9U0+WuagK7IwxzhGZY3vLRrX01oujiRrevB4xbW7Oxi/Agp7CQGlJXCgmRE8Rhm+Vj2s+wc/4VLNZRHDcwtfejogjrjdi8p6nfUyqoQRRPARzRGUnnCbh+LqhigT6gQf3sVilnydMRScEc0/YYNLWnaw9nbyBa7wFBAiGbJwO40k39wj+xT6HTSbSUgFZzopxroO3f/o4+ubx2+IL3fkev22mEN38+dFmYF3zE+hpE7jVxrJpC3EP9PLoFgFPKCuctMnjXmeHoiGs756N5r1Mm1ffZu4H19MSuALJlxQR7VXE/LzxRXDuaB2u9days/6muP6gbGX1ASxbJd/ou8+viHmSC/ioHzNjItVCPaJjDyc6bv+gs1NPCt0qZ69G+JmgHW/PsMMeL4n5bh74g0fJSHqiI9ewEmOG/8bedSREv2XXtKV39STxPweceIOh0k23s3N6+wvuSUAJE7u1LkDo14cobtZ/MCw/QhimYPd1u5HnEJvRhPxz0nVPz0QqL/YQeOkAYk7uzgeb2yPzJ6DBtnTnGDkglekhVzQBFRJdk740LEj6swkJ",
|
||||
"sig":"c94e74533b482aa8eeeb54ae72a5303e0b21f62909ca43c8ef06b0357412d6f8a92f96e1a205102753777fd25321a58fba3fb384eee114bd53ce6c06a1c22bab"
|
||||
}
|
||||
```
|
||||
61
34.md
61
34.md
@@ -17,20 +17,17 @@ Git repositories are hosted in Git-enabled servers, but their existence can be a
|
||||
"kind": 30617,
|
||||
"content": "",
|
||||
"tags": [
|
||||
["d", "<repo-id>"], // usually kebab-case short name
|
||||
["d", "<repo-id>"],
|
||||
["name", "<human-readable project name>"],
|
||||
["description", "brief human-readable project description>"],
|
||||
["web", "<url for browsing>", ...], // a webpage url, if the git server being used provides such a thing
|
||||
["clone", "<url for git-cloning>", ...], // a url to be given to `git clone` so anyone can clone it
|
||||
["relays", "<relay-url>", ...] // relays that this repository will monitor for patches and issues
|
||||
["earliest-unique-commit", "<commit-id>"] // usually root commit but a recent commit for forks
|
||||
["r", "<earliest-unique-commit-id>"] // so clients can subscribe to all events related to a local git repo
|
||||
["maintainers", "<other-recognized-maintainer>", ...]
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
The tags `web`, `clone`, `relays`, `maintainers` can have multiple values.
|
||||
The tags `web`, `clone`, `relays` can have multiple values.
|
||||
|
||||
Except `d`, all tags are optional.
|
||||
|
||||
@@ -38,30 +35,23 @@ Except `d`, all tags are optional.
|
||||
|
||||
Patches can be sent by anyone to any repository. Patches to a specific repository SHOULD be sent to the relays specified in that repository's announcement event's `"relays"` tag. Patch events SHOULD include an `a` tag pointing to that repository's announcement address.
|
||||
|
||||
Patches in a patch set SHOULD include a NIP-10 `e` `reply` tag pointing to the previous patch.
|
||||
|
||||
The first patch revision in a patch revision SHOULD include a NIP-10 `e` `reply` to the original root patch.
|
||||
|
||||
```jsonc
|
||||
{
|
||||
"kind": 1617,
|
||||
"content": "<patch>", // contents of <git format-patch>
|
||||
"tags": [
|
||||
["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>"],
|
||||
["r", "<earliest-unique-commit-id-of-repo>"] // so clients can subscribe to all patches sent to a local git repo
|
||||
["p", "<repository-owner>"],
|
||||
["p", "<other-user>"], // optionally send the patch to another user to bring it to their attention
|
||||
|
||||
["t", "root"], // ommited for additional patches in a series
|
||||
// for the first patch in a revision
|
||||
["t", "root-revision"],
|
||||
// for the first patch in a thread or series
|
||||
["t", "root"],
|
||||
|
||||
// optional tags for when it is desirable that the merged patch has a stable commit id
|
||||
// these fields are necessary for ensuring that the commit resulting from applying a patch
|
||||
// has the same id as it had in the proposer's machine -- all these tags can be omitted
|
||||
// if the maintainer doesn't care about these things
|
||||
["commit", "<current-commit-id>"],
|
||||
["r", "<current-commit-id>"] // so clients can find existing patches for a specific commit
|
||||
["parent-commit", "<parent-commit-id>"],
|
||||
["commit-pgp-sig", "-----BEGIN PGP SIGNATURE-----..."], // empty string for unsigned commit
|
||||
["committer", "<name>", "<email>", "<timestamp>", "<timezone offset in minutes>"],
|
||||
@@ -69,8 +59,6 @@ The first patch revision in a patch revision SHOULD include a NIP-10 `e` `reply`
|
||||
}
|
||||
```
|
||||
|
||||
The first patch in a series MAY be a cover letter in the format produced by `git format-patch`.
|
||||
|
||||
## Issues
|
||||
|
||||
Issues are Markdown text that is just human-readable conversational threads related to the repository: bug reports, feature requests, questions or comments of any kind. Like patches, these SHOULD be sent to the relays specified in that repository's announcement event's `"relays"` tag.
|
||||
@@ -106,46 +94,9 @@ Replies are also Markdown text. The difference is that they MUST be issued as re
|
||||
}
|
||||
```
|
||||
|
||||
## Status
|
||||
|
||||
Root Patches and Issues have a Status that defaults to 'Open' and can be set by issuing Status events.
|
||||
|
||||
```jsonc
|
||||
{
|
||||
"kind": 1630, // Open
|
||||
"kind": 1631, // Applied / Merged for Patches; Resolved for Issues
|
||||
"kind": 1632, // Closed
|
||||
"kind": 1633, // Draft
|
||||
"content": "<markdown text>",
|
||||
"tags": [
|
||||
["e", "<issue-or-original-root-patch-id-hex>", "", "root"],
|
||||
["e", "<accepted-revision-root-id-hex>", "", "reply"], // for when revisions applied
|
||||
["p", "<repository-owner>"],
|
||||
["p", "<root-event-author>"],
|
||||
["p", "<revision-author>"],
|
||||
|
||||
// optional for improved subscription filter efficency
|
||||
["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>", "<relay-url>"],
|
||||
["r", "<earliest-unique-commit-id-of-repo>"]
|
||||
|
||||
// optional for `1631` status
|
||||
["e", "<applied-or-merged-patch-event-id>", "", "mention"], // for each
|
||||
// when merged
|
||||
["merge-commit", "<merge-commit-id>"]
|
||||
["r", "<merge-commit-id>"]
|
||||
// when applied
|
||||
["applied-as-commits", "<commit-id-in-master-branch>", ...]
|
||||
["r", "<applied-commit-id>"] // for each
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
The Status event with the largest created_at date is valid.
|
||||
|
||||
The Status of a patch-revision defaults to either that of the root-patch, or `1632` (Closed) if the root-patch's Status is `1631` and the patch-revision isn't tagged in the `1631` event.
|
||||
|
||||
|
||||
## Possible things to be added later
|
||||
|
||||
- "status" kind (for letting people know a patch was merged or an issue was fixed or won't be fixed)
|
||||
- "branch merge" kind (specifying a URL from where to fetch the branch to be merged)
|
||||
- "cover letter" kind (to which multiple patches can refer and serve as a unifying layer to them)
|
||||
- inline file comments kind (we probably need one for patches and a different one for merged files)
|
||||
|
||||
4
46.md
4
46.md
@@ -153,13 +153,13 @@ The `content` field is a JSON-RPC-like message that is [NIP-04](https://github.c
|
||||
{
|
||||
"id": <request_id>,
|
||||
"result": <results_string>,
|
||||
"error": <optional_error_string>
|
||||
"error": <error_string>
|
||||
}
|
||||
```
|
||||
|
||||
- `id` is the request ID that this response is for.
|
||||
- `results` is a string of the result of the call (this can be either a string or a JSON stringified object)
|
||||
- `error`, _optionally_, it is an error in string form, if any. Its presence indicates an error with the request.
|
||||
- `error` is an error in string form.
|
||||
|
||||
### Auth Challenges
|
||||
|
||||
|
||||
52
91.md
Normal file
52
91.md
Normal file
@@ -0,0 +1,52 @@
|
||||
NIP-91
|
||||
======
|
||||
|
||||
EOSE Extensions
|
||||
---------------
|
||||
|
||||
`draft` `optional`
|
||||
|
||||
This NIP defines an extension to the EOSE message that allows relays to convey additional information to clients.
|
||||
|
||||
## Extended EOSE
|
||||
|
||||
An extended EOSE is an EOSE message, with the 2nd parameter being the "extensions object". For example: `["EOSE","example-sub",{"example_ext":"example value"}]`
|
||||
|
||||
An EOSE extension is a field in the extensions object. This may contain any value.
|
||||
|
||||
Clients MUST NOT rely on relays implementing any extensions.
|
||||
|
||||
## Extensions
|
||||
|
||||
This NIP defines a set of standard extensions.
|
||||
|
||||
### `next_created_at`
|
||||
`recommended`
|
||||
|
||||
The value of this extension MUST be an integer if present, and should specify the next `until` value the client should use for pagination.
|
||||
This MAY be higher or lower than the lowest `created_at`, and the clients SHOULD NOT perform any modifications to this value.
|
||||
|
||||
### `cursor`
|
||||
|
||||
The value of this extension MUST be a string or `null` if present, and represents a cursor the client can use to paginate this query.
|
||||
If the value is `null`, then it indicates that no more events are available for the given set of filters.
|
||||
To get more events, the client MUST send a `REQ` with the same filters (except limit, which can be changed), and the `cursor` string
|
||||
in the 1st filter with the key `cursor`. Example:
|
||||
```jsonc
|
||||
< ["REQ", "examplereq1", {"kinds": [1], "limit": 1}, {"authors": ["..."], "limit": 1}]
|
||||
> ["EVENT", "examplereq1", ...]
|
||||
> ["EOSE", "examplereq1", {"cursor": "example-cursor-string", ...}]
|
||||
< ["CLOSE", "examplereq1"]
|
||||
< ["REQ", "examplereq2", {"kinds": [1], "limit": 5, "cursor": "example-cursor-string"}, {"authors": ["..."], "limit": 5}]
|
||||
> ["EVENT", "examplereq2", ...]
|
||||
...
|
||||
```
|
||||
|
||||
This cursor MUST be valid for the duration of the connection, and MAY be valid in a new connection. A relay may indicate a cursor is no longer valid
|
||||
by sending a CLOSED with the prefix `bad-cursor: `.
|
||||
|
||||
### `auth_recommended`
|
||||
|
||||
The value of this extension MUST be a boolean if present, and indicates if the client should `AUTH` to get more events that match this query.
|
||||
This is a less disruptive alternative to `CLOSED` with `auth-required:` for filters that don't explicitly ask for access controlled events,
|
||||
but may match them.
|
||||
10
README.md
10
README.md
@@ -25,7 +25,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
|
||||
- [NIP-01: Basic protocol flow description](01.md)
|
||||
- [NIP-02: Follow List](02.md)
|
||||
- [NIP-03: OpenTimestamps Attestations for Events](03.md)
|
||||
- [NIP-04: Encrypted Direct Message](04.md) --- **unrecommended**: deprecated in favor of [NIP-17](17.md)
|
||||
- [NIP-04: Encrypted Direct Message](04.md) --- **unrecommended**: deprecated in favor of [NIP-44](44.md)
|
||||
- [NIP-05: Mapping Nostr keys to DNS-based internet identifiers](05.md)
|
||||
- [NIP-06: Basic key derivation from mnemonic seed phrase](06.md)
|
||||
- [NIP-07: `window.nostr` capability for web browsers](07.md)
|
||||
@@ -36,7 +36,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
|
||||
- [NIP-13: Proof of Work](13.md)
|
||||
- [NIP-14: Subject tag in text events](14.md)
|
||||
- [NIP-15: Nostr Marketplace (for resilient marketplaces)](15.md)
|
||||
- [NIP-17: Private Direct Messages](17.md)
|
||||
- [NIP-18: Reposts](18.md)
|
||||
- [NIP-19: bech32-encoded entities](19.md)
|
||||
- [NIP-21: `nostr:` URI scheme](21.md)
|
||||
@@ -100,7 +99,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
|
||||
| `11` | Group Thread | [29](29.md) |
|
||||
| `12` | Group Thread Reply | [29](29.md) |
|
||||
| `13` | Seal | [59](59.md) |
|
||||
| `14` | Direct Message | [17](17.md) |
|
||||
| `16` | Generic Repost | [18](18.md) |
|
||||
| `40` | Channel Creation | [28](28.md) |
|
||||
| `41` | Channel Metadata | [28](28.md) |
|
||||
@@ -116,7 +114,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
|
||||
| `1617` | Patches | [34](34.md) |
|
||||
| `1621` | Issues | [34](34.md) |
|
||||
| `1622` | Replies | [34](34.md) |
|
||||
| `1630`-`1633` | Status | [34](34.md) |
|
||||
| `1971` | Problem Tracker | [nostrocket][nostrocket] |
|
||||
| `1984` | Reporting | [56](56.md) |
|
||||
| `1985` | Label | [32](32.md) |
|
||||
@@ -140,7 +137,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
|
||||
| `10009` | User groups | [51](51.md), [29](29.md) |
|
||||
| `10015` | Interests list | [51](51.md) |
|
||||
| `10030` | User emoji list | [51](51.md) |
|
||||
| `10050` | Relay list to receive DMs | [17](17.md) |
|
||||
| `10096` | File storage server list | [96](96.md) |
|
||||
| `13194` | Wallet Info | [47](47.md) |
|
||||
| `21000` | Lightning Pub RPC | [Lightning.Pub][lnpub] |
|
||||
@@ -250,10 +246,10 @@ Please update these lists when proposing NIPs introducing new event kinds.
|
||||
| `price` | price | currency, frequency | [99](99.md) |
|
||||
| `proxy` | external ID | protocol | [48](48.md) |
|
||||
| `published_at` | unix timestamp (string) | -- | [23](23.md) |
|
||||
| `relay` | relay url | -- | [42](42.md), [17](17.md) |
|
||||
| `relay` | relay url | -- | [42](42.md) |
|
||||
| `relays` | relay list | -- | [57](57.md) |
|
||||
| `server` | file storage server url | -- | [96](96.md) |
|
||||
| `subject` | subject | -- | [14](14.md), [17](17.md) |
|
||||
| `subject` | subject | -- | [14](14.md) |
|
||||
| `summary` | article summary | -- | [23](23.md) |
|
||||
| `thumb` | badge thumbnail | dimensions in pixels | [58](58.md) |
|
||||
| `title` | article title | -- | [23](23.md) |
|
||||
|
||||
Reference in New Issue
Block a user