7 files changed, 115 insertions, 14 deletions

diff --git a/01.md b/01.md
index 33a10e7..0744058 100644
--- a/01.md
+++ b/01.md
@@ -16,7 +16,7 @@ The only object type that exists is the `event`, which has the following format
 
 ```json
 {
-  "id": <32-bytes lowercase hex-encoded sha256 of the serialized event data>
+  "id": <32-bytes lowercase hex-encoded sha256 of the serialized event data>,
   "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
   "created_at": <unix timestamp in seconds>,
   "kind": <integer>,
@@ -99,7 +99,7 @@ This NIP defines no rules for how `NOTICE` messages should be sent or treated.
 ## Basic Event Kinds
 
   - `0`: `set_metadata`: the `content` is set to a stringified JSON object `{name: <username>, about: <string>, picture: <url, string>}` describing the user who created the event. A relay may delete past `set_metadata` events once it gets a new one for the same pubkey.
-  - `1`: `text_note`: the `content` is set to the plaintext content of a note (anything the user wants to say). Do not use Markdown! Clients should not have to guess how to interpret content like `[]()`. Use different event kinds for parsable content.
+  - `1`: `text_note`: the `content` is set to the **plaintext** content of a note (anything the user wants to say). Content that must be parsed, such as Markdown and HTML, should not be used. Clients should also not parse content as those.
   - `2`: `recommend_server`: the `content` is set to the URL (e.g., `wss://somerelay.com`) of a relay the event creator wants to recommend to its followers.
 
 A relay may choose to treat different message kinds differently, and it may or may not choose to have a default way to handle kinds it doesn't know about.
@@ -110,3 +110,4 @@ A relay may choose to treat different message kinds differently, and it may or m
 - The `tags` array can store a tag identifier as the first element of each subarray, plus arbitrary information afterward (always as strings). This NIP defines `"p"` — meaning "pubkey", which points to a pubkey of someone that is referred to in the event —, and `"e"` — meaning "event", which points to the id of an event this event is quoting, replying to or referring to somehow. See [NIP-10](10.md) for a detailed description of "e" and "p" tags.
 - The `<recommended relay URL>` item present on the `"e"` and `"p"` tags is an optional (could be set to `""`) URL of a relay the client could attempt to connect to fetch the tagged event or other events from a tagged profile. It MAY be ignored, but it exists to increase censorship resistance and make the spread of relay addresses more seamless across clients.
 - Clients should use the created_at field to judge the age of a metadata event and completely replace older metadata events with newer metadata events regardless of the order in which they arrive.  Clients should not merge any filled fields within older metadata events into empty fields of newer metadata events.
+- When a websocket is closed by the relay with a status code 4000 that means the client shouldn't try to connect again.
diff --git a/09.md b/09.md
index a73e0ab..9dab90f 100644
--- a/09.md
+++ b/09.md
@@ -8,7 +8,7 @@ Event Deletion
 
 A special event with kind `5`, meaning "deletion" is defined as having a list of one or more `e` tags, each referencing an event the author is requesting to be deleted.
 
-Each tag entry must contain an "e" event id intended for deletion.
+Each tag entry must contain an "e" event id and/or NIP-33 `a` tags intended for deletion.
 
 The event's `content` field MAY contain a text note describing the reason for the deletion.
 
@@ -20,7 +20,8 @@ For example:
   "pubkey": <32-bytes hex-encoded public key of the event creator>,
   "tags": [
     ["e", "dcd59..464a2"],
-    ["e", "968c5..ad7a4"]
+    ["e", "968c5..ad7a4"],
+    ["a", "<kind>:<pubkey>:<d-identifier>"]
   ],
   "content": "these posts were published by accident",
   ...other fields
diff --git a/18.md b/18.md
index 422ad9c..75c4100 100644
--- a/18.md
+++ b/18.md
@@ -6,11 +6,10 @@ Reposts
 
 `draft` `optional` `author:jb55` `author:fiatjaf` `author:arthurfranca`
 
-A repost is a `kind 6` note that is used to signal to followers
-that another event is worth reading.
+A repost is a `kind 6` event that is used to signal to followers
+that a `kind 1` text note is worth reading.
 
-The `content` of a repost event is empty. Optionally, it MAY contain
-the stringified JSON of the reposted note event for quick look up.
+The `content` of a repost event is _the stringified JSON of the reposted note_. It MAY also be empty, but that is not recommended.
 
 The repost event MUST include an `e` tag with the `id` of the note that is
 being reposted. That tag MUST include a relay URL as its third entry
@@ -21,5 +20,15 @@ reposted.
 
 ## Quote Reposts
 
-Quote reposts are `kind 1` events with an embedded `e` tag (see [NIP-08](08.md) and [NIP-27](27.md)).
-Because a quote repost includes an `e` tag, it may show up along replies to the reposted note.
+Quote reposts are `kind 1` events with an embedded `e` tag
+(see [NIP-08](08.md) and [NIP-27](27.md)). Because a quote repost includes
+an `e` tag, it may show up along replies to the reposted note.
+
+## Generic Reposts
+
+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
+of the reposted event as its value.
diff --git a/26.md b/26.md
index b8fa902..59cf807 100644
--- a/26.md
+++ b/26.md
@@ -1,4 +1,4 @@
-NIP: 26
+NIP-26
 =======
 
 Delegated Event Signing
@@ -52,7 +52,9 @@ For example, the following condition strings are valid:
 - `kind=0&kind=1&created_at>1675721813`
 - `kind=1&created_at>1674777689&created_at<1675721813`
 
-For the vast majority of use-cases, it is advisable that query strings should include a `created_at` ***after*** condition reflecting the current time, to prevent the delegatee from publishing historic notes on the delegator's behalf.
+For the vast majority of use-cases, it is advisable that:
+1. Query strings should include a `created_at` ***after*** condition reflecting the current time, to prevent the delegatee from publishing historic notes on the delegator's behalf.
+2. Query strings should include a `created_at` ***before*** condition that is not empty and is not some extremely distant time in the future. If delegations are not limited in time scope, they expose similar security risks to simply using the root key for authentication.
 
 #### Example
 
@@ -105,4 +107,4 @@ Clients should display the delegated note as if it was published directly by the
 
 Relays should answer requests such as `["REQ", "", {"authors": ["A"]}]` by querying both the `pubkey` and delegation tags `[1]` value.
 
-Relays SHOULD allow the delegator (8e0d3d3e) to delete the events published by the delegatee (477318cf).
\ No newline at end of file
+Relays SHOULD allow the delegator (8e0d3d3e) to delete the events published by the delegatee (477318cf).
diff --git a/31.md b/31.md
new file mode 100644
index 0000000..e77ae34
--- /dev/null
+++ b/31.md
@@ -0,0 +1,15 @@
+NIP-31
+======
+
+Dealing with unknown event kinds
+--------------------------------
+
+`draft` `optional` `author:pablof7z` `author:fiatjaf`
+
+When creating a new custom event kind that is part of a custom protocol and isn't meant to be read as text (like `kind:1`), clients should use an `alt` tag to write a short human-readable plaintext summary of what that event is about.
+
+The intent is that social clients, used to display only `kind:1` notes, can still show something in case a custom event pops up in their timelines. The content of the `alt` tag should provide enough context for a user that doesn't know anything about this event kind to understand what it is.
+
+These clients that only know `kind:1` are not expected to ask relays for events of different kinds, but users could still reference these weird events on their notes, and without proper context these could be nonsensical notes. Having the fallback text makes that situation much better -- even if only for making the user aware that they should try to view that custom event elsewhere.
+
+`kind:1`-centric clients can make interacting with these event kinds more functional by supporting [NIP-89](https://github.com/nostr-protocol/nips/blob/master/89.md).
diff --git a/98.md b/98.md
new file mode 100644
index 0000000..ecbebc0
--- /dev/null
+++ b/98.md
@@ -0,0 +1,68 @@
+NIP-98
+======
+
+HTTP Auth
+-------------------------
+
+`draft` `optional` `author:kieran` `author:melvincarvalho`
+
+This NIP defines an ephemerial event used to authorize requests to HTTP servers using nostr events.
+
+This is useful for HTTP services which are build for Nostr and deal with Nostr user accounts.
+
+## Nostr event
+
+A `kind 27235` (In reference to [RFC 7235](https://www.rfc-editor.org/rfc/rfc7235)) event is used.
+
+The `content` SHOULD be empty.
+
+The following tags are defined as REQUIRED.
+
+* `u` - absolute URL
+* `method` - HTTP Request Method
+
+Example event:
+```json
+{
+    "id": "fe964e758903360f28d8424d092da8494ed207cba823110be3a57dfe4b578734",
+    "pubkey": "63fe6318dc58583cfe16810f86dd09e18bfd76aabc24a0081ce2856f330504ed",
+    "content": "",
+    "kind": 27235,
+    "created_at": 1682327852,
+    "tags": [
+        [
+            "u",
+            "https://api.snort.social/api/v1/n5sp/list"
+        ],
+        [
+            "method",
+            "GET"
+        ]
+    ],
+    "sig": "5ed9d8ec958bc854f997bdc24ac337d005af372324747efe4a00e24f4c30437ff4dd8308684bed467d9d6be3e5a517bb43b1732cc7d33949a3aaf86705c22184"
+}
+```
+
+Servers MUST perform the following checks in order to validate the event:
+1. The `kind` MUST be `27235`.
+2. The `created_at` MUST be within a reasonable time window (suggestion 60 seconds).
+3. The `u` tag MUST be exactly the same as the absolute request URL (including query parameters).
+4. The `method` tag MUST be the same HTTP method used for the requested resource.
+
+When the request contains a body (as in POST/PUT/PATCH methods) clients SHOULD include a SHA256 hash of the request body in a `payload` tag as hex (`["payload", "<sha256-hex>"]`), servers MAY check this to validate that the requested payload is authorized.
+
+If one of the checks was to fail the server SHOULD respond with a 401 Unauthorized response code.
+
+All other checks which server MAY do are OPTIONAL, and implementation specific.
+
+## Request Flow
+
+Using the `Authorization` header, the `kind 27235` event MUST be `base64` encoded and use the Authorization scheme `Nostr`
+
+Example HTTP Authorization header:
+```
+Authorization: Nostr eyJpZCI6ImZlOTY0ZTc1ODkwMzM2MGYyOGQ4NDI0ZDA5MmRhODQ5NGVkMjA3Y2JhODIzMTEwYmUzYTU3ZGZlNGI1Nzg3MzQiLCJwdWJrZXkiOiI2M2ZlNjMxOGRjNTg1ODNjZmUxNjgxMGY4NmRkMDllMThiZmQ3NmFhYmMyNGEwMDgxY2UyODU2ZjMzMDUwNGVkIiwiY29udGVudCI6IiIsImtpbmQiOjI3MjM1LCJjcmVhdGVkX2F0IjoxNjgyMzI3ODUyLCJ0YWdzIjpbWyJ1cmwiLCJodHRwczovL2FwaS5zbm9ydC5zb2NpYWwvYXBpL3YxL241c3AvbGlzdCJdLFsibWV0aG9kIiwiR0VUIl1dLCJzaWciOiI1ZWQ5ZDhlYzk1OGJjODU0Zjk5N2JkYzI0YWMzMzdkMDA1YWYzNzIzMjQ3NDdlZmU0YTAwZTI0ZjRjMzA0MzdmZjRkZDgzMDg2ODRiZWQ0NjdkOWQ2YmUzZTVhNTE3YmI0M2IxNzMyY2M3ZDMzOTQ5YTNhYWY4NjcwNWMyMjE4NCJ9
+```
+
+## Reference Implementations
+- C# ASP.NET `AuthenticationHandler` [NostrAuth.cs](https://gist.github.com/v0l/74346ae530896115bfe2504c8cd018d3)
\ No newline at end of file
diff --git a/README.md b/README.md
index fbe43f9..83d19ad 100644
--- a/README.md
+++ b/README.md
@@ -46,6 +46,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-27: Text Note References](27.md)
 - [NIP-28: Public Chat](28.md)
 - [NIP-30: Custom Emoji](30.md)
+- [NIP-31: Dealing with Unknown Events](31.md)
 - [NIP-33: Parameterized Replaceable Events](33.md)
 - [NIP-36: Sensitive Content](36.md)
 - [NIP-39: External Identities in Profiles](39.md)
@@ -63,6 +64,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-78: Application-specific data](78.md)
 - [NIP-89: Recommended Application Handlers](89.md)
 - [NIP-94: File Metadata](94.md)
+- [NIP-98: HTTP Auth](98.md)
 
 ## Event Kinds
 
@@ -74,9 +76,10 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `3`     | Contacts                   | [2](02.md)  |
 | `4`     | Encrypted Direct Messages  | [4](04.md)  |
 | `5`     | Event Deletion             | [9](09.md)  |
-| `6`     | Reposts                    | [18](18.md) |
+| `6`     | Repost                     | [18](18.md) |
 | `7`     | Reaction                   | [25](25.md) |
 | `8`     | Badge Award                | [58](58.md) |
+| `16`    | Generic Repost             | [18](18.md) |
 | `40`    | Channel Creation           | [28](28.md) |
 | `41`    | Channel Metadata           | [28](28.md) |
 | `42`    | Channel Message            | [28](28.md) |
@@ -94,6 +97,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `23194` | Wallet Request             | [47](47.md) |
 | `23195` | Wallet Response            | [47](47.md) |
 | `24133` | Nostr Connect              | [46](46.md) |
+| `27235` | HTTP Auth                  | [98](98.md) |
 | `30000` | Categorized People List    | [51](51.md) |
 | `30001` | Categorized Bookmark List  | [51](51.md) |
 | `30008` | Profile Badges             | [58](58.md) |
@@ -146,6 +150,7 @@ When experimenting with kinds, keep in mind the classification introduced by [NI
 | name              | value                                | other parameters     | NIP                      |
 | ----------------- | ------------------------------------ | -------------------- | ------------------------ |
 | `a`               | coordinates to an event              | relay URL            | [33](33.md), [23](23.md) |
+| `alt`             | Alt tag                              | --                   | [31](31.md)              |
 | `d`               | identifier                           | --                   | [33](33.md)              |
 | `e`               | event id (hex)                       | relay URL, marker    | [1](01.md), [10](10.md)  |
 | `g`               | geohash                              | --                   | [12](12.md)              |