diff --git a/.cspell.json b/.cspell.json index b6f63a2..4690b49 100644 --- a/.cspell.json +++ b/.cspell.json @@ -30,7 +30,8 @@ "QUIC", "Dappnode", "gameplay", - "Smol" + "Smol", + "Datagram" ], "flagWords": [], "ignorePaths": [ diff --git a/docs/overview/concepts/network-domains.md b/docs/overview/concepts/network-domains.md index 8420ec1..6610305 100644 --- a/docs/overview/concepts/network-domains.md +++ b/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. \ No newline at end of file diff --git a/docs/overview/concepts/node-discovery.md b/docs/overview/concepts/node-discovery.md index 44e4b6d..d5a1e15 100644 --- a/docs/overview/concepts/node-discovery.md +++ b/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. -- Nodes hindered by restrictive NAT setups are unable to run this protocol. +- Requires lots of connections and involves frequent churn. +- 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. - -:::info -This protocol is intended for situations where the use of `Discv5` is not feasible. -::: +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). #### Pros