From dea4bebf4b1bf36feeb8a066bccf62b9b1aeb5c5 Mon Sep 17 00:00:00 2001 From: Terry Yiu <963907+tyiu@users.noreply.github.com> Date: Tue, 6 Aug 2024 23:55:47 -0400 Subject: [PATCH 01/14] Amend NIP-52 to include e and p tags to calendar event RSVPs --- 52.md | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/52.md b/52.md index f35d9040..077c8472 100644 --- a/52.md +++ b/52.md @@ -178,6 +178,12 @@ This NIP is intentionally not defining who is authorized to attend a calendar ev This NIP is also intentionally not defining what happens if a calendar event changes after an RSVP is submitted. +The RSVP MUST tag the calendar event it is in response to with an `e` tag on the calendar event's id. + +The RSVP MAY tag use an `a` tag to the calendar event's event coordinates to indicate that the RSVP response could hold trueregardless of any future revisions to the calendar event. If the `a` tag is omitted, the author of the RSVP is explicitly indicating that its response holds true for only that specific revision of the calendar event from the `e` tag. + +The RSVP MAY tag the author of the calendar event it is in response to using a `p` tag so that clients can easily query all RSVPs that pertain to the author. + ### Format The format uses a parameterized replaceable event kind `31925`. @@ -185,10 +191,12 @@ The format uses a parameterized replaceable event kind `31925`. The `.content` of these events is optional and should be a free-form note that adds more context to this calendar event response. The list of tags are as follows: -* `a` (required) reference tag to kind `31922` or `31923` calendar event being responded to. +* `e` (required) event tag to kind `31922` or `31923` calendar event being responded to. +* `a` (optional) reference tag to kind `31922` or `31923` calendar event being responded to. * `d` (required) universally unique identifier. Generated by the client creating the calendar event RSVP. * `status` (required) `accepted`, `declined`, or `tentative`. Determines attendance status to the referenced calendar event. * `fb` (optional) `free` or `busy`. Determines if the user would be free or busy for the duration of the calendar event. This tag must be omitted or ignored if the `status` label is set to `declined`. +* `p` (optional) author of the calendar event being responded to. ```json { @@ -198,10 +206,12 @@ The list of tags are as follows: "kind": 31925, "content": "", "tags": [ - ["a", "<31922 or 31923>::", ""], + ["e", ""] + ["a", "<31922 or 31923>::", ""], ["d", ""], ["status", ""], ["fb", ""], + ["p", "", ""] ] } ``` From d36b24c82a07ad9769d5ff9aa2e01cfa65ca0614 Mon Sep 17 00:00:00 2001 From: Terry Yiu <963907+tyiu@users.noreply.github.com> Date: Thu, 8 Aug 2024 01:04:25 -0400 Subject: [PATCH 02/14] Revise NIP-52 amendments so that they are backwards compatible --- 52.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/52.md b/52.md index fb857374..2b2f6db6 100644 --- a/52.md +++ b/52.md @@ -187,9 +187,11 @@ This NIP is intentionally not defining who is authorized to attend a calendar ev This NIP is also intentionally not defining what happens if a calendar event changes after an RSVP is submitted. -The RSVP MUST tag the calendar event it is in response to with an `e` tag on the calendar event's id. +The RSVP MUST have at least one of an `a` tag of the event coordinates to the calendar event, or `e` tag of the id of the specific calendar event revision. -The RSVP MAY tag use an `a` tag to the calendar event's event coordinates to indicate that the RSVP response could hold trueregardless of any future revisions to the calendar event. If the `a` tag is omitted, the author of the RSVP is explicitly indicating that its response holds true for only that specific revision of the calendar event from the `e` tag. +If an `e` tag is present, clients SHOULD interpret it as an indication that the RSVP is a response to that revision of the calendar event. + +If an `a` tag is present, clients SHOULD interpret it as an indication that the RSVP may hold true for all revisions of the calendar event. The RSVP MAY tag the author of the calendar event it is in response to using a `p` tag so that clients can easily query all RSVPs that pertain to the author. @@ -200,12 +202,12 @@ The format uses a parameterized replaceable event kind `31925`. The `.content` of these events is optional and should be a free-form note that adds more context to this calendar event response. The list of tags are as follows: -* `e` (required) event tag to kind `31922` or `31923` calendar event being responded to. -* `a` (optional) reference tag to kind `31922` or `31923` calendar event being responded to. +* `e` (optional) event id of a kind `31922` or `31923` calendar event being responded to. This tag is required if `a` is omitted. +* `a` (optional) coordinates to a kind `31922` or `31923` calendar event being responded to. This tag is required if `e` is omitted. * `d` (required) universally unique identifier. Generated by the client creating the calendar event RSVP. * `status` (required) `accepted`, `declined`, or `tentative`. Determines attendance status to the referenced calendar event. * `fb` (optional) `free` or `busy`. Determines if the user would be free or busy for the duration of the calendar event. This tag must be omitted or ignored if the `status` label is set to `declined`. -* `p` (optional) author of the calendar event being responded to. +* `p` (optional) pubkey of the author of the calendar event being responded to. ```json { From ec1f0fcadaa7b62cc17633cc5a86686e85ebe7a6 Mon Sep 17 00:00:00 2001 From: Terry Yiu <963907+tyiu@users.noreply.github.com> Date: Sun, 11 Aug 2024 15:50:39 -0400 Subject: [PATCH 03/14] Update NIP-52 change to not be backwards incompatible by restoring required 'a' tag and clarify how clients should or may interpret the optional 'e' tag --- 52.md | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/52.md b/52.md index 2b2f6db6..bedf613c 100644 --- a/52.md +++ b/52.md @@ -187,11 +187,7 @@ This NIP is intentionally not defining who is authorized to attend a calendar ev This NIP is also intentionally not defining what happens if a calendar event changes after an RSVP is submitted. -The RSVP MUST have at least one of an `a` tag of the event coordinates to the calendar event, or `e` tag of the id of the specific calendar event revision. - -If an `e` tag is present, clients SHOULD interpret it as an indication that the RSVP is a response to that revision of the calendar event. - -If an `a` tag is present, clients SHOULD interpret it as an indication that the RSVP may hold true for all revisions of the calendar event. +The RSVP MUST have an `a` tag of the event coordinates to the calendar event, and optionally an `e` tag of the id of the specific calendar event revision. If an `e` tag is present, clients SHOULD interpret it as an indication that the RSVP is a response to that revision of the calendar event, and MAY interpret it to not necessarily apply to other revisions of the calendar event. The RSVP MAY tag the author of the calendar event it is in response to using a `p` tag so that clients can easily query all RSVPs that pertain to the author. @@ -202,8 +198,8 @@ The format uses a parameterized replaceable event kind `31925`. The `.content` of these events is optional and should be a free-form note that adds more context to this calendar event response. The list of tags are as follows: -* `e` (optional) event id of a kind `31922` or `31923` calendar event being responded to. This tag is required if `a` is omitted. -* `a` (optional) coordinates to a kind `31922` or `31923` calendar event being responded to. This tag is required if `e` is omitted. +* `a` (required) coordinates to a kind `31922` or `31923` calendar event being responded to. +* `e` (optional) event id of a kind `31922` or `31923` calendar event being responded to. * `d` (required) universally unique identifier. Generated by the client creating the calendar event RSVP. * `status` (required) `accepted`, `declined`, or `tentative`. Determines attendance status to the referenced calendar event. * `fb` (optional) `free` or `busy`. Determines if the user would be free or busy for the duration of the calendar event. This tag must be omitted or ignored if the `status` label is set to `declined`. From e44491466836abfc567a9652392205d02b803ca7 Mon Sep 17 00:00:00 2001 From: theborakompanioni Date: Thu, 28 Dec 2023 14:59:53 +0100 Subject: [PATCH 04/14] docs(NIP-64): Portable Game Notation --- 64.md | 125 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 125 insertions(+) create mode 100644 64.md diff --git a/64.md b/64.md new file mode 100644 index 00000000..b65fb569 --- /dev/null +++ b/64.md @@ -0,0 +1,125 @@ +NIP-64 +====== + +Portable Game Notation +----- + +`draft` `optional` + +This NIP defines `kind:30` notes representing Chess games in [PGN][pgn_specification] format, which can be read by humans and is also supported by most chess software. + +## Note + +### Content + +The `.content` of these notes is a string representing a [PGN-database][pgn_formal_syntax]. + +### Tags + +A note can contain `e` tags of each move or a subset of moves with the hashed piece placement data of a [FEN][fen_wikipedia] string, e.g. +```shell +sha256('rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR') := '63e2bcdcf5b275cd48b535ed210fb321197c4296b08d04329ca2d8f4391342a4' +sha256('8/8/4R1p1/2k3p1/1p4P1/1P1b1P2/3K1n2/8') := 'e8f876dfe8adac7ee02413f2160bae5808b7ea27a190cc7d4896d5e64f600c3d' +``` + +```json +[ "e", "63e2bcdcf5b275cd48b535ed210fb321197c4296b08d04329ca2d8f4391342a4"] +[ "e", "e8f876dfe8adac7ee02413f2160bae5808b7ea27a190cc7d4896d5e64f600c3d"] +``` + +## Example + +### Content + +```pgn +// A game where nothing is known. Game still in progress, game abandoned, or result otherwise unknown. +// Maybe players died before a move has been made. +* +``` + +```pgn +1. e4 * +``` + +```pgn +[White "Fischer, Robert J."] +[Black "Spassky, Boris V."] + +1. e4 e5 2. Nf3 Nc6 3. Bb5 {This opening is called the Ruy Lopez.} * +``` + +```pgn +[Event "F/S Return Match"] +[Site "Belgrade, Serbia JUG"] +[Date "1992.11.04"] +[Round "29"] +[White "Fischer, Robert J."] +[Black "Spassky, Boris V."] +[Result "1/2-1/2"] + +1. e4 e5 2. Nf3 Nc6 3. Bb5 {This opening is called the Ruy Lopez.} 3... a6 +4. Ba4 Nf6 5. O-O Be7 6. Re1 b5 7. Bb3 d6 8. c3 O-O 9. h3 Nb8 10. d4 Nbd7 +11. c4 c6 12. cxb5 axb5 13. Nc3 Bb7 14. Bg5 b4 15. Nb1 h6 16. Bh4 c5 17. dxe5 +Nxe4 18. Bxe7 Qxe7 19. exd6 Qf6 20. Nbd2 Nxd6 21. Nc4 Nxc4 22. Bxc4 Nb6 +23. Ne5 Rae8 24. Bxf7+ Rxf7 25. Nxf7 Rxe1+ 26. Qxe1 Kxf7 27. Qe3 Qg5 28. Qxg5 +hxg5 29. b3 Ke6 30. a3 Kd6 31. axb4 cxb4 32. Ra5 Nd5 33. f3 Bc8 34. Kf2 Bf5 +35. Ra7 g6 36. Ra6+ Kc5 37. Ke1 Nf4 38. g3 Nxh3 39. Kd2 Kb5 40. Rd6 Kc5 41. Ra6 +Nf2 42. g4 Bd3 43. Re6 1/2-1/2 +``` + +### Notes + +```json +{ + "kind": 30, + "content": "1. e4 *", + ... +} +``` + +```json +{ + "kind": 30, + "tags": [ + ["alt", "Fischer vs. Spassky in Belgrade on 1992-11-04 (F/S Return Match, Round 29)"], + [ "e", "63e2bcdcf5b275cd48b535ed210fb321197c4296b08d04329ca2d8f4391342a4"], + ... + [ "e", "e8f876dfe8adac7ee02413f2160bae5808b7ea27a190cc7d4896d5e64f600c3d"] + ], + "content": "[Event \"F/S Return Match\"]\n[Site \"Belgrade, Serbia JUG\"]\n[Date \"1992.11.04\"]\n[Round \"29\"]\n[White \"Fischer, Robert J.\"]\n[Black \"Spassky, Boris V.\"]\n[Result \"1/2-1/2\"]\n\n1. e4 e5 2. Nf3 Nc6 3. Bb5 {This opening is called the Ruy Lopez.} 3... a6\n4. Ba4 Nf6 5. O-O Be7 6. Re1 b5 7. Bb3 d6 8. c3 O-O 9. h3 Nb8 10. d4 Nbd7\n11. c4 c6 12. cxb5 axb5 13. Nc3 Bb7 14. Bg5 b4 15. Nb1 h6 16. Bh4 c5 17. dxe5\nNxe4 18. Bxe7 Qxe7 19. exd6 Qf6 20. Nbd2 Nxd6 21. Nc4 Nxc4 22. Bxc4 Nb6\n23. Ne5 Rae8 24. Bxf7+ Rxf7 25. Nxf7 Rxe1+ 26. Qxe1 Kxf7 27. Qe3 Qg5 28. Qxg5\nhxg5 29. b3 Ke6 30. a3 Kd6 31. axb4 cxb4 32. Ra5 Nd5 33. f3 Bc8 34. Kf2 Bf5\n35. Ra7 g6 36. Ra6+ Kc5 37. Ke1 Nf4 38. g3 Nxh3 39. Kd2 Kb5 40. Rd6 Kc5 41. Ra6\nNf2 42. g4 Bd3 43. Re6 1/2-1/2" + ... +} +``` + +## Client Behavior + +Clients SHOULD check whether the formatting is valid and all moves comply with chess rules. + +Clients SHOULD display the content represented as chessboard. + +Clients SHOULD publish PGN notes in ["export format"][pgn_export_format] ("strict mode", i.e. created by machines) but expect incoming notes to be in ["import format"][pgn_import_format] ("lax mode", i.e. created by humans). + +Clients SHOULD add `e` tags of each move or a subset of moves (hashed piece placement data of a [FEN][fen_wikipedia] string) in order to improve discoverability of certain board positions. + +Clients MAY include additional tags (e.g. like [`"alt"`](https://github.com/nostr-protocol/nips/blob/master/31.md)) in order to represent the note to users of non-supporting clients. + +## Relay Behavior + +Relays MAY validate PGN contents and reject invalid notes. + +## Resources +- [PGN Specification][pgn_specification]: PGN (Portable Game Notation) specification +- [PGN Specification Supplement](https://github.com/mliebelt/pgn-spec-commented/blob/main/pgn-spec-supplement.md): Addition for adding graphical elements, clock values, eval, ... +- [PGN Formal Syntax][pgn_formal_syntax] +- [PGN Seven Tag Roster][pgn_seven_tag_roster] +- [PGN Import Format][pgn_import_format] +- [PGN Export Format][pgn_export_format] +- [Forsyth–Edwards Notation (FEN)][fen_wikipedia] +- [lichess / pgn-viewer (GitHub)](https://github.com/lichess-org/pgn-viewer): PGN viewer widget, designed to be embedded in content pages + +[pgn_specification]: https://github.com/mliebelt/pgn-spec-commented/blob/main/pgn-specification.md +[pgn_formal_syntax]: https://github.com/mliebelt/pgn-spec-commented/blob/main/pgn-specification.md#18-formal-syntax +[pgn_seven_tag_roster]: https://github.com/mliebelt/pgn-spec-commented/blob/main/pgn-specification.md#811-seven-tag-roster +[pgn_import_format]: https://github.com/mliebelt/pgn-spec-commented/blob/main/pgn-specification.md#31-import-format-allows-for-manually-prepared-data +[pgn_export_format]: https://github.com/mliebelt/pgn-spec-commented/blob/main/pgn-specification.md#32-export-format-used-for-program-generated-output +[fen_wikipedia]: https://en.wikipedia.org/wiki/Forsyth%E2%80%93Edwards_Notation From d476dea62ff54a3efda98ff8af027e5e6a3cb6ff Mon Sep 17 00:00:00 2001 From: theborakompanioni Date: Wed, 28 Feb 2024 16:16:34 +0100 Subject: [PATCH 05/14] docs(NIP-64): remove FEN tags --- 64.md | 19 ------------------- 1 file changed, 19 deletions(-) diff --git a/64.md b/64.md index b65fb569..8ea0ac65 100644 --- a/64.md +++ b/64.md @@ -14,19 +14,6 @@ This NIP defines `kind:30` notes representing Chess games in [PGN][pgn_specifica The `.content` of these notes is a string representing a [PGN-database][pgn_formal_syntax]. -### Tags - -A note can contain `e` tags of each move or a subset of moves with the hashed piece placement data of a [FEN][fen_wikipedia] string, e.g. -```shell -sha256('rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR') := '63e2bcdcf5b275cd48b535ed210fb321197c4296b08d04329ca2d8f4391342a4' -sha256('8/8/4R1p1/2k3p1/1p4P1/1P1b1P2/3K1n2/8') := 'e8f876dfe8adac7ee02413f2160bae5808b7ea27a190cc7d4896d5e64f600c3d' -``` - -```json -[ "e", "63e2bcdcf5b275cd48b535ed210fb321197c4296b08d04329ca2d8f4391342a4"] -[ "e", "e8f876dfe8adac7ee02413f2160bae5808b7ea27a190cc7d4896d5e64f600c3d"] -``` - ## Example ### Content @@ -82,9 +69,7 @@ Nf2 42. g4 Bd3 43. Re6 1/2-1/2 "kind": 30, "tags": [ ["alt", "Fischer vs. Spassky in Belgrade on 1992-11-04 (F/S Return Match, Round 29)"], - [ "e", "63e2bcdcf5b275cd48b535ed210fb321197c4296b08d04329ca2d8f4391342a4"], ... - [ "e", "e8f876dfe8adac7ee02413f2160bae5808b7ea27a190cc7d4896d5e64f600c3d"] ], "content": "[Event \"F/S Return Match\"]\n[Site \"Belgrade, Serbia JUG\"]\n[Date \"1992.11.04\"]\n[Round \"29\"]\n[White \"Fischer, Robert J.\"]\n[Black \"Spassky, Boris V.\"]\n[Result \"1/2-1/2\"]\n\n1. e4 e5 2. Nf3 Nc6 3. Bb5 {This opening is called the Ruy Lopez.} 3... a6\n4. Ba4 Nf6 5. O-O Be7 6. Re1 b5 7. Bb3 d6 8. c3 O-O 9. h3 Nb8 10. d4 Nbd7\n11. c4 c6 12. cxb5 axb5 13. Nc3 Bb7 14. Bg5 b4 15. Nb1 h6 16. Bh4 c5 17. dxe5\nNxe4 18. Bxe7 Qxe7 19. exd6 Qf6 20. Nbd2 Nxd6 21. Nc4 Nxc4 22. Bxc4 Nb6\n23. Ne5 Rae8 24. Bxf7+ Rxf7 25. Nxf7 Rxe1+ 26. Qxe1 Kxf7 27. Qe3 Qg5 28. Qxg5\nhxg5 29. b3 Ke6 30. a3 Kd6 31. axb4 cxb4 32. Ra5 Nd5 33. f3 Bc8 34. Kf2 Bf5\n35. Ra7 g6 36. Ra6+ Kc5 37. Ke1 Nf4 38. g3 Nxh3 39. Kd2 Kb5 40. Rd6 Kc5 41. Ra6\nNf2 42. g4 Bd3 43. Re6 1/2-1/2" ... @@ -99,8 +84,6 @@ Clients SHOULD display the content represented as chessboard. Clients SHOULD publish PGN notes in ["export format"][pgn_export_format] ("strict mode", i.e. created by machines) but expect incoming notes to be in ["import format"][pgn_import_format] ("lax mode", i.e. created by humans). -Clients SHOULD add `e` tags of each move or a subset of moves (hashed piece placement data of a [FEN][fen_wikipedia] string) in order to improve discoverability of certain board positions. - Clients MAY include additional tags (e.g. like [`"alt"`](https://github.com/nostr-protocol/nips/blob/master/31.md)) in order to represent the note to users of non-supporting clients. ## Relay Behavior @@ -114,7 +97,6 @@ Relays MAY validate PGN contents and reject invalid notes. - [PGN Seven Tag Roster][pgn_seven_tag_roster] - [PGN Import Format][pgn_import_format] - [PGN Export Format][pgn_export_format] -- [Forsyth–Edwards Notation (FEN)][fen_wikipedia] - [lichess / pgn-viewer (GitHub)](https://github.com/lichess-org/pgn-viewer): PGN viewer widget, designed to be embedded in content pages [pgn_specification]: https://github.com/mliebelt/pgn-spec-commented/blob/main/pgn-specification.md @@ -122,4 +104,3 @@ Relays MAY validate PGN contents and reject invalid notes. [pgn_seven_tag_roster]: https://github.com/mliebelt/pgn-spec-commented/blob/main/pgn-specification.md#811-seven-tag-roster [pgn_import_format]: https://github.com/mliebelt/pgn-spec-commented/blob/main/pgn-specification.md#31-import-format-allows-for-manually-prepared-data [pgn_export_format]: https://github.com/mliebelt/pgn-spec-commented/blob/main/pgn-specification.md#32-export-format-used-for-program-generated-output -[fen_wikipedia]: https://en.wikipedia.org/wiki/Forsyth%E2%80%93Edwards_Notation From 653642205e3e807c65b2e9b64f5325c7179c447c Mon Sep 17 00:00:00 2001 From: theborakompanioni Date: Wed, 28 Feb 2024 16:35:30 +0100 Subject: [PATCH 06/14] docs(NIP-64): move examples section to bottom --- 64.md | 120 ++++++++++++++++++++++++++++++++++++++-------------------- 1 file changed, 80 insertions(+), 40 deletions(-) diff --git a/64.md b/64.md index 8ea0ac65..bef63262 100644 --- a/64.md +++ b/64.md @@ -14,46 +14,6 @@ This NIP defines `kind:30` notes representing Chess games in [PGN][pgn_specifica The `.content` of these notes is a string representing a [PGN-database][pgn_formal_syntax]. -## Example - -### Content - -```pgn -// A game where nothing is known. Game still in progress, game abandoned, or result otherwise unknown. -// Maybe players died before a move has been made. -* -``` - -```pgn -1. e4 * -``` - -```pgn -[White "Fischer, Robert J."] -[Black "Spassky, Boris V."] - -1. e4 e5 2. Nf3 Nc6 3. Bb5 {This opening is called the Ruy Lopez.} * -``` - -```pgn -[Event "F/S Return Match"] -[Site "Belgrade, Serbia JUG"] -[Date "1992.11.04"] -[Round "29"] -[White "Fischer, Robert J."] -[Black "Spassky, Boris V."] -[Result "1/2-1/2"] - -1. e4 e5 2. Nf3 Nc6 3. Bb5 {This opening is called the Ruy Lopez.} 3... a6 -4. Ba4 Nf6 5. O-O Be7 6. Re1 b5 7. Bb3 d6 8. c3 O-O 9. h3 Nb8 10. d4 Nbd7 -11. c4 c6 12. cxb5 axb5 13. Nc3 Bb7 14. Bg5 b4 15. Nb1 h6 16. Bh4 c5 17. dxe5 -Nxe4 18. Bxe7 Qxe7 19. exd6 Qf6 20. Nbd2 Nxd6 21. Nc4 Nxc4 22. Bxc4 Nb6 -23. Ne5 Rae8 24. Bxf7+ Rxf7 25. Nxf7 Rxe1+ 26. Qxe1 Kxf7 27. Qe3 Qg5 28. Qxg5 -hxg5 29. b3 Ke6 30. a3 Kd6 31. axb4 cxb4 32. Ra5 Nd5 33. f3 Bc8 34. Kf2 Bf5 -35. Ra7 g6 36. Ra6+ Kc5 37. Ke1 Nf4 38. g3 Nxh3 39. Kd2 Kb5 40. Rd6 Kc5 41. Ra6 -Nf2 42. g4 Bd3 43. Re6 1/2-1/2 -``` - ### Notes ```json @@ -90,6 +50,86 @@ Clients MAY include additional tags (e.g. like [`"alt"`](https://github.com/nost Relays MAY validate PGN contents and reject invalid notes. + +## Examples + +```pgn +// A game where nothing is known. Game still in progress, game abandoned, or result otherwise unknown. +// Maybe players died before a move has been made. +* +``` + +```pgn +1. e4 * +``` + +```pgn +[White "Fischer, Robert J."] +[Black "Spassky, Boris V."] + +1. e4 e5 2. Nf3 Nc6 3. Bb5 {This opening is called the Ruy Lopez.} * +``` + +```pgn +[Event "F/S Return Match"] +[Site "Belgrade, Serbia JUG"] +[Date "1992.11.04"] +[Round "29"] +[White "Fischer, Robert J."] +[Black "Spassky, Boris V."] +[Result "1/2-1/2"] + +1. e4 e5 2. Nf3 Nc6 3. Bb5 {This opening is called the Ruy Lopez.} 3... a6 +4. Ba4 Nf6 5. O-O Be7 6. Re1 b5 7. Bb3 d6 8. c3 O-O 9. h3 Nb8 10. d4 Nbd7 +11. c4 c6 12. cxb5 axb5 13. Nc3 Bb7 14. Bg5 b4 15. Nb1 h6 16. Bh4 c5 17. dxe5 +Nxe4 18. Bxe7 Qxe7 19. exd6 Qf6 20. Nbd2 Nxd6 21. Nc4 Nxc4 22. Bxc4 Nb6 +23. Ne5 Rae8 24. Bxf7+ Rxf7 25. Nxf7 Rxe1+ 26. Qxe1 Kxf7 27. Qe3 Qg5 28. Qxg5 +hxg5 29. b3 Ke6 30. a3 Kd6 31. axb4 cxb4 32. Ra5 Nd5 33. f3 Bc8 34. Kf2 Bf5 +35. Ra7 g6 36. Ra6+ Kc5 37. Ke1 Nf4 38. g3 Nxh3 39. Kd2 Kb5 40. Rd6 Kc5 41. Ra6 +Nf2 42. g4 Bd3 43. Re6 1/2-1/2 +``` + +```pgn +[Event "Hourly HyperBullet Arena"] +[Site "https://lichess.org/wxx4GldJ"] +[Date "2017.04.01"] +[White "T_LUKE"] +[Black "decidement"] +[Result "1-0"] +[UTCDate "2017.04.01"] +[UTCTime "11:56:14"] +[WhiteElo "2047"] +[BlackElo "1984"] +[WhiteRatingDiff "+10"] +[BlackRatingDiff "-7"] +[Variant "Standard"] +[TimeControl "30+0"] +[ECO "B00"] +[Termination "Abandoned"] + +1. e4 1-0 + + +[Event "Hourly HyperBullet Arena"] +[Site "https://lichess.org/rospUdSk"] +[Date "2017.04.01"] +[White "Bastel"] +[Black "oslochess"] +[Result "1-0"] +[UTCDate "2017.04.01"] +[UTCTime "11:55:56"] +[WhiteElo "2212"] +[BlackElo "2000"] +[WhiteRatingDiff "+6"] +[BlackRatingDiff "-4"] +[Variant "Standard"] +[TimeControl "30+0"] +[ECO "A01"] +[Termination "Normal"] + +1. b3 d5 2. Bb2 c6 3. Nc3 Bf5 4. d4 Nf6 5. e3 Nbd7 6. f4 Bg6 7. Nf3 Bh5 8. Bd3 e6 9. O-O Be7 10. Qe1 O-O 11. Ne5 Bg6 12. Nxg6 hxg6 13. e4 dxe4 14. Nxe4 Nxe4 15. Bxe4 Nf6 16. c4 Bd6 17. Bc2 Qc7 18. f5 Be7 19. fxe6 fxe6 20. Qxe6+ Kh8 21. Qh3+ Kg8 22. Bxg6 Qd7 23. Qe3 Bd6 24. Bf5 Qe7 25. Be6+ Kh8 26. Qh3+ Nh7 27. Bf5 Rf6 28. Qxh7# 1-0 +``` + ## Resources - [PGN Specification][pgn_specification]: PGN (Portable Game Notation) specification - [PGN Specification Supplement](https://github.com/mliebelt/pgn-spec-commented/blob/main/pgn-spec-supplement.md): Addition for adding graphical elements, clock values, eval, ... From e735ef9aeff1e5d18d0dfa7a163b1bdc63ee742e Mon Sep 17 00:00:00 2001 From: theborakompanioni Date: Wed, 28 Feb 2024 16:41:40 +0100 Subject: [PATCH 07/14] docs(NIP-64): change kind from 30 to 64 --- 64.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/64.md b/64.md index bef63262..dd6ee849 100644 --- a/64.md +++ b/64.md @@ -6,7 +6,7 @@ Portable Game Notation `draft` `optional` -This NIP defines `kind:30` notes representing Chess games in [PGN][pgn_specification] format, which can be read by humans and is also supported by most chess software. +This NIP defines `kind:64` notes representing games in [PGN][pgn_specification] format, which can be read by humans and is also supported by most chess software. ## Note @@ -18,7 +18,7 @@ The `.content` of these notes is a string representing a [PGN-database][pgn_form ```json { - "kind": 30, + "kind": 64, "content": "1. e4 *", ... } @@ -26,7 +26,7 @@ The `.content` of these notes is a string representing a [PGN-database][pgn_form ```json { - "kind": 30, + "kind": 64, "tags": [ ["alt", "Fischer vs. Spassky in Belgrade on 1992-11-04 (F/S Return Match, Round 29)"], ... @@ -38,12 +38,12 @@ The `.content` of these notes is a string representing a [PGN-database][pgn_form ## Client Behavior -Clients SHOULD check whether the formatting is valid and all moves comply with chess rules. - Clients SHOULD display the content represented as chessboard. Clients SHOULD publish PGN notes in ["export format"][pgn_export_format] ("strict mode", i.e. created by machines) but expect incoming notes to be in ["import format"][pgn_import_format] ("lax mode", i.e. created by humans). +Clients SHOULD check whether the formatting is valid and all moves comply with chess rules. + Clients MAY include additional tags (e.g. like [`"alt"`](https://github.com/nostr-protocol/nips/blob/master/31.md)) in order to represent the note to users of non-supporting clients. ## Relay Behavior From 5d37fea585f93fb98743f37f5f1318894b99a246 Mon Sep 17 00:00:00 2001 From: theborakompanioni Date: Fri, 8 Mar 2024 13:26:47 +0100 Subject: [PATCH 08/14] docs(NIP-64): add chess to title make clear that the nip is about chess --- 64.md | 4 ++-- README.md | 2 ++ 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/64.md b/64.md index dd6ee849..6d8d3736 100644 --- a/64.md +++ b/64.md @@ -1,12 +1,12 @@ NIP-64 ====== -Portable Game Notation +Chess (Portable Game Notation) ----- `draft` `optional` -This NIP defines `kind:64` notes representing games in [PGN][pgn_specification] format, which can be read by humans and is also supported by most chess software. +This NIP defines `kind:64` notes representing chess games in [PGN][pgn_specification] format, which can be read by humans and is also supported by most chess software. ## Note diff --git a/README.md b/README.md index d6840fcd..82778f85 100644 --- a/README.md +++ b/README.md @@ -73,6 +73,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos - [NIP-57: Lightning Zaps](57.md) - [NIP-58: Badges](58.md) - [NIP-59: Gift Wrap](59.md) +- [NIP-64: Chess (PGN)](64.md) - [NIP-65: Relay List Metadata](65.md) - [NIP-70: Protected Events](70.md) - [NIP-71: Video Events](71.md) @@ -115,6 +116,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos | `42` | Channel Message | [28](28.md) | | `43` | Channel Hide Message | [28](28.md) | | `44` | Channel Mute User | [28](28.md) | +| `64` | Chess (PGN) | [64](64.md) | | `818` | Merge Requests | [54](54.md) | | `1021` | Bid | [15](15.md) | | `1022` | Bid confirmation | [15](15.md) | From 452fcc05a0b8e3ed1554aafc6ca1aea20bfc1835 Mon Sep 17 00:00:00 2001 From: Asai Toshiya Date: Wed, 14 Aug 2024 23:44:30 +0900 Subject: [PATCH 09/14] README: add NIP-52 link to `image` and `summary` tags --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 82778f85..e9a10a45 100644 --- a/README.md +++ b/README.md @@ -264,7 +264,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos | `encrypted` | -- | -- | [90](90.md) | | `expiration` | unix timestamp (string) | -- | [40](40.md) | | `goal` | event id (hex) | relay URL | [75](75.md) | -| `image` | image URL | dimensions in pixels | [23](23.md), [58](58.md) | +| `image` | image URL | dimensions in pixels | [23](23.md), [52](52.md), [58](58.md) | | `imeta` | inline metadata | -- | [92](92.md) | | `lnurl` | `bech32` encoded `lnurl` | -- | [57](57.md) | | `location` | location string | -- | [52](52.md), [99](99.md) | @@ -278,7 +278,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos | `relays` | relay list | -- | [57](57.md) | | `server` | file storage server url | -- | [96](96.md) | | `subject` | subject | -- | [14](14.md), [17](17.md) | -| `summary` | article summary | -- | [23](23.md) | +| `summary` | summary | -- | [23](23.md), [52](52.md) | | `thumb` | badge thumbnail | dimensions in pixels | [58](58.md) | | `title` | article title | -- | [23](23.md) | | `web` | webpage URL | -- | [34](34.md) | From 95885afe2da245b0c4d80b91e9e44ee7f5ad447f Mon Sep 17 00:00:00 2001 From: Terry Yiu <963907+tyiu@users.noreply.github.com> Date: Wed, 14 Aug 2024 20:02:13 -0400 Subject: [PATCH 10/14] Update NIP-09 to rename deletion to retraction --- 09.md | 26 ++++++++++++++------------ 32.md | 2 +- 34.md | 2 +- 71.md | 2 +- 72.md | 2 +- 90.md | 2 +- README.md | 4 ++-- 7 files changed, 21 insertions(+), 19 deletions(-) diff --git a/09.md b/09.md index b6aa72c7..f153aba1 100644 --- a/09.md +++ b/09.md @@ -1,14 +1,14 @@ NIP-09 ====== -Event Deletion +Event Retraction -------------- `draft` `optional` -A special event with kind `5`, meaning "deletion" is defined as having a list of one or more `e` or `a` tags, each referencing an event the author is requesting to be deleted. Deletion requests SHOULD include a `k` tag for the kind of each event being deleted. +A special event with kind `5`, meaning "retraction" is defined as having a list of one or more `e` or `a` tags, each referencing an event the author is requesting to be retracted. Retraction requests SHOULD include a `k` tag for the kind of each event being retracted. -The event's `content` field MAY contain a text note describing the reason for the deletion. +The event's `content` field MAY contain a text note describing the reason for the retraction. For example: @@ -28,24 +28,26 @@ For example: } ``` -Relays SHOULD delete or stop publishing any referenced events that have an identical `pubkey` as the deletion request. Clients SHOULD hide or otherwise indicate a deletion status for referenced events. +Relays SHOULD delete or stop publishing any referenced events that have an identical `pubkey` as the retraction request. Clients SHOULD hide or otherwise indicate a retraction status for referenced events. -Relays SHOULD continue to publish/share the deletion events indefinitely, as clients may already have the event that's intended to be deleted. Additionally, clients SHOULD broadcast deletion events to other relays which don't have it. +Relays SHOULD continue to publish/share the retraction events indefinitely, as clients may already have the event that's intended to be retracted. Additionally, clients SHOULD broadcast retraction events to other relays which don't have it. -When an `a` tag is used, relays SHOULD delete all versions of the replaceable event up to the `created_at` timestamp of the deletion event. +When an `a` tag is used, relays SHOULD delete all versions of the replaceable event up to the `created_at` timestamp of the retraction event. ## Client Usage -Clients MAY choose to fully hide any events that are referenced by valid deletion events. This includes text notes, direct messages, or other yet-to-be defined event kinds. Alternatively, they MAY show the event along with an icon or other indication that the author has "disowned" the event. The `content` field MAY also be used to replace the deleted events' own content, although a user interface should clearly indicate that this is a deletion reason, not the original content. +Clients MAY choose to fully hide any events that are referenced by valid retraction events. This includes text notes, direct messages, or other yet-to-be defined event kinds. Alternatively, they MAY show the event along with an icon or other indication that the author has "disowned" the event. The `content` field MAY also be used to replace the retracted events' own content, although a user interface should clearly indicate that this is a retraction reason, not the original content. -A client MUST validate that each event `pubkey` referenced in the `e` tag of the deletion request is identical to the deletion request `pubkey`, before hiding or deleting any event. Relays can not, in general, perform this validation and should not be treated as authoritative. +A client MUST validate that each event `pubkey` referenced in the `e` tag of the retraction request is identical to the retraction request `pubkey`, before hiding or deleting any event. Relays can not, in general, perform this validation and should not be treated as authoritative. -Clients display the deletion event itself in any way they choose, e.g., not at all, or with a prominent notice. +Clients display the retraction event itself in any way they choose, e.g., not at all, or with a prominent notice. + +Clients MAY choose to inform the user that their request for retraction does not guarantee deletion because it is impossible to delete events from all relays and clients. ## Relay Usage -Relays MAY validate that a deletion event only references events that have the same `pubkey` as the deletion itself, however this is not required since relays may not have knowledge of all referenced events. +Relays MAY validate that a retraction event only references events that have the same `pubkey` as the retraction itself, however this is not required since relays may not have knowledge of all referenced events. -## Deleting a Deletion +## Retracting a Retraction -Publishing a deletion event against a deletion has no effect. Clients and relays are not obliged to support "undelete" functionality. +Publishing a retraction event against a retraction has no effect. Clients and relays are not obliged to support "unretract" functionality. diff --git a/32.md b/32.md index 0fb765a7..08966fcd 100644 --- a/32.md +++ b/32.md @@ -145,7 +145,7 @@ Author is labeling their note language as English using ISO-639-1. Other Notes ----------- -When using this NIP to bulk-label many targets at once, events may be deleted and a replacement +When using this NIP to bulk-label many targets at once, events may be retracted using [NIP-09](09.md) and a replacement may be published. We have opted not to use parameterizable/replaceable events for this due to the complexity in coming up with a standard `d` tag. In order to avoid ambiguity when querying, publishers SHOULD limit labeling events to a single namespace. diff --git a/34.md b/34.md index 4989803d..14c76058 100644 --- a/34.md +++ b/34.md @@ -53,7 +53,7 @@ An optional source of truth for the state of branches and tags in a repository. The `refs` tag may appear multiple times, or none. -If no `refs` tags are present, the author is no longer tracking repository state using this event. This approach enables the author to restart tracking state at a later time unlike [NIP-09](09.md) deletion. +If no `refs` tags are present, the author is no longer tracking repository state using this event. This approach enables the author to restart tracking state at a later time unlike [NIP-09](09.md) retraction. The `refs` tag can be optionally extended to enable clients to identify how many commits ahead a ref is: diff --git a/71.md b/71.md index a811434c..51ea4b91 100644 --- a/71.md +++ b/71.md @@ -6,7 +6,7 @@ Video Events `draft` `optional` -This specification defines video events representing a dedicated post of externally hosted content. These video events are _parameterized replaceable_ and deletable per [NIP-09](09.md). +This specification defines video events representing a dedicated post of externally hosted content. These video events are _parameterized replaceable_ and retractable per [NIP-09](09.md). Unlike a `kind 1` event with a video attached, Video Events are meant to contain all additional metadata concerning the subject media and to be surfaced in video-specific clients rather than general micro-blogging clients. The thought is for events of this kind to be referenced in a Netflix, YouTube, or TikTok like nostr client where the video itself is at the center of the experience. diff --git a/72.md b/72.md index d19b80b4..ffa921f6 100644 --- a/72.md +++ b/72.md @@ -62,7 +62,7 @@ An approval event MUST include one or more community `a` tags, an `e` or `a` tag The event SHOULD also include the JSON-stringified `post request` event inside the `.content`, and a `k` tag with the original post's event kind to allow filtering of approved posts by kind. -Moderators MAY delete their approval of a post at any time using NIP 09 event deletions. +Moderators MAY retract their approval of a post at any time using NIP 09 event retractions. ```jsonc { diff --git a/90.md b/90.md index 5a15ebb6..a5f85873 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 canceled by publishing a `kind:5` delete request event tagging the job request event. +A job request might be canceled by publishing a `kind:5` retract 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. diff --git a/README.md b/README.md index e9a10a45..3cc5fe6b 100644 --- a/README.md +++ b/README.md @@ -30,7 +30,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos - [NIP-06: Basic key derivation from mnemonic seed phrase](06.md) - [NIP-07: `window.nostr` capability for web browsers](07.md) - [NIP-08: Handling Mentions](08.md) --- **unrecommended**: deprecated in favor of [NIP-27](27.md) -- [NIP-09: Event Deletion](09.md) +- [NIP-09: Event Retraction](09.md) - [NIP-10: Conventions for clients' use of `e` and `p` tags in text events](10.md) - [NIP-11: Relay Information Document](11.md) - [NIP-13: Proof of Work](13.md) @@ -99,7 +99,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos | `2` | Recommend Relay | 01 (deprecated) | | `3` | Follows | [02](02.md) | | `4` | Encrypted Direct Messages | [04](04.md) | -| `5` | Event Deletion | [09](09.md) | +| `5` | Event Retraction | [09](09.md) | | `6` | Repost | [18](18.md) | | `7` | Reaction | [25](25.md) | | `8` | Badge Award | [58](58.md) | From 0ee877275a339d7a29915ddb6a4b37feb714c61d Mon Sep 17 00:00:00 2001 From: Terry Yiu <963907+tyiu@users.noreply.github.com> Date: Thu, 15 Aug 2024 01:19:07 -0400 Subject: [PATCH 11/14] Update NIP-09 to rename to deletion request --- 09.md | 26 +++++++++++++------------- 32.md | 2 +- 34.md | 2 +- 71.md | 2 +- 72.md | 2 +- 90.md | 2 +- README.md | 4 ++-- 7 files changed, 20 insertions(+), 20 deletions(-) diff --git a/09.md b/09.md index f153aba1..e1be5429 100644 --- a/09.md +++ b/09.md @@ -1,14 +1,14 @@ NIP-09 ====== -Event Retraction +Event Deletion Request -------------- `draft` `optional` -A special event with kind `5`, meaning "retraction" is defined as having a list of one or more `e` or `a` tags, each referencing an event the author is requesting to be retracted. Retraction requests SHOULD include a `k` tag for the kind of each event being retracted. +A special event with kind `5`, meaning "deletion request" is defined as having a list of one or more `e` or `a` tags, each referencing an event the author is requesting to be deleted. Deletion requests SHOULD include a `k` tag for the kind of each event being requested for deletion. -The event's `content` field MAY contain a text note describing the reason for the retraction. +The event's `content` field MAY contain a text note describing the reason for the deletion request. For example: @@ -28,26 +28,26 @@ For example: } ``` -Relays SHOULD delete or stop publishing any referenced events that have an identical `pubkey` as the retraction request. Clients SHOULD hide or otherwise indicate a retraction status for referenced events. +Relays SHOULD delete or stop publishing any referenced events that have an identical `pubkey` as the deletion request. Clients SHOULD hide or otherwise indicate a deletion request status for referenced events. -Relays SHOULD continue to publish/share the retraction events indefinitely, as clients may already have the event that's intended to be retracted. Additionally, clients SHOULD broadcast retraction events to other relays which don't have it. +Relays SHOULD continue to publish/share the deletion request events indefinitely, as clients may already have the event that's intended to be deleted. Additionally, clients SHOULD broadcast deletion request events to other relays which don't have it. -When an `a` tag is used, relays SHOULD delete all versions of the replaceable event up to the `created_at` timestamp of the retraction event. +When an `a` tag is used, relays SHOULD delete all versions of the replaceable event up to the `created_at` timestamp of the deletion request event. ## Client Usage -Clients MAY choose to fully hide any events that are referenced by valid retraction events. This includes text notes, direct messages, or other yet-to-be defined event kinds. Alternatively, they MAY show the event along with an icon or other indication that the author has "disowned" the event. The `content` field MAY also be used to replace the retracted events' own content, although a user interface should clearly indicate that this is a retraction reason, not the original content. +Clients MAY choose to fully hide any events that are referenced by valid deletion request events. This includes text notes, direct messages, or other yet-to-be defined event kinds. Alternatively, they MAY show the event along with an icon or other indication that the author has "disowned" the event. The `content` field MAY also be used to replace the deleted events' own content, although a user interface should clearly indicate that this is a deletion request reason, not the original content. -A client MUST validate that each event `pubkey` referenced in the `e` tag of the retraction request is identical to the retraction request `pubkey`, before hiding or deleting any event. Relays can not, in general, perform this validation and should not be treated as authoritative. +A client MUST validate that each event `pubkey` referenced in the `e` tag of the deletion request is identical to the deletion request `pubkey`, before hiding or deleting any event. Relays can not, in general, perform this validation and should not be treated as authoritative. -Clients display the retraction event itself in any way they choose, e.g., not at all, or with a prominent notice. +Clients display the deletion request event itself in any way they choose, e.g., not at all, or with a prominent notice. -Clients MAY choose to inform the user that their request for retraction does not guarantee deletion because it is impossible to delete events from all relays and clients. +Clients MAY choose to inform the user that their request for deletion does not guarantee deletion because it is impossible to delete events from all relays and clients. ## Relay Usage -Relays MAY validate that a retraction event only references events that have the same `pubkey` as the retraction itself, however this is not required since relays may not have knowledge of all referenced events. +Relays MAY validate that a deletion request event only references events that have the same `pubkey` as the deletion request itself, however this is not required since relays may not have knowledge of all referenced events. -## Retracting a Retraction +## Deletion Request of a Deletion Request -Publishing a retraction event against a retraction has no effect. Clients and relays are not obliged to support "unretract" functionality. +Publishing a deletion request event against a deletion request has no effect. Clients and relays are not obliged to support "unrequest deletion" functionality. diff --git a/32.md b/32.md index 08966fcd..92d18ebd 100644 --- a/32.md +++ b/32.md @@ -145,7 +145,7 @@ Author is labeling their note language as English using ISO-639-1. Other Notes ----------- -When using this NIP to bulk-label many targets at once, events may be retracted using [NIP-09](09.md) and a replacement +When using this NIP to bulk-label many targets at once, events may be requested for deletion using [NIP-09](09.md) and a replacement may be published. We have opted not to use parameterizable/replaceable events for this due to the complexity in coming up with a standard `d` tag. In order to avoid ambiguity when querying, publishers SHOULD limit labeling events to a single namespace. diff --git a/34.md b/34.md index 14c76058..69f460b7 100644 --- a/34.md +++ b/34.md @@ -53,7 +53,7 @@ An optional source of truth for the state of branches and tags in a repository. The `refs` tag may appear multiple times, or none. -If no `refs` tags are present, the author is no longer tracking repository state using this event. This approach enables the author to restart tracking state at a later time unlike [NIP-09](09.md) retraction. +If no `refs` tags are present, the author is no longer tracking repository state using this event. This approach enables the author to restart tracking state at a later time unlike [NIP-09](09.md) deletion requests. The `refs` tag can be optionally extended to enable clients to identify how many commits ahead a ref is: diff --git a/71.md b/71.md index 51ea4b91..2743b2b1 100644 --- a/71.md +++ b/71.md @@ -6,7 +6,7 @@ Video Events `draft` `optional` -This specification defines video events representing a dedicated post of externally hosted content. These video events are _parameterized replaceable_ and retractable per [NIP-09](09.md). +This specification defines video events representing a dedicated post of externally hosted content. These video events are _parameterized replaceable_ and delete requestable per [NIP-09](09.md). Unlike a `kind 1` event with a video attached, Video Events are meant to contain all additional metadata concerning the subject media and to be surfaced in video-specific clients rather than general micro-blogging clients. The thought is for events of this kind to be referenced in a Netflix, YouTube, or TikTok like nostr client where the video itself is at the center of the experience. diff --git a/72.md b/72.md index ffa921f6..b2f523b4 100644 --- a/72.md +++ b/72.md @@ -62,7 +62,7 @@ An approval event MUST include one or more community `a` tags, an `e` or `a` tag The event SHOULD also include the JSON-stringified `post request` event inside the `.content`, and a `k` tag with the original post's event kind to allow filtering of approved posts by kind. -Moderators MAY retract their approval of a post at any time using NIP 09 event retractions. +Moderators MAY request deletion of their approval of a post at any time using [NIP-09 event deletion requests](09.md). ```jsonc { diff --git a/90.md b/90.md index a5f85873..5a15ebb6 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 canceled by publishing a `kind:5` retract 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. diff --git a/README.md b/README.md index 3cc5fe6b..8bf036b5 100644 --- a/README.md +++ b/README.md @@ -30,7 +30,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos - [NIP-06: Basic key derivation from mnemonic seed phrase](06.md) - [NIP-07: `window.nostr` capability for web browsers](07.md) - [NIP-08: Handling Mentions](08.md) --- **unrecommended**: deprecated in favor of [NIP-27](27.md) -- [NIP-09: Event Retraction](09.md) +- [NIP-09: Event Deletion Request](09.md) - [NIP-10: Conventions for clients' use of `e` and `p` tags in text events](10.md) - [NIP-11: Relay Information Document](11.md) - [NIP-13: Proof of Work](13.md) @@ -99,7 +99,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos | `2` | Recommend Relay | 01 (deprecated) | | `3` | Follows | [02](02.md) | | `4` | Encrypted Direct Messages | [04](04.md) | -| `5` | Event Retraction | [09](09.md) | +| `5` | Event Deletion Request | [09](09.md) | | `6` | Repost | [18](18.md) | | `7` | Reaction | [25](25.md) | | `8` | Badge Award | [58](58.md) | From 055101786bb4570f00a14f347c22545833922414 Mon Sep 17 00:00:00 2001 From: sepehr-safari Date: Sun, 18 Aug 2024 14:54:21 +0330 Subject: [PATCH 12/14] add kind 9008 for deleting a group --- 29.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/29.md b/29.md index 74dfd666..7a599b56 100644 --- a/29.md +++ b/29.md @@ -120,6 +120,7 @@ Each moderation action uses a different kind and requires different arguments, w | 9005 | `delete-event` | `e` (id hex) | | 9006 | `edit-group-status` | `public` or `private`, `open` or `closed` | | 9007 | `create-group` | | +| 9008 | `delete-group` | | - *group metadata* (`kind:39000`) (optional) @@ -160,6 +161,7 @@ The list of capabilities, as defined by this NIP, for now, is the following: - `add-permission` - `remove-permission` - `edit-group-status` +- `delete-group` ```js { From 62ac522333d374f9c8bab95f08413f13cf648038 Mon Sep 17 00:00:00 2001 From: sepehr-safari Date: Sun, 18 Aug 2024 14:57:50 +0330 Subject: [PATCH 13/14] add kind 9022 for leave request --- 29.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/29.md b/29.md index 7a599b56..c2b86f1f 100644 --- a/29.md +++ b/29.md @@ -93,6 +93,20 @@ Any user can send one of these events to the relay in order to be automatically } ``` +- *leave request* (`kind:9022`) + +Any user can send one of these events to the relay in order to be automatically removed from the group. The relay will automatically issue a `kind:9001` in response removing this user. + +```js +{ + "kind": 9022, + "content": "optional reason", + "tags": [ + ["h", ""] + ] +} +``` + - *moderation events* (`kinds:9000-9020`) (optional) Clients can send these events to a relay in order to accomplish a moderation action. Relays must check if the pubkey sending the event is capable of performing the given action. The relay may discard the event after taking action or keep it as a moderation log. From 3aff37bd4bfd2e28dda2d53367f6e7a322370498 Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Sun, 9 Jun 2024 21:16:01 -0300 Subject: [PATCH 14/14] nip54: change to asciidoc, markdown is trash. --- 54.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/54.md b/54.md index fe469185..0c2dd1c4 100644 --- a/54.md +++ b/54.md @@ -28,13 +28,13 @@ Articles are identified by lowercase, normalized ascii `d` tags. ### 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: +The content should be Asciidoc, 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. +One extra functionality is added: **wikilinks**. Unlike normal Asciidoc 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. Wikilinks can take these two forms: @@ -86,12 +86,12 @@ 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 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? +Why Asciidoc? ------------- -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. +Wikitext is [garbage](nostr:nevent1qqsqt0gcggry60n72uglhuhypdlmr2dm6swjj69jex5v530gcpazlzsprpmhxue69uhhyetvv9ujumn0wdmksetjv5hxxmmdqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hsygpm7rrrljungc6q0tuh5hj7ue863q73qlheu4vywtzwhx42a7j9n5ueneex) and Markdown is not powerful enough (besides being too freeform and unspecified and prone to generate incompatibilities in the future). -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. +Asciidoc has a strict spec, multiple implementations in many languages, and support for features that are very much necessary in a wiki article, like _sidebars_, _tables_ (with rich markup inside cells), many levels of _headings_, _footnotes_, _superscript_ and _subscript_ markup and _description lists_. It is also arguably easier to read in its plaintext format than Markdown (and certainly much better than Wikitext). # 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.