Add previous tag

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 one or more strings, with some conventions around them. Take a look at the example below:
+Each tag is an array of strings of arbitrary size, with some conventions around them. Take a look at the example below:
 
 ```jsonc
 {
@@ -99,6 +99,8 @@ And also a convention for kind ranges that allow for easier experimentation and
 
 In case of replaceable events with the same timestamp, the event with the lowest id (first in lexical order) should be retained, and the other discarded.
 
+When the `previous` tag exists on a replaceable event relays SHOULD use this id as the id of the version the client wishes to replace, if the id does not match the stored version, relays MUST reject the update.
+
 When answering to `REQ` messages for replaceable events such as `{"kinds":[0],"authors":[<hex-key>]}`, even if the relay has more than one version stored, it SHOULD return just the latest one.
 
 These are just conventions and relay implementations may differ.

34.md

@@ -17,20 +17,17 @@ Git repositories are hosted in Git-enabled servers, but their existence can be a
   "kind": 30617,
   "content": "",
   "tags": [
-    ["d", "<repo-id>"], // usually kebab-case short name
+    ["d", "<repo-id>"],
     ["name", "<human-readable project name>"],
     ["description", "brief human-readable project description>"],
     ["web", "<url for browsing>", ...], // a webpage url, if the git server being used provides such a thing
     ["clone", "<url for git-cloning>", ...], // a url to be given to `git clone` so anyone can clone it
     ["relays", "<relay-url>", ...] // relays that this repository will monitor for patches and issues
-    ["earliest-unique-commit", "<commit-id>"] // usually root commit but a recent commit for forks
-    ["r", "<earliest-unique-commit-id>"] // so clients can subscribe to all events related to a local git repo
-    ["maintainers", "<other-recognized-maintainer>", ...]
   ]
 }
 ```
 
-The tags `web`, `clone`, `relays`, `maintainers` can have multiple values.
+The tags `web`, `clone`, `relays` can have multiple values.
 
 Except `d`, all tags are optional.
 
@@ -38,30 +35,23 @@ Except `d`, all tags are optional.
 
 Patches can be sent by anyone to any repository. Patches to a specific repository SHOULD be sent to the relays specified in that repository's announcement event's `"relays"` tag. Patch events SHOULD include an `a` tag pointing to that repository's announcement address.
 
-Patches in a patch set SHOULD include a NIP-10 `e` `reply` tag pointing to the previous patch. 
-
-The first patch revision in a patch revision SHOULD include a NIP-10 `e` `reply` to the original root patch.
-
 ```jsonc
 {
   "kind": 1617,
   "content": "<patch>", // contents of <git format-patch>
   "tags": [
     ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>"],
-    ["r", "<earliest-unique-commit-id-of-repo>"] // so clients can subscribe to all patches sent to a local git repo
     ["p", "<repository-owner>"],
     ["p", "<other-user>"], // optionally send the patch to another user to bring it to their attention
 
-    ["t", "root"], // ommited for additional patches in a series
-    // for the first patch in a revision
-    ["t", "root-revision"],
+    // for the first patch in a thread or series
+    ["t", "root"],
 
     // optional tags for when it is desirable that the merged patch has a stable commit id
     // these fields are necessary for ensuring that the commit resulting from applying a patch
     // has the same id as it had in the proposer's machine -- all these tags can be omitted
     // if the maintainer doesn't care about these things
     ["commit", "<current-commit-id>"],
-    ["r", "<current-commit-id>"] // so clients can find existing patches for a specific commit
     ["parent-commit", "<parent-commit-id>"],
     ["commit-pgp-sig", "-----BEGIN PGP SIGNATURE-----..."], // empty string for unsigned commit
     ["committer", "<name>", "<email>", "<timestamp>", "<timezone offset in minutes>"],
@@ -69,8 +59,6 @@ The first patch revision in a patch revision SHOULD include a NIP-10 `e` `reply`
 }
 ```
 
-The first patch in a series MAY be a cover letter in the format produced by `git format-patch`.
-
 ## Issues
 
 Issues are Markdown text that is just human-readable conversational threads related to the repository: bug reports, feature requests, questions or comments of any kind. Like patches, these SHOULD be sent to the relays specified in that repository's announcement event's `"relays"` tag.
@@ -106,46 +94,9 @@ Replies are also Markdown text. The difference is that they MUST be issued as re
 }
 ```
 
-## Status
-
-Root Patches and Issues have a Status that defaults to 'Open' and can be set by issuing Status events.
-
-```jsonc
-{
-  "kind": 1630, // Open
-  "kind": 1631, // Applied / Merged for Patches; Resolved for Issues
-  "kind": 1632, // Closed
-  "kind": 1633, // Draft
-  "content": "<markdown text>",
-  "tags": [
-    ["e", "<issue-or-original-root-patch-id-hex>", "", "root"],
-    ["e", "<accepted-revision-root-id-hex>", "", "reply"], // for when revisions applied
-    ["p", "<repository-owner>"],
-    ["p", "<root-event-author>"],
-    ["p", "<revision-author>"],
-
-    // optional for improved subscription filter efficency
-    ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>", "<relay-url>"],
-    ["r", "<earliest-unique-commit-id-of-repo>"]
-
-    // optional for `1631` status
-    ["e", "<applied-or-merged-patch-event-id>", "", "mention"], // for each
-    // when merged
-    ["merge-commit", "<merge-commit-id>"]
-    ["r", "<merge-commit-id>"] 
-    // when applied
-    ["applied-as-commits", "<commit-id-in-master-branch>", ...]
-    ["r", "<applied-commit-id>"] // for each
-  ]
-}
-```
-
-The Status event with the largest created_at date is valid.
-
-The Status of a patch-revision defaults to either that of the root-patch, or `1632` (Closed) if the root-patch's Status is `1631` and the patch-revision isn't tagged in the `1631` event. 
-
-
 ## Possible things to be added later
 
+- "status" kind (for letting people know a patch was merged or an issue was fixed or won't be fixed)
 - "branch merge" kind (specifying a URL from where to fetch the branch to be merged)
+- "cover letter" kind (to which multiple patches can refer and serve as a unifying layer to them)
 - inline file comments kind (we probably need one for patches and a different one for merged files)

README.md

@@ -114,7 +114,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `1617`        | Patches                    | [34](34.md)              |
 | `1621`        | Issues                     | [34](34.md)              |
 | `1622`        | Replies                    | [34](34.md)              |
-| `1630`-`1633` | Status                     | [34](34.md)              |
 | `1971`        | Problem Tracker            | [nostrocket][nostrocket] |
 | `1984`        | Reporting                  | [56](56.md)              |
 | `1985`        | Label                      | [32](32.md)              |