From eb3a857288fe99d99b73e07dfa28ac548fc10efb Mon Sep 17 00:00:00 2001 From: Asai Toshiya Date: Mon, 22 Apr 2024 12:35:48 +0900 Subject: [PATCH 01/17] README: add status kinds of NIP-34 --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index c3c5ef09..5fcdaf76 100644 --- a/README.md +++ b/README.md @@ -114,6 +114,7 @@ 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) | From df30012430c88d49fb5b124992b04d5c61b6338b Mon Sep 17 00:00:00 2001 From: Vitor Pamplona Date: Wed, 24 Apr 2024 15:31:45 -0400 Subject: [PATCH 02/17] NIP-17 (old 24) Sealed Gift-Wrapped Messages for Private DMs and Small Group Chats (#686) --- 04.md | 2 +- 11.md | 2 +- 17.md | 154 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ README.md | 9 ++-- 4 files changed, 162 insertions(+), 5 deletions(-) create mode 100644 17.md diff --git a/04.md b/04.md index dc232b40..a561a2f8 100644 --- a/04.md +++ b/04.md @@ -1,4 +1,4 @@ -> __Warning__ `unrecommended`: deprecated in favor of [NIP-44](44.md) +> __Warning__ `unrecommended`: deprecated in favor of [NIP-17](17.md) NIP-04 ====== diff --git a/11.md b/11.md index 45102d7e..a50038a0 100644 --- a/11.md +++ b/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-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. +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. diff --git a/17.md b/17.md new file mode 100644 index 00000000..cc04a888 --- /dev/null +++ b/17.md @@ -0,0 +1,154 @@ +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": "", +  "pubkey": "", + "created_at": now(), +  "kind": 14, +  "tags": [ +    ["p", "", ""], +    ["p", "", ""], +    ["e", "", "", "reply"] // if this is a reply + ["subject", ""], +    ... +  ], +  "content": "", +} +``` + +`.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": "", +  "pubkey": randomPublicKey, +  "created_at": randomTimeUpTo2DaysInThePast(), + "kind": 1059, // gift wrap +  "tags": [ +    ["p", receiverPublicKey, ""] // receiver +  ], +  "content": nip44Encrypt( +    { + "id": "", +      "pubkey": senderPublicKey, +      "created_at": randomTimeUpTo2DaysInThePast(), +      "kind": 13, // seal +      "tags": [], // no tags +      "content": nip44Encrypt(unsignedKind14, senderPrivateKey, receiverPublicKey), +      "sig": "" +    }, +    randomPrivateKey, receiverPublicKey +  ), +  "sig": "" +} +``` + +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, falling back to `read` relays of [NIP-65](65.md) if `kind:10050` is not available. + +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. + +---- + +## 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" +} +``` diff --git a/README.md b/README.md index 5fcdaf76..619c9846 100644 --- a/README.md +++ b/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-44](44.md) +- [NIP-04: Encrypted Direct Message](04.md) --- **unrecommended**: deprecated in favor of [NIP-17](17.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,6 +36,7 @@ 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) @@ -99,6 +100,7 @@ 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) | @@ -138,6 +140,7 @@ 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] | @@ -247,10 +250,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) | +| `relay` | relay url | -- | [42](42.md), [17](17.md) | | `relays` | relay list | -- | [57](57.md) | | `server` | file storage server url | -- | [96](96.md) | -| `subject` | subject | -- | [14](14.md) | +| `subject` | subject | -- | [14](14.md), [17](17.md) | | `summary` | article summary | -- | [23](23.md) | | `thumb` | badge thumbnail | dimensions in pixels | [58](58.md) | | `title` | article title | -- | [23](23.md) | From 7dfb11b435a903c703bc38216eca805cefa494d4 Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Wed, 24 Apr 2024 17:20:45 -0300 Subject: [PATCH 03/17] nip17: relay considerations and implementation details. --- 17.md | 52 +++++++++++++++++++++++++++++++--------------------- 1 file changed, 31 insertions(+), 21 deletions(-) diff --git a/17.md b/17.md index cc04a888..0f51367a 100644 --- a/17.md +++ b/17.md @@ -6,7 +6,7 @@ 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. +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 @@ -18,7 +18,7 @@ Kind `14` is a chat message. `p` tags identify one or more receivers of the mess   "pubkey": "", "created_at": now(),   "kind": 14, -  "tags": [ +  "tags": [     ["p", "", ""],     ["p", "", ""],     ["e", "", "", "reply"] // if this is a reply @@ -29,19 +29,19 @@ 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. +`.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). +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. +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. +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. +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 @@ -51,7 +51,7 @@ Following [NIP-59](59.md), the **unsigned** `kind:14` chat message must be seale { "id": "",   "pubkey": randomPublicKey, -  "created_at": randomTimeUpTo2DaysInThePast(), +  "created_at": randomTimeUpTo2DaysInThePast(), "kind": 1059, // gift wrap   "tags": [     ["p", receiverPublicKey, ""] // receiver @@ -60,7 +60,7 @@ Following [NIP-59](59.md), the **unsigned** `kind:14` chat message must be seale     { "id": "",       "pubkey": senderPublicKey, -      "created_at": randomTimeUpTo2DaysInThePast(), +      "created_at": randomTimeUpTo2DaysInThePast(),       "kind": 13, // seal       "tags": [], // no tags       "content": nip44Encrypt(unsignedKind14, senderPrivateKey, receiverPublicKey), @@ -72,17 +72,17 @@ Following [NIP-59](59.md), the **unsigned** `kind:14` chat message must be seale } ``` -The encryption algorithm MUST use the latest version of [NIP-44](44.md). +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. +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 +## Publishing Kind `10050` indicates the user's preferred relays to receive DMs. The event MUST include a list of `relay` tags with relay URIs. @@ -98,16 +98,22 @@ Kind `10050` indicates the user's preferred relays to receive DMs. The event MUS } ``` -Clients SHOULD publish kind `14` events to the `10050`-listed relays, falling back to `read` relays of [NIP-65](65.md) if `kind:10050` is not available. +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. +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: +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. +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 @@ -115,13 +121,17 @@ This NIP offers the following privacy and security features: 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. +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`. +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: @@ -138,7 +148,7 @@ The two final GiftWraps, one to the receiver and the other to the sender, are: "sig":"a3c6ce632b145c0869423c1afaff4a6d764a9b64dedaf15f170b944ead67227518a72e455567ca1c2a0d187832cecbde7ed478395ec4c95dd3e71749ed66c480" } ``` - + ```json { "id":"162b0611a1911cfcb30f8a5502792b346e535a45658b3a31ae5c178465509721", @@ -151,4 +161,4 @@ The two final GiftWraps, one to the receiver and the other to the sender, are: "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" } -``` +``` From 6071f3489eabe50eea748a2585a73c02a23d96cf Mon Sep 17 00:00:00 2001 From: Alex Gleason Date: Thu, 25 Apr 2024 06:38:36 -0500 Subject: [PATCH 04/17] NIP-46: "error" property of response is optional (#1195) * NIP-46: clarify "error" property of response * NIP-46: It's -> Its * optionally Co-authored-by: Asai Toshiya --------- Co-authored-by: fiatjaf_ Co-authored-by: Asai Toshiya --- 46.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/46.md b/46.md index 56b84022..d4b5728b 100644 --- a/46.md +++ b/46.md @@ -153,13 +153,13 @@ The `content` field is a JSON-RPC-like message that is [NIP-04](https://github.c { "id": , "result": , - "error": + "error": } ``` - `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` is an error in string form. +- `error`, _optionally_, it is an error in string form, if any. Its presence indicates an error with the request. ### Auth Challenges From 243b2865826edff22eebe5ec6e893c711802c7e5 Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Thu, 25 Apr 2024 18:03:38 -0300 Subject: [PATCH 05/17] nip46: signer should fill in pubkey, id and sig on sign_event. --- 46.md | 29 +++++++++++++++-------------- 1 file changed, 15 insertions(+), 14 deletions(-) diff --git a/46.md b/46.md index d4b5728b..e0a5b2ec 100644 --- a/46.md +++ b/46.md @@ -61,8 +61,9 @@ nostrconnect://?relay=&metadata "method": "sign_event", "params": [json_stringified(<{ content: "Hello, I'm signing remotely", - pubkey: "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52", - // ...the rest of the event data + kind: 1, + tags: [], + created_at: 1714078911 }>)] }), "tags": [["p", "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52"]], // p-tags the remote user pubkey @@ -118,21 +119,21 @@ The `content` field is a JSON-RPC-like message that is [NIP-04](https://github.c Each of the following are methods that the client sends to the remote signer. -| Command | Params | Result | -| ------------------------ | ------------------------------------------------- | ---------------------------------------------------------------------- | -| `connect` | `[, , ]` | "ack" | -| `sign_event` | `[]` | `json_stringified()` | -| `ping` | `[]` | "pong" | -| `get_relays` | `[]` | `json_stringified({: {read: , write: }})` | -| `get_public_key` | `[]` | `` | -| `nip04_encrypt` | `[, ]` | `` | -| `nip04_decrypt` | `[, ]` | `` | -| `nip44_encrypt` | `[<third_party_pubkey>, <plaintext_to_encrypt>]` | `<nip44_ciphertext>` | -| `nip44_decrypt` | `[<third_party_pubkey>, <nip44_ciphertext_to_decrypt>]` | `<plaintext>` | +| Command | Params | Result | +| ------------------------ | ------------------------------------------------- | ---------------------------------------------------------------------- | +| `connect` | `[<remote_user_pubkey>, <optional_secret>, <optional_requested_permissions>]` | "ack" | +| `sign_event` | `[<{kind, content, tags, created_at}>]` | `json_stringified(<signed_event>)` | +| `ping` | `[]` | "pong" | +| `get_relays` | `[]` | `json_stringified({<relay_url>: {read: <boolean>, write: <boolean>}})` | +| `get_public_key` | `[]` | `<hex-pubkey>` | +| `nip04_encrypt` | `[<third_party_pubkey>, <plaintext_to_encrypt>]` | `<nip04_ciphertext>` | +| `nip04_decrypt` | `[<third_party_pubkey>, <nip04_ciphertext_to_decrypt>]` | `<plaintext>` | +| `nip44_encrypt` | `[<third_party_pubkey>, <plaintext_to_encrypt>]` | `<nip44_ciphertext>` | +| `nip44_decrypt` | `[<third_party_pubkey>, <nip44_ciphertext_to_decrypt>]` | `<plaintext>` | ### Requested permissions -The `connect` method may be provided with `optional_requested_permissions` for user convenience. The permissions are a comma-separated list of `method[:params]`, i.e. `nip04_encrypt,sign_event:4` meaning permissions to call `nip04_encrypt` and to call `sign_event` with `kind:4`. Optional parameter for `sign_event` is the kind number, parameters for other methods are to be defined later. +The `connect` method may be provided with `optional_requested_permissions` for user convenience. The permissions are a comma-separated list of `method[:params]`, i.e. `nip04_encrypt,sign_event:4` meaning permissions to call `nip04_encrypt` and to call `sign_event` with `kind:4`. Optional parameter for `sign_event` is the kind number, parameters for other methods are to be defined later. ## Response Events `kind:24133` From bad8826211ca2eb8660e4bd68b292d14616d3669 Mon Sep 17 00:00:00 2001 From: fiatjaf <fiatjaf@gmail.com> Date: Wed, 24 Apr 2024 18:44:36 -0300 Subject: [PATCH 06/17] nip34: simplify `r` tag for earliest unique commit. --- 34.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/34.md b/34.md index f72fcf28..03ee0391 100644 --- a/34.md +++ b/34.md @@ -23,8 +23,7 @@ Git repositories are hosted in Git-enabled servers, but their existence can be a ["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 + ["r", "<earliest-unique-commit-id>", "euc"] ["maintainers", "<other-recognized-maintainer>", ...] ] } @@ -32,13 +31,15 @@ Git repositories are hosted in Git-enabled servers, but their existence can be a The tags `web`, `clone`, `relays`, `maintainers` can have multiple values. +The `r` tag annotated with the `"euc"` marker should be the commit ID of the earliest unique commit of this repo, made to identify it among forks and group it with other repositories hosted elsewhere that may represent essentially the same project. In most cases it will be the root commit of a repository. In case of a permanent fork between two projects, then the first commit after the fork should be used. + Except `d`, all tags are optional. ## Patches 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. +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. @@ -132,7 +133,7 @@ Root Patches and Issues have a Status that defaults to 'Open' and can be set by ["e", "<applied-or-merged-patch-event-id>", "", "mention"], // for each // when merged ["merge-commit", "<merge-commit-id>"] - ["r", "<merge-commit-id>"] + ["r", "<merge-commit-id>"] // when applied ["applied-as-commits", "<commit-id-in-master-branch>", ...] ["r", "<applied-commit-id>"] // for each @@ -142,7 +143,7 @@ Root Patches and Issues have a Status that defaults to 'Open' and can be set by 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. +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 From 88246c27414d11983dced414462b2be2d010fad8 Mon Sep 17 00:00:00 2001 From: Leo Wandersleb <leo@leowandersleb.de> Date: Wed, 24 Apr 2024 12:18:27 -0400 Subject: [PATCH 07/17] Require tags to have at least one string fixes #1193 --- 01.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/01.md b/01.md index a91febc5..8be85bc8 100644 --- a/01.md +++ b/01.md @@ -56,7 +56,7 @@ To prevent implementation differences from creating a different event ID for the ### Tags -Each tag is an array of strings of arbitrary size, with some conventions around them. Take a look at the example below: +Each tag is an array of one or more strings, with some conventions around them. Take a look at the example below: ```jsonc { From ef5eacd48904a5cee0b4e51c4b7d46a9606a7351 Mon Sep 17 00:00:00 2001 From: Lucas Nuic <165694895+lucasnuic@users.noreply.github.com> Date: Wed, 1 May 2024 22:48:11 -0300 Subject: [PATCH 08/17] =?UTF-8?q?=E2=80=9Cdecentralized=20reporting=20of?= =?UTF-8?q?=20digital=20threats=20such=20as=20malware=E2=80=9D=20in=20nost?= =?UTF-8?q?r?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit I added new tags for reporting bad things like malware --- 56.md | 1 + 1 file changed, 1 insertion(+) diff --git a/56.md b/56.md index 3209b80d..190e0b45 100644 --- a/56.md +++ b/56.md @@ -26,6 +26,7 @@ A `report type` string MUST be included as the 3rd entry to the `e` or `p` tag being reported, which consists of the following report types: - `nudity` - depictions of nudity, porn, etc. +- `malware` - depictions of malware, virus, Trojan Horse, worm, robot, spyware, adware, back door, ransomware, rootkit, kidnapper, etc. - `profanity` - profanity, hateful speech, etc. - `illegal` - something which may be illegal in some jurisdiction - `spam` - spam From 2b490b168e4b51e1c441d985ca89e5e1f426a610 Mon Sep 17 00:00:00 2001 From: Lucas Nuic <165694895+lucasnuic@users.noreply.github.com> Date: Wed, 1 May 2024 23:29:14 -0300 Subject: [PATCH 09/17] fixed typo --- 56.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/56.md b/56.md index 190e0b45..fc8d8985 100644 --- a/56.md +++ b/56.md @@ -26,7 +26,7 @@ A `report type` string MUST be included as the 3rd entry to the `e` or `p` tag being reported, which consists of the following report types: - `nudity` - depictions of nudity, porn, etc. -- `malware` - depictions of malware, virus, Trojan Horse, worm, robot, spyware, adware, back door, ransomware, rootkit, kidnapper, etc. +- `malware` - virus, trojan horse, worm, robot, spyware, adware, back door, ransomware, rootkit, kidnapper, etc. - `profanity` - profanity, hateful speech, etc. - `illegal` - something which may be illegal in some jurisdiction - `spam` - spam From 218fbb1cc7ac900fd256f666cb6add590cabb24a Mon Sep 17 00:00:00 2001 From: fiatjaf_ <fiatjaf@gmail.com> Date: Thu, 2 May 2024 11:04:55 -0300 Subject: [PATCH 10/17] NIP-54: decentralized wikis (#787) * draft of NIP-34: decentralized wikis. * add merge requests. * add merge request flow * update nip number --------- Co-authored-by: Pablo Fernandez <p@f7z.io> --- 51.md | 26 +++++++------- 54.md | 106 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ README.md | 2 ++ 3 files changed, 122 insertions(+), 12 deletions(-) create mode 100644 54.md diff --git a/51.md b/51.md index 95acbc81..fb40b26e 100644 --- a/51.md +++ b/51.md @@ -20,18 +20,20 @@ Standard lists use non-parameterized replaceable events, meaning users may only For example, _mute list_ can contain the public keys of spammers and bad actors users don't want to see in their feeds or receive annoying notifications from. -| name | kind | description | expected tag items | -| --- | --- | --- | --- | -| Mute list | 10000 | things the user doesn't want to see in their feeds | `"p"` (pubkeys), `"t"` (hashtags), `"word"` (lowercase string), `"e"` (threads) | -| Pinned notes | 10001 | events the user intends to showcase in their profile page | `"e"` (kind:1 notes) | -| Bookmarks | 10003 | uncategorized, "global" list of things a user wants to save | `"e"` (kind:1 notes), `"a"` (kind:30023 articles), `"t"` (hashtags), `"r"` (URLs) | -| Communities | 10004 | [NIP-72](72.md) communities the user belongs to | `"a"` (kind:34550 community definitions) | -| Public chats | 10005 | [NIP-28](28.md) chat channels the user is in | `"e"` (kind:40 channel definitions) | -| Blocked relays | 10006 | relays clients should never connect to | `"relay"` (relay URLs) | -| Search relays | 10007 | relays clients should use when performing search queries | `"relay"` (relay URLs) | -| Simple groups | 10009 | [NIP-29](29.md) groups the user is in | `"group"` ([NIP-29](29.md) group ids + mandatory relay URL) | -| Interests | 10015 | topics a user may be interested in and pointers | `"t"` (hashtags) and `"a"` (kind:30015 interest set) | -| Emojis | 10030 | user preferred emojis and pointers to emoji sets | `"emoji"` (see [NIP-30](30.md)) and `"a"` (kind:30030 emoji set) | +| name | kind | description | expected tag items | +| --- | --- | --- | --- | +| Mute list | 10000 | things the user doesn't want to see in their feeds | `"p"` (pubkeys), `"t"` (hashtags), `"word"` (lowercase string), `"e"` (threads) | +| Pinned notes | 10001 | events the user intends to showcase in their profile page | `"e"` (kind:1 notes) | +| Bookmarks | 10003 | uncategorized, "global" list of things a user wants to save | `"e"` (kind:1 notes), `"a"` (kind:30023 articles), `"t"` (hashtags), `"r"` (URLs) | +| Communities | 10004 | [NIP-72](72.md) communities the user belongs to | `"a"` (kind:34550 community definitions) | +| Public chats | 10005 | [NIP-28](28.md) chat channels the user is in | `"e"` (kind:40 channel definitions) | +| Blocked relays | 10006 | relays clients should never connect to | `"relay"` (relay URLs) | +| Search relays | 10007 | relays clients should use when performing search queries | `"relay"` (relay URLs) | +| Simple groups | 10009 | [NIP-29](29.md) groups the user is in | `"group"` ([NIP-29](29.md) group ids + mandatory relay URL) | +| Interests | 10015 | topics a user may be interested in and pointers | `"t"` (hashtags) and `"a"` (kind:30015 interest set) | +| Emojis | 10030 | user preferred emojis and pointers to emoji sets | `"emoji"` (see [NIP-30](30.md)) and `"a"` (kind:30030 emoji set) | +| Good wiki authors | 10101 | [NIP-54](54.md) user recommended wiki authors | `"p"` (pubkeys) | +| Good wiki relays | 10102 | [NIP-54](54.md) relays deemed to only host useful articles | `"relay"` (relay URLs) | ## Sets diff --git a/54.md b/54.md new file mode 100644 index 00000000..9063ca95 --- /dev/null +++ b/54.md @@ -0,0 +1,106 @@ +NIP-54 +====== + +Wiki +---- +`draft` `optional` + +This NIP defines `kind:30818` (a _parameterized replaceable event_) for long-form text content similar to [NIP-23](23.md), but with one important difference: articles are meant to be descriptions, or encyclopedia entries, of particular subjects, and it's expected that multiple people will write articles about the exact same subjects, with either small variations or completely independent content. + +Articles are identified by lowercase, normalized ascii `d` tags. + +### Articles +```js +{ + "content": "A wiki is a hypertext publication collaboratively edited and managed by its own audience.", + "tags": [ + [ "d", "wiki" ], + [ "title", "Wiki" ], + ] +} +``` + +[INSERT NORMALIZATION EXAMPLES] + +The content should be Markdown, following the same rules as of [NIP-23](23.md), although it takes some extra (optional) metadata tags: + + - `title`: for when the display title should be different from the `d` tag. + - `summary`: for display in lists. + - `a` and `e`: for referencing the original event a wiki article was forked from. + +One extra functionality is added: **wikilinks**. Unlike normal Markdown links `[]()` that link to webpages, wikilinks `[[]]` link to other articles in the wiki. In this case, the wiki is the entirety of Nostr. Clicking on a wikilink should cause the client to ask relays for events with `d` tags equal to the target of that wikilink. + +### Merge Requests + +Event `kind:818` represents a request to merge from a forked article into the source. It is directed to a pubkey and references the original article and the modified event. + +[INSERT EVENT EXAMPLE] + +### Redirects + +Event `kind:30819` is also defined to stand for "wiki redirects", i.e. if one thinks `Shell structure` should redirect to `Thin-shell structure` they can issue one of these events instead of replicating the content. These events can be used for automatically redirecting between articles on a client, but also for generating crowdsourced "disambiguation" pages ([common in Wikipedia](https://en.wikipedia.org/wiki/Help:Disambiguation)). + +[INSERT EVENT EXAMPLE] + +How to decide what article to display +------------------------------------- + +As there could be many articles for each given name, some kind of prioritization must be done by clients. Criteria for this should vary between users and clients, but some means that can be used are described below: + +### Reactions + +[NIP-25](25.md) reactions are very simple and can be used to create a simple web-of-trust between wiki article writers and their content. While just counting a raw number of "likes" is unproductive, reacting to any wiki article event with a `+` can be interpreted as a recommendation for that article specifically and a partial recommendation of the author of that article. When 2 or 3-level deep recommendations are followed, suddenly a big part of all the articles may have some form of tagging. + +### Relays + +[NIP-51](51.md) lists of relays can be created with the kind 10102 and then used by wiki clients in order to determine where to query articles first and to rank these differently in relation to other events fetched from other relays. + +### Contact lists + +[NIP-02](02.md) contact lists can form the basis of a recommendation system that is then expanded with relay lists and reaction lists through nested queries. These lists form a good starting point only because they are so widespread. + +### Wiki-related contact lists + +[NIP-51](51.md) lists can also be used to create a list of users that are trusted only in the context of wiki authorship or wiki curationship. + +Forks +--------- +Wiki-events can tag other wiki-events with a `fork` marker to specify that this event came from a different version. Both `a` and `e` tags SHOULD be used and have the `fork` marker applied, to identify the exact version it was forked from. + +Deference +--------- +Wiki-events can tag other wiki-events with a `defer` marker to indicate that it considers someone else's entry as a "better" version of itself. If using a `defer` marker both `a` and `e` tags SHOULD be used. + +This is a stronger signal of trust than a `+` reaction. + +This marker is useful when a user edits someone else's entry; if the original author includes the editor's changes and the editor doesn't want to keep/maintain an indepedent version, the `link` tag could effectively be a considered a "deletion" of the editor's version and putting that pubkey's WoT weight behind the original author's version. + +Why Markdown? +------------- + +If the idea is to make a wiki then the most obvious text format to use is probably the mediawiki/wikitext format used by Wikipedia since it's widely deployed in all mediawiki installations and used for decades with great success. However, it turns out that format is very bloated and convoluted, has way too many features and probably because of that it doesn't have many alternative implementations out there, and the ones that exist are not complete and don't look very trustworthy. Also it is very much a centralized format that can probably be changed at the whims of the Wikipedia owners. + +On the other hand, Markdown has proven to work well for small scale wikis and one of the biggest wikis in the planet (which is not very often thought of as a wiki), [StackOverflow](https://stackoverflow.com) and its child sites, and also one of the biggest "personal wiki" software, [Obsidian](https://obsidian.md/). Markdown can probably deliver 95% of the functionality of wikitext. When augmented with tables, diagram generators and MathJax (which are common extensions that exist in the wild and can be included in this NIP) that rate probably goes to 99%, and its simplicity is a huge benefit that can't be overlooked. Wikitext format can also be transpíled into Markdown using Pandoc. Given all that, I think it's a reasonable suspicion that mediawiki is not inherently better than Markdown, the success of Wikipedia probably cannot be predicated on the syntax language choice. + +# Appendix 1: Merge requests +Users can request other users to get their entries merged into someone else's entry by creating a `kind:818` event. + +```js +{ + "content": "I added information about how to make hot ice-creams", + "kind": 818, + "tags": [ + [ "a", "30818:<destination-pubkey>:hot-ice-creams", "<relay-url>" ], + [ "e", "<version-against-which-the-modification-was-made>", "<relay-url>' ], + [ "p", "<destination-pubkey>" ], + [ "e", "<version-to-be-merged>", "<relay-url>", "source" ] + ] +} +``` + +`.content`: an optional explanation detailing why this merge is being requested. +`a` tag: tag of the article which should be modified (i.e. the target of this merge request). +`e` tag: optional version of the article in which this modifications is based +`e` tag with `source` marker: the ID of the event that should be merged. This event id MUST be of a `kind:30818` as defined in this NIP. + +The destination-pubkey (the pubkey being requested to merge something into their article can create [[NIP-25]] reactions that tag the `kind:818` event with `+` or `-` diff --git a/README.md b/README.md index 619c9846..b3736ea4 100644 --- a/README.md +++ b/README.md @@ -66,6 +66,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos - [NIP-51: Lists](51.md) - [NIP-52: Calendar Events](52.md) - [NIP-53: Live Activities](53.md) +- [NIP-54: Wiki](54.md) - [NIP-56: Reporting](56.md) - [NIP-57: Lightning Zaps](57.md) - [NIP-58: Badges](58.md) @@ -171,6 +172,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos | `30402` | Classified Listing | [99](99.md) | | `30403` | Draft Classified Listing | [99](99.md) | | `30617` | Repository announcements | [34](34.md) | +| `30818` | Wiki article | [54](54.md) | | `31922` | Date-Based Calendar Event | [52](52.md) | | `31923` | Time-Based Calendar Event | [52](52.md) | | `31924` | Calendar | [52](52.md) | From dcb5d0f18d6b0c60bda9abc79c6cca99a4d86177 Mon Sep 17 00:00:00 2001 From: fiatjaf <fiatjaf@gmail.com> Date: Thu, 2 May 2024 11:32:58 -0300 Subject: [PATCH 11/17] small fixes on nip 54. --- 54.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/54.md b/54.md index 9063ca95..78703303 100644 --- a/54.md +++ b/54.md @@ -3,6 +3,7 @@ NIP-54 Wiki ---- + `draft` `optional` This NIP defines `kind:30818` (a _parameterized replaceable event_) for long-form text content similar to [NIP-23](23.md), but with one important difference: articles are meant to be descriptions, or encyclopedia entries, of particular subjects, and it's expected that multiple people will write articles about the exact same subjects, with either small variations or completely independent content. @@ -10,7 +11,7 @@ This NIP defines `kind:30818` (a _parameterized replaceable event_) for long-for Articles are identified by lowercase, normalized ascii `d` tags. ### Articles -```js +```jsonc { "content": "A wiki is a hypertext publication collaboratively edited and managed by its own audience.", "tags": [ @@ -85,7 +86,7 @@ On the other hand, Markdown has proven to work well for small scale wikis and on # Appendix 1: Merge requests Users can request other users to get their entries merged into someone else's entry by creating a `kind:818` event. -```js +```jsonc { "content": "I added information about how to make hot ice-creams", "kind": 818, From 3834c6b60474a677b53847743212df27710e64ec Mon Sep 17 00:00:00 2001 From: Vitor Pamplona <vitor@vitorpamplona.com> Date: Sat, 4 May 2024 16:10:13 -0400 Subject: [PATCH 12/17] Simplifying reactions --- 25.md | 14 +++++--------- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/25.md b/25.md index 3b4aa590..bdee0666 100644 --- a/25.md +++ b/25.md @@ -25,14 +25,13 @@ consider it a "+". Tags ---- -The reaction event SHOULD include `e` and `p` tags from the note the user is -reacting to. This allows users to be notified of reactions to posts they were -mentioned in. Including the `e` tags enables clients to pull all the reactions -associated with individual posts or all the posts in a thread. +The reaction event SHOULD include `e` and `p` tags pointing to the note the user is +reacting to. The `p` tag allows authors to be notified. The `e` tags enables clients +to pull all the reactions to individual posts. -The last `e` tag MUST be the `id` of the note that is being reacted to. +The `e` tag MUST be the `id` of the note that is being reacted to. -The last `p` tag MUST be the `pubkey` of the event being reacted to. +The `p` tag MUST be the `pubkey` of the event being reacted to. The reaction event MAY include a `k` tag with the stringified kind number of the reacted event as its value. @@ -41,9 +40,6 @@ Example code ```swift func make_like_event(pubkey: String, privkey: String, liked: NostrEvent) -> NostrEvent { - var tags: [[String]] = liked.tags.filter { - tag in tag.count >= 2 && (tag[0] == "e" || tag[0] == "p") - } tags.append(["e", liked.id]) tags.append(["p", liked.pubkey]) tags.append(["k", liked.kind]) From 4bcf91944a9e53680cc928424e7af145242b1a39 Mon Sep 17 00:00:00 2001 From: Vitor Pamplona <vitor@vitorpamplona.com> Date: Sat, 4 May 2024 16:35:39 -0400 Subject: [PATCH 13/17] adds a tags. --- 25.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/25.md b/25.md index bdee0666..7cc96b5f 100644 --- a/25.md +++ b/25.md @@ -25,12 +25,15 @@ consider it a "+". Tags ---- -The reaction event SHOULD include `e` and `p` tags pointing to the note the user is +The reaction event SHOULD include `a`, `e` and `p` tags pointing to the note the user is reacting to. The `p` tag allows authors to be notified. The `e` tags enables clients -to pull all the reactions to individual posts. +to pull all the reactions to individual events and `a` tags enables clients to seek reactions +for all versions of a replaceable event. The `e` tag MUST be the `id` of the note that is being reacted to. +The `a` tag MUST contain the coordinates (`kind:pubkey:d-tag`) of the replaceable being reacted to. + The `p` tag MUST be the `pubkey` of the event being reacted to. The reaction event MAY include a `k` tag with the stringified kind number From c1360c4f0b111143747bad6226df6f00499f5cfe Mon Sep 17 00:00:00 2001 From: fiatjaf <fiatjaf@gmail.com> Date: Sat, 4 May 2024 23:34:37 -0300 Subject: [PATCH 14/17] nip54: add normalization rules. --- 54.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/54.md b/54.md index 78703303..c481eb63 100644 --- a/54.md +++ b/54.md @@ -21,7 +21,12 @@ Articles are identified by lowercase, normalized ascii `d` tags. } ``` -[INSERT NORMALIZATION EXAMPLES] +### `d` tag normalization rules + +- Any non-letter character MUST be converted to a `-`. +- All letters MUST be converted to lowercase. + +### Content rules The content should be Markdown, following the same rules as of [NIP-23](23.md), although it takes some extra (optional) metadata tags: From 4fa65b81cede9eaf8375d4f92bc80cf298190e0c Mon Sep 17 00:00:00 2001 From: fiatjaf <fiatjaf@gmail.com> Date: Sat, 4 May 2024 23:36:48 -0300 Subject: [PATCH 15/17] nip54: fix json indentation. --- 54.md | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/54.md b/54.md index c481eb63..2090182d 100644 --- a/54.md +++ b/54.md @@ -13,11 +13,11 @@ Articles are identified by lowercase, normalized ascii `d` tags. ### Articles ```jsonc { - "content": "A wiki is a hypertext publication collaboratively edited and managed by its own audience.", - "tags": [ - [ "d", "wiki" ], - [ "title", "Wiki" ], - ] + "content": "A wiki is a hypertext publication collaboratively edited and managed by its own audience.", + "tags": [ + ["d", "wiki"], + ["title", "Wiki"], + ] } ``` @@ -93,14 +93,14 @@ Users can request other users to get their entries merged into someone else's en ```jsonc { - "content": "I added information about how to make hot ice-creams", - "kind": 818, - "tags": [ - [ "a", "30818:<destination-pubkey>:hot-ice-creams", "<relay-url>" ], - [ "e", "<version-against-which-the-modification-was-made>", "<relay-url>' ], - [ "p", "<destination-pubkey>" ], - [ "e", "<version-to-be-merged>", "<relay-url>", "source" ] - ] + "content": "I added information about how to make hot ice-creams", + "kind": 818, + "tags": [ + [ "a", "30818:<destination-pubkey>:hot-ice-creams", "<relay-url>" ], + [ "e", "<version-against-which-the-modification-was-made>", "<relay-url>' ], + [ "p", "<destination-pubkey>" ], + [ "e", "<version-to-be-merged>", "<relay-url>", "source" ] + ] } ``` From cb9bddb8dfd11972286215d9bdee7434764ccf7b Mon Sep 17 00:00:00 2001 From: Adam Shannon <adamkshannon@gmail.com> Date: Sat, 11 May 2024 11:52:32 -0500 Subject: [PATCH 16/17] all: minor spelling fixes --- 34.md | 2 +- 46.md | 2 +- 54.md | 2 +- 72.md | 2 +- 90.md | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/34.md b/34.md index 03ee0391..fcc2cece 100644 --- a/34.md +++ b/34.md @@ -125,7 +125,7 @@ Root Patches and Issues have a Status that defaults to 'Open' and can be set by ["p", "<root-event-author>"], ["p", "<revision-author>"], - // optional for improved subscription filter efficency + // optional for improved subscription filter efficiency ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>", "<relay-url>"], ["r", "<earliest-unique-commit-id-of-repo>"] diff --git a/46.md b/46.md index e0a5b2ec..15281162 100644 --- a/46.md +++ b/46.md @@ -208,7 +208,7 @@ When the user types a NIP-05 the client: #### Remote signer discovery via NIP-89 -In this last case, most often used to fascilitate an OAuth-like signin flow, the client first looks for remote signers that have announced themselves via NIP-89 application handler events. +In this last case, most often used to facilitate an OAuth-like signin flow, the client first looks for remote signers that have announced themselves via NIP-89 application handler events. First the client will query for `kind: 31990` events that have a `k` tag of `24133`. diff --git a/54.md b/54.md index 2090182d..8823af9a 100644 --- a/54.md +++ b/54.md @@ -79,7 +79,7 @@ Wiki-events can tag other wiki-events with a `defer` marker to indicate that it This is a stronger signal of trust than a `+` reaction. -This marker is useful when a user edits someone else's entry; if the original author includes the editor's changes and the editor doesn't want to keep/maintain an indepedent version, the `link` tag could effectively be a considered a "deletion" of the editor's version and putting that pubkey's WoT weight behind the original author's version. +This marker is useful when a user edits someone else's entry; if the original author includes the editor's changes and the editor doesn't want to keep/maintain an independent version, the `link` tag could effectively be a considered a "deletion" of the editor's version and putting that pubkey's WoT weight behind the original author's version. Why Markdown? ------------- diff --git a/72.md b/72.md index 4bafce06..5a8be0a5 100644 --- a/72.md +++ b/72.md @@ -76,7 +76,7 @@ The post-approval event MUST include `a` tags of the communities the moderator i It's recommended that multiple moderators approve posts to avoid deleting them from the community when a moderator is removed from the owner's list. In case the full list of moderators must be rotated, the new moderator set must sign new approvals for posts in the past or the community will restart. The owner can also periodically copy and re-sign of each moderator's approval events to make sure posts don't disappear with moderators. -Post Approvals of replaceable events can be created in three ways: (i) by tagging the replaceable event as an `e` tag if moderators want to approve each individual change to the repleceable event; (ii) by tagging the replaceable event as an `a` tag if the moderator authorizes the replaceable event author to make changes without additional approvals and (iii) by tagging the replaceable event with both its `e` and `a` tag which empowers clients to display the original and updated versions of the event, with appropriate remarks in the UI. Since relays are instructed to delete old versions of a replaceable event, the `.content` of an `e`-approval MUST have the specific version of the event or Clients might not be able to find that version of the content anywhere. +Post Approvals of replaceable events can be created in three ways: (i) by tagging the replaceable event as an `e` tag if moderators want to approve each individual change to the replaceable event; (ii) by tagging the replaceable event as an `a` tag if the moderator authorizes the replaceable event author to make changes without additional approvals and (iii) by tagging the replaceable event with both its `e` and `a` tag which empowers clients to display the original and updated versions of the event, with appropriate remarks in the UI. Since relays are instructed to delete old versions of a replaceable event, the `.content` of an `e`-approval MUST have the specific version of the event or Clients might not be able to find that version of the content anywhere. Clients SHOULD evaluate any non-`34550:*` `a` tag as posts to be included in all `34550:*` `a` tags. diff --git a/90.md b/90.md index 241eb38f..2b499a85 100644 --- a/90.md +++ b/90.md @@ -199,7 +199,7 @@ Some service providers might choose to submit a `payment-required` as the first It's not up to this NIP to define how individual vending machines should choose to run their business. # Cancellation -A job request might be cancelled by publishing a `kind:5` delete request event tagging the job request event. +A job request might be canceled by publishing a `kind:5` delete request event tagging the job request event. # Appendix 1: Job chaining A Customer MAY request multiple jobs to be processed as a chain, where the output of a job is the input of another job. (e.g. podcast transcription -> summarization of the transcription). This is done by specifying as input an event id of a different job with the `job` type. From c2d9b40d5bcf2d04cd04c19b42065e5158ecbab8 Mon Sep 17 00:00:00 2001 From: Adam Shannon <adamkshannon@gmail.com> Date: Sat, 11 May 2024 12:38:01 -0500 Subject: [PATCH 17/17] nip90: fix links --- 90.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/90.md b/90.md index 2b499a85..5a15ebb6 100644 --- a/90.md +++ b/90.md @@ -162,8 +162,8 @@ Service providers can give feedback about a job back to the customer. ``` * `content`: Either empty or a job-result (e.g. for partial-result samples) -* `amount` tag: as defined in the [Job Result](#job-result) section. -* `status` tag: Service Providers SHOULD indicate what this feedback status refers to. [Appendix 1](#appendix-1-job-feedback-status) defines status. Extra human-readable information can be added as an extra argument. +* `amount` tag: as defined in the [Job Result](#job-result-kind6000-6999) section. +* `status` tag: Service Providers SHOULD indicate what this feedback status refers to. [Job Feedback Status](#job-feedback-status) defines status. Extra human-readable information can be added as an extra argument. * NOTE: If the input params requires input to be encrypted, then `content` field will have encrypted payload with `p` tag as key. @@ -177,7 +177,7 @@ Service providers can give feedback about a job back to the customer. | `success` | Service Provider successfully processed the job. | | `partial` | Service Provider partially processed the job. The `.content` might include a sample of the partial results. | -Any job feedback event MIGHT include results in the `.content` field, as described in the [Job Result](#job-result) section. This is useful for service providers to provide a sample of the results that have been processed so far. +Any job feedback event MIGHT include results in the `.content` field, as described in the [Job Result](#job-result-kind6000-6999) section. This is useful for service providers to provide a sample of the results that have been processed so far. # Protocol Flow