NIP-34: add git remote helper

add Git Remote Nostr URL format so clients can provide appropriate
clone urls. This is used by ngit and gitworkshop.dev minus the
usage of nip05 addresses.

See this discussion of the format:
https://njump.me/nevent1qvzqqqqqqypzpgqgmmc409hm4xsdd74sf68a2uyf9pwel4g9mfdg8l5244t6x4jdqy88wumn8ghj7mn0wvhxcmmv9uqsuamnwvaz7tmwdaejumr0dshsqg993aqt7e4v2p3cu06axwzsz999s798d04u27e50nn52la7t6t5dy94kk26

add wider git remote helper spec implemented by git plugin bundled
with 'ngit'

34.md

@@ -1,8 +1,6 @@
-NIP-34
-======
+# NIP-34
 
-`git` stuff
------------
+## `git` stuff
 
 `draft` `optional`
 
@@ -96,6 +94,9 @@ The first patch revision in a patch revision SHOULD include a NIP-10 `e` `reply`
     ["parent-commit", "<parent-commit-id>"],
     ["commit-pgp-sig", "-----BEGIN PGP SIGNATURE-----..."], // empty string for unsigned commit
     ["committer", "<name>", "<email>", "<timestamp>", "<timezone offset in minutes>"],
+
+    ["branch-name", "<custom-branch-name>"], // optional short name for use by git-remote-nostr
+
   ]
 }
 ```
@@ -104,7 +105,7 @@ The first patch in a series MAY be a cover letter in the format produced by `git
 
 ## 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. 
+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.
 
@@ -136,9 +137,9 @@ Replies are also Markdown text. The difference is that they MUST be issued as re
 
     // other "e" and "p" tags should be applied here when necessary, following the threading rules of NIP-10
     ["p", "<patch-author-pubkey-hex>", "", "mention"],
-    ["e", "<previous-reply-id-hex>", "", "reply"],
+    ["e", "<previous-reply-id-hex>", "", "reply"]
     // rest of tags...
-  ],
+  ]
   // other fields...
 }
 ```
@@ -181,6 +182,49 @@ The Status event with the largest created_at date is valid.
 
 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.
 
+## Git client nostr plugin (git-remote-nostr)
+
+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
+- kind `30617` event coordinate in format:
+  - `<naddr>`
+  - `<npub|nip05-address>/<identifier>`
+  - `<npub|nip05-address>/<relay-hint*>/<identifier>`
+
+\*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:
+
+`pr/<branch-name*>(<first-8-chars-of-hex-root-patch-event-id)`
+
+A branch pushed in the format `pr/<branch-name>` should be published as a:
+
+- patch / patch set, if there is no upstream branch
+- patch revision, if there is a upstream branch with conflicts
+- as additional patches in the set, if there is an upstream branch without conflicts
+
+\*`<branch-name>` is the first 60 chars of root event `branch-name` tag if present, or the commit subject, with invalid chars replaced with `-`.
 
 ## Possible things to be added later