update nip-79 proposal with some changes

79.md

@@ -15,14 +15,16 @@ only via clients implementing a message cache and uploading them to their follow
 default never retaining the message stream (saving data storage and query processing).
 
 If users want asynchronous message delivery, there is existing kinds for this purpose, this NIP only concerns itself
-with synchronous messaging, and only defines ephemeral message kinds.
+with synchronous messaging, and only defines ephemeral message kinds. It is a bare minimal specification, there is no
+explicit moderation capability, only user's own mute lists to have the relay not send them spam, and the use of hashtags
+as a channel specifier.
 
 ## Message Kinds
 
 There are two new message kinds defined for this protocol:
 
 - NRCMessage - a message posted by the user to be broadcast to active subscribers.
-- NRCConnect - a message indicating that a specific user has connected or is about to disconnect.
+- NRCStatus - a message indicating that a specific user is connected or is about to disconnect.
 
 ### NRCMessage 23514
 
@@ -37,12 +39,18 @@ the following basic markdown features:
 - Preformatted monospaced via either indentation or optionally syntax labeled backtick fences
 
 The reason for supporting these features is to facilitate use of the chat for technical discussions. It is OPTIONAL to
-actually implement (since for a TTY or speech based client this may not be practical to render) 
+actually implement (since for a TTY or speech based client this may not be practical to render).
 
-### NRCConnect 23515
+Mentions should use the same syntax as kind 1 notes, with the `nostr:` protocol prefix and the bech32 entity reference.
+Special handling for replies in the context of the ephemeral messages should be used as described below regarding
+replies and quotes, so that anyone who has connected since a replied to message can still see the message.
+
+### NRCStatus 23515
 
 This message type is simply an "online/offline" text in the "content" field, and is used to facilitate "join/part"
 messages to be rendered. This also facilitates the ability for direct messages to be resent if the receiver was offline.
+This message should be sent periodically, like once every 60 seconds or so, in order to function as a dead man switch if
+the offline message fails to send.
 
 ## Chatrooms via Hashtags
 
@@ -50,11 +58,12 @@ The simple use of `t` tags and a hashtag MUST be recognised as meaning a message
 this specific chatroom. `#general` will be a default in clients for the initial room that is rendered in an not yet
 configured client, clients should receive all events in the background and populate a hashtag list to enable favourites.
 
-## Automatic Subscription
+## Automatic Filtering
 
 Follow lists include hashtags, and relays should only send messages that are on the user's follow list OR are tagged
 with a hashtag they follow AND NOT users or hashtags on their mute list. This is additionally facilitated by Directory
-Spidering to gather the available user information required.
+Spidering to gather the available user information required. Additionally, active subscriptions for hashtags should be
+considered a temporary white list for allowed events, AND NOT those the user has designated a mute for.
 
 ## Directory Spidering
 
@@ -80,8 +89,24 @@ order to implement the features of this NIP.
 
 ## Direct Messages
 
-Contain `P` (private) tags and are only sent to the users authed with the designated public key, and are additionally
+Contain `P` (private) tags that designate the recipient,and are only sent to the users authed with the designated public
-encrypted using [NIP-44](44.md).
+key, and are additionally encrypted using [NIP-44](44.md). These may only be sent to a user with the matching pubkey as
+the one designated in the `P` tag. If the user is not online, the message will be dropped, and resending will be the
+responsibility of the client, which may also give the user the option to send a standard 1059/1060 gift wrapped
+persistent private message, which is specified elsewhere.
 
-Optionally clients can implement the ability to resend direct messages that the recipient may not have seen due to the
+## Resending, Quoting and Replying
-client having seen a NRCConnect offline message signalling the user is not receiving messages thereafter.
+
+Clients should enable the feature for users to resend events that are cached in their client, which will be the original
+event stringified in the content field, signed with a new, current timestamp.
+
+To keep things simple, making a reply should wrap the replied to message in a prior message, and the reply itself is a
+subsequent message with an "e" tag marked "reply" in the same way as used for kind 1 text notes.
+
+## Denial of Service Countermeasures
+
+The main kind of DoS attack on a relay hosting a chat service as described here is that of channel stuffing. This can be
+mitigated by using a reasonable averaging window that simply drops messages that exceed a volume of characters beyond
+the capability of a human to input, which would be around 1kb/minute maximum bytes of text, measured by the size of the
+content field of the events. A further limit could cap individual event content size to equivalent to about the same as
+a printed page of text, or about 4096 characters max for a post size.