diff --git a/.cspell.json b/.cspell.json new file mode 100644 index 0000000..962242d --- /dev/null +++ b/.cspell.json @@ -0,0 +1,24 @@ +{ + "version": "0.2", + "$schema": "https://raw.githubusercontent.com/streetsidesoftware/cspell/master/cspell.schema.json", + "language": "en", + "words": ["waku"], + "flagWords": [], + "ignorePaths": [ + "package.json", + "package-lock.json", + "yarn.lock", + "tsconfig.json", + "node_modules/**" + ], + "patterns": [ + { "name": "multiaddr", "pattern": "/p2p.*/" }, + { "name": "dnsMultiaddr", "pattern": "//dns4.*/" }, + { "name": "wss", "pattern": "/wss:.*/" }, + { + "name": "youtube-link", + "pattern": "/< youtube.*/" + } + ], + "ignoreRegExpList": ["multiaddr", "dnsMultiaddr", "wss", "youtube-link"] +} diff --git a/.gitignore b/.gitignore index 3651560..bd5955b 100644 --- a/.gitignore +++ b/.gitignore @@ -1,6 +1,7 @@ # Dependencies /node_modules + # Production /build @@ -15,8 +16,8 @@ .env.test.local .env.production.local + npm-debug.log* yarn-debug.log* yarn-error.log* -.idea \ No newline at end of file diff --git a/.vscode/settings.json b/.vscode/settings.json new file mode 100644 index 0000000..5429fb5 --- /dev/null +++ b/.vscode/settings.json @@ -0,0 +1,3 @@ +{ + "cSpell.words": ["Waku"] +} diff --git a/docs/About/1.md b/docs/About/1.md new file mode 100644 index 0000000..59cb09c --- /dev/null +++ b/docs/About/1.md @@ -0,0 +1,13 @@ +--- +title: Introduction +--- + +Waku (v2) is family of modular peer-to-peer protocols for **secure communication**. The protocols are designed to be secure, privacy-preserving, censorship-resistant and able to run in resource restricted environments. + +It enables you to **add communication features** to your dApp in a **decentralized manner**, +ensuring to your users that they will not be censored or de-platformed. + +- **removes centralized third parties from messaging**: enabling private, secure, censorship-free communication with no single point of failure. +- provides **privacy-preserving capabilities**: sender anonymity, metadata protection and unlinkability to personally identifiable information. +- designed for **generalized messaging**: enables human-to-human, machine-to-machine or hybrid communication. +- **runs everywhere**: desktop, server, including resource-restricted devices, such as mobile devices and browsers. diff --git a/docs/About/2.md b/docs/About/2.md new file mode 100644 index 0000000..6fb09a1 --- /dev/null +++ b/docs/About/2.md @@ -0,0 +1,28 @@ +--- +title: History +--- + +Waku v1 was a fork of Whisper with some added tweaks for efficiency. +Waku v2 is a completely redesigned suite of protocols designed to address the goals set out [previously](./1). + +### 2013 + +Ethereum White Paper was introduced with the Holy Trinity, +consisting of Ethereum for consensus, Swarm for decentralized storage, and Whisper for p2p messaging. + +### 2015-2018 + +R&D of Whisper was slow to follow progress of the Ethereum EVM and Swarm without a dedicated team building out the protocol. + +### 2018 + +With little progress made on Whisper and significant scalability concerns growing, +Vac was formed to conduct R&D on more scalable p2p messaging. + +### 2020 + +Waku v1 was introduced as the messaging protocol in Status, replacing Whisper. + +### 2021 + +Waku v2 replaces Waku v1. diff --git a/docs/About/3.md b/docs/About/3.md new file mode 100644 index 0000000..fc0fea9 --- /dev/null +++ b/docs/About/3.md @@ -0,0 +1,46 @@ +--- +title: Motivation and goals +--- + +Waku as a family of protocols is designed to have a set of properties that are useful for many applications: + +1. **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. + +2. **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 + +3. **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 + +4. **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 + +5. **Modular design.** + +Waku nodes are [adaptive](https://rfc.vac.dev/spec/30/): 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 diff --git a/docs/About/4.md b/docs/About/4.md new file mode 100644 index 0000000..18bc224 --- /dev/null +++ b/docs/About/4.md @@ -0,0 +1,32 @@ +--- +title: Why Waku? +--- + +Communication today is rife with third party interference. +From censorship and deplatforming, to rent seeking intermediaries, to the misuse of data in the surveillance economy. + +Waku is designed to place control of communication back into the hands of the individual. + +It is the communication layer for Web3 -- **decentralized communication that scales**. + +- Waku fills the void left by Whisper. + +- We are building Waku as a public good for the Ethereum and multi-chain ecosystem. + +- It is not tied to a specific chain. + +- It is modular and adaptive, enabling various use cases. + +- It enables developers to decentralize communication in their dApps or move actions off-chain without compromising decentralization. + +- It aims to run anywhere, in the cloud and browser alike. + +Private. Secure. Runs anywhere. + +| | Whisper | Waku | +|----------------------------------------| ------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------: | +| **Scalability** | Whisper doesn't scale very well, specifically when it comes to bandwidth usage on mobile devices. | Uses gossipsub and content topics. | +| **Spam Resistance** | Proof of work requires too much battery and compute power making it a poor mechanism for heterogeneous nodes. | Uses innovative p2p economic spam protection mechanism RLN Relay | +| **No incentivized infrastructure** | There is no incentive to run a Whisper node | Research in progress to design incentivization for node operators. | +| **Formal Specification/Documentation** | Lack of formal and unambiguous specification | Open source specs & docs and available for anyone to read or improve. | +| **Portability** | Runs over devp2p which limits where Whisper can run and how | Waku is built using libp2p, making it easy to run Waku anywhere. | diff --git a/docs/About/5.md b/docs/About/5.md new file mode 100644 index 0000000..d909b11 --- /dev/null +++ b/docs/About/5.md @@ -0,0 +1,15 @@ +--- +title: Who is using Waku? +--- + +### Status + +[Status](https://status.im/) is a secure messaging app, crypto wallet, and Web3 browser built with state-of-the-art technology. + +### XMTP + +[XMTP](https://xmtp.org/) is using Waku v2 for their open protocol and network for secure web3 messaging. + +### RAILGUN + +[RAILGUN](https://railgun.org/) is a privacy system for Ethereum that shields your assets in your own smart contract wallet. RAILGUN uses Waku when offering the ETH gas payments to other users, privately signaling fees and offers for gas payment relayers to keep the privacy & anonymity of your stablecoin & token transactions. diff --git a/docs/About/6.md b/docs/About/6.md new file mode 100644 index 0000000..30411d6 --- /dev/null +++ b/docs/About/6.md @@ -0,0 +1,21 @@ +--- +title: Implementations +--- + +Waku has been implemented in multiple languages to cater to a variety of unique use-cases: + +#### [nwaku](https://github.com/status-im/nwaku) + +A nim implementation of the Waku v2 protocol. The reference implementation, recommended to deploy a node in the cloud or at home. + +#### [js-waku](https://github.com/waku-org/js-waku/) + +A JavaScript/TypeScript implementation for browser environments. + +#### [go-waku](https://github.com/status-im/go-waku) + +A Go implementation for native integration in go applications, C-Bindings are also available with C#, Swift and Kotlin examples. + +#### [@waku/react-native](https://github.com/waku-org/waku-react-native) + +Integrate Waku in your React Native app using go-waku for mobile. diff --git a/docs/About/7.md b/docs/About/7.md new file mode 100644 index 0000000..e0a4d1b --- /dev/null +++ b/docs/About/7.md @@ -0,0 +1,16 @@ +--- +title: How does it work? +--- + +The backbone of Waku Network is the Waku Relay protocol. +It is a pubsub protocol based on libp2p gossipsub. +Other Waku protocols have been defined to enable capabilities such as: + +1. retrieving **historical messages** for mostly-offline devices +2. key turn solution for **encrypted communication** (symmetric encryption, ECIES/asymmetric encryption, noise handshake). +3. preserving bandwidth usage for **resource-restricted devices** +4. Economic **spam protection** (rate limit) with privacy preserving capabilities +5. Mass deanonymization protection (research in progress) + + +If you want to learn how Waku works under the hoods, check out the [10/WAKU2](https://rfc.vac.dev/spec/10/) RFC. diff --git a/docs/Concepts/1.md b/docs/Concepts/1.md new file mode 100644 index 0000000..c4add40 --- /dev/null +++ b/docs/Concepts/1.md @@ -0,0 +1,69 @@ +--- +title: Protocols Explained +--- + +Currently the main protocols used for Waku are: + +### [Waku Relay](https://rfc.vac.dev/spec/11/) + +`WAKU2-RELAY` specifies a Publish/Subscribe approach to peer-to-peer messaging with a strong focus on privacy, censorship-resistance, security and scalability. +Its current implementation is a minor extension of the libp2p GossipSub protocol and prescribes gossip-based dissemination. + +An extension of this is `WAKU-RLN-RELAY`, a privacy-preserving economic spam protection mechanism. + +### [Waku Filter](https://rfc.vac.dev/spec/12/) + +`WAKU2-FILTER` is a protocol that enables subscribing to messages that a peer receives. +It enables a node to access the relay network without the connectivity and bandwidth requirements of relay nodes, but it comes with privacy drawbacks. +Light nodes subscribe to service nodes and only receive the messages they desire. + +This is used to make fetching of a subset of messages more bandwidth preserving. + +### [Waku Store](https://rfc.vac.dev/spec/13/) + +DApps running on a phone or in a browser are often offline: +The browser could be closed or mobile app in the background. + +[Waku Relay](https://rfc.vac.dev/spec/11/) is a gossip protocol. +As a user, it means that your peers forward you messages they just received. +If you cannot be reached by your peers, then messages are not relayed; +relay peers do **not** save messages for later. + +However, [Waku Store](https://rfc.vac.dev/spec/13/) peers do save messages they relay, +allowing you to retrieve them at a later time. +The Waku Store protocol is best-effort and does not guarantee data availability. +Waku Relay or Waku Filter should still be preferred when online; +Waku Store can be used after resuming connectivity: +For example, when the dApp starts. + +### [Waku Light Push](https://rfc.vac.dev/spec/19/) + +Waku Light Push enables a client to receive a confirmation when sending a message. + +The Waku Relay protocol sends messages to connected peers but does not provide any information on whether said peers have received messages. +This can be an issue when facing potential connectivity issues. +For example, when the connection drops easily, or it is connected to a small number of relay peers. + +Waku Light Push allows a client to get a response from a remote peer when sending a message. +Note this only guarantees that the remote peer has received the message, +it cannot guarantee propagation to the network. + +It also means weaker privacy properties as the remote peer knows the client is the originator of the message. +Whereas with Waku Relay, a remote peer would not know whether the client created or forwarded the message. + +You can find Waku Light Push's specifications on [Vac RFC](https://rfc.vac.dev/spec/19/). + +`WAKU2-LIGHTPUSH` is a request/response protocol for this. + +## Additional Protocols + +This is in addition to protocols that specify messages, payloads, and recommended usages. +For example: + +- [14/WAKU2-MESSAGE](https://rfc.vac.dev/spec/14) and [26/WAKU2-PAYLOAD](https://rfc.vac.dev/spec/26) for message payloads +- [23/WAKU2-TOPICS](https://rfc.vac.dev/spec/23) and [27/WAKU2-PEERS](https://rfc.vac.dev/spec/27) for recommendations around usage + +There are also more experimental libp2p protocols such as +[`WAKU-RLN-RELAY`](https://rfc.vac.dev/spec/17/) + +You can find more information on this [here](./6.md). diff --git a/docs/Concepts/2.md b/docs/Concepts/2.md new file mode 100644 index 0000000..27f0586 --- /dev/null +++ b/docs/Concepts/2.md @@ -0,0 +1,11 @@ +--- +title: Transports in Waku +--- + +Waku v2 is built in top of libp2p, and like libp2p it strives to be transport agnostic. We define a set of recommended transports in order to achieve a baseline of interoperability between clients. + +This section describes these recommended transports: + +- Waku nodes uses TCP to communicate by default. A service node should be using TCP to connect to other nodes and listen to +- In environments where TCP is not available, such as browser, secure websocket is used. service nodes are encouraged to setup a SSL certificate to enable incoming connections from browser and serve them. +- Other protocols such as [WebRTC](https://github.com/waku-org/js-waku/issues/20), [WebTransport](https://github.com/waku-org/js-waku/issues/697) and QUIC have been studied. diff --git a/docs/Concepts/3.md b/docs/Concepts/3.md new file mode 100644 index 0000000..4731ad0 --- /dev/null +++ b/docs/Concepts/3.md @@ -0,0 +1,46 @@ +--- +title: Content Topic and How to Choose One +--- + +A content topic is used for content based filtering and allows you to filter out the messages that your dApp processes, +both when receiving live messages (Relay or Filter) or retrieving historical messages (Store). + +The recommended format for content topics is as follows: + +`/{dapp-name}/{version}/{content-topic-name}/{encoding}` + +- `dapp-name`: The name of your dApp, it must be unique to avoid conflict with other dApps. +- `version`: We usually start at `1`, useful when introducing breaking changes in your messages. +- `content-topic-name`: The actual content topic name to use for filtering. + If your dApp uses Waku for several features, + you should use a content topic per feature. +- `encoding`: The encoding format of the message, [Protobuf](https://developers.google.com/protocol-buffers) is most often used: `proto`. + +For example: Your dApp's name is SuperCrypto, +it enables users to receive notifications and send private messages. +You may want to use the following content topics: + +- `/supercrypto/1/notification/proto` +- `/supercrypto/1/private-message/proto` + +## PubSub topic + +There is another type of a _topic_ in Waku: A pubsub topic is used for routing of messages between the relaying nodes in the Waku network. + +> This section talks more about how networking and relaying of messages is handled by the nodes in the network, +> and has little to do with the application layer of Waku. +> Feel free to skip ahead this section if you are not interested in the details of how Waku works. + +The format for a pubsub topic is as follows: +`/waku/2/{topic-name}/{encoding}` and the default pubsub topic is `/waku/2/default-waku/proto`. + +This indicates to: + +1. `waku`: Waku problem domain +2. `2`: Version is 2 +3. `default-waku`: Default topic for exchanging WakuMessages +4. `proto`: The data field in PubSub is serialized/encoded as Protobuf as determined by WakuMessage + +Unless there’s a good reason, the default PubSub topic is used for all protocols. However, in certain situations other topics may be used. + +Using a single PubSub topic ensures a connected network, as well some degree of metadata protection. See [Anonymity/Unlinkability](https://rfc.vac.dev/spec/10/#anonymity--unlinkability) for more details. diff --git a/docs/Concepts/4.md b/docs/Concepts/4.md new file mode 100644 index 0000000..1fb06b3 --- /dev/null +++ b/docs/Concepts/4.md @@ -0,0 +1,60 @@ +--- +title: Security Features +--- + +Each protocol layer of Waku v2 provides a distinct service and is associated with a separate set of security features and concerns. +Therefore, the overall security of Waku v2 depends on how the different layers are utilized. + +The security models are detailed in the RFC of the protocols. +That we strive to provide well documented and open source RFCs so that Waku users know what security guarantees are and aren't provided by each protocol. + +Some of the security features of Waku v2 are: + +### Pseudonymity + +Waku v2 by default guarantees pseudonymity for all of the protocol layers since parties do not have to disclose their true identity +and instead they utilize libp2p `PeerID` as their identifiers. +While pseudonymity is an appealing security feature, it does not guarantee full anonymity since the actions taken under the same pseudonym +i.e., `PeerID` can be linked together and potentially result in the re-identification of the true actor. + +### Anonymity / Unlinkability + +At a high level, anonymity is the inability of an adversary in linking an actor to its data/performed action (the actor and action are context-dependent). +To be precise about linkability, we use the term Personally Identifiable Information (PII) to refer to any piece of data that could potentially be used to uniquely identify a party. +For example, the signature verification key, and the hash of one's static IP address are unique for each user and hence count as PII. +Notice that users' actions can be traced through their PIIs (e.g., signatures) and hence result in their re-identification risk. +As such, we seek anonymity by avoiding linkability between actions and the actors / actors' PII. Concerning anonymity, Waku v2 provides the following features: + +**Publisher-Message Unlinkability**: +This feature signifies the unlinkability of a publisher to its published messages in the `WAKU-RELAY` protocol. + +**Subscriber-Topic Unlinkability**: +This feature stands for the unlinkability of the subscriber to its subscribed topics in the `WAKU-RELAY` protocol. +The [Subscriber-Topic Unlinkability](https://rfc.vac.dev/spec/11/#security-analysis) is achieved through the utilization of a single PubSub topic. +As such, subscribers are not re-identifiable from their subscribed topic IDs as the entire network is linked to the same topic ID. +This level of unlinkability / anonymity is known as [k-anonymity](https://www.privitar.com/blog/k-anonymity-an-introduction/) where k is proportional to the system size (number of subscribers). +Note that there is no hard limit on the number of the pubsub topics, however, the use of one topic is recommended for the sake of anonymity. + +### Spam protection + +This property indicates that no adversary can flood the system (i.e., publishing a large number of messages in a short amount of time), either accidentally or deliberately, with any kind of message i.e. even if the message content is valid or useful. +Spam protection is partly provided in `WAKU2-RELAY` through the [scoring mechanism](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md#spam-protection-measures) provided for by GossipSub v1.1. +At a high level, peers utilize a scoring function to locally score the behavior of their connections and remove peers with a low score. + +There's also further research being done in this domain, including the designing of (RLN (Rate Limiting Nullifiers))[./7.md] + +### Data confidentiality, Integrity, and Authenticity + +Confidentiality can be addressed through data encryption whereas integrity and authenticity are achievable through digital signatures. +These features are provided for in [WAKU-MESSAGE (version 1)](https://rfc.vac.dev/spec/14#version-1) and [WAKU-NOISE](https://rfc.vac.dev/spec/35/) through payload encryption as well as encrypted signatures. + +> `WAKU-NOISE` enables secure channel negotiation over Waku. + +## Security Considerations + +**Lack of anonymity/unlinkability in the protocols involving direct connections including [`13/WAKU2-STORE`](https://rfc.vac.dev/spec/13/) and [`12/WAKU2-FILTER`](https://rfc.vac.dev/spec/12/) protocols**: +The anonymity/unlinkability is not guaranteed in the protocols like `13/WAKU2-STORE` and `12/WAKU2-FILTER` where peers need to have direct connections to benefit from the designated service. +This is because during the direct connections peers utilize `PeerID` to identify each other, +therefore the service obtained in the protocol is linkable to the beneficiary's `PeerID` (which counts as PII). +For `13/WAKU2-STORE`, the queried node would be able to link the querying node's `PeerID` to its queried topics. +Likewise, in the `12/WAKU2-FILTER`, a full node can link the light node's `PeerID`s to its content filter. diff --git a/docs/Concepts/5.md b/docs/Concepts/5.md new file mode 100644 index 0000000..5431749 --- /dev/null +++ b/docs/Concepts/5.md @@ -0,0 +1,19 @@ +--- +title: Research in Progress +--- + +The following features are currently experimental and under research and initial implementation: + +**Economic Spam resistance**: +We aim to enable an incentivized spam protection technique to enhance `WAKU-RELAY` by using rate limiting nullifiers. +More details on this can be found in [17/WAKU2-RLN-RELAY](https://rfc.vac.dev/spec/17). +In this advanced method, peers are limited to a certain rate of messaging per epoch and an immediate financial penalty is enforced for spammers who break this rate. + +**Prevention of Denial of Service (DoS) and Node Incentivization**: +Denial of service signifies the case where an adversarial node 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. +DoS attack is to be mitigated through the accounting model as described in [18/WAKU2-SWAP](https://rfc.vac.dev/spec/18). +In a nutshell, peers have to pay for the service they obtain from each other. +In addition to incentivizing the service provider, accounting also makes DoS attacks costly for malicious peers. +The accounting model can be used in `13/WAKU2-STORE` and `12/WAKU2-FILTER` to protect against DoS attacks. + +Additionally, this gives node operators who provide a useful service to the network an incentive to perform that service. diff --git a/docs/Concepts/6.md b/docs/Concepts/6.md new file mode 100644 index 0000000..3c4c92a --- /dev/null +++ b/docs/Concepts/6.md @@ -0,0 +1,22 @@ +--- +title: Waku vs libp2p - what's the difference? +--- + +Since Waku v2 is built on top of libp2p, they share a lot of concepts and terminologies between them. However, there are key differences between them that are worth noting. + +### Waku as a service network + +Waku offers incentivization mechanisms to run nodes, whereas libp2p does not. + +Additionally, a user or a developer does not have to deploy own infra as a prerequisite to use Waku, it is a service network. +However, it is encouraged to [run your own node](https://github.com/status-im/nwaku/tree/master/docs/operators) to support and decentralize the network. + +### Waku as a keyturn solution + +Waku includes a number of protocol covering the following domains like privacy preservation, censorship resistance, portability/runs anywhere. + +libp2p does not provide out of the box protocols to enable mostly offline/resource restricted devices, [WAKU-STORE](https://rfc.vac.dev/spec/13/)/[WAKU-LIGHTPUSH](https://rfc.vac.dev/spec/19/)/[WAKU-FILTER](https://rfc.vac.dev/spec/12/) caters to those use cases. + +### Economic spam protection + +libp2p does not have strong spam protection guarantees, [RLN (Rate Limit Nullifier)](https://rfc.vac.dev/spec/32/) is a protocol being developed by the Waku team towards this goal. diff --git a/docs/Concepts/overview.png b/docs/Concepts/overview.png new file mode 100644 index 0000000..bcf3747 Binary files /dev/null and b/docs/Concepts/overview.png differ diff --git a/docs/choose-content-topic.md b/docs/choose-content-topic.md deleted file mode 100644 index cfc744d..0000000 --- a/docs/choose-content-topic.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: How to Choose a Content Topic ---- - -# How to Choose a Content Topic - -A content topic is used for content based filtering. - -It allows you to filter out the messages that your dApp processes, -both when receiving live messages (Relay) or retrieving historical messages (Store). - -The format for content topics is as follows: - -`/{dapp-name}/{version}/{content-topic-name}/{encoding}` - -- `dapp-name`: The name of your dApp, it must be unique to avoid conflict with other dApps. -- `version`: We usually start at `1`, useful when introducing breaking changes in your messages. -- `content-topic-name`: The actual content topic name to use for filtering. - If your dApp uses Waku Connect for several features, - you should use a content topic per feature. -- `encoding`: The encoding format of the message, Protobuf is most often used: `proto`. - -For example: Your dApp's name is SuperCrypto, -it enables users to receive notifications and send private messages. -You may want to use the following content topics: - -- `/supercrypto/1/notification/proto` -- `/supercrypto/1/private-message/proto` - -You can learn more about Waku topics in the [23/WAKU2-TOPICS](https://rfc.vac.dev/spec/23/) specs. diff --git a/docs/index.md b/docs/index.md deleted file mode 100644 index e1f46cc..0000000 --- a/docs/index.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: Waku Guide ---- - -# Waku Guide - -Waku is a decentralized, censorship-resistant, network and protocol family. -It enables you to add communication features to your dApp in a decentralized manner, -ensuring to your users that they will not be censored or de-platformed. - -Waku can be used for chat (human-to-human) purposes and for many machine-to-machine use cases. - -Here you can find general, high level explanation of Waku concepts. - -If you want to learn how Waku works under the hoods, check out the [10/WAKU2](https://rfc.vac.dev/spec/10/) RFC. - -## Implementation Documentation - -We are currently in the process of migrating our documentation 🏗️. -For now, please go to the following location to learn more about the different Waku implementations: - -- [nwaku](https://github.com/status-im/nwaku) -- [js-waku](https://docs.wakuconnect.dev/) -- [go-waku](https://github.com/status-im/go-waku) - -## Bugs, Questions & Support - -To get help, join [Vac Discord](https://discord.gg/j5pGbn7MHZ) -or the [Waku Telegram Group](https://t.me/waku_org). diff --git a/docs/protocols/index.md b/docs/protocols/index.md deleted file mode 100644 index cfeaea9..0000000 --- a/docs/protocols/index.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: Protocols ---- - - - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - - - - -```shell -npm isntall js-waku -``` - - - - -```shell -yarn isntall js-waku -``` - - - - -```shell -pnpm isntall js-waku -``` - - - diff --git a/docs/sign_messages_version_1.md b/docs/sign_messages_version_1.md deleted file mode 100644 index ad88940..0000000 --- a/docs/sign_messages_version_1.md +++ /dev/null @@ -1,98 +0,0 @@ ---- -summary: Demonstrate how to sign messages using Waku -authors: -- Fryorcraken -date: 2022-08-15 ---- - -# Sign Messages Using Waku Message Version 1 - -The Waku Message format provides an easy way to sign messages using elliptic curve cryptography. - -It also allows the sender to encrypt messages, -see [Encrypt Messages Using Waku Message Version 1](/) to learn how. - -You can find more details about Waku Message Payload Signature in [26/WAKU-PAYLOAD](https://rfc.vac.dev/spec/26/). - -See [Cryptographic Libraries](/) for more details on the cryptographic libraries used by js-waku. - -## Create new keypair - -Generate a new keypair to sign your messages: - -```ts -import { generatePrivateKey, getPublicKey } from "js-waku"; - -const privateKey = generatePrivateKey(); -const publicKey = getPublicKey(privateKey); -``` - -## Sign Waku Messages - -As per version 1's [specs](https://rfc.vac.dev/spec/26/), signatures are only included in encrypted messages. -In the case where your app does not need encryption then you could use symmetric encryption with a trivial key. - -You can learn more about encryption at [Encrypt Messages Using Waku Message Version 1](/). - -### Using symmetric encryption - -Given `symKey` the symmetric key used for encryption: - -```ts -import { WakuMessage } from "js-waku"; - -const message = await WakuMessage.fromBytes(payload, myAppContentTopic, { - encPublicKey: symKey, - sigPrivKey: privateKey, -}); -``` - -If encryption is not needed for your use case, -then you can create a symmetric key from the content topic: - -```ts -import { hexToBuf } from "js-waku/lib/utils"; -import { keccak256 } from "ethers/lib/utils"; - -const symKey = hexToBuf(keccak256(Buffer.from(myAppContentTopic, "utf-8"))); -``` - -`symKey` can then be used to encrypt and decrypt messages on `myAppContentTopic` content topic. -Read [How to Choose a Content Topic](/) to learn more about content topics. - -### Using asymmetric encryption - -Given `recipientPublicKey` the public key of the message's recipient: - -```ts -import { WakuMessage } from "js-waku"; - -const message = await WakuMessage.fromBytes(payload, myAppContentTopic, { - encPublicKey: recipientPublicKey, - sigPrivKey: privateKey, -}); -``` - -## Verify Waku Message signatures - -Two fields are available on signed `WakuMessage`s: - -- `signaturePublicKey`: Holds the public key of the signer, -- `signature`: Holds the actual signature. - -Thus, if you expect messages to be signed by Alice, -you can simply compare `WakuMessage.signaturePublicKey` with Alice's public key. -As comparing hex string can lead to issues (is the `0x` prefix present?), -simply use helper function `equalByteArrays`. - -```ts -import { equalByteArrays } from "js-waku/lib/utils"; - -const sigPubKey = wakuMessage.signaturePublicKey; - -const isSignedByAlice = sigPubKey && equalByteArrays(sigPubKey, alicePublicKey); - -if (!isSignedByAlice) { - // Message is not signed by Alice -} -``` diff --git a/docs/use cases/case-study-1.md b/docs/use cases/case-study-1.md deleted file mode 100644 index 8437fbf..0000000 --- a/docs/use cases/case-study-1.md +++ /dev/null @@ -1,3 +0,0 @@ ---- -title: Case study 1 ---- \ No newline at end of file diff --git a/docs/use cases/case-study-2.md b/docs/use cases/case-study-2.md deleted file mode 100644 index a59e53f..0000000 --- a/docs/use cases/case-study-2.md +++ /dev/null @@ -1,3 +0,0 @@ ---- -title: Case study 2 ---- \ No newline at end of file diff --git a/docs/use cases/index.md b/docs/use cases/index.md deleted file mode 100644 index 0d3d164..0000000 --- a/docs/use cases/index.md +++ /dev/null @@ -1,3 +0,0 @@ ---- -title: Use cases ---- \ No newline at end of file diff --git a/docusaurus.config.js b/docusaurus.config.js index 4bf4101..27f069b 100644 --- a/docusaurus.config.js +++ b/docusaurus.config.js @@ -1,105 +1,106 @@ // @ts-check // Note: type annotations allow type checking and IDEs autocompletion -const lightCodeTheme = require('prism-react-renderer/themes/github'); -const darkCodeTheme = require('prism-react-renderer/themes/dracula'); +const lightCodeTheme = require("prism-react-renderer/themes/github"); +const darkCodeTheme = require("prism-react-renderer/themes/dracula"); /** @type {import('@docusaurus/types').Config} */ const config = { title: "Waku guides", - tagline: 'Waku is the communication layer for Web3.', - url: 'https://waku.guides', - baseUrl: '/', - onBrokenLinks: 'throw', - onBrokenMarkdownLinks: 'warn', - favicon: 'img/favicon.ico', + tagline: "Waku is the communication layer for Web3.", + url: "https://waku.guides", + baseUrl: "/", + onBrokenLinks: "throw", + onBrokenMarkdownLinks: "warn", + favicon: "img/favicon.ico", // GitHub pages deployment config. // If you aren't using GitHub pages, you don't need these. - organizationName: 'waku-org', // Usually your GitHub org/user name. - projectName: 'waku.guide', // Usually your repo name. + organizationName: "waku-org", // Usually your GitHub org/user name. + projectName: "waku.guide", // Usually your repo name. // Even if you don't use internalization, you can use this field to set useful // metadata like html lang. For example, if your site is Chinese, you may want // to replace "en" with "zh-Hans". i18n: { - defaultLocale: 'en', - locales: ['en'], + defaultLocale: "en", + locales: ["en"], }, presets: [ [ - 'classic', + "classic", /** @type {import('@docusaurus/preset-classic').Options} */ ({ docs: { - sidebarPath: require.resolve('./sidebars.js'), + sidebarPath: require.resolve("./sidebars.js"), // Please change this to your repo. // Remove this to remove the "edit this page" links. editUrl: - 'https://github.com/facebook/docusaurus/tree/main/packages/create-docusaurus/templates/shared/', + "https://github.com/facebook/docusaurus/tree/main/packages/create-docusaurus/templates/shared/", }, theme: { - customCss: require.resolve('./src/css/custom.css'), + customCss: require.resolve("./src/css/custom.css"), }, }), ], ], - themeConfig: - ({ - colorMode: { - defaultMode: 'dark', - disableSwitch: false, - respectPrefersColorScheme: true + themeConfig: { + colorMode: { + defaultMode: "dark", + disableSwitch: false, + respectPrefersColorScheme: true, + }, + navbar: { + title: "Waku", + logo: { + alt: "Waku Logo", + src: "img/logo.svg", }, - navbar: { - title: 'Waku', - logo: { - alt: 'My Site Logo', - src: 'img/logo.svg', + + items: [ + { + type: "doc", + docId: "About/1", + position: "left", + label: "About", }, - items: [ - { - type: 'doc', - docId: 'index', - position: 'left', - label: 'Guides', - }, - { - href: 'https://github.com/facebook/docusaurus', - label: 'GitHub', - position: 'right', - }, - ], - }, - footer: { - style: 'dark', - links: [ - { - title: 'Community', - items: [ - { - label: 'Stack Overflow', - href: 'https://stackoverflow.com/questions/tagged/docusaurus', - }, - { - label: 'Discord', - href: 'https://discordapp.com/invite/docusaurus', - }, - { - label: 'Twitter', - href: 'https://twitter.com/docusaurus', - }, - ], - } - ], - copyright: `Copyright © ${new Date().getFullYear()} My Project, Inc. Built with Docusaurus.`, - }, - prism: { - theme: lightCodeTheme, - darkTheme: darkCodeTheme, - }, - }), + { + type: "doc", + docId: "Concepts/1", + position: "left", + label: "Concepts", + }, + ], + }, + footer: { + style: "dark", + links: [ + { + title: "Community", + items: [ + { + label: "Stack Overflow", + href: "https://stackoverflow.com/questions/tagged/docusaurus", + }, + { + label: "Discord", + href: "https://discordapp.com/invite/docusaurus", + }, + { + label: "Twitter", + href: "https://twitter.com/docusaurus", + }, + ], + }, + ], + copyright: `Copyright © ${new Date().getFullYear()} Status Gmbh. Built with Docusaurus.`, + }, + prism: { + theme: lightCodeTheme, + darkTheme: darkCodeTheme, + }, + }, }; module.exports = config;