-
Notifications
You must be signed in to change notification settings - Fork 770
NIP-34: git stuff #997
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NIP-34: git stuff #997
Changes from all commits
e3d42d6
7887d7b
d86acbf
16d14e5
0b5774d
039f5e1
70fdfe7
29a6426
cb8b66a
23a46d3
157c56e
cccc929
bbfb5a7
d721d86
4ab3262
79cbe56
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| @@ -0,0 +1,102 @@ | ||||||||||||||||||||||||||||
| NIP-34 | ||||||||||||||||||||||||||||
| ====== | ||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||
| `git` stuff | ||||||||||||||||||||||||||||
| ----------- | ||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||
| `draft` `optional` | ||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||
| This NIP defines all the ways code collaboration using and adjacent to [`git`](https://git-scm.com/) can be done using Nostr. | ||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||
| ## Repository announcements | ||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||
| Git 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. | ||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||
| ```jsonc | ||||||||||||||||||||||||||||
| { | ||||||||||||||||||||||||||||
| "kind": 30617, | ||||||||||||||||||||||||||||
| "content": "", | ||||||||||||||||||||||||||||
| "tags": [ | ||||||||||||||||||||||||||||
| ["d", "<repo-id>"], | ||||||||||||||||||||||||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. this enables clients with access to the local repo to find repo events for it. It is also resilient to name changes.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. alternatively, the following could be added.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What if I have two projects with the same root commit id?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. then there is a fork and the earliest unique commit id should be used instead. the repo event should contain a ["r","[commit-id]"] outlining this so the contributor doesn't need to identify it. Clients could make more sense of this if, in the case of a fork, 2 tags are used as follows:
Suggested change
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sounds good to me, but I think we should leave |
||||||||||||||||||||||||||||
| ["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 | ||||||||||||||||||||||||||||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. i think this could document all you could use directly for |
||||||||||||||||||||||||||||
| ["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 | ||||||||||||||||||||||||||||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. this is missing some
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. all nostr events must include a |
||||||||||||||||||||||||||||
| ] | ||||||||||||||||||||||||||||
| } | ||||||||||||||||||||||||||||
| ``` | ||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||
| The tags `web`, `clone`, `relays` can have multiple values. | ||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||
| Except `d`, all tags are optional. | ||||||||||||||||||||||||||||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. i think you can recommend
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. using human readable |
||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||
| ## Patches | ||||||||||||||||||||||||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. how do you send a patch series?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Isn't it simpler to send a pull request?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't know? How do people normally do it in Or you could send multiple events? I'm not sure what is the best flow.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. git send-email sends multiple emails when you give it multiple patches. it creates a proper email thread so that you can reply to each patch individually. the nostr equivalent would be building a nip-10 thread of patches.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
this implies you have write access to the repo in question, or that you have a hosted fork somewhere. it is much easier to just send patches as it requires no hosting.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What about a pull request event which patches tag? later updates based on feedback or rebases could also be associated with the same pull request. |
||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||
| 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. | ||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||
| ```jsonc | ||||||||||||||||||||||||||||
| { | ||||||||||||||||||||||||||||
| "kind": 1617, | ||||||||||||||||||||||||||||
| "content": "<patch>", // contents of <git format-patch> | ||||||||||||||||||||||||||||
|
Giszmo marked this conversation as resolved.
|
||||||||||||||||||||||||||||
| "tags": [ | ||||||||||||||||||||||||||||
| ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>"], | ||||||||||||||||||||||||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. we probably also want a "version" tag. patches tend to have more than one version
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I mean lots of this stuff already shows up in the patch itself, so not sure if worth it. but just something to consider.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
This associates the patch with the git repository. If the maintainer changes (or if there are multiple), clients can easily query relays for all patch. |
||||||||||||||||||||||||||||
| ["p", "<repository-owner>"], | ||||||||||||||||||||||||||||
|
fiatjaf marked this conversation as resolved.
|
||||||||||||||||||||||||||||
| ["p", "<other-user>"], // optionally send the patch to another user to bring it to their attention | ||||||||||||||||||||||||||||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. can say a default limit (e.g
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. events that tag large numbers of pubkeys or events can be identified as spam either at the relay level or by clients. |
||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||
| // 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>"], | ||||||||||||||||||||||||||||
| ["parent-commit", "<parent-commit-id>"], | ||||||||||||||||||||||||||||
| ["commit-pgp-sig", "-----BEGIN PGP SIGNATURE-----..."], // empty string for unsigned commit | ||||||||||||||||||||||||||||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. often on projects like linux, you can have commit signed by multiple authors / contributors.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That's an interesting idea. git only supports a single pgp signature which in the git-over-email model is the committer rather than the author(s). |
||||||||||||||||||||||||||||
| ["committer", "<name>", "<email>", "<timestamp>", "<timezone offset in minutes>"], | ||||||||||||||||||||||||||||
| ] | ||||||||||||||||||||||||||||
|
fiatjaf marked this conversation as resolved.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
reflecting proposal in #997 (comment)
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm confused by these quotes,
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think instead of writing all these Now about the
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
typo fixed
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I agree that what I wrote is confusing regarding threading however, its not clear how NIP-10 threading rules should be applied. Should the third patch in the set 'reply' to the second? a naive reading of the rules may suggest not unless it directly uses the change, but clients shouldn't be expected to automatically detect this. I think we this nip should clarify, for both consistency and as the decision effects comparability with the PR model. The problem trying to be solved by stating that patches should reply to the previous patch in the PR model is as follows:
without the reply mechanism the typo fix 'amended' commit could be seen as a descendant, instead of a replacement by a client. Of course a human would see it, but we want clients to detect this and provide a smooth user experience.
Here is the problem this is trying to solve: as a client I want to create a single subscription to return the only the root event of proposed changes so that I can display their titles as a list. I suppose it is not too much of a problem to get all versions of proposed changes and filter them client side by filtering those that 'mention' other proposed changes. This would remove the How else could this be achieved without the ["t","root"] tag or requesting every 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. | ||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It is common place for titles to be updated by the author or maintainer to better reflect the issue at hand. What about an update mechanism similar to the |
||||||||||||||||||||||||||||
| ```jsonc | ||||||||||||||||||||||||||||
| { | ||||||||||||||||||||||||||||
| "kind": 1621, | ||||||||||||||||||||||||||||
| "content": "<markdown text>", | ||||||||||||||||||||||||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What about issue title? It could be a tag or the first line of the content with any markdown heading notation removed?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do we really want Markdown here? But yes, let's add a |
||||||||||||||||||||||||||||
| "tags": [ | ||||||||||||||||||||||||||||
| ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>"], | ||||||||||||||||||||||||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
This associates the issue to the git repository. If the maintainer changes (or if there are multiple), clients can easily query relays for all issues. |
||||||||||||||||||||||||||||
| ["p", "<repository-owner>"] | ||||||||||||||||||||||||||||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. i think you could have a list of “p” - “other-user” in kind
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes. The |
||||||||||||||||||||||||||||
| ] | ||||||||||||||||||||||||||||
| } | ||||||||||||||||||||||||||||
| ``` | ||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||
| ## 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>"], | ||||||||||||||||||||||||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
This associates the issue with the git repository. If the maintainer changes (or if there are multiple), clients can easily query relays for all issues. |
||||||||||||||||||||||||||||
| ["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 | ||||||||||||||||||||||||||||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. i think you could have “relay-local” threading policy on max default “p” elements. |
||||||||||||||||||||||||||||
| ["p", "<patch-author-pubkey-hex>", "", "mention"], | ||||||||||||||||||||||||||||
| ["e", "<previous-reply-id-hex>", "", "reply"], | ||||||||||||||||||||||||||||
| // ... | ||||||||||||||||||||||||||||
| ] | ||||||||||||||||||||||||||||
| } | ||||||||||||||||||||||||||||
| ``` | ||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Each proposed commit / patch should have its own event so there is a record available for those who are interested in reviewing the of history how a change evolved over time before it got merged even if the contributor deletes the repo on their git server. Patches that are too large for an event should have a special patch event type called a stub. This points to a git server for the full commit but contains most of the details of the patch but with only the large file diffs removed. I agree their should be a PR event to hang multiple patches on - see #997 (comment). |
||||||||||||||||||||||||||||
| ## 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) | ||||||||||||||||||||||||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Status is quite important. Shouldn't we add this now? Its impossible to identify open proposals or issues unless you are a maintainer with a client that stores the status internally. |
||||||||||||||||||||||||||||
| - "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) | ||||||||||||||||||||||||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. as mentioned in #997 (comment) we should have a cover_letter as a separate kind than a patch because it is different in nature.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What is the difference between a "cover letter" kind and an "issue" kind?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. A cover letter is always paired with a proposed change. An issue may result in zero or more changes in the future. |
||||||||||||||||||||||||||||
| - inline file comments kind (we probably need one for patches and a different one for merged files) | ||||||||||||||||||||||||||||

There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A word on this, please. I can't find a repo-id definition
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's just an arbitrary string, as in all other
dtags.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't it make sense to prescribe this? If we used the initial commit hash for example, finding/detecting forks would be easier.
fiatjaf:30617:helloWorldmight be a very different repo thangiszmo:30617:helloWorldbutgiszmo:30617:<sha256-of-bitcoin-root-commit>... would hopefully match between all forks.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this idea a lot - something github doesn't do and we could - that allows people to find all the forks. But this particular event contains data that would differ between forks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like it too, but how can you be sure? Maybe we can have another single-letter tag for this that only interested implementations would include, to prevent others from having to check invalid data.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some OSS products which fork has become the official developer because the original author retired the development.
https://github.com/ctrlpvim/ctrlp.vim
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not make it the root commit id? For forks it could be the id of the earliest unique commit. The repository COULD contain a config file which specifies this id so that clients MAY access the config to automatically identify the correct id.