diff --git a/README.md b/README.md index fc054e64f..ec5de6c78 100644 --- a/README.md +++ b/README.md @@ -55,7 +55,7 @@ After successfully building the project, you may bring the bundled runtime into ```bash source env.sh ``` -If everything went well, your should see your prompt suffixed with `[Nimbus env]$`. Now you can run `nim` commands as usual. +If everything went well, you should see your prompt suffixed with `[Nimbus env]$`. Now you can run `nim` commands as usual. ### Waku Protocol Test Suite diff --git a/apps/networkmonitor/README.md b/apps/networkmonitor/README.md index 79041953c..eef956db0 100644 --- a/apps/networkmonitor/README.md +++ b/apps/networkmonitor/README.md @@ -54,14 +54,14 @@ Metrics are divided into two categories: The following metrics are available. See `http://localhost:8008/metrics` -* `peer_type_as_per_enr`: Number of peers supporting each capability according the the ENR (Relay, Store, Lightpush, Filter) +* `peer_type_as_per_enr`: Number of peers supporting each capability according to the ENR (Relay, Store, Lightpush, Filter) * `peer_type_as_per_protocol`: Number of peers supporting each protocol, after a successful connection) * `peer_user_agents`: List of useragents found in the network and their count Other relevant metrics reused from `nim-eth`: * `routing_table_nodes`: Inherited from nim-eth, number of nodes in the routing table -* `discovery_message_requests_outgoing_total`: Inherited from nim-eth, number of outging discovery requests, useful to know if the node is actiely looking for new peers +* `discovery_message_requests_outgoing_total`: Inherited from nim-eth, number of outgoing discovery requests, useful to know if the node is actively looking for new peers ### Custom Metrics diff --git a/apps/networkmonitor/networkmonitor_metrics.nim b/apps/networkmonitor/networkmonitor_metrics.nim index 61d2d6912..e93d3da58 100644 --- a/apps/networkmonitor/networkmonitor_metrics.nim +++ b/apps/networkmonitor/networkmonitor_metrics.nim @@ -26,7 +26,7 @@ logScope: #discovery_message_requests_outgoing_total{response="no_response"} declarePublicGauge networkmonitor_peer_type_as_per_enr, - "Number of peers supporting each capability according the the ENR", + "Number of peers supporting each capability according to the ENR", labels = ["capability"] declarePublicGauge networkmonitor_peer_type_as_per_protocol, diff --git a/docs/tutorial/chat2.md b/docs/tutorial/chat2.md index d0e8383d4..6ccc7f181 100644 --- a/docs/tutorial/chat2.md +++ b/docs/tutorial/chat2.md @@ -7,7 +7,7 @@ It optionally connects to a [fleet of nodes](fleets.status.im) to provide end-to Each fleet is a publicly accessible network of Waku v2 peers, providing a bootstrap connection point for new peers, historical message storage, etc. The Waku team is currently using this application on the _production_ fleet for internal testing. For more information on the available fleets, see [`Connecting to a Waku v2 fleet`](#connecting-to-a-waku-v2-fleet). -If you want try our protocols, or join the dogfooding fun, follow the instructions below. +If you want to try our protocols, or join the dogfooding fun, follow the instructions below. ## Preparation diff --git a/waku/node/waku_node.nim b/waku/node/waku_node.nim index 82f72f8e5..edbaad32e 100644 --- a/waku/node/waku_node.nim +++ b/waku/node/waku_node.nim @@ -430,7 +430,7 @@ proc filterHandleMessage*(node: WakuNode, proc mountFilterClient*(node: WakuNode) {.async, raises: [Defect, LPError].} = ## Mounting both filter clients v1 - legacy and v2. - ## Giving option for application level to chose btw own push message handling or + ## Giving option for application level to choose btw own push message handling or ## rely on node provided cache. - This only applies for v2 filter client info "mounting filter client" @@ -869,7 +869,7 @@ when defined(waku_exp_store_resume): proc resume*(node: WakuNode, peerList: Option[seq[RemotePeerInfo]] = none(seq[RemotePeerInfo])) {.async, gcsafe.} = ## resume proc retrieves the history of waku messages published on the default waku pubsub topic since the last time the waku node has been online ## for resume to work properly the waku node must have the store protocol mounted in the full mode (i.e., persisting messages) - ## messages are stored in the the wakuStore's messages field and in the message db + ## messages are stored in the wakuStore's messages field and in the message db ## the offline time window is measured as the difference between the current time and the timestamp of the most recent persisted waku message ## an offset of 20 second is added to the time window to count for nodes asynchrony ## peerList indicates the list of peers to query from. The history is fetched from the first available peer in this list. Such candidates should be found through a discovery method (to be developed). diff --git a/waku/waku_rln_relay/rln/rln_interface.nim b/waku/waku_rln_relay/rln/rln_interface.nim index c3668c6c6..7a37ac990 100644 --- a/waku/waku_rln_relay/rln/rln_interface.nim +++ b/waku/waku_rln_relay/rln/rln_interface.nim @@ -80,7 +80,7 @@ proc atomic_write*(ctx: ptr RLN, index: uint, leaves_buffer: ptr Buffer, indices ## the return bool value indicates the success or failure of the operation proc reset_tree*(ctx: ptr RLN, tree_height: uint): bool {.importc: "set_tree".} -## resets the tree stored by ctx to the the empty tree (all leaves set to 0) of height tree_height +## resets the tree stored by ctx to the empty tree (all leaves set to 0) of height tree_height ## the return bool value indicates the success or failure of the operation #----------------------------------------------------------------------------------------------