chore: fix typos (#2239)

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
 

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
 

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,

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
 

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).

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
 
 #----------------------------------------------------------------------------------------------