diff --git a/79.md b/79.md
index 40547e3d..09aa0577 100644
--- a/79.md
+++ b/79.md
@@ -61,23 +61,23 @@ then they can forward messages they have received from their client, wrapped as
 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 
+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 
+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 
+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 
+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 
+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:
@@ -87,7 +87,7 @@ For protection against spam, multiple measures can be applied:
 - 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 
+With all these measures in place, open membership based groups across multiple relays can function without central
 coordination.
 
 ## Chatrooms via Hashtags
@@ -96,7 +96,7 @@ 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.
 
-The hashtag of a message should also appear in all 23516 group forwarded messages tags as well to facilitate easier 
+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
@@ -124,9 +124,11 @@ additionally permitted in order to facilitate easy access, this can be informal,
 Further, to facilitate necessary user interface features, all following kinds of users permitted to use the relay should
 be sought and cached:
 
-- ProfileMetadata 0
-- FollowList 3
-- MuteList 10000
+- 0 ProfileMetadata
+- 3 FollowList
+- 10000 MuteList
+- 5 Event Deletion
+- 1984 Reporting
 
 The relay lists can be used to acquire a set of sources to interrogate, and from there these event kinds are needed in
 order to implement the features of this NIP.