mirror of
https://github.com/acid-info/waku.guide.git
synced 2025-02-23 23:38:10 +00:00
397be651dc
* chore: rename md files and use config ordering it is unfeasible to track the changes in files labelled as '1.md', '2.md', etc and way easier when the files are named after their contents. * fix: hint box render * fix: markdown links
1.6 KiB
1.6 KiB
| title |
|---|
| Motivation and goals |
Waku as a family of protocols is designed to have a set of properties that are useful for many applications:
- Generalized messaging.
Many applications require some form of messaging protocol to communicate between different subsystems or different nodes. This messaging can be human-to-human or machine-to-machine or a mix. Waku is designed to work for all these scenarios.
- Peer-to-peer.
Applications sometimes have requirements that make them suitable for peer-to-peer solutions:
- Censorship-resistant with no single point of failure
- Adaptive and scalable network
- Shared infrastructure/service network
- Runs anywhere.
Applications often run in restricted environments, where resources or the environment is restricted in some fashion. For example:
- Limited bandwidth, CPU, memory, disk, battery, etc
- Not being publicly connectable
- Only being intermittently connected; mostly-offline
- Privacy-preserving.
Applications often have a desire for some privacy guarantees, such as:
- Pseudonymity and not being tied to any personally identifiable information (PII)
- Metadata protection in transit
- Various forms of unlinkability, etc
- Modular design.
Waku nodes are adaptive: you can turn several dials depending on your use case and environment.
For example:
- Low privacy/low resource usage vs high privacy/increased latency + bandwidth usage
- Providing resources to the network vs consuming resources
- Stronger guarantees for spam protection vs economic registration cost