Fix grammatical errors in documentation

docs/learn/faq.md

@@ -27,7 +27,7 @@ import { AccordionItem } from '@site/src/components/mdx'
 </AccordionItem>
 
 <AccordionItem title="How does Waku differ from IPFS?">
-  Waku focuses on short, ephemeral, real-time time messages, while IPFS focuses on large, long-term data storage. Although there's an overlap between the two technologies, Waku does not currently support large data for privacy reasons.
+  Waku focuses on short, ephemeral, real-time messages, while IPFS focuses on large, long-term data storage. Although there's an overlap between the two technologies, Waku does not currently support large data for privacy reasons.
 </AccordionItem>
 
 <AccordionItem title="What are Rate Limiting Nullifiers (RLN)?">

docs/learn/research.md

@@ -13,7 +13,7 @@ We have prepared a PoC implementation of this method in JS: <https://examples.wa
 
 ## Prevention of denial of service (DoS) and node incentivisation
 
-Denial of service signifies the case where an adversarial peer exhausts another node's service capacity (e.g., by making a large number of requests) and makes it unavailable to the rest of the system. RnD on DoS attack mitigation can tracked from here: <https://github.com/vacp2p/research/issues/148>.
+Denial of service signifies the case where an adversarial peer exhausts another node's service capacity (e.g., by making a large number of requests) and makes it unavailable to the rest of the system. RnD on DoS attack mitigation can be tracked from here: <https://github.com/vacp2p/research/issues/148>.
 
 In a nutshell, peers have to pay for the service they obtain from each other. In addition to incentivising the service provider, accounting also makes DoS attacks costly for malicious peers. The accounting model can be used in `Store` and `Filter` to protect against DoS attacks.
 

docs/learn/security-features.md

@@ -5,7 +5,7 @@ hide_table_of_contents: true
 
 Waku's protocol layers offer different services and security considerations, shaping the overall security of Waku. We document the security models in the [RFCs of the protocols](https://rfc.vac.dev/), aiming to provide transparent and open-source references. This empowers Waku users to understand each protocol's security guarantees and limitations.
 
-Some of the Waku's security features include the following:
+Some of Waku's security features include the following:
 
 ## [Pseudonymity](https://rfc.vac.dev/waku/standards/core/10/waku2/#pseudonymity)
 

docs/learn/waku-network.md

@@ -11,7 +11,7 @@ The Waku Network is a shared p2p messaging network that is open-access, useful f
 4. Services for resource-restricted nodes, including historical message storage and retrieval, filtering, etc.
 
 :::tip
-If you want to learn more about the Waku Network, the [The Waku Network: Technical Overview](https://blog.waku.org/2024-waku-network-tech-overview) article provides an in-depth look under the hood.
+If you want to learn more about the Waku Network, [The Waku Network: Technical Overview](https://blog.waku.org/2024-waku-network-tech-overview) article provides an in-depth look under the hood.
 :::
 
 ## Why join the Waku network?

docs/privacy-policy.md

@@ -27,7 +27,7 @@ Whenever we refer to “Logos”, “we” or other similar references, we are r
 
 ### 2) We limit the collection and processing of personal data from your use of the Website
 
-We aim to limit the collection and collection and processing of personal data from users of the Website. We only collect and process certain personal data for specific purposes and where we have the legal basis to do so under applicable privacy legislation. We will not collect or process any personal data that we don’t need and where we do store any personal data, we will only store it for the least amount of time needed for the indicated purpose. 
+We aim to limit the collection and processing of personal data from users of the Website. We only collect and process certain personal data for specific purposes and where we have the legal basis to do so under applicable privacy legislation. We will not collect or process any personal data that we don’t need and where we do store any personal data, we will only store it for the least amount of time needed for the indicated purpose. 
 
 In this regard, we collect and process the following personal data from your use of the Website:  
 

docs/research/research-and-studies/maximum-bandwidth.md

@@ -58,7 +58,7 @@ The **trade-off is clear**:
 So it's about where to draw this line.
 
 Points to take into account:
-- **Relay contributes to bandwidth the most**: Relay is the protocol that mostly contributes to bandwidth usage, and it can't choose to allocate fewer bandwidth resources like other protocols (eg `store` can choose to provide less resources and it will work). In other words, the network sets the relay bandwidth requirements, and if the node can't meet them, it just wont work.
+- **Relay contributes to bandwidth the most**: Relay is the protocol that mostly contributes to bandwidth usage, and it can't choose to allocate fewer bandwidth resources like other protocols (eg `store` can choose to provide less resources and it will work). In other words, the network sets the relay bandwidth requirements, and if the node can't meet them, it just won't work.
 - **Upload and download bandwidth are the same**: Due to how gossipsub works, and hence `relay`, the bandwidth consumption is symmetric, meaning that upload and download bandwidth is the same. This is because of `D` and the reciprocity of the connections, meaning that one node upload is another download.
 - **Nodes not meeting requirements can use light clients**. Note that nodes not meeting the bandwidth requirements can still use waku, but they will have to use light protocols, which are a great alternative, especially on mobile, but with some drawbacks (trust assumptions, less reliability, etc)
 - **Waku can't take all the bandwidth:** Waku is meant to be used in conjunction with other services, so it shouldn't consume all the existing bandwidth. If Waku consumes `x Mbps` and someone bandwidth is `x Mpbs`, the UX won't be good.
@@ -80,4 +80,4 @@ Coming up with a number:
 
 **Conclusion:** Limit to `10 Mbps` each waku shard. How? Not trivial, see https://github.com/waku-org/research/issues/22#issuecomment-1727795042
 
-*Note:* This number is not set in stone and is subject to modifications, but it will most likely stay in the same order of magnitude if changed.
+*Note:* This number is not set in stone and is subject to modifications, but it will most likely stay in the same order of magnitude if changed.