gnostr-org
diff --git a/‎01.md‎
Lines changed: 3 additions & 2 deletions b/‎01.md‎
Lines changed: 3 additions & 2 deletions
diff --git a/‎03.md‎
Lines changed: 2 additions & 2 deletions b/‎03.md‎
Lines changed: 2 additions & 2 deletions
diff --git a/‎18.md‎
Lines changed: 1 addition & 2 deletions b/‎18.md‎
Lines changed: 1 addition & 2 deletions
diff --git a/‎21.md‎
Lines changed: 1 addition & 1 deletion b/‎21.md‎
Lines changed: 1 addition & 1 deletion
diff --git a/‎22.md‎
Lines changed: 5 additions & 5 deletions b/‎22.md‎
Lines changed: 5 additions & 5 deletions
diff --git a/‎24.md‎
Lines changed: 5 additions & 8 deletions b/‎24.md‎
Lines changed: 5 additions & 8 deletions
diff --git a/‎25.md‎
Lines changed: 21 additions & 9 deletions b/‎25.md‎
Lines changed: 21 additions & 9 deletions
diff --git a/‎26.md‎
Lines changed: 1 addition & 1 deletion b/‎26.md‎
Lines changed: 1 addition & 1 deletion
diff --git a/‎34.md‎
Lines changed: 7 additions & 7 deletions b/‎34.md‎
Lines changed: 7 additions & 7 deletions
diff --git a/‎38.md‎
Lines changed: 2 additions & 2 deletions b/‎38.md‎
Lines changed: 2 additions & 2 deletions
@@ -85,7 +85,7 @@ As a convention, all single-letter (only english alphabet letters: a-z, A-Z) key
 
 ### Kinds
 
-Kinds specify how clients should interpret the meaning of each event and the other fields of each event (e.g. an `"r"` tag may have a meaning in an event of kind 1 and an entirely different meaning in an event of kind 10002). Each NIP may define the meaning of a set of kinds that weren't defined elsewhere. [NIP-10](10.md), for instance, specifies the `kind:1` text note for social media applications.  
+Kinds specify how clients should interpret the meaning of each event and the other fields of each event (e.g. an `"r"` tag may have a meaning in an event of kind 1 and an entirely different meaning in an event of kind 10002). Each NIP may define the meaning of a set of kinds that weren't defined elsewhere. [NIP-10](10.md), for instance, specifies the `kind:1` text note for social media applications.
 
 This NIP defines one basic kind:
 
@@ -170,8 +170,9 @@ This NIP defines no rules for how `NOTICE` messages should be sent or treated.
   * `["OK", "b1a649ebe8...", false, "pow: difficulty 26 is less than 30"]`
   * `["OK", "b1a649ebe8...", false, "restricted: not allowed to write."]`
   * `["OK", "b1a649ebe8...", false, "error: could not connect to the database"]`
+  * `["OK", "b1a649ebe8...", false, "mute: no one was listening to your ephemeral event and it wasn't handled in any way, it was ignored"]`
 - `CLOSED` messages MUST be sent in response to a `REQ` when the relay refuses to fulfill it. It can also be sent when a relay decides to kill a subscription on its side before a client has disconnected or sent a `CLOSE`. This message uses the same pattern of `OK` messages with the machine-readable prefix and human-readable message. Some examples:
   * `["CLOSED", "sub1", "unsupported: filter contains unknown elements"]`
   * `["CLOSED", "sub1", "error: could not connect to the database"]`
   * `["CLOSED", "sub1", "error: shutting down idle subscription"]`
-- The standardized machine-readable prefixes for `OK` and `CLOSED` are: `duplicate`, `pow`, `blocked`, `rate-limited`, `invalid`, `restricted`, and `error` for when none of that fits.
+- The standardized machine-readable prefixes for `OK` and `CLOSED` are: `duplicate`, `pow`, `blocked`, `rate-limited`, `invalid`, `restricted`, `mute` and `error` for when none of that fits.
@@ -12,8 +12,8 @@ This NIP defines an event with `kind:1040` that can contain an [OpenTimestamps](
 {
   "kind": 1040
   "tags": [
-    ["e", <event-id>, <relay-url>],
-    ["alt", "opentimestamps attestation"]
+    ["e", <target-event-id>, <relay-url>],
+    ["k", "<target-event-kind>"]
   ],
   "content": <base64-encoded OTS file data>
 }
 
@@ -40,6 +40,5 @@ Since `kind 6` reposts are reserved for `kind 1` contents, we use `kind 16`
 as a "generic repost", that can include any kind of event inside other than
 `kind 1`.
 
-`kind 16` reposts SHOULD contain a `k` tag with the stringified kind number
+`kind 16` reposts SHOULD contain a `"k"` tag with the stringified kind number
 of the reposted event as its value.
-
@@ -21,7 +21,7 @@ The identifiers that come after are expected to be the same as those defined in
 
 ### Linking HTML pages to Nostr entities
 
-`<link>` tags with `rel="alternate"` can be used to associate webpages to Nostr events, in cases where the same content is served via the two mediums (for example, a web server that exposes Markdown articles both as HTML pages and as `kind:30023' events served under itself as a relay or through some other relay). For example:
+`<link>` tags with `rel="alternate"` can be used to associate webpages to Nostr events, in cases where the same content is served via the two mediums (for example, a web server that exposes Markdown articles both as HTML pages and as `kind:30023` events served under itself as a relay or through some other relay). For example:
 
 ```
 <head>
 
@@ -45,7 +45,7 @@ Tags `K` and `k` MUST be present to define the event kind of the root and the pa
 
 `I` and `i` tags create scopes for hashtags, geohashes, URLs, and other external identifiers.
 
-The possible values for `i` tags – and `k` tags, when related to an extenal identity – are listed on [NIP-73](73.md).
+The possible values for `i` tags – and `k` tags, when related to an external identity – are listed on [NIP-73](73.md).
 Their uppercase versions use the same type of values but relate to the root item instead of the parent one.
 
 `q` tags MAY be used when citing events in the `.content` with [NIP-21](21.md).
@@ -143,13 +143,13 @@ A comment on a website's url looks like this:
   "tags": [
     // referencing the root url
     ["I", "https://abc.com/articles/1"],
-    // the root "kind": for an url, the kind is its domain
-    ["K", "https://abc.com"],
+    // the root "kind": for an url
+    ["K", "web"],
 
     // the parent reference (same as root for top-level comments)
     ["i", "https://abc.com/articles/1"],
-    // the parent "kind": for an url, the kind is its domain
-    ["k", "https://abc.com"]
+    // the parent "kind": for an url
+    ["k", "web"]
   ]
   // other fields
 }
 
@@ -8,8 +8,7 @@ Extra metadata fields and tags
 
 This NIP keeps track of extra optional fields that can added to events which are not defined anywhere else but have become _de facto_ standards and other minor implementation possibilities that do not deserve their own NIP and do not have a place in other NIPs.
 
-kind 0
-======
+### kind 0
 
 These are extra fields not specified in NIP-01 that may be present in the stringified JSON of metadata events:
 
@@ -19,24 +18,22 @@ These are extra fields not specified in NIP-01 that may be present in the string
   - `bot`: a boolean to clarify that the content is entirely or partially the result of automation, such as with chatbots or newsfeeds.
   - `birthday`: an object representing the author's birth date. The format is { "year": number, "month": number, "day": number }. Each field MAY be omitted.
 
-### Deprecated fields
+#### Deprecated fields
 
 These are fields that should be ignored or removed when found in the wild:
 
   - `displayName`: use `display_name` instead.
   - `username`: use `name` instead.
 
-kind 3
-======
+### kind 3
 
 These are extra fields not specified in NIP-02 that may be present in the stringified JSON of follow events:
 
-### Deprecated fields
+#### Deprecated fields
 
   - `{<relay-url>: {"read": <true|false>, "write": <true|false>}, ...}`: an object of relays used by a user to read/write. [NIP-65](65.md) should be used instead.
 
-tags
-====
+### tags
 
 These tags may be present in multiple event kinds. Whenever a different meaning is not specified by some more specific NIP, they have the following meanings:
 
 
@@ -26,8 +26,6 @@ There SHOULD be a `p` tag set to the `pubkey` of the event being reacted to. If
 
 If the event being reacted to is an addressable event, an `a` SHOULD be included together with the `e` tag, it must be set to the coordinates (`kind:pubkey:d-tag`) of the event being reacted to.
 
-The reaction SHOULD include a `k` tag with the stringified kind number of the reacted event as its value.
-
 The `e` and `a` tags SHOULD include relay and pubkey hints. The `p` tags SHOULD include relay hints.
 
 The reaction event MAY include a `k` tag with the stringified kind number of the reacted event as its value.
@@ -47,25 +45,39 @@ func make_like_event(pubkey: String, privkey: String, liked: NostrEvent, hint: S
 }
 ```
 
-Reactions to a website
+External Content Reactions
 ---------------------
 
-If the target of the reaction is a website, the reaction MUST be a `kind 17` event and MUST include an `r` tag with the website's URL.
+If the target of a reaction is not a native nostr event, the reaction MUST be a `kind 17` event and MUST include [NIP-73](73.md) external content `k` + `i` tags to properly reference the content.
 
+_Reacting to a website:_
 ```jsonc
 {
   "kind": 17,
   "content": "⭐",
   "tags": [
-    ["r", "https://example.com/"]
+    ["k", "web"],
+    ["i", "https://example.com"]
+  ],
+}
+```
+
+_Reacting to a podcast episode:_
+```jsonc
+{
+  "kind": 17,
+  "content": "+",
+  "tags": [
+    ["k", "podcast:guid"],
+    ["i", "podcast:guid:917393e3-1b1e-5cef-ace4-edaa54e1f810", "https://fountain.fm/show/QRT0l2EfrKXNGDlRrmjL"],
+    ["k", "podcast:item:guid"],
+    ["i", "podcast:item:guid:PC20-229", "https://fountain.fm/episode/DQqBg5sD3qFGMCZoSuLF"]
   ],
-  // other fields...
 }
 ```
 
-URLs SHOULD be [normalized](https://datatracker.ietf.org/doc/html/rfc3986#section-6), so that reactions to the same website are not omitted from queries.
-A fragment MAY be attached to the URL, to react to a section of the page.
-It should be noted that a URL with a fragment is not considered to be the same URL as the original.
+
+
 
 Custom Emoji Reaction
 ---------------------
 
@@ -1,4 +1,4 @@
-> __Warning__  `unrecommended`: adds unecessary burden for little gain
+> __Warning__  `unrecommended`: adds unnecessary burden for little gain
 
 NIP-26
 =======
 
@@ -45,7 +45,7 @@ An optional source of truth for the state of branches and tags in a repository.
   "kind": 30618,
   "content": "",
   "tags": [
-    ["d", "<repo-id>"], // matches the identifier in the coresponding repository announcement
+    ["d", "<repo-id>"], // matches the identifier in the corresponding repository announcement
     ["refs/<heads|tags>/<branch-or-tag-name>","<commit-id>"]
     ["HEAD", "ref: refs/heads/<branch-name>"]
   ]
@@ -70,9 +70,9 @@ The `refs` tag can be optionally extended to enable clients to identify how many
 
 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 in a patch set SHOULD include a NIP-10 `e` `reply` tag pointing to the previous patch.
+Patches in a patch set SHOULD include a [NIP-10](10.md) `e` `reply` tag pointing to the previous patch.
 
-The first patch revision in a patch revision SHOULD include a NIP-10 `e` `reply` to the original root patch.
+The first patch revision in a patch revision SHOULD include a [NIP-10](10.md) `e` `reply` to the original root patch.
 
 ```jsonc
 {
@@ -125,7 +125,7 @@ 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_) or a `kind:1617` (_patch_) event should follow [NIP-22 comment](22.md).
 
 ## Status
 
@@ -150,7 +150,7 @@ Root Patches and Issues have a Status that defaults to 'Open' and can be set by
     ["r", "<earliest-unique-commit-id-of-repo>"]
 
     // optional for `1631` status
-    ["e", "<applied-or-merged-patch-event-id>", "", "mention"], // for each
+    ["q", "<applied-or-merged-patch-event-id>", "<relay-url>", "<pubkey>"], // for each
     // when merged
     ["merge-commit", "<merge-commit-id>"]
     ["r", "<merge-commit-id>"]
@@ -161,9 +161,9 @@ Root Patches and Issues have a Status that defaults to 'Open' and can be set by
 }
 ```
 
-The Status event with the largest created_at date is valid.
+The most recent Status event (by `created_at` date) from either the issue/patch author or a maintainer is considered 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.
+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.
 
 
 ## Possible things to be added later
 
@@ -50,11 +50,11 @@ The status MAY include an `r`, `p`, `e` or `a` tag linking to a URL, profile, no
 
 The `content` MAY include emoji(s), or [NIP-30](30.md) custom emoji(s). If the `content` is an empty string then the client should clear the status.
 
-# Client behavior
+## Client behavior
 
 Clients MAY display this next to the username on posts or profiles to provide live user status information.
 
-# Use Cases
+## Use Cases
 
 * Calendar nostr apps that update your general status when you're in a meeting
 * Nostr Nests that update your general status with a link to the nest when you join
Original file line number	Diff line number	Diff line change
@@ -12,8 +12,8 @@ This NIP defines an event with `kind:1040` that can contain an [OpenTimestamps](
`12`	`12`	`{`
`13`	`13`	`"kind": 1040`
`14`	`14`	`"tags": [`
`15`		`- ["e", <event-id>, <relay-url>],`
`16`		`- ["alt", "opentimestamps attestation"]`
	`15`	`+ ["e", <target-event-id>, <relay-url>],`
	`16`	`+ ["k", "<target-event-kind>"]`
`17`	`17`	`],`
`18`	`18`	`"content": <base64-encoded OTS file data>`
`19`	`19`	`}`
Original file line number	Diff line number	Diff line change
`@@ -1,4 +1,4 @@`
`1`		-> __Warning__ `unrecommended`: adds unecessary burden for little gain
	`1`	+> __Warning__ `unrecommended`: adds unnecessary burden for little gain
`2`	`2`
`3`	`3`	`NIP-26`
`4`	`4`	`=======`