add a scheme for grouping relays for redundancy

79.md

@@ -21,10 +21,11 @@ as a channel specifier.
 
 ## Message Kinds
 
-There are two new message kinds defined for this protocol:
+There are three new event kinds defined for this protocol:
 
-- NRCMessage - a message posted by the user to be broadcast to active subscribers.
-- NRCStatus - a message indicating that a specific user is connected or is about to disconnect.
+- NRCMessage - a message posted by the user to be broadcast to active subscribers
+- NRCStatus - a message indicating that a specific user is connected or is about to disconnect
+- NRCGroup - a wrapped message that was received by one relay and forwarded to others
 
 ### NRCMessage 23514
 
@@ -36,7 +37,7 @@ the following basic markdown features:
 - Headers 1 to 6
 - Double linefeed paragraph separation
 - Images/embeds - but also optionally render them if the file extension is recognised
-- Preformatted monospaced via either indentation or optionally syntax labeled backtick fences
+- Preformatted monospaced via either indentation or (optionally syntax labeled) triple 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).
@@ -52,18 +53,61 @@ messages to be rendered. This also facilitates the ability for direct messages t
 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.
 
+### NRCGroup 23516
+
+In order to facilitate more resilience, it is possible to join a group of relays together and have the above messages
+propagate across all members of the group. The relay must be in the follow list of the recipient and authenticated, and
+then they can forward messages they have received from their client, wrapped as stringified JSON inside a 23516 kind
+event.
+
+For efficiency of filtering, all encapsulated events inside a 23516 must have the npubs in a `p` tag that are found in
+the stringified json inside, which should be copied from further 23516 events at any level of depth. Compliance with 
+this should be verified by relays and failure to do this correctly should result in halting relaying of events from this
+relay, messages should be simply dropped, and the sender will likely automatically drop the connection due to not 
+getting OK acks anymore.
+
+The initiation of this process starts with this message kind with no content, and this causes the recipient to 
+add a subscription for forwarding events received by the relay of the 235xx kind wrapped in a 23516 to the sender of 
+this empty message. This will cease when the socket is disconnected. The wrapped events are sent as-is to all listeners
+subscribed to the event kind, so long as the p tags validate against the p tags in the layers of forwarded messages.
+
+When a relay has more than two other relays joined with it in a group, it will only send messages it receives to two of
+the 3+ other relays, ensuring that the volume of messages is received at most 2-3 times by other members of the group. A 
+buffer of recently broadcast IDs should be maintained along with their timestamp of being received, and after they are
+more than 30 seconds old, they can be safely removed.
+
+The messages will be propagated including the forwarding wrapper, so as a message group gets larger, the messages will 
+be 3 and more layers deep. There is no real need to have groups get much larger than maybe 16 so a depth of 5-7 is 
+likely the maximum practical, and a relay can refuse to forward messages that are more than some specified depth.
+
+For protection against spam, multiple measures can be applied:
+
+- Relays will not accept group join subscriptions from an npub on the owners' mute lists
+- Clients can subscribe to only 23514 and 23516 events and not see events relayed from other group relay members
+- Relays won't send events to clients if the npub of the sender is on their mute list, thus users can mute group member
+  propagated messages, as well as separately filtering out relays and users npubs contained within
+
+With all these measures in place, open membership based groups across multiple relays can function without central 
+coordination.
+
 ## Chatrooms via Hashtags
 
 The simple use of `t` tags and a hashtag MUST be recognised as meaning a message is sent to subscribers interested in
 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.
 
+The hashtag of a message should also appear in all 23516 group forwarded messages tags as well to facilitate easier 
+processing, in addition to all npubs appearing in encapsulated messages. Messages can only have one hashtag.
+
+Messages with hashtags should be whitelist propagated to users who have the hashtag in their follow list, AND NOT in the
+mute list.
+
 ## 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. 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.
+considered a temporary white list for allowed npubs, AND NOT those the user has designated a mute for.
 
 ## Directory Spidering