add nip-20: web comments.

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 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.  
+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.  
 
 Suggested Use Cases
 -------------------

20.md

@@ -0,0 +1,50 @@
+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.

22.md

@@ -1,42 +0,0 @@
-NIP-22
-======
-
-Event `created_at` Limits
----------------------------
-
-`draft` `optional` `author:jeffthibault` `author:Giszmo`
-
-Relays may define both upper and lower limits within which they will consider an event's `created_at` to be acceptable. Both the upper and lower limits MUST be unix timestamps in seconds as defined in [NIP-01](01.md).
-
-If a relay supports this NIP, the relay SHOULD send the client a `NOTICE` message saying the event was not stored for the `created_at` timestamp not being within the permitted limits.
-
-Client Behavior
----------------
-
-Clients SHOULD use the [NIP-11](11.md) `supported_nips` field to learn if a relay uses event `created_at` time limits as defined by this NIP.
-
-Motivation
-----------
-
-This NIP formalizes restrictions on event timestamps as accepted by a relay and allows clients to be aware of relays that have these restrictions.
-
-The event `created_at` field is just a unix timestamp and can be set to a time in the past or future. Relays accept and share events dated to 20 years ago or 50,000 years in the future. This NIP aims to define a way for relays that do not want to store events with *any* timestamp to set their own restrictions.
-
-[Replaceable events](16.md#replaceable-events) can behave rather unexpected if the user wrote them - or tried to write them - with a wrong system clock. Persisting an update with a backdated system now would result in the update not getting persisted without a `NOTICE` and if they did the last update with a forward dated system, they will again fail to do another update with the now correct time.
-
-A wide adoption of this nip could create a better user experience as it would decrease the amount of events that appear wildly out of order or even from impossible dates in the distant past or future.
-
-Python Example
---------------
-
-```python
-import time
-
-TIME = int(time.now)
-LOWER_LIMIT = TIME - (60 * 60 * 24) # Define lower limit as 1 day into the past
-UPPER_LIMIT = TIME + (60 * 15)      # Define upper limit as 15 minutes into the future
-
-if event.created_at not in range(LOWER_LIMIT, UPPER_LIMIT):
-  # NOTE: This is one example of a notice message. Relays can change this to notify clients however they like.
-  ws.send('["NOTICE", "The event created_at field is out of the acceptable range (-24h, +15min) for this relay and was not stored."]')
-```

25.md

@@ -1,49 +0,0 @@
-
-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
-}

27.md

@@ -1,91 +0,0 @@
-NIP-27
-======
-
-Restricted Tags
----------------
-
-`draft` `optional` `author:cameri`
-
-This NIP extends the `<filters>` object described in `NIP-01` to contain
-arbitrary two-letter tags (known as restricted tags) prefixed by `#`, allowing
-for events with restricted tags to be queried. Any two-letter key prefixed by
-`#` is a restricted tag query and must be an array of strings.
-
-The filter condition matches an event if and only if all of the restricted tags
-in the event are also present in a `<filters>` object. As such, relays should not
-forward events with restricted tags to clients without a strictly matching filter.
-
-A client wishing to use restricted tags should only send events with restricted
-tags to relays that explicitly support NIP-27.
-
-## Events
-
-Clients wishing to send an event with a restricted tag may include one or more
-two-letter tags with a value set to an arbitrary string.
-
-Suppose that Alice wants to send an event with the restricted tag `#ch`. The value
-of the `#ch` restricted tag is the following string: `/nostr/social`
-
-Alice would construct the following message and send it to her favorite relay
-which happens to support restricted tags:
-
-```json
-[
-  "EVENT",
-  {
-    "id": "<id>",
-    "pubkey": "<Alice's pubkey>",
-    "created_at": 1231469640,
-    "content": "Let's get the conversation started",
-    "tags": [
-      ["ch", "/nostr/social"],
-    ],
-    "sig": "<sig>"
-  }
-]
-```
-
-## Subscriptions
-
-Clients wishing to subscribe to events with restricted tags MUST include a filter
-that matches all of the restricted tags in said events.
-
-Suppose that Bob and Charlie both share Alice's interest and would like to stay
-up to date. Both would construct the following message to subscribe:
-
-```json
-[
-  "REQ",
-  "<subscriptionId>",
-  {
-    "#ch": ["/nostr/social"]
-  }
-]
-```
-
-# Use Cases
-
-1. Subreddit/IRC-like channels (e.g. `{ "#ch": ["r/oldschoolcool"] }`) over Nostr.
-2. Forums. (e.g. General/Support subforum at itguys.com forum
-  `{ "#fr": ["itguys.com"], "#sb": ["General/Support"] }`)
-3. Clients wishing to filter out all the noise from the broad public events may
-choose to only subscribe to events with restricted tags. Apps/games/bots leveraging
-Nostr may prefer communicating using NIP-27 to namespace their communications.
-4. A restricted tag with a hard-to-guess value can be used for increased isolation
-in communications without the expectation of privacy. A "channel-hopping" algorithm
-shared by clients may improve isolation in this scenario.
-5. Two or more parties may initiate contact publicly using Direct Messaging to then
-upgrade their communications to using events with restricted tags with a hard-to-guess
-value before continuing their exchange. Parties can re-negotiate a new hard-to-guess
-value at any point.
-6. Live events can take advantage of ephemeral events and events with restricted
-tags for exclusivity during the event.
-7. Smart contracts may communicate with individual clients using events with
-restricted tags.
-8. Developers debugging in Nostr can use events with restricted tags to avoid spamming
-others in public relays.
-
-
-# Notes
-
-1. Events with restricted tags are public and offer no privacy.

README.md

@@ -18,9 +18,6 @@ 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-22: Event created_at Limits](22.md)
-- [NIP-25: Reactions](25.md)
-- [NIP-27: Restricted events](27.md)
 
 ## Event Kinds
 
@@ -32,7 +29,6 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh
 | 3    | Contacts                  | 2    |
 | 4    | Encrypted Direct Messages | 4    |
 | 5    | Event Deletion            | 9    |
-| 7    | Reaction                  | 25   |
 
 Please update this list when proposing NIPs introducing new event kinds.