NIP-34!: use NIP-22 thread style for patch and status events

34.md

@@ -67,25 +67,32 @@ The `refs` tag can be optionally extended to enable clients to identify how many
 
 ## 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 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. Root patch and revision root 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.
+Additional patches in a patch set SHOULD follow NIP-22 style threading. NIP-10 stye is deprecated.
 
-The first patch revision in a patch revision SHOULD include a NIP-10 `e` `reply` to the original root patch.
+Patches can be appended to an existing patch set however revisions, which are equivalent to a `git push --force`, should reference the original patch set and become a new NIP-22 root event. This mirrors git patches over email.
 
 ```jsonc
 {
   "kind": 1617,
   "content": "<patch>", // contents of <git format-patch>
   "tags": [
+    // root or revision root
+    ["t", "root"],
     ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>"],
-    ["r", "<earliest-unique-commit-id-of-repo>"] // so clients can subscribe to all patches sent to a local git repo
+    ["r", "<earliest-unique-commit-id-of-repo>"] // so clients can subscribe to all root patches sent to a local git repo
     ["p", "<repository-owner>"],
     ["p", "<other-user>"], // optionally send the patch to another user to bring it to their attention
 
-    ["t", "root"], // omitted for additional patches in a series
-    // for the first patch in a revision
-    ["t", "root-revision"],
+    ["t", "root-revision"], // for the first patch in a revision
+
+    // for additional patches in a set use NIP-22 references
+    ["K", "1617"],
+    ["E", "<root-or-revision-root-event-id>"],
+    ["P", "<root-or-revision-root-pubkey>"],
+    ["e", "<parent-patch-event-id>"]
+    ["p", "<parent-pubkey>"]
 
     // optional tags for when it is desirable that the merged patch has a stable commit id
     // these fields are necessary for ensuring that the commit resulting from applying a patch
@@ -124,24 +131,7 @@ Issues may have a `subject` tag, which clients can utilize to display a header.
 
 ## Replies
 
-Replies are also Markdown text. The difference is that they MUST be issued as replies to either a `kind:1621` _issue_ or a `kind:1617` _patch_ event. The threading of replies and patches should follow NIP-10 rules.
-
-```jsonc
-{
-  "kind": 1622,
-  "content": "<markdown text>",
-  "tags": [
-    ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>", "<relay-url>"],
-    ["e", "<issue-or-patch-id-hex>", "", "root"],
-
-    // other "e" and "p" tags should be applied here when necessary, following the threading rules of NIP-10
-    ["p", "<patch-author-pubkey-hex>", "", "mention"],
-    ["e", "<previous-reply-id-hex>", "", "reply"],
-    // rest of tags...
-  ],
-  // other fields...
-}
-```
+Replies to either a `kind:1621` _issue_ or a `kind:1617` _patch_ event should follow [NIP-22 comment](22.md).
 
 ## Status
 
@@ -155,18 +145,18 @@ Root Patches and Issues have a Status that defaults to 'Open' and can be set by
   "kind": 1633, // Draft
   "content": "<markdown text>",
   "tags": [
-    ["e", "<issue-or-original-root-patch-id-hex>", "", "root"],
-    ["e", "<accepted-revision-root-id-hex>", "", "reply"], // for when revisions applied
+    ["E", "<issue-or-original-root-patch-id-hex>"],
+    ["e", "<accepted-revision-root-id-hex>"], // for when revision applied
     ["p", "<repository-owner>"],
-    ["p", "<root-event-author>"],
+    ["P", "<root-event-author>"],
     ["p", "<revision-author>"],
 
     // optional for improved subscription filter efficiency
     ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>", "<relay-url>"],
     ["r", "<earliest-unique-commit-id-of-repo>"]
 
     // optional for `1631` status
-    ["e", "<applied-or-merged-patch-event-id>", "", "mention"], // for each
+    ["q", "<applied-or-merged-patch-event-id>"], // for each
     // when merged
     ["merge-commit", "<merge-commit-id>"]
     ["r", "<merge-commit-id>"]

README.md

@@ -142,7 +142,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `1311`        | Live Chat Message               | [53](53.md)                            |
 | `1617`        | Patches                         | [34](34.md)                            |
 | `1621`        | Issues                          | [34](34.md)                            |
-| `1622`        | Replies                         | [34](34.md)                            |
+| `1622`        | Git Replies (deprecated)        | [34](34.md)                            |
 | `1630`-`1633` | Status                          | [34](34.md)                            |
 | `1971`        | Problem Tracker                 | [nostrocket][nostrocket]               |
 | `1984`        | Reporting                       | [56](56.md)                            |