update network-domains & node-discovery

.cspell.json

@@ -30,7 +30,8 @@
     "QUIC",
     "Dappnode",
     "gameplay",
-    "Smol"
+    "Smol",
+    "Datagram"
   ],
   "flagWords": [],
   "ignorePaths": [

docs/overview/concepts/network-domains.md

@@ -31,7 +31,7 @@ participant B as B relay(pubtopic1)
 participant C as C relay(pubtopic1)
 participant D as D relay(pubtopic1), store(pubtopic1), filter
 participant E as E relay, store
-participant F as F relay, filter
+participant F as F filter
 
 A ->> A: msg1=WakuMessage(contentTopic1, data) (1)
 F ->> D: FilterRequest(pubtopic1, contentTopic1) (2)
@@ -39,6 +39,7 @@ D ->> D: Subscribe F to filter (2)
 A ->> B: Publish msg1 on pubtopic1 (3)
 B ->> D: relay msg1 on pubtopic1 (3)
 D ->> D: store: saves msg1 (4)
+D ->> C: relay msg1 on pubtopic1 (4)
 D ->> F: MessagePush(msg1) (5)
 E ->> E: E comes online (6)
 E ->> D: HistoryQuery(pubtopic1, contentTopic1) (6)
@@ -50,6 +51,6 @@ The Pub/Sub topic `pubtopic1` serves as a means of routing messages (the network
 1. Node A creates a WakuMessage `msg1` with a [ContentTopic](/overview/concepts/content-topics) `contentTopic1`.
 2. Node F requests to get messages filtered by Pub/Sub topic `pubtopic1` and ContentTopic `contentTopic1`. Node D subscribes F to this filter and will forward messages that match that filter in the future.
 3. Node A publishes `msg1` on `pubtopic1`. The message is sent from Node A to Node B and then forwarded to Node D.
-4. Node D, upon receiving `msg1`, stores the message in its store for possible later retrieval by other nodes.
+4. Node D, upon receiving `msg1` both stores the message for future retrieval by other nodes and forwards it to Node C.
 5. Node D also pushes `msg1` to Node F, informing it about the arrival of a new message.
 6. At a later time, Node E comes online and requests messages matching `pubtopic1` and `contentTopic1` from Node D. Node D responds with `msg1` and potentially other messages that match the query.

docs/overview/concepts/node-discovery.md

@@ -2,7 +2,7 @@
 title: Node Discovery Mechanisms
 ---
 
-When initializing a Waku node, it must connect with other nodes to enable message sending, receiving, and retrieval. To achieve this, a discovery mechanism is employed to locate other nodes where no connections are present. This process is known as bootstrapping.
+When initializing a Waku node, it must connect with other nodes to enable message sending, receiving, and retrieval. To achieve this, a discovery mechanism is employed to locate and connect with other nodes. This process is known as bootstrapping.
 
 After establishing a connection, the node must actively seek out additional peers to have:
 
@@ -23,7 +23,7 @@ Waku applications have the flexibility to embed bootstrap node addresses directl
 
 - Vulnerable to censorship: Node IPs can be blocked or restricted.
 - Limited scalability: The number of nodes is fixed and cannot easily be expanded.
-- Maintenance challenges: Updating the node list requires modifying the code, which can be cumbersome and less maintainable.
+- Maintenance challenges: Updating the node list requires modifying the code, which can be cumbersome and involves releasing and deploying.
 
 ## [DNS Discovery](https://rfc.vac.dev/spec/31/)
 
@@ -40,7 +40,7 @@ This bootstrapping method allows anyone to register and publish a domain name fo
 #### Cons
 
 - Vulnerable to censorship: Domain names can be blocked or restricted.
-- Limited scalability: The number of nodes is fixed, and operators need to provide their `ENR` to the domain owner for listing.
+- Limited scalability: The listed nodes are at risk of being overwhelmed by receiving all queries. Also, operators must provide their `ENR` to the domain owner for listing.
 
 ## [Discv5](https://rfc.vac.dev/spec/33/)
 
@@ -53,16 +53,12 @@ This bootstrapping method allows anyone to register and publish a domain name fo
 
 #### Cons
 
-- Demands high resource allocation.
+- Requires lots of connections and involves frequent churn.
-- Nodes hindered by restrictive NAT setups are unable to run this protocol.
+- Relies on User Datagram Protocol (UDP), which is not supported in web browsers.
 
 ## [Peer Exchange](https://rfc.vac.dev/spec/34/)
 
-The primary objective of this protocol is to facilitate peer connectivity for resource-restricted devices. The peer exchange protocol enables lightweight nodes to request peers from other nodes within the network. Light nodes can bootstrap and expand their mesh independently without relying on [Discv5](#discv5) or bootstrap nodes.
+The primary objective of this protocol is to facilitate peer connectivity for resource-restricted devices. The peer exchange protocol enables lightweight nodes to request peers from other nodes within the network. Light nodes can bootstrap and expand their mesh independently without relying on [Discv5](#discv5).
-
-:::info
-This protocol is intended for situations where the use of `Discv5` is not feasible.
-:::
 
 #### Pros