NIP-34: git stuff #997
NIP-34: git stuff #997
Conversation
|
awesome, this is very close to what I was converging on. |
|
When I looked into this topic, I discovered https://git-scm.com/book/en/v2/Git-on-the-Server-Smart-HTTP |
| "kind": 30617, | ||
| "content": "", | ||
| "tags": [ | ||
| ["d", "<repo-id>"], |
There was a problem hiding this comment.
A word on this, please. I can't find a repo-id definition
There was a problem hiding this comment.
It's just an arbitrary string, as in all other d tags.
There was a problem hiding this comment.
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:helloWorld might be a very different repo than giszmo:30617:helloWorld but giszmo:30617:<sha256-of-bitcoin-root-commit> ... would hopefully match between all forks.
There was a problem hiding this comment.
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.
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.
Some OSS products which fork has become the official developer because the original author retired the development.
There was a problem hiding this comment.
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.
34.md
Outdated
| ## Branch merge | ||
|
|
||
| To be defined. | ||
|
|
There was a problem hiding this comment.
I would remove these lines and add some ## Outlook at the bottom to mention what else this nip could cover. Furthermore are you thinking of a "merge request" event here? As the different clone urls in the original repo might use different branch names, the target needs one specific url to reference the branch to merge into. As branches can be renamed, these events have no absolute cryptographic reference unless we add one via the branches heads.
MRs call for code reviews ...
| ## Branch merge | |
| To be defined. | |
| ## Merge Request | |
| Notify repository owner of an improvement under development. | |
| ```jsonc | |
| { | |
| "kind": 31617, | |
| "content": "<Description using markdown>", | |
| "tags": [ | |
| ["d", "<something unique / UUID>"], | |
| ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>"], | |
| ["title", "<merge request title>"], // | |
| ["state", "[wip|ready|final]"], // wip: share an idea, knowing it's not ready to merge, ready: author thinks it can be merged, final: author doesn't intend to update the source repo after feedback | |
| ["source", "<url for git-cloning>", "<branch name>", "<current branch head sha1-hex>"], // | |
| ["target", "<url for git-cloning>", "<branch name>", "<current branch head sha1-hex>"], // | |
| ] | |
| } | |
| ``` | |
| ## Merge Request Review | |
| ```jsonc | |
| { | |
| "kind": 2617, | |
| "content": "<summary/comment allowing markdown>", | |
| "tags": [ | |
| ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>"], | |
| ["a", "31617:<merge-request-owner-pubkey>:<merge-request-d-tag>"], | |
| ["type", "[ACK|NACK|...]"], | |
| ["anchor", "<source-commit-id>", "<target-commit-id>"], | |
| ["source-comment", "<file-with-path>:<line>", "<comment>"], | |
| ["target-comment", "<file-with-path>:<line>", "<comment>"], | |
| ] | |
| } | |
| ``` | |
| Both `a` tags are required. The other tags are optional. `type` and `anchor` may only be used once. | |
There was a problem hiding this comment.
Yes, the branch merge thing would probably have to specify a branch name and a URL from where to fetch it. The person calling for a branch merge must have a git server somewhere. I don't know the details.
I like the review kind -- but I would leave that for much later (it's good to have the proposal here though).
I don't understand the "notify owner of improvement", to me that fits under the "issue" kind, but what do I know?
I was also thinking of another kind for standalone inline comments of files, but all of that can also be done much later I think.
There was a problem hiding this comment.
The MR state was just me being creative. An issue would usually not include the fix and when you want to send a fix, you can do so with a patch. The MR with a final state would be better done with a patch but on the other hand, maybe you want to propose a 5GB change, so a patch wouldn't work but if you host a fork, you can propose the 5GB change that way.
There was a problem hiding this comment.
The state field is probably not the best way to approach this. For example, closing an issue or a PR doesn't have to publish a whole new Issue Event, having just one field changed. I think it's better to have a separate kind for closing issues and PRs.
|
This proposal has a lot in common with the NIP-62 PR I opened recently. Perhaps we can merge them. I think NIP-62 proposes a general solution that can be applied to the Git use case, whereas NIP-32 is very Git-specific. Git is a large use case, so it could make sense to have a NIP solely for that purpose; but in general, don't we want NIPs to be reusable and broadly applicable? |
|
@buttercat1791 no, I think having NIPs not be general is better. Of course it depends and we must think of it case-by-case, but as a rule of thumb less general ends up being better. |
|
@jb55 what do you think is missing or could be changed here? |
|
Aside fom "head", the data format is almost like package.json |
|
git commit proof of work miner #gnostr |
|
It would be worth giving ForgeFed a look over: https://forgefed.org/spec/ GitLab is currently implementating this: https://gitlab.com/groups/gitlab-org/-/epics/11247 |
|
@fiatjaf I would be interested to see your analysis on why there needs to be a specific NIP for each type of version control system, when we could easily define the same solution for multiple types. Are we really to have a seperate NIP for each brand name covered? |
|
@alexgleason this nip is explicitly an interoperability layer between gitlab, gitea, github and your various local git instances. From the document you linked:
The gist of this nip here: what people really want is to have one global "Git network" to be able to interact between various projects without having to register on each of their hosts. |
|
@SilberWitch not for each version control system, just for git. No one uses the others. git is very specific and an open protocol of its own and requires special handling. It's also used by a ton of people, so it makes no sense to try to shove it into some generic thing that wouldn't know about its intricacies. We would still need to write software specific for git with hardcoded git stuff in it, so why not define that in a specific NIP? Now for some kind of plaintext diffing that doesn't come with all the crazy features that git has (including its network effect) we can come up with our own scheme, like the NIP-62 proposal linked above. Indeed it would be very useful given that there is basically no decent version-control of anything except code in this world. Many people have tried to apply git or git-like approaches to other things and as far as I know never had any success. |
|
https://github.com/fiatjaf/nak, https://github.com/nbd-wtf/go-nostr and https://github.com/fiatjaf/gitstr are now accepting patches over Nostr. Check their READMEs. |
|
This looks really good. Can we find a common way to mark the patch/issue as merged/closed? |
|
@fiatjaf As far as I can tell, the core concept behind both NIP-62 and NIP-34 is pretty much the same: define an event to announce something happening off of Nostr (such as an update to a Git repository) and offer clients hints as to where to find out more (such as a git server URL). Having some common standard for announcing off-Nostr events would be valuable, I think. Git-specific things, like patches, issues, etc. can and should be defined separately, but I think the underlying concept of announcing off-Nostr things is inherently reusable and should be defined as such. |
|
|
||
| The tags `web`, `clone`, `patches` and `issues` can be specified multiple times. Except `d`, all tags are optional. | ||
|
|
||
| ## Patches |
There was a problem hiding this comment.
how do you send a patch series?
There was a problem hiding this comment.
Isn't it simpler to send a pull request?
There was a problem hiding this comment.
I don't know? How do people normally do it in git send-email? I know you can send multiple patches in the same email and you could do the same in the Nostr event. Then when applying with git am -i <patch> it works fine.
Or you could send multiple events? I'm not sure what is the best flow.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Isn't it simpler to send a pull request?
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.
There was a problem hiding this comment.
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.
|
I've been trying to solve the same problem in the context of Nostrocket, I've added my thoughts here: https://nostrocket.org/Snub/problems/c1cc39a3386b96d79dc5b5de335a88acd8476cce191efc76da79fc286955ddfb |
|
@gazhayes I left a comment on your post expressing my disagreements. But aside from that I agree with the rest. So your suggestion is just to do everything as I say here, but add a new kind for "pull request" that includes a URL to another repository from which the code is to be pulled? I like that. We can definitely add that to this NIP. |
the equivalent in git+email is git-request-pull should definitely support that, but we should encourage the patch workflow as that is self contained patches are best for code review, pull requests are better if you're someone like linus torvalds with submaintainers who review things for you and just need to merge stuff. |
| "kind": 1617, | ||
| "content": "<patch>", // contents of <git format-patch> | ||
| "tags": [ | ||
| ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>"], |
There was a problem hiding this comment.
we probably also want a "version" tag. patches tend to have more than one version git format-patch -v2, -v3, etc
There was a problem hiding this comment.
I mean lots of this stuff already shows up in the patch itself, so not sure if worth it. but just something to consider.
There was a problem hiding this comment.
As a final note in my review: Should the key header items of the patch be optionally extract and put into nostr tags to make it easy for non-specialised clients to read or is this putting to much of a burden on clients that apply patches which would need to render it?
Instead of repeating this data it could be extracted and removed. Here is the format:
From [commit-id] Mon Sep 17 00:00:00 2001\nFrom: [author-name] <[author email]>\nDate: [authored-date]\nSubject: \[PATCH\] [commit-msg]\n---\n
note date format here is: ddd, DD MMM YYY HH:mm:ss ZZ
Example:
From 1263051aa4426937c5ef4f7616e06e9a8ea021e0 Mon Sep 17 00:00:00 2001\nFrom: William Casarin <jb55@jb55.com>\nDate: Mon, 22 Jan 2024 14:41:54 -0800\nSubject: [PATCH] Revert "mention: fix broken mentions when there is text is\n directly after"\n\nThis reverts commit af75eed83a2a1dd0eb33a0a27ded71c9f44dacbd.\n---\n
| "kind": 30617, | ||
| "content": "", | ||
| "tags": [ | ||
| ["d", "<repo-id>"], |
There was a problem hiding this comment.
| ["d", "<repo-id>"], | |
| ["d", "<repo-id>"], // the earliest unique commit id. usually the root commit id unless it's a fork. |
There was a problem hiding this comment.
this enables clients with access to the local repo to find repo events for it. It is also resilient to name changes.
There was a problem hiding this comment.
alternatively, the following could be added.
["r", "<repository-unique-reference>"], // the earliest unique commit id. usually the root commit id unless it's a fork.
There was a problem hiding this comment.
What if I have two projects with the same root commit id?
There was a problem hiding this comment.
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:
| ["d", "<repo-id>"], | |
| ["d", "<repo-id>"], // the earliest unique commit id. usually the root commit id unless it's a fork. | |
| ["r", "<repo-id>"], | |
| ["r", "<first-commit-id>"], // if the first commit id isn't the earliest unique commit. |
There was a problem hiding this comment.
Sounds good to me, but I think we should leave d as an arbitrary string and use r for the root/fork git commit identifiers.
| ```jsonc | ||
| { | ||
| "kind": 1621, | ||
| "content": "<markdown text>", |
There was a problem hiding this comment.
What about issue title? It could be a tag or the first line of the content with any markdown heading notation removed?
There was a problem hiding this comment.
Do we really want Markdown here?
But yes, let's add a title tag.
| ## 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. | ||
|
|
There was a problem hiding this comment.
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 status kind?
| ["parent-commit", "<parent-commit-id>"], | ||
| ["commit-pgp-sig", "-----BEGIN PGP SIGNATURE-----..."], | ||
| ["committer", "<name>", "<email>", "<timezone offset in minutes>"], | ||
| ] |
There was a problem hiding this comment.
| ] | |
| // if first patch in patch set with no cover_letter | |
| ["t", "root"], // if first version | |
| ["t", "root-version"], // if first additional version | |
| ["e", "<id-of-root-of-previous-version", "mention"], // if first additional version | |
| // else | |
| ["e", "<id-of-root-patch-or-cover-letter", "root"], // this may be a root-version | |
| ["e", "<id-of-[previous-patch-in-set]-or-for-first-[cover-letter]", "reply"], | |
| ] |
reflecting proposal in #997 (comment)
There was a problem hiding this comment.
I'm confused by these quotes, "["root"]?
There was a problem hiding this comment.
I think instead of writing all these e tags in the example we should just say these events should follow NIP-10 threading rules. It will be less confusing for people reading.
Now about the t tags I don't think they help. If a human is reading a list of patches or a thread with multiple patches and comments they will be able to see which patches are roots and which ones are v2, v3 and so, either from the context or from something written in the patch title. And if a machine is reading it or if someone wants to refer to a patch with absolute precision they should use the Nostr event id.
There was a problem hiding this comment.
I'm confused by these quotes,
"["root"]?
typo fixed
There was a problem hiding this comment.
I think instead of writing all these
etags in the example we should just say these events should follow NIP-10 threading rules. It will be less confusing for people reading.
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:
Assuming the commit id's cannot be replied upon, how can a client know if the patch is a intended to be used in combination with, or replace, another patch?
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.
Now about the
ttags I don't think they help. If a human is reading a list of patches or a thread with multiple patches and comments they will be able to see which patches are roots and which ones are v2, v3 and so, either from the context or from something written in the patch title. And if a machine is reading it or if someone wants to refer to a patch with absolute precision they should use the Nostr event id.
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 root-version tag.
How else could this be achieved without the ["t","root"] tag or requesting every patch?
| "kind": 1617, | ||
| "content": "<patch>", // contents of <git format-patch> | ||
| "tags": [ | ||
| ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>"], |
There was a problem hiding this comment.
| ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>"], | |
| ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>", "<relay-url>"], | |
| ["r", "<repository-unique-reference>"], // the earliest unique commit id. usually the root commit id unless it's a fork. |
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.
also adds relay hint to a
| "kind": 1622, | ||
| "content": "<markdown text>", | ||
| "tags": [ | ||
| ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>", "<relay-url>"], |
There was a problem hiding this comment.
| ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>", "<relay-url>"], | |
| ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>", "<relay-url>"], | |
| ["r", "<repository-unique-reference>"], // the earliest unique commit id. usually the root commit id unless it's a fork. |
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.
|
|
||
| - "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) |
There was a problem hiding this comment.
as mentioned in #997 (comment) we should have a cover_letter as a separate kind than a patch because it is different in nature.
There was a problem hiding this comment.
What is the difference between a "cover letter" kind and an "issue" kind?
There was a problem hiding this comment.
A cover letter is always paired with a proposed change. An issue may result in zero or more changes in the future.
Co-authored-by: DanConwayDev <114834599+DanConwayDev@users.noreply.github.com>
|
Here is an idea for reducing duplicate patches in the patch model which wouldn't be feasible in the email client model: |
|
On Tue, Jan 30, 2024 at 08:31:35AM -0800, DanConwayDev wrote:
Here is an idea for reducing duplicate patches in the patch model which wouldn't be feasible in the email client model:
<img width="767" alt="patch-data-saving" src="https://github.com/nostr-protocol/nips/assets/114834599/e09e4695-c2c4-4a97-ab5d-41b1bbbf6710">
I think this just overcomplicates things. It's not uncommon that the
patch set is rebased each time they are sent anyways.
|
|
As @DanConwayDev pointed out it is important to have a way to identify the "root" of a series of patches and comments that refer to that in order to have UIs that display these patches in a coherent way. I'm not thinking about just "patch sets", but also reviews of the same patch by the author after comments, or the cases in which someone might reply to someone else's patch proposing a different way to implement the same thing, or even amending someone else's patch with a patch to the patch -- I don't know. We have some options:
@jb55 @gazhayes @vitorpamplona what do you think would be the best? |
|
Actually now that I wrote that I think this might be a nice solution:
|
|
On Wed, Feb 07, 2024 at 09:54:57AM -0800, fiatjaf_ wrote:
1. enforce a tag `t=root` or something like that for the first patch in
a series of patches so they can be queried on relays
This makes sense to me.
|
|
On Wed, Feb 07, 2024 at 09:57:00AM -0800, fiatjaf_ wrote:
4. the first patch has an `a` tag pointing to the repository
announcement, but the subsequent patches don't, they only refer to the
initial patch, so they don't show in lists of patches for any given
repo.
makes sense
|
|
I have very little knowledge of how git actually works (I never cared enough to learn the clusterfuck of commands that is git), so take this suggestion with a grain of salt. I would keep the Repo Announcement kind (30617) and create two chain heads as new event kinds:
These don't necessarily contain any description or patch but they SHOULD have a From those two kinds, users can attach Comments/Replies (kind:1622) and Patches (1617). These events MUST point to an Issue OR a Change request which controls their lifecycle. People can submit a Patch during a discussion of an Issue (say to show how things could be done) and a Comment during the discussion of a Change Request. They are interchangeable but their order in the chain matters. Both Comments and Patches should reference their parent event in the same way kind 1 replies work. So, not only patches can be applied to the main repo, but also to other patches (or after parent patches were applied to the repo). The "GitHub" client can help take one of these tree branches of replies and patches, apply all patches in sequence to the main repo before merging them. There will be ways to preview each step and rebase them if needed. The order of patches will be dictated by the e-tags and not by the date of each post. Once an Issue or a Change Request is marked as closed, all comments/replies and patches are also closed. |
|
today I released the first version of https://gitworkshop.dev and ngit i'd really appreciate your feedback you can read more about them on the about gitworkshop.dev and ngit pages they implement this nip34 draft with some optional and backwards comparable features (which we could call nip34+ for now), most of which I have mentioned in the thread. the most notable features are to enable a PR-like workflow for those who want it. if anyone's interested I can produce a revision of this nip so you can compare them more easily |
|
I don't know if NIP-34 is the place for this or not, but I need releases and release notes. :) |
|
I think it is. I was thinking of having an event kind for tracking commits and tags. Like you could publish it on every commit, or on every tag so people following a repo could automatically update their local version, or CI services could have their actions triggered. A tag event with a description is a "release". |
|
@DanConwayDev I see that you are using different event types for each status (Open, Closed, Resolved). Was that necessary? |
Originally I had a single status kind and the status name would be included as a hashtag. The approach of using separate kinds for each status, suggested by @fiatjaf, reduces the likelihood of status bloat. I intend to add some optional tags to the applied status kind (1631):
I am currently reusing the same status kinds for root patches and issues. Perhaps that's less kinds for clients to worry about but the 'applied' status feels awkward as it really means 'resolved' in the context of an issue. Perhaps an additional kind could be added just for that. It is also my intention to enables labels (with nip32) so that proposals and issues can be tagged with 'bug', 'feature' 'good-first-issue', 'vnext', 'repo-specific-label', etc. repo maintainers could optionally include a field in their repo event that specifies labels they would like to see used.
Are you suggesting an event per commit? whats the rationale? storing releases in a replaceable tag event is an interesting idea. links to files such as binaries, checksums could be added later, if some of these require the assistance of CI tools (eg platform specific binaries). |
|
If no one opposes that I'm going to merge this and then @DanConwayDev can you open a PR adding the status stuff? |
|
Let's go! We got 3 clients implementing it. |
make that 4. Nostrocket too, and also this service: https://nostrocket.org/products, so 5 depending on how you count. |
|
Looks like I was 20 minutes late but DanConwayDev@6fba968 includes some extra tags and clarifications in case you would like to cherry pick any of it. |
|
Why late? No, the idea was that you would open the PR to |
|
It's ridiculous that we're using GitHub PRs to define how we will get rid of GitHub PRs. |
There was a problem hiding this comment.
sounds good overall.
I personally have given up on pgp. It definitely shines in key rotation,
I give it that, but key rotation in pgp is a huge pain. Right now I
can't really rotate my pgp keys on my yubikey because I have to go
through 100 arcane gpg smartcard steps that I can't be bothered to
figure out again. nostr has already replaced pgp as my web of trust
model for most things.
pgp has a fundamental advantage over NIP-01 as an authenticated format message.
you have multiple signature scheme algorithm supported.
nostr has only one so far, schnorr bip340.
|
|
||
| The tags `web`, `clone`, `relays` can have multiple values. | ||
|
|
||
| Except `d`, all tags are optional. |
There was a problem hiding this comment.
i think you can recommend d to be a 80-bit / 128-bit random string.
that way minimize collision at the relay level
there is name for human-readable label.
There was a problem hiding this comment.
using human readable d identifiers follows a precedent established outside of nip34.
replaceable events are referenced with <kind>:<pubkey>:<identifier> so the collision problem is limited to repo events issued by the same pubkey.
The r tag with a euc marker (earliest unique commit) can also be used to identify the repository.
| "tags": [ | ||
| ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>"], | ||
| ["p", "<repository-owner>"], | ||
| ["p", "<other-user>"], // optionally send the patch to another user to bring it to their attention |
There was a problem hiding this comment.
can say a default limit (e.g 20’s other-user).
relays can have local policy saying they allow more.
or price them with zaps or other micro-payments.
otherwise amplification attack vector for relay.
There was a problem hiding this comment.
events that tag large numbers of pubkeys or events can be identified as spam either at the relay level or by clients.
I'm not sure there needs to be a default limit as other spam identification criteria can be used such as web of trust, reports, etc.
| // 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.
often on projects like linux, you can have commit signed by multiple authors / contributors.
so i think “commit-pgp-sig” + “committer” could be option duplicated.
There was a problem hiding this comment.
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).
The main purpose of retaining the pgp signature is to retain the original commit id.
Including more than one pgp signature and committer would make it unclear which should be used to create the commit id.
What would be the value of including additional pgp signatures when git can't interpret them and all patches / responses are in signed nostr events?
| ["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 |
There was a problem hiding this comment.
i think this could document all you could use directly for mailto URI email address.
emails still widely used for project like linux.
also a fall-back if the list of original relay is perm down.
| "content": "<markdown text>", | ||
| "tags": [ | ||
| ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>"], | ||
| ["p", "<repository-owner>"] |
There was a problem hiding this comment.
i think you could have a list of “p” - “other-user” in kind 1621 as generally you have many people working on large projects.
There was a problem hiding this comment.
Yes. The p tag can be used on any event to bring it to a users attention. The explicit inclusion of this only in the Patch section of the nip is potentially confusing.
| ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>", "<relay-url>"], | ||
| ["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.
i think you could have “relay-local” threading policy on max default “p” elements.
| ["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 |
There was a problem hiding this comment.
this is missing some timestamp / expiry notion.
you can have collaborative codes contributions spawning years on some project.
that ways can be used for policy migration if you wish to update repo-id / relays / root.
There was a problem hiding this comment.
all nostr events must include a created_at timestamp.
any nostr event with a kind in the 30000-40000 range is a 'parameterized replaceable event'. This means all metadata apart from the pubkey and d tag can be updated by issuing a new event with a larger timestamp.
a deletion event (nip09) would indicate the repository event has expired
The simplest possible git collaboration flow that has a chance of working.
The patch stuff is based on http://git.jb55.com/git-nostr-tools, with some changes.
https://github.com/nostr-protocol/nips/blob/git/34.md
Here's a standalone CLI tool that allows for announcing a repository, sending and downloading patches: https://github.com/fiatjaf/gitstr -- probably very rough still, but I just merged a patch from myself using it so I am happy.