tiny fix

based on https://github.com/nostr-protocol/nips/pull/20#issuecomment-1194729229

16.md

@@ -21,7 +21,7 @@ Upon an ephemeral event being received, the relay SHOULD send it to all clients
 Client Behavior
 ---------------
 
-Clients SHOULD use the `supported_nips` field to learn if a relay supports generic tag queries.  Clients SHOULD NOT send ephemeral events to relays that do not support this NIP; they will most likely be persisted.  Clients MAY send replaceable events to relays that may not support this NIP, and clients querying SHOULD be prepared for the relay to send multiple events and should use the latest one.  
+Clients SHOULD use the `supported_nips` field to learn if a relay supports this NIP.  Clients SHOULD NOT send ephemeral events to relays that do not support this NIP; they will most likely be persisted.  Clients MAY send replaceable events to relays that may not support this NIP, and clients querying SHOULD be prepared for the relay to send multiple events and should use the latest one.  
 
 Suggested Use Cases
 -------------------

20.md

@@ -1,50 +0,0 @@
-NIP-20
-======
-
-Web Comments
-------------
-
-`draft` `optional` `author:fiatjaf`
-
-A special event with kind `34` is defined, meaning "web comment".
-
-Events of this kind should have at least one `r` tag with the value set to the normalized URL of the webpage they're commenting in.
-
-The content should be the plaintext of the comment.
-
-For example:
-
-```json
-{
-  "kind": 34,
-  "tags": [
-    ["r", "https://random.blog/article"]
-  ],
-  "content": "I didn't like this article.",
-  ...other fields
-```
-
-URL Normalization
------------------
-
-Early prototypes have been using the following naïve URL normalization algorithm:
-
-```js
-export function normalizeURL(raw) {
-  let url = new URL(raw)
-  return (
-    url.origin
-      .replace('://m.', '://') // remove known 'mobile' subdomains
-      .replace('://mobile.', '://')
-      .replace('http://', 'https://') // default everything to https (maybe a terrible idea)
-      .replace( /:\d+/, port => (port === ':443' || port === ':80' ? '' : port)) + // remove 443 and 80 ports
-    url.pathname
-      .replace(/\/+/g, '/') // remove duplicated slashes in the middle of the path
-      .replace(/\/*$/, '') // remove slashes from the end of path
-
-    // notice that only origin ("https://random.blog") and pathname ("/article") are used, all the rest is thrown away
-  )
-}
-```
-
-This is open for improvement, of course.

21.md

@@ -0,0 +1,68 @@
+NIP-21
+======
+
+Non-public encrypted messages
+-----------------------------
+
+`draft` `optional` `author:fiatjaf`
+
+This NIP defines a method for relays to verify the identity of the client that is requesting ["encrypted directed messages"](04.md) and only allow these clients to see messages authored by them or intended for them.
+
+When connecting to relays that support this NIP, clients SHOULD send an event of kind `20001`, meaning "client identification", with the content set to `"client identification for <relay hostname>"`.
+
+The relay MUST then use the event to verify the identity of the client and discard it afterwards. In the verification process the relay MUST check:
+
+  1. if event signature is valid;
+  2. if the content phrase matches the canonical phrase with the actual relay hostname in it;
+  3. if the event timestamp is not too far from the relay's current timestamp.
+
+If all is well, then the relay can use the identified pubkey to validate further requests for kind-4 events and only return kind-4 events that were either authored by the identified pubkey (`"pubkey": ...`) or are addressed to the identified pubkey (`"tags": ["p", ...]`).
+
+### Example
+
+1. Client connects to `wss://chat.relay.nostr.com/`
+2. Client sends `["EVENT", {"id": "...", "pubkey": "aeae...", "sig": "...", "kind": 20001, "tags": [], "created_at": 1609470000, "content": "client identification for chat.relay.nostr.com"}]`
+3. Client sends `["REQ", "my-dms", {"kinds": [4], "#p": ["aeae..."]}, {"kinds": [4],"authors": ["aeae"]}]`
+4. Relay sends `["EVENT", "my-dms", {"id": "...", "pubkey": "aeae...", "kind": 4, "content": "<encrypted>", "sig": "...", "tags": ["p", "786b..."]}]`
+5. Relay sends `["EVENT", "my-dms", {"id": "...", "pubkey": "786b...", "kind": 4, "content": "<encrypted>", "sig": "...", "tags": ["p", "aeae..."]}]`
+
+Ids and signatures omitted and pubkeys shortened for readability.
+
+## Rationale
+
+[NIP-04](04.md) is flawed because its event contents are encrypted, but the metadata around it is not, and by the nature of Nostr as a protocol designed for public communication in general anyone is able to query relays for any event they want -- thus it's possible to anyone to track conversations between any other Nostr users, not _exactly what_ they're saying, but to whom they're chatting and how often.
+
+Thus it's ironic that an end-to-end encrypted messaging protocol (such as NIP-04) turns out to be less private then a not end-to-end encrypted messaging protocol (such as Telegram).
+
+Telegram and other widely used direct messaging apps are generally trusted not only to not reveal metatada, but also to not reveal the contents of the messages, to which they have direct access.
+
+Other messaging services, deemed more private, such as Signal, do not have the contents of the conversations as these are end-to-end encrypted, but do have the metadata, and are trusted to not reveal that.
+
+This NIP, if used in conjunction with relays that are trusted to honor it and not leak private data, makes it so Nostr direct messaging is strictly superior to Telegram[^1] and on par with Signal[^2].
+
+[^1]: Not considering, of course, the million other features Telegram offers, that are irrelevant to this document.
+[^2]: Not considering, of course, the cryptographic protocols that Signal uses to provide forward secrecy and other advanced functionality which are already not present in NIP-04.
+
+## Comparison with other proposals
+
+Over the last months a number of other proposals were made to try to improve the lack of privacy NIP-04 provides[^3][^4][^5].
+
+Although all these proposals solve the issue in some way of another, and it can be argued they are superior to the current (although that can be disputed[^6][^7]), they generally have two shortcomings:
+
+  1. They add a lot of complexity: NIP-04 is very simple and direct, these other proposals are much more involved. More complexity means less clients and less decentralization.
+  2. They are incompatible with the broader Nostr identity scheme: one of the important strengths of Nostr is the ability of relays to identify the authors of events and decide if they are spammers or not, and if they want to store and relay these events or not these or not (for example, based on payment or some other form of registration). Ephemeral public keys or key aliases break these, or at least make them much harder to implement on the relay and client sides, which brings us back to point 1.
+
+[^3]: https://github.com/nostr-protocol/nostr/issues/69
+[^4]: https://github.com/nostr-protocol/nostr/pull/71/files
+[^5]: https://github.com/nostr-protocol/nips/pull/17
+[^6]: For example, even with ephemeral keys, if the general public still have access to all the events some time-analyses and other heuristics can be used to try to track chat activity between Nostr users.
+[^7]: Another example: even with ephemeral keys, it can be assumed that relays will know at least the IP address of the clients that are using it for the kind-4 messages, so they will have almost as much metadata as before -- which brings us back, again, to some level of trust on these relays to not reveal this metadata to the public, as in the current proposal.
+
+## Further possibilities
+
+Some random things that can be optionally done based on this NIP:
+
+  1. If relays can now get the public key of a client that is using it for direct messages, it can also give read reports to the ones who sent the messages (because it will know when the other side of the conversation have requested and received each message in the chat). This is a UX improvement that can't be achieved otherwise.
+  2. Clients can obfuscate the global view relays would have from their metadata by using multiple relays and only sending direct messages to one (or a few) at a time. Thus, if two peers share relays A and B, they can send 50% of the messages through relay A and 50% through relay B.
+
+These possibilities can be specified better on further NIPs.

25.md

@@ -0,0 +1,49 @@
+
+NIP-25
+======
+
+Reactions
+---------
+
+`draft` `optional` `author:jb55`
+
+A reaction is a `kind 7` note that is used to react to `kind 1` text notes.
+
+The generic reaction, represented by the `content` set to a `+` string, SHOULD
+be interpreted as a "like" or "upvote".
+
+A reaction with `content` set to `-` SHOULD be interepreted as a "dislike" or
+"downvote". It SHOULD NOT be counted as a "like", and MAY be displayed as a
+downvote or dislike on a post. A client MAY also choose to tally likes against
+dislikes in a reddit-like system of upvotes and downvotes, or display them as
+separate tallys.
+
+The `content` MAY be an emoji, in this case it MAY be interpreted as a "like",
+or the client MAY display this emoji reaction on the post.
+
+Tags
+----
+
+The reaction event SHOULD include `e` and `p` tags from the note the user is
+reacting to. This allows users to be notified of reactions to posts they were
+mentioned in. Including the `e` tags enables clients to pull all the reactions
+associated with individual posts or all the posts in a thread.
+
+The last `e` tag MUST be the `id` of the note that is being reacted to. 
+
+The last `p` tag MUST be the `pubkey` of the event being reacted to.
+
+Example code
+
+```swift
+func make_like_event(pubkey: String, privkey: String, liked: NostrEvent) -> NostrEvent {
+    var tags: [[String]] = liked.tags.filter { 
+    	tag in tag.count >= 2 && (tag[0] == "e" || tag[0] == "p") 
+    }
+    tags.append(["e", liked.id])
+    tags.append(["p", liked.pubkey])
+    let ev = NostrEvent(content: "", pubkey: pubkey, kind: 7, tags: tags)
+    ev.calculate_id()
+    ev.sign(privkey: privkey)
+    return ev
+}

README.md

@@ -18,17 +18,20 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh
 - [NIP-14: Subject tag in text events.](14.md)
 - [NIP-15: End of Stored Events Notice](15.md)
 - [NIP-16: Event Treatment](16.md)
+- [NIP-25: Reactions](25.md)
 
 ## Event Kinds
 
-| kind | description               | NIP  |
-|------|---------------------------|------|
-| 0    | Metadata                  | 1, 5 |
-| 1    | Text                      | 1    |
-| 2    | Recommend Relay           | 1    |
-| 3    | Contacts                  | 2    |
-| 4    | Encrypted Direct Messages | 4    |
-| 5    | Event Deletion            | 9    |
+| kind  | description               | NIP  |
+|-------|---------------------------|------|
+| 0     | Metadata                  | 1, 5 |
+| 1     | Text                      | 1    |
+| 2     | Recommend Relay           | 1    |
+| 3     | Contacts                  | 2    |
+| 4     | Encrypted Direct Messages | 4    |
+| 5     | Event Deletion            | 9    |
+| 7     | Reaction                  | 25   |
+| 20001 | Client Identification     | 21   |
 
 Please update this list when proposing NIPs introducing new event kinds.