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.md102
1 files changed, 102 insertions, 0 deletions
diff --git a/34.md b/34.md
new file mode 100644
index 0000000..651407d
--- /dev/null
+++ b/34.md
@@ -0,0 +1,102 @@
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>"],
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 ]
27}
28```
29
30The tags `web`, `clone`, `relays` can have multiple values.
31
32Except `d`, all tags are optional.
33
34## Patches
35
36Patches 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.
37
38```jsonc
39{
40 "kind": 1617,
41 "content": "<patch>", // contents of <git format-patch>
42 "tags": [
43 ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>"],
44 ["p", "<repository-owner>"],
45 ["p", "<other-user>"], // optionally send the patch to another user to bring it to their attention
46
47 // for the first patch in a thread or series
48 ["t", "root"],
49
50 // optional tags for when it is desirable that the merged patch has a stable commit id
51 // these fields are necessary for ensuring that the commit resulting from applying a patch
52 // has the same id as it had in the proposer's machine -- all these tags can be omitted
53 // if the maintainer doesn't care about these things
54 ["commit", "<current-commit-id>"],
55 ["parent-commit", "<parent-commit-id>"],
56 ["commit-pgp-sig", "-----BEGIN PGP SIGNATURE-----..."], // empty string for unsigned commit
57 ["committer", "<name>", "<email>", "<timestamp>", "<timezone offset in minutes>"],
58 ]
59}
60```
61
62## Issues
63
64Issues 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.
65
66```jsonc
67{
68 "kind": 1621,
69 "content": "<markdown text>",
70 "tags": [
71 ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>"],
72 ["p", "<repository-owner>"]
73 ]
74}
75```
76
77## Replies
78
79Replies 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.
80
81```jsonc
82{
83 "kind": 1622,
84 "content": "<markdown text>",
85 "tags": [
86 ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>", "<relay-url>"],
87 ["e", "<issue-or-patch-id-hex>", "", "root"],
88
89 // other "e" and "p" tags should be applied here when necessary, following the threading rules of NIP-10
90 ["p", "<patch-author-pubkey-hex>", "", "mention"],
91 ["e", "<previous-reply-id-hex>", "", "reply"],
92 // ...
93 ]
94}
95```
96
97## Possible things to be added later
98
99- "status" kind (for letting people know a patch was merged or an issue was fixed or won't be fixed)
100- "branch merge" kind (specifying a URL from where to fetch the branch to be merged)
101- "cover letter" kind (to which multiple patches can refer and serve as a unifying layer to them)
102- inline file comments kind (we probably need one for patches and a different one for merged files)