upleb.uk

Public git repos — served from a NIP-34 GRASP relay at git.upleb.uk

summaryrefslogtreecommitdiff
path: root/34.md
diff options
context:
space:
mode:
Diffstat (limited to '34.md')
-rw-r--r--34.md152
1 files changed, 152 insertions, 0 deletions
diff --git a/34.md b/34.md
new file mode 100644
index 0000000..52e23b5
--- /dev/null
+++ b/34.md
@@ -0,0 +1,152 @@
1NIP-34
2======
3
4`git` stuff
5-----------
6
7`draft` `optional`
8
9This NIP defines all the ways code collaboration using and adjacent to [`git`](https://git-scm.com/) can be done using Nostr.
10
11## Repository announcements
12
13Git repositories are hosted in Git-enabled servers, but their existence can be announced using Nostr events, as well as their willingness to receive patches, bug reports and comments in general.
14
15```jsonc
16{
17 "kind": 30617,
18 "content": "",
19 "tags": [
20 ["d", "<repo-id>"], // usually kebab-case short name
21 ["name", "<human-readable project name>"],
22 ["description", "brief human-readable project description>"],
23 ["web", "<url for browsing>", ...], // a webpage url, if the git server being used provides such a thing
24 ["clone", "<url for git-cloning>", ...], // a url to be given to `git clone` so anyone can clone it
25 ["relays", "<relay-url>", ...] // relays that this repository will monitor for patches and issues
26 ["r", "<earliest-unique-commit-id>", "euc"]
27 ["maintainers", "<other-recognized-maintainer>", ...]
28 ]
29}
30```
31
32The tags `web`, `clone`, `relays`, `maintainers` can have multiple values.
33
34The `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.
35
36Except `d`, all tags are optional.
37
38## Patches
39
40Patches 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.
41
42Patches in a patch set SHOULD include a NIP-10 `e` `reply` tag pointing to the previous patch.
43
44The first patch revision in a patch revision SHOULD include a NIP-10 `e` `reply` to the original root patch.
45
46```jsonc
47{
48 "kind": 1617,
49 "content": "<patch>", // contents of <git format-patch>
50 "tags": [
51 ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>"],
52 ["r", "<earliest-unique-commit-id-of-repo>"] // so clients can subscribe to all patches sent to a local git repo
53 ["p", "<repository-owner>"],
54 ["p", "<other-user>"], // optionally send the patch to another user to bring it to their attention
55
56 ["t", "root"], // omitted for additional patches in a series
57 // for the first patch in a revision
58 ["t", "root-revision"],
59
60 // optional tags for when it is desirable that the merged patch has a stable commit id
61 // these fields are necessary for ensuring that the commit resulting from applying a patch
62 // has the same id as it had in the proposer's machine -- all these tags can be omitted
63 // if the maintainer doesn't care about these things
64 ["commit", "<current-commit-id>"],
65 ["r", "<current-commit-id>"] // so clients can find existing patches for a specific commit
66 ["parent-commit", "<parent-commit-id>"],
67 ["commit-pgp-sig", "-----BEGIN PGP SIGNATURE-----..."], // empty string for unsigned commit
68 ["committer", "<name>", "<email>", "<timestamp>", "<timezone offset in minutes>"],
69 ]
70}
71```
72
73The first patch in a series MAY be a cover letter in the format produced by `git format-patch`.
74
75## Issues
76
77Issues 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.
78
79```jsonc
80{
81 "kind": 1621,
82 "content": "<markdown text>",
83 "tags": [
84 ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>"],
85 ["p", "<repository-owner>"]
86 ]
87}
88```
89
90## Replies
91
92Replies 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.
93
94```jsonc
95{
96 "kind": 1622,
97 "content": "<markdown text>",
98 "tags": [
99 ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>", "<relay-url>"],
100 ["e", "<issue-or-patch-id-hex>", "", "root"],
101
102 // other "e" and "p" tags should be applied here when necessary, following the threading rules of NIP-10
103 ["p", "<patch-author-pubkey-hex>", "", "mention"],
104 ["e", "<previous-reply-id-hex>", "", "reply"],
105 // ...
106 ]
107}
108```
109
110## Status
111
112Root Patches and Issues have a Status that defaults to 'Open' and can be set by issuing Status events.
113
114```jsonc
115{
116 "kind": 1630, // Open
117 "kind": 1631, // Applied / Merged for Patches; Resolved for Issues
118 "kind": 1632, // Closed
119 "kind": 1633, // Draft
120 "content": "<markdown text>",
121 "tags": [
122 ["e", "<issue-or-original-root-patch-id-hex>", "", "root"],
123 ["e", "<accepted-revision-root-id-hex>", "", "reply"], // for when revisions applied
124 ["p", "<repository-owner>"],
125 ["p", "<root-event-author>"],
126 ["p", "<revision-author>"],
127
128 // optional for improved subscription filter efficiency
129 ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>", "<relay-url>"],
130 ["r", "<earliest-unique-commit-id-of-repo>"]
131
132 // optional for `1631` status
133 ["e", "<applied-or-merged-patch-event-id>", "", "mention"], // for each
134 // when merged
135 ["merge-commit", "<merge-commit-id>"]
136 ["r", "<merge-commit-id>"]
137 // when applied
138 ["applied-as-commits", "<commit-id-in-master-branch>", ...]
139 ["r", "<applied-commit-id>"] // for each
140 ]
141}
142```
143
144The Status event with the largest created_at date is valid.
145
146The 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.
147
148
149## Possible things to be added later
150
151- "branch merge" kind (specifying a URL from where to fetch the branch to be merged)
152- inline file comments kind (we probably need one for patches and a different one for merged files)