From d607a288b5db72a84f3d6cc8fd42304d31e1f66b Mon Sep 17 00:00:00 2001 From: DanConwayDev Date: Thu, 7 Mar 2024 07:59:16 +0000 Subject: NIP-34: clarify nip10 thread application for consistancy and so that the intended order of patches is easier to ascertain enables additional patches to be appended to a patch set, supporting a PR-like workflow alongside patch-over-email-like workflow --- 34.md | 4 ++++ 1 file changed, 4 insertions(+) (limited to '34.md') diff --git a/34.md b/34.md index 651407d..2a7f489 100644 --- a/34.md +++ b/34.md @@ -35,6 +35,10 @@ 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, -- cgit v1.2.3 From 46ea8dcf9cedd1f64e9444b70ac0ed24e40bbe1a Mon Sep 17 00:00:00 2001 From: DanConwayDev Date: Thu, 7 Mar 2024 08:03:48 +0000 Subject: NIP-34: add repo-id standard suggested guidance for repo-id --- 34.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to '34.md') diff --git a/34.md b/34.md index 2a7f489..7eea92b 100644 --- a/34.md +++ b/34.md @@ -17,7 +17,7 @@ Git repositories are hosted in Git-enabled servers, but their existence can be a "kind": 30617, "content": "", "tags": [ - ["d", ""], + ["d", ""], // usually kebab-case short name ["name", ""], ["description", "brief human-readable project description>"], ["web", "", ...], // a webpage url, if the git server being used provides such a thing -- cgit v1.2.3 From cb0d35a5f9f1b88a270f7fbbfbdb97e095e28d56 Mon Sep 17 00:00:00 2001 From: DanConwayDev Date: Thu, 7 Mar 2024 08:25:49 +0000 Subject: NIP-34: optional additional repo maintainers can be used by clients to tag multiple maintainers in patches helps clients identify whether multiple repo events for the same repository are complementary or in competion --- 34.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to '34.md') diff --git a/34.md b/34.md index 7eea92b..bb7e3ee 100644 --- a/34.md +++ b/34.md @@ -23,11 +23,12 @@ Git repositories are hosted in Git-enabled servers, but their existence can be a ["web", "", ...], // a webpage url, if the git server being used provides such a thing ["clone", "", ...], // a url to be given to `git clone` so anyone can clone it ["relays", "", ...] // relays that this repository will monitor for patches and issues + ["maintainers", "", ...] ] } ``` -The tags `web`, `clone`, `relays` can have multiple values. +The tags `web`, `clone`, `relays`, `maintainers` can have multiple values. Except `d`, all tags are optional. -- cgit v1.2.3 From 8225a018c72c4d11b575ed4e57fa587d08c09027 Mon Sep 17 00:00:00 2001 From: DanConwayDev Date: Thu, 7 Mar 2024 09:01:19 +0000 Subject: NIP-34: optional tags to improve discoverability earliest-unique-commit r tag enables clients to: - retrieve all repo events refering to a local git repo - group repo events with different identifers that refer to same repo - retrieve all patches for a local repo, irespective of the tagged repo event current-commit-id r tag enables clients to prevent accidental submission of a patch, which has already been proposed root-revision tag enables clients to filter out proposal revisions from a list of proposals --- 34.md | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) (limited to '34.md') diff --git a/34.md b/34.md index bb7e3ee..fefc7af 100644 --- a/34.md +++ b/34.md @@ -23,6 +23,8 @@ Git repositories are hosted in Git-enabled servers, but their existence can be a ["web", "", ...], // a webpage url, if the git server being used provides such a thing ["clone", "", ...], // a url to be given to `git clone` so anyone can clone it ["relays", "", ...] // relays that this repository will monitor for patches and issues + ["earliest-unique-commit", ""] // usually root commit but a recent commit for forks + ["r", ""] // so clients can subscribe to all events related to a local git repo ["maintainers", "", ...] ] } @@ -46,17 +48,20 @@ The first patch revision in a patch revision SHOULD include a NIP-10 `e` `reply` "content": "", // contents of "tags": [ ["a", "30617::"], + ["r", ""] // so clients can subscribe to all patches sent to a local git repo ["p", ""], ["p", ""], // optionally send the patch to another user to bring it to their attention - // for the first patch in a thread or series - ["t", "root"], + ["t", "root"], // ommited for additional patches in a series + // for the first patch in a revision + ["t", "root-revision"], // 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", ""], + ["r", ""] // so clients can find existing patches for a specific commit ["parent-commit", ""], ["commit-pgp-sig", "-----BEGIN PGP SIGNATURE-----..."], // empty string for unsigned commit ["committer", "", "", "", ""], -- cgit v1.2.3 From 0b62729e318497922822c39471ab31a869563ba5 Mon Sep 17 00:00:00 2001 From: DanConwayDev Date: Thu, 7 Mar 2024 09:20:25 +0000 Subject: NIP-34: clarify cover letters remove cover letters from 'possible things to be added later' and add a clarification that can they can be added through patches --- 34.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to '34.md') diff --git a/34.md b/34.md index fefc7af..c6e7225 100644 --- a/34.md +++ b/34.md @@ -69,6 +69,8 @@ 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. @@ -108,5 +110,4 @@ Replies are also Markdown text. The difference is that they MUST be issued as re - "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) -- cgit v1.2.3 From 403b5199a490b6a148063003e00924f5e79ba36c Mon Sep 17 00:00:00 2001 From: DanConwayDev Date: Thu, 7 Mar 2024 10:21:06 +0000 Subject: NIP-34: add status events merge-commit and applied-commit-id tags enable discussion of patches to be mapped to lines of code accepted into the master branch --- 34.md | 40 +++++++++++++++++++++++++++++++++++++++- 1 file changed, 39 insertions(+), 1 deletion(-) (limited to '34.md') diff --git a/34.md b/34.md index c6e7225..f72fcf2 100644 --- a/34.md +++ b/34.md @@ -106,8 +106,46 @@ 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": "", + "tags": [ + ["e", "", "", "root"], + ["e", "", "", "reply"], // for when revisions applied + ["p", ""], + ["p", ""], + ["p", ""], + + // optional for improved subscription filter efficency + ["a", "30617::", ""], + ["r", ""] + + // optional for `1631` status + ["e", "", "", "mention"], // for each + // when merged + ["merge-commit", ""] + ["r", ""] + // when applied + ["applied-as-commits", "", ...] + ["r", ""] // 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) - inline file comments kind (we probably need one for patches and a different one for merged files) -- cgit v1.2.3 From bad8826211ca2eb8660e4bd68b292d14616d3669 Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Wed, 24 Apr 2024 18:44:36 -0300 Subject: nip34: simplify `r` tag for earliest unique commit. --- 34.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) (limited to '34.md') diff --git a/34.md b/34.md index f72fcf2..03ee039 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", "", ...], // a webpage url, if the git server being used provides such a thing ["clone", "", ...], // a url to be given to `git clone` so anyone can clone it ["relays", "", ...] // relays that this repository will monitor for patches and issues - ["earliest-unique-commit", ""] // usually root commit but a recent commit for forks - ["r", ""] // so clients can subscribe to all events related to a local git repo + ["r", "", "euc"] ["maintainers", "", ...] ] } @@ -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", "", "", "mention"], // for each // when merged ["merge-commit", ""] - ["r", ""] + ["r", ""] // when applied ["applied-as-commits", "", ...] ["r", ""] // 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 -- cgit v1.2.3 From cb9bddb8dfd11972286215d9bdee7434764ccf7b Mon Sep 17 00:00:00 2001 From: Adam Shannon Date: Sat, 11 May 2024 11:52:32 -0500 Subject: 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(-) (limited to '34.md') diff --git a/34.md b/34.md index 03ee039..fcc2cec 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", ""], ["p", ""], - // optional for improved subscription filter efficency + // optional for improved subscription filter efficiency ["a", "30617::", ""], ["r", ""] diff --git a/46.md b/46.md index e0a5b2e..1528116 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 2090182..8823af9 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 4bafce0..5a8be0a 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 241eb38..2b499a8 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. -- cgit v1.2.3