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.
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.
If no `refs` tags are present, the author is no longer tracking repository state using this event. This approach enables the author to restart tracking state at a later time unlike [NIP-09](09.md) deletion requests.
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.
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.
Issues may have a `subject` tag, which clients can utilize to display a header. Additionally, one or more `t` tags may be included to provide labels for the issue.
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.
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.
Definition: Clone URL - a git remote URL listed under the `clone` tag of the repositories kind `30617` event
The offical git client supports interacting with 'remotes' using custom protocols via [git-remote-helpers](https://git-scm.com/docs/gitremote-helpers).
An implementation of git-remote-nostr SHOULD:
### 1. Use Git Remote Nostr URL Format
Struture:
-`nostr://` - git syntax for a protocol URL
-`<user>@` - optional ssh user for interacting with Clone URLs
-`<protocol>/` - optional prefered protocol for interacting with Clone URLs. eg. ssh or https
\*relay hints SHOULD be [URL encoded](https://www.w3.org/Addressing/URL/4_Recommentations.html) eg `ws%3A%2F%2Funencrypted.com` and may omit `wss://` for brevity and readability.
for example `nostr://dan@gitworkshop.dev/ngit` or `nostr://npub15qydau2hjma6ngxkl2cyar74wzyjshvl65za5k5rl69264ar2exs5cyejr/relay.damus.io/ngit`
### 2. Manage state on nostr and access objects via Clone URLs
Store and retrieve state in the `30618` event and git objects in the Clone URLs. Proxy state updates to each Clone URLs.
If a `30618` cannot be found or git config item `nostr.nostate` is `true`, use state from the first Clone URL.
### 3. Use `pr/*` branch namespace for 'Open' patches
Each 'Open' patch / patch set on repository relays SHOULD be have a corresponding branch in the format: