Merge branch 'nostr-protocol:master' into master

Author: RandyMcMillan

11.md

@@ -20,11 +20,9 @@ When a relay receives an HTTP(s) request with an `Accept` header of `application
   "contact": <administrative alternate contact>,
   "supported_nips": <a list of NIP numbers supported by the relay>,
   "software": <string identifying relay software URL>,
-  "version": <string version identifier>
+  "version": <string version identifier>,
   "privacy_policy": <a link to a text file describing the relay's privacy policy>,
   "terms_of_service": <a link to a text file describing the relay's term of service>,
-
-
 }
 ```
 
@@ -162,7 +160,7 @@ a specific niche kind or content. Normal anti-spam heuristics, for example, do n
 
 - `created_at_upper_limit`: 'created_at' upper limit
 
-- `default_limit`: The maximum returned events if you send a filter with the limit set to 0.
+- `default_limit`: The maximum returned events if you send a filter without a `limit`.
 
 ### Event Retention
 

18.md

@@ -21,18 +21,12 @@ reposted.
 
 ## Quote Reposts
 
-Quote reposts are `kind 1` events with an embedded `q` tag of the note being
-quote reposted. The `q` tag ensures quote reposts are not pulled and included
-as replies in threads. It also allows you to easily pull and count all of the
-quotes for a post.
+Mentions to [NIP-21](21.md) entities like `nevent`, `note` and `naddr` on any 
+event must be converted into `q` tags. The `q` tag ensures quote reposts are 
+not pulled and included as replies in threads. It also allows you to easily 
+pull and count all of the quotes for a post. The syntax follows
 
-`q` tags should follow the same conventions as NIP 10 `e` tags, with the exception
-of the `mark` argument.
-
-`["q", <event-id>, <relay-url>, <pubkey>]`
-
-Quote reposts MUST include the [NIP-21](21.md) `nevent`, `note`, or `naddr` of the
-event in the content.
+`["q", "<event-id> or <event-address>", "<relay-url>", "<pubkey-if-a-regular-event>"]`
 
 ## Generic Reposts
 

34.md

@@ -10,7 +10,7 @@ This NIP defines all the ways code collaboration using and adjacent to [`git`](h
 
 ## 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.
+Git repositories are hosted in Git-enabled servers, but their existence can be announced using Nostr events. By doing so the author asserts themselves as a maintainer and expresses a willingness to receive patches, bug reports and comments in general, unless `t` tag `personal-fork` is included.
 
 ```jsonc
 {
@@ -25,6 +25,7 @@ Git repositories are hosted in Git-enabled servers, but their existence can be a
     ["relays", "<relay-url>", ...], // relays that this repository will monitor for patches and issues
     ["r", "<earliest-unique-commit-id>", "euc"],
     ["maintainers", "<other-recognized-maintainer>", ...],
+    ["t","personal-fork"], // optionally indicate author isn't a maintainer
     ["t", "<arbitrary string>"], // hashtags labelling the repository
   ]
 }
@@ -66,9 +67,13 @@ The `refs` tag can be optionally extended to enable clients to identify how many
 }
 ```
 
-## Patches
+## Patches and Pull Requests (PRs)
 
-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.
+Patches and PRs can be sent by anyone to any repository. Patches and PRs to a specific repository SHOULD be sent to the relays specified in that repository's announcement event's `"relays"` tag. Patch and PR events SHOULD include an `a` tag pointing to that repository's announcement address.
+
+Patches SHOULD be used if each event is under 60kb, otherwise PRs SHOULD be used.
+
+### Patches
 
 Patches in a patch set SHOULD include a [NIP-10](10.md) `e` `reply` tag pointing to the previous patch.
 
@@ -103,9 +108,66 @@ The first patch revision in a patch revision SHOULD include a [NIP-10](10.md) `e
 
 The first patch in a series MAY be a cover letter in the format produced by `git format-patch`.
 
+### Pull Requests
+
+The PR or PR update tip SHOULD be successfully pushed to `refs/nostr/<[PR|PR-Update]-event-id>` in all repositories listed in its `clone` tag before the event is signed.
+
+An attempt SHOULD be made to push this ref to all repositories listed in the repository's announcement event's `"clone"` tag, for which their is reason to believe the user might have write access. This includes each [grasp server](https://njump.me/naddr1qvzqqqrhnypzpgqgmmc409hm4xsdd74sf68a2uyf9pwel4g9mfdg8l5244t6x4jdqy28wumn8ghj7un9d3shjtnwva5hgtnyv4mqqpt8wfshxuqlnvh8x) which can be identified using this method: `clone` tag includes `[http|https]://<grasp-path>/<valid-npub>/<string>.git` and `relays` tag includes `[ws/wss]://<grasp-path>`.
+
+Clients MAY fallback to creating a 'personal-fork' `repository announcement` listing other grasp servers, e.g. from the `User grasp list`, for the purpose of serving the specified commit(s).
+
+```jsonc
+{
+  "kind": 1618,
+  "content": "<markdown text>",
+  "tags": [
+    ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>"],
+    ["r", "<earliest-unique-commit-id-of-repo>"] // so clients can subscribe to all PRs sent to a local git repo
+    ["p", "<repository-owner>"],
+    ["p", "<other-user>"], // optionally send the PR to another user to bring it to their attention
+
+    ["subject", "<PR-subject>"],
+    ["t", "<PR-label>"], // optional
+    ["t", "<another-PR-label>"], // optional
+
+    ["c", "<current-commit-id>"], // tip of the PR branch
+    ["clone", "<clone-url>", ...], // at least one git clone url where commit can be downloaded
+    ["branch-name", "<branch-name>"], // optional recommended branch name
+
+    ["e", "<root-patch-event-id>"], // optionally indicate PR is a revision of an existing patch, which should be closed
+    ["merge-base", "<commit-id>"], // optional: the most recent common ancestor with the target branch
+  ]
+}
+```
+
+### Pull Request Updates
+
+A PR Update changes the tip of a referenced PR event.
+
+```jsonc
+{
+  "kind": 1619,
+  "content": "",
+  "tags": [
+    ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>"],
+    ["r", "<earliest-unique-commit-id-of-repo>"] // so clients can subscribe to all PRs sent to a local git repo
+    ["p", "<repository-owner>"],
+    ["p", "<other-user>"], // optionally send the PR to another user to bring it to their attention
+
+    // NIP-22 tags
+    ["E", "<pull-request-event-id>"],
+    ["P", "<pull-request-author>"],
+
+    ["c", "<current-commit-id>"], // updated tip of PR
+    ["clone", "<clone-url>", ...], // at least one git clone url where commit can be downloaded
+    ["merge-base", "<commit-id>"], // optional: the most recent common ancestor with the target branch
+  ]
+}
+```
+
 ## 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.
 
@@ -125,11 +187,11 @@ Issues may have a `subject` tag, which clients can utilize to display a header.
 
 ## Replies
 
-Replies to either a `kind:1621` (_issue_) or a `kind:1617` (_patch_) event should follow [NIP-22 comment](22.md).
+Replies to either a `kind:1621` (_issue_), `kind:1617` (_patch_) or `kind:1618` (_pull request_) event should follow [NIP-22 comment](22.md).
 
 ## Status
 
-Root Patches and Issues have a Status that defaults to 'Open' and can be set by issuing Status events.
+Root Patches, PRs and Issues have a Status that defaults to 'Open' and can be set by issuing Status events.
 
 ```jsonc
 {
@@ -139,7 +201,7 @@ Root Patches and Issues have a Status that defaults to 'Open' and can be set by
   "kind": 1633, // Draft
   "content": "<markdown text>",
   "tags": [
-    ["e", "<issue-or-original-root-patch-id-hex>", "", "root"],
+    ["e", "<issue-or-PR-or-original-root-patch-id-hex>", "", "root"],
     ["e", "<accepted-revision-root-id-hex>", "", "reply"], // for when revisions applied
     ["p", "<repository-owner>"],
     ["p", "<root-event-author>"],
@@ -165,8 +227,22 @@ The most recent Status event (by `created_at` date) from either the issue/patch
 
 The Status of a patch-revision is to either that of the root-patch, or `1632` (_Closed_) if the root-patch's Status is `1631` (_Applied/Merged_) and the patch-revision isn't tagged in the `1631` (_Applied/Merged_) event.
 
+## User grasp list
+
+List of [grasp servers](https://njump.me/naddr1qvzqqqrhnypzpgqgmmc409hm4xsdd74sf68a2uyf9pwel4g9mfdg8l5244t6x4jdqy28wumn8ghj7un9d3shjtnwva5hgtnyv4mqqpt8wfshxuqlnvh8x) the user generally wishes to use for NIP-34 related activity. It is similar in function to the NIP-65 relay list and NIP-B7 blossom list.
+
+The event SHOULD include a list of `g` tags with grasp service websocket URLs in order of preference.
+
+```jsonc
+{
+  "kind": 10317,
+  "content": "",
+  "tags": [
+    ["g", "<grasp-service-websocket-url>"], // zero or more grasp sever urls
+  ]
+}
+```
 
 ## Possible things to be added later
 
-- "branch merge" kind (specifying a URL from where to fetch the branch to be merged)
 - inline file comments kind (we probably need one for patches and a different one for merged files)

37.md

@@ -1,50 +1,57 @@
 NIP-37
 ======
 
-Draft Events 
-------------
+Draft Wraps
+-----------
 
 `draft` `optional`
 
-This NIP defines kind `31234` as a private wrap for drafts of any other event kind. 
+This NIP defines kind `31234` as an encrypted storage for unsigned draft events of any other kind. 
 
-The draft event is JSON-stringified, [NIP44-encrypted](44.md) to the signer's public key and placed inside the `.content` of the event.
+The draft is JSON-stringified, [NIP44-encrypted](44.md) to the signer's public key and placed inside the `.content`.
 
-An additional `k` tag identifies the kind of the draft event. 
+`k` tags identify the kind of the draft. 
 
 ```js
 {
   "kind": 31234,
   "tags": [
     ["d", "<identifier>"],
-    ["k", "<kind of the draft event>"],
-    ["e", "<anchor event event id>", "<relay-url>"],
-    ["a", "<anchor event address>", "<relay-url>"],
+    ["k", "<kind of the draft event>"], // required
+    ["expiration", "now + 90 days"] // recommended
   ],
   "content": nip44Encrypt(JSON.stringify(draft_event)),
   // other fields
 }
 ```
 
-A blanked `.content` means this draft has been deleted by a client but relays still have the event. 
+A blanked `.content` field signals that the draft has been deleted. 
 
-Tags `e` and `a` identify one or more anchor events, such as parent events on replies.   
+[NIP-40](40.md) `expiration` tags are recommended. 
+
+Clients SHOULD publish kind `31234` events to relays listed on kind `10013` below.
 
 ## Relay List for Private Content
 
-Kind `10013` indicates the user's preferred relays to store private events like Drafts. The event MUST include a list of `relay` URLs in private tags. Private tags are JSON Stringified, NIP-44-encrypted to the signer's keys and placed inside the .content of the event.
+Kind `10013` indicates the user's preferred relays to store private events like Draft Wraps. 
+
+The event MUST include a list of `relay` URLs in private tags. Private tags are JSON Stringified, [NIP44-encrypted](44.md) to the signer's keys and placed inside the .content of the event.
 
 ```js
 {
   "kind": 10013,
   "tags": [],
-  "content": nip44Encrypt(JSON.stringify([
-    ["relay", "wss://myrelay.mydomain.com"]
-  ]))
+  "content": nip44Encrypt(
+    JSON.stringify(
+      [
+        ["relay", "wss://myrelay.mydomain.com"]
+      ]
+    )
+  )
   //...other fields
 }
 ```
 
-Relays listed in this event SHOULD be authed and only allow downloads to events signed by the authed user.
+It's recommended that Private Storage relays SHOULD be [NIP-42](42.md)-authed and only allow downloads of events signed by the authed user.
 
-Clients SHOULD publish kind `10013` events to the author's [NIP-65](65.md) `write` relays. 
+Clients MUST publish kind `10013` events to the author's [NIP-65](65.md) `write` relays. 

42.md

@@ -32,6 +32,8 @@ And, when sent by clients, the following form:
 ["AUTH", <signed-event-json>]
 ```
 
+Clients MAY provide signed events from multiple pubkeys in a sequence of `AUTH` messages. Relays MUST treat all pubkeys as authenticated accordingly.
+
 `AUTH` messages sent by clients MUST be answered with an `OK` message, like any `EVENT` message.
 
 ### Canonical authentication event
@@ -69,7 +71,9 @@ relay: ["AUTH", "<challenge>"]
 client: ["REQ", "sub_1", {"kinds": [4]}]
 relay: ["CLOSED", "sub_1", "auth-required: we can't serve DMs to unauthenticated users"]
 client: ["AUTH", {"id": "abcdef...", ...}]
+client: ["AUTH", {"id": "abcde2...", ...}]
 relay: ["OK", "abcdef...", true, ""]
+relay: ["OK", "abcde2...", true, ""]
 client: ["REQ", "sub_1", {"kinds": [4]}]
 relay: ["EVENT", "sub_1", {...}]
 relay: ["EVENT", "sub_1", {...}]

45.md

@@ -14,17 +14,17 @@ Some queries a client may want to execute against connected relays are prohibiti
 
 ## Filters and return values
 
-This NIP defines the verb `COUNT`, which accepts a subscription id and filters as specified in [NIP 01](01.md) for the verb `REQ`. Multiple filters are OR'd together and aggregated into a single count result.
+This NIP defines the verb `COUNT`, which accepts a query id and filters as specified in [NIP 01](01.md) for the verb `REQ`. Multiple filters are OR'd together and aggregated into a single count result.
 
 ```
-["COUNT", <subscription_id>, <filters JSON>...]
+["COUNT", <query_id>, <filters JSON>...]
 ```
 
 Counts are returned using a `COUNT` response in the form `{"count": <integer>}`. Relays may use probabilistic counts to reduce compute requirements.
 In case a relay uses probabilistic counts, it MAY indicate it in the response with `approximate` key i.e. `{"count": <integer>, "approximate": <true|false>}`.
 
 ```
-["COUNT", <subscription_id>, {"count": <integer>}]
+["COUNT", <query_id>, {"count": <integer>}]
 ```
 
 Whenever the relay decides to refuse to fulfill the `COUNT` request, it MUST return a `CLOSED` message.
@@ -34,27 +34,27 @@ Whenever the relay decides to refuse to fulfill the `COUNT` request, it MUST ret
 ### Followers count
 
 ```
-["COUNT", <subscription_id>, {"kinds": [3], "#p": [<pubkey>]}]
-["COUNT", <subscription_id>, {"count": 238}]
+["COUNT", <query_id>, {"kinds": [3], "#p": [<pubkey>]}]
+["COUNT", <query_id>, {"count": 238}]
 ```
 
 ### Count posts and reactions
 
 ```
-["COUNT", <subscription_id>, {"kinds": [1, 7], "authors": [<pubkey>]}]
-["COUNT", <subscription_id>, {"count": 5}]
+["COUNT", <query_id>, {"kinds": [1, 7], "authors": [<pubkey>]}]
+["COUNT", <query_id>, {"count": 5}]
 ```
 
 ### Count posts approximately
 
 ```
-["COUNT", <subscription_id>, {"kinds": [1]}]
-["COUNT", <subscription_id>, {"count": 93412452, "approximate": true}]
+["COUNT", <query_id>, {"kinds": [1]}]
+["COUNT", <query_id>, {"count": 93412452, "approximate": true}]
 ```
 
 ### Relay refuses to count
 
 ```
-["COUNT", <subscription_id>, {"kinds": [4], "authors": [<pubkey>], "#p": [<pubkey>]}]
-["CLOSED", <subscription_id>, "auth-required: cannot count other people's DMs"]
+["COUNT", <query_id>, {"kinds": [1059], "#p": [<pubkey>]}]
+["CLOSED", <query_id>, "auth-required: cannot count other people's DMs"]
 ```