addressed review comments

Signed-off-by: Prem Chaitanya Prathi <[email protected]>

Author: chaitanyaprem

standards/core/mix.md

@@ -29,12 +29,12 @@ Without further anonymization, it is easy to analyze the network traffic and det
 Topic interests of a user can be identified by analyzing [Store](https://rfc.vac.dev/waku/standards/core/13/store) query messages sent by a user.
 Same applies for topic subscriptions via [Filter](https://rfc.vac.dev/waku/standards/core/12/filter) protocol.
 
-`Mix` protocol allows libp2p nodes to send messages without revealing the sender's identity to intermediary mix nodes or the recipient/destination.
+`Mix` protocol allows libp2p nodes to send messages without revealing the sender's identity (peer ID, IP address) to intermediary mix nodes or the recipient/destination.
 Anonymity is achieved by using the [Sphinx packet format](#references), which encrypts and routes messages through a series of mix nodes before reaching the recipient.
 
 By integrating the `mix` protocol into the waku network, we can improve the anonymity for publishers and store query users.
-Each waku relay node will be acting as a mix node that forms an `overly mix network`.
-This network of mix nodes SHALL relay mix messages anonymousl to the recepient.
+Each waku relay node will be acting as a mix node that forms an `overlay mix network`.
+This network of mix nodes SHALL relay mix messages anonymously to the recepient.
 
 Anonymity of [Filter](https://rfc.vac.dev/waku/standards/core/12/filter) users is not addressed by this document.
 
@@ -47,30 +47,34 @@ The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL
 Waku Mix creates an `overlay network` of all the waku nodes that support the `mix` protocol.
 
 Nodes with `mix` protocol mounted SHOULD advertise that they support mix protocol via their their chosen discovery method.
-They may do so by updating their [ENR](#enr-updates) and using one of the ENR based discovery methods.
+They MAY do so by updating their [ENR](#enr-updates) and using one of the ENR based discovery methods.
 
 Nodes that want higher anonymity while publishing a message via [lightpush](https://rfc.vac.dev/waku/standards/core/19/lightpush) or performing a [store](https://rfc.vac.dev/waku/standards/core/13/store) query SHOULD use the `mix` protocol to route their messages to the destination.
 Sender Node that would like to use `mix` protocol SHOULD discover enough mix nodes so that there is always a healthy pool of mix nodes available for selection.
-The pool size of mix nodes SHOULD be large enough(greater than 100) for the mixing to be effective.
+The pool size of mix nodes SHOULD be large enough for the mixing to be effective.
+We RECOMMEND a pool size of at least 100 mix nodes for the mixing to be effective.
+
+The serialized [Waku Message](https://rfc.vac.dev/waku/standards/core/14/message) SHOULD be the payload in the [sphinx packet](https://rfc.vac.dev/vac/raw/mix#4-sphinx-packet-format).
 
 In order to provide anonymity of the sender node from the `service-node`,  `Single Use reply blocks` or `anonymous replies` as specified in the original [sphinx](#references) paper SHALL be used.
 
-A node that sends messages using `mix` MAY use 2 redundant (paths)[https://rfc.vac.dev/vac/raw/mix#24-node-discovery] to have better reliability of the message being delivered.
+A node that sends messages using `mix` MAY use two redundant (paths)[https://rfc.vac.dev/vac/raw/mix#24-node-discovery] to have better reliability of the message being delivered.
+It is up to the higher-layer mixed protocol to deduplicate redundant messages received in this way.
 
 ## Node Roles
 
 Mix protocol defines 3 roles for the nodes in the mix network - `sender`, `exit`, `intermediary`.
 
 - An `sender` node is the originator node of a message, i.e a node that wishes to publish/query messages to/from the waku network.
-- An `exit` node is responsible for delivery messages to destination peer in the network.
+- An `exit` node is responsible for delivering messages to destination peer in the network.
 - An `intermediary` node is responsible for forwarding a mix packet to the next mix node in the path.
 
 A Waku relay node SHOULD by default have mix `intermediary` and `exit` node roles in the network.
 The implementation MAY provide a configuration to disable a node from acting as an `intermediary\exit` node.
 
-Any waku node that wishes to publish/query messages from the waku network MUST act as an `sender` node.
+Any waku node that wishes to publish/query messages from the waku network MUST act as a `sender` node.
 
-Light nodes with short connection windows SHOULD always be acting as `sender` nodes.
+Resource-restricted/Edge nodes with short connection windows SHOULD always be acting as `sender` nodes.
 
 ## ENR updates
 
@@ -86,7 +90,8 @@ This moves the problem into discovery domain and requires the following from dis
 1. It is important for nodes to be able to discover as many nodes as possible quickly. This becomes especially important for edge nodes that come online just to publish/query messages for a short period of time.
 2. It is important to have the most recent online status of the nodes so that mix paths that are selected are not broken which lead to reliability issues.
 
-Point-2 above can be mitigated partially by choosing redundant mix paths for the same message by the sender node. This may not be an effective solution as it increases the overall bandwidth usage.
+Point-2 above can be mitigated partially by choosing redundant mix paths for the same message by the sender node.
+This may not be an effective solution as it increases the overall bandwidth usage.
 
 ## Spam Protection
 
@@ -96,8 +101,6 @@ Mix protocol in waku network SHOULD have `rate-limiting/spam` protection to hand
 2. Any node can intentionally generate paths which are broken and send messages into the mix network.
 3. An attacker can spawn a huge number of mix nodes so that user behaviour is observed in order to determine traffic patterns and deanonymize users. 
 
-The current [WAKU RLN](https://rfc.vac.dev/waku/standards/core/17/rln-relay) can address scenario-3 by making it restrictive for users to be able to spawn a lot of nodes in the network.
-
 There is a need to enforce rate-limits and spam protect the mix network. 
 The rate-limiting and spam protection SHALL be addressed as part of future work.