5 files changed, 216 insertions, 7 deletions

diff --git a/10.md b/10.md
index 8b7bd57..7f697e9 100644
--- a/10.md
+++ b/10.md
@@ -13,7 +13,7 @@ This NIP describes how to use "e" and "p" tags in text events, especially those
 ## Positional "e" tags (DEPRECATED)
 >This scheme is in common use; but should be considered deprecated.
 
-`["e", <event-id> <relay-url>]`  as per NIP-01.
+`["e", <event-id>, <relay-url>]`  as per NIP-01.
 
 Where:
 
@@ -26,19 +26,19 @@ Where:
  This event is not a reply to, nor does it refer to, any other event.
 
  * One "e" tag: <br>
- `["e",<id>]`: The id of the event to which this event is a reply.
+ `["e", <id>]`: The id of the event to which this event is a reply.
 
- * Two "e" tags:  `["e",<root-id>]`, `["e",<reply-id>]` <br>
+ * Two "e" tags:  `["e", <root-id>]`, `["e", <reply-id>]` <br>
  `<root-id>` is the id of the event at the root of the reply chain.  `<reply-id>` is the id of the article to which this event is a reply.  
 
- * Many "e" tags: `["e",<root-id>]` `["e",<mention-id>]`, ..., `["e",<reply-id>]`<br>
+ * Many "e" tags: `["e", <root-id>]` `["e", <mention-id>]`, ..., `["e", <reply-id>]`<br>
 There may be any number of `<mention-ids>`.  These are the ids of events which may, or may not be in the reply chain.  
 They are citings from this event.  `root-id` and `reply-id` are as above.
 
 >This scheme is deprecated because it creates ambiguities that are difficult, or impossible to resolve when an event references another but is not a reply.
 
 ## Marked "e" tags (PREFERRED)
-`["e", <event-id> <relay-url> <marker>]`  
+`["e", <event-id>, <relay-url>, <marker>]`  
         
 Where:
 
@@ -54,7 +54,7 @@ Where:
 ## The "p" tag
 Used in a text event contains a list of pubkeys used to record who is involved in a reply thread.
 
-When replying to a text event E the reply event's "p" tags should contain all of E's "p" tags as well as the `"pubkey"` of the of the event being replied to.  
+When replying to a text event E the reply event's "p" tags should contain all of E's "p" tags as well as the `"pubkey"` of the event being replied to.  
 
 Example:  Given a text event authored by `a1` with "p" tags [`p1`, `p2`, `p3`] then the "p" tags of the reply should be [`a1`, `p1`, `p2`, `p3`] 
 in no particular order.
diff --git a/22.md b/22.md
new file mode 100644
index 0000000..e4cea51
--- /dev/null
+++ b/22.md
@@ -0,0 +1,42 @@
+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."]')
+```
diff --git a/25.md b/25.md
index b294255..d406a69 100644
--- a/25.md
+++ b/25.md
@@ -7,7 +7,7 @@ Reactions
 
 `draft` `optional` `author:jb55`
 
-A reaction is a `kind 7` note that is used to react to `kind 1` text notes.
+A reaction is a `kind 7` note that is used to react to other notes.
 
 The generic reaction, represented by the `content` set to a `+` string, SHOULD
 be interpreted as a "like" or "upvote".
diff --git a/28.md b/28.md
new file mode 100644
index 0000000..f37299e
--- /dev/null
+++ b/28.md
@@ -0,0 +1,158 @@
+
+NIP-28
+======
+
+Public Chat
+-----------
+
+`draft` `optional` `author:ChristopherDavid` `author:fiatjaf` `author:jb55` `author:Cameri`
+
+This NIP defines new event kinds for public chat channels, channel messages, and basic client-side moderation.
+
+It reserves five event kinds (40-44) for immediate use and five event kinds (45-49) for future use.
+
+- `40 - channel create`
+- `41 - channel metadata`
+- `42 - channel message`
+- `43 - hide message`
+- `44 - mute user`
+
+Client-centric moderation gives client developers discretion over what types of content they want included in their apps, while imposing no additional requirements on relays.
+
+## Kind 40: Create channel
+
+Create a public chat channel.
+
+In the channel creation `content` field, Client SHOULD include basic channel metadata (`name`, `about`, `picture` as specified in kind 41).
+
+```json
+{
+    "content": "{\"name\": \"Demo Channel\", \"about\": \"A test channel.\", \"picture\": \"https://placekitten.com/200/200\"}",
+    ...
+}
+```
+
+
+## Kind 41: Set channel metadata
+
+Update a channel's public metadata.
+
+Clients and relays SHOULD handle kind 41 events similar to kind 0 `metadata` events.
+
+Clients SHOULD ignore kind 41s from pubkeys other than the kind 40 pubkey.
+
+Clients SHOULD support basic metadata fields:
+
+- `name` - string - Channel name
+- `about` - string - Channel description
+- `picture` - string - URL of channel picture
+
+Clients MAY add additional metadata fields.
+
+Clients SHOULD use [NIP-10](10.md) marked "e" tags to recommend a relay.
+
+```json
+{
+    "content": "{\"name\": \"Updated Demo Channel\", \"about\": \"Updating a test channel.\", \"picture\": \"https://placekitten.com/201/201\"}",
+    "tags": [["e", <channel_create_event_id> <relay-url>]],
+    ...
+}
+```
+
+
+## Kind 42: Create channel message
+
+Send a text message to a channel.
+
+Clients SHOULD use [NIP-10](10.md) marked "e" tags to recommend a relay and specify whether it is a reply or root message.
+
+Clients SHOULD append [NIP-10](10.md) "p" tags to replies.
+
+Root message:
+
+```json
+{
+    "content": <string>,
+    "tags": [["e", <kind_40_event_id> <relay-url> "root"]],
+    ...
+}
+```
+
+Reply to another message:
+
+```json
+{
+    "content": <string>,
+    "tags": [
+        ["e", <kind_42_event_id> <relay-url> "reply"],
+        ["p", <pubkey> <relay-url>],
+        ...
+    ],
+    ...
+}
+```
+
+
+## Kind 43: Hide message
+
+User no longer wants to see a certain message.
+
+The `content` may optionally include metadata such as a `reason`.
+
+Clients SHOULD hide event 42s shown to a given user, if there is an event 43 from that user matching the event 42 `id`.
+
+Clients MAY hide event 42s for other users other than the user who sent the event 43.
+
+(For example, if three users 'hide' an event giving a reason that includes the word 'pornography', a Nostr client that is an iOS app may choose to hide that message for all iOS clients.)
+
+```json
+{
+    "content": "{\"reason\": \"Dick pic\"}",
+    "tags": [["e", <kind_42_event_id>]],
+    ...
+}
+```
+
+## Kind 44: Mute user
+
+User no longer wants to see messages from another user.
+
+The `content` may optionally include metadata such as a `reason`.
+
+Clients SHOULD hide event 42s shown to a given user, if there is an event 44 from that user matching the event 42 `pubkey`.
+
+Clients MAY hide event 42s for users other than the user who sent the event 44.
+
+```json
+{
+    "content": "{\"reason\": \"Posting dick pics\"}",
+    "tags": [["p", <pubkey>]],
+    ...
+}
+```
+
+## NIP-10 relay recommendations
+
+For [NIP-10](10.md) relay recommendations, clients generally SHOULD use the relay URL of the original (oldest) kind 40 event.
+
+Clients MAY recommend any relay URL. For example, if a relay hosting the original kind 40 event for a channel goes offline, clients could instead fetch channel data from a backup relay, or a relay that clients trust more than the original relay.
+
+
+Future extensibility
+--------------------
+
+We reserve event kinds 45-49 for other events related to chat, to potentially include new types of media (photo/video), moderation, or support of private or group messaging.
+
+
+Motivation
+----------
+If we're solving censorship-resistant communication for social media, we may as well solve it also for Telegram-style messaging.
+
+We can bring the global conversation out from walled gardens into a true public square open to all.
+
+
+Additional info
+---------------
+
+- [Chat demo PR with fiatjaf+jb55 comments](https://github.com/ArcadeCity/arcade/pull/28)
+- [Conversation about NIP16](https://t.me/nostr_protocol/29566)
diff --git a/README.md b/README.md
index acf8689..aa419bb 100644
--- a/README.md
+++ b/README.md
@@ -18,7 +18,9 @@ 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-28: Public Chat](28.md)
 
 ## Event Kinds
 
@@ -31,6 +33,13 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh
 | 4    | Encrypted Direct Messages | 4    |
 | 5    | Event Deletion            | 9    |
 | 7    | Reaction                  | 25   |
+| 40   | Channel Creation          | 28   |
+| 41   | Channel Metadata          | 28   |
+| 42   | Channel Message           | 28   |
+| 43   | Channel Hide Message      | 28   |
+| 44   | Channel Mute User         | 28   |
+| 45-49 | Public Chat Reserved     | 28   |
+
 
 Please update this list when proposing NIPs introducing new event kinds.