address comments and clean up
This commit is contained in:
danisharora099
parent
3570c2ff64
commit
726a397f04
|
|
@ -1,60 +1,48 @@
|
|||
---
|
||||
title: Security Features
|
||||
title: Content topic and how to choose one
|
||||
---
|
||||
|
||||
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.
|
||||
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 retrieving historical messages (Store).
|
||||
|
||||
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.
|
||||
The format for content topics is as follows:
|
||||
|
||||
Some of the security features of Waku v2 are:
|
||||
`/{dapp-name}/{version}/{content-topic-name}/{encoding}`
|
||||
|
||||
### Pseudonymity
|
||||
- `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`.
|
||||
|
||||
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.
|
||||
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:
|
||||
|
||||
### Anonymity / Unlinkability
|
||||
- `/supercrypto/1/notification/proto`
|
||||
- `/supercrypto/1/private-message/proto`
|
||||
|
||||
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:
|
||||
Please refer to [this example](../../Concepts/4.md) to learn more about how to use content topics.
|
||||
|
||||
**Publisher-Message Unlinkability**:
|
||||
This feature signifies the unlinkability of a publisher to its published messages in the `WAKU-RELAY` protocol.
|
||||
## PubSub topic
|
||||
|
||||
**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.
|
||||
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.
|
||||
|
||||
### Spam protection
|
||||
> 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.
|
||||
|
||||
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.
|
||||
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`.
|
||||
|
||||
There's also further research being done in this domain, including the designing of (RLN (Rate Limiting Nullifiers))[./7.md]
|
||||
This indicates to:
|
||||
|
||||
### Data confidentiality, Integrity, and Authenticity
|
||||
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
|
||||
|
||||
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.
|
||||
Unless there’s a good reason, the default PubSub topic is used for all protocols. However, in certain situations other topics may be used.
|
||||
|
||||
> `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.
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -1,19 +1,60 @@
|
|||
---
|
||||
title: Experimental work in progress
|
||||
title: Security Features
|
||||
---
|
||||
|
||||
The following features are currently experimental and under research and initial implementation:
|
||||
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.
|
||||
|
||||
**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.
|
||||
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.
|
||||
|
||||
**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.
|
||||
Some of the security features of Waku v2 are:
|
||||
|
||||
Additionally, this gives node operators who provide a useful service to the network an incentive to perform that service.
|
||||
### 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.
|
||||
|
|
|
|||
|
|
@ -1,22 +1,19 @@
|
|||
---
|
||||
title: Waku vs libp2p - what's the difference?
|
||||
title: Experimental work in progress
|
||||
---
|
||||
|
||||
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.
|
||||
The following features are currently experimental and under research and initial implementation:
|
||||
|
||||
### Waku as a service network
|
||||
**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.
|
||||
|
||||
Waku offers incentivization mechanisms to run nodes, whereas libp2p does not.
|
||||
**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, 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.
|
||||
Additionally, this gives node operators who provide a useful service to the network an incentive to perform that service.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -1,48 +0,0 @@
|
|||
---
|
||||
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 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 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`
|
||||
|
||||
Please refer to [this example](../../Concepts/4.md) to learn more about how to use content topics.
|
||||
|
||||
## 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.
|
||||
|
|
@ -1,148 +0,0 @@
|
|||
---
|
||||
title: Discovery & Bootstrap Nodes
|
||||
---
|
||||
|
||||
This guide explains the discovery and bootstrap mechanisms currently available in js-waku,
|
||||
their benefits and caveats and how to use them.
|
||||
|
||||
Node discovery is the mechanism that enables a Waku node to find other nodes.
|
||||
Waku is a modular protocol; several discovery mechanisms are and will be included in Waku
|
||||
so that developers can select the best mechanism(s) based for their use case and the user's environment
|
||||
(e.g. mobile phone, desktop browser, server, etc).
|
||||
|
||||
When starting a Waku node,
|
||||
it needs to connect to other nodes to be able to send, receive and retrieve messages.
|
||||
Which means there needs to be a discovery mechanism that enable finding other nodes when not connected to any node.
|
||||
This is called _bootstrapping_.
|
||||
|
||||
Once connected, the node needs to find additional peers to have:
|
||||
|
||||
- Enough peers in the Waku Relay mesh (target is 6),
|
||||
- Enough peers in reserve, in case current peers are overloaded or go offline,
|
||||
- Peers with specific Waku capabilities (e.g. Store, Light Push, Filter).
|
||||
|
||||
For now, we are focusing in making bootstrap discovery protocols available,
|
||||
research of other discovery protocols is in progress.
|
||||
|
||||
## Default Bootstrap Mechanism
|
||||
|
||||
**The default bootstrap mechanism is to connect to the Status' nim-waku prod fleet**.
|
||||
|
||||
To use:
|
||||
|
||||
```ts
|
||||
const waku = await createNode({ bootstrap: { default: true } });
|
||||
```
|
||||
|
||||
{{< hint info >}}
|
||||
When creating a Waku node without passing the `bootstrap` option,
|
||||
the node does **not** connect to any remote peer or bootstrap node.
|
||||
|
||||
As the current strategy is to connect to nodes operated by Status,
|
||||
we want to ensure that developers consciously opt-in
|
||||
while providing a friendly developer experience.
|
||||
|
||||
We intend to change this in the future and enable bootstrap by default
|
||||
once we have implemented more decentralized strategies.
|
||||
{{< /hint >}}
|
||||
|
||||
## Predefined Bootstrap Nodes
|
||||
|
||||
Addresses of nodes hosted by Status are predefined in the codebase:
|
||||
|
||||
https://github.com/status-im/js-waku/blob/e4024d5c7246535ddab28a4262006915d2db58be/src/lib/discovery/predefined.ts#L48
|
||||
|
||||
**Pros:**
|
||||
|
||||
- Low latency,
|
||||
- Low resource requirements.
|
||||
|
||||
**Cons:**
|
||||
|
||||
- Prone to censorship: node ips can be blocked,
|
||||
- Limited: Static number of nodes,
|
||||
- Poor maintainability: Code needs to be changed to update the list.
|
||||
|
||||
## Use your own nodes
|
||||
|
||||
Developers have the choice to run their own [nwaku](https://github.com/status-im/nim-waku/) nodes
|
||||
and use them to bootstrap js-waku nodes.
|
||||
|
||||
There are two ways to set bootstrap nodes:
|
||||
|
||||
1. Using an array of multiaddrs (as `string` or `Multiaddr`):
|
||||
|
||||
```ts
|
||||
import { Waku } from "js-waku";
|
||||
|
||||
const waku = await createNode({
|
||||
bootstrap: {
|
||||
peers: [
|
||||
"/dns4/node-01.ac-cn-hongkong-c.wakuv2.test.statusim.net/tcp/443/wss/p2p/16Uiu2HAkvWiyFsgRhuJEb9JfjYxEkoHLgnUQmr1N5mKWnYjxYRVm",
|
||||
],
|
||||
},
|
||||
});
|
||||
```
|
||||
|
||||
2. Passing an async function that returns an array of multiaddr (as `string` or `Multiaddr`):
|
||||
|
||||
```ts
|
||||
import { Waku } from "js-waku";
|
||||
|
||||
const waku = await createNode({
|
||||
bootstrap: {
|
||||
getPeers: async () => {
|
||||
const addresses = [];
|
||||
// Fetch the multiaddrs from somewhere...
|
||||
return addresses;
|
||||
},
|
||||
},
|
||||
});
|
||||
```
|
||||
|
||||
{{< hint info >}}
|
||||
Read [Nwaku Service Node](https://github.com/status-im/nwaku/tree/master/docs/operators) to learn how to run your own node.
|
||||
{{< /hint >}}
|
||||
|
||||
**Pros & Cons**: Same than [Predefined Bootstrap Nodes](#predefined-bootstrap-nodes)
|
||||
|
||||
## DNS Discovery
|
||||
|
||||
[EIP-1459: Node Discovery via DNS](https://eips.ethereum.org/EIPS/eip-1459) has been implemented in js-waku, nwaku and go-waku
|
||||
with some modification on the [ENR format](https://rfc.vac.dev/spec/31/).
|
||||
|
||||
DNS Discovery enables anyone to register an ENR tree in the `TXT` field of a domain name.
|
||||
|
||||
_ENR_ is the format used to store node connection details (ip, port, multiaddr, etc).
|
||||
|
||||
This enables a separation of software development and operations
|
||||
as dApp developers can include one or several domain names to use for DNS discovery,
|
||||
while operators can handle the update of the dns record.
|
||||
|
||||
It also enables more decentralized bootstrapping as anyone can register a domain name and publish it for others to use.
|
||||
|
||||
{{< hint warning >}}
|
||||
While this method is implemented in js-waku,
|
||||
it is currently not recommended to use due to a [bug](https://github.com/status-im/nim-waku/issues/845) in the websocket implementation of nwaku.
|
||||
{{< /hint >}}
|
||||
|
||||
**Pros:**
|
||||
|
||||
- Low latency, low resource requirements,
|
||||
- Bootstrap list can be updated by editing a domain name: no code change is needed,
|
||||
- Can reference to a greater list of nodes by pointing to other domain names in the code or in the ENR tree.
|
||||
|
||||
**Cons:**
|
||||
|
||||
- Prone to censorship: domain names can be blocked,
|
||||
- Limited: Static number of nodes, operators must provide their ENR to the domain owner to get their node listed.
|
||||
|
||||
## Other Discovery Mechanisms
|
||||
|
||||
Other discovery mechanisms such as gossipsub peer exchange, discv5, etc are currently being research and developed.
|
||||
|
||||
They aim to improve the current _status quo_ in the following aspects:
|
||||
|
||||
- More decentralized mechanisms: Less reliance on specific entities,
|
||||
- Less setup for node operators: Enabling their nodes to be discovered by connecting to bootstrap nodes,
|
||||
without having to update a domain name.
|
||||
139
docs/Guide/1.md
139
docs/Guide/1.md
|
|
@ -1,139 +0,0 @@
|
|||
---
|
||||
title: Group chat with Waku Relay
|
||||
---
|
||||
|
||||
Waku Relay is a gossip protocol that enables you to send and receive messages. You can find more info on Waku Relay [here](../Concepts/3.md).
|
||||
|
||||
Before starting, you need to choose a Content Topic for your dApp. Check out the [How to choose a content topic](../Concepts/2.md) guide to learn more about content topics.
|
||||
|
||||
For this guide, we are using a single content topic: `/relay-guide/1/chat/proto`.
|
||||
|
||||
## 0. Setup a boilerplate app
|
||||
|
||||
> This document assumes previous knowledge and experience of working with JavaScript web applications.
|
||||
|
||||
To set up a boilerplate React app using CRA, please refer to: [https://reactjs.org/docs/create-a-new-react-app.html](https://reactjs.org/docs/create-a-new-react-app.html)
|
||||
|
||||
You can also use vanilla JavaScript, Vue, or any other framework of your choice.
|
||||
|
||||
Please refer to [references](#references) to check our reference applications built with Waku Relay for React and vanilla JavaScript.
|
||||
|
||||
## 1. Install dependencies
|
||||
|
||||
First, you need to install the dependencies for the project. You can use `npm` or `yarn` for this.
|
||||
|
||||
```bash
|
||||
npm install js-waku protobufjs
|
||||
```
|
||||
|
||||
> If you're not using a package manager, you can use minified bundle of waku-js from unpkg.com directly
|
||||
> Please refer to [references](#references) for more info.
|
||||
|
||||
## 2. Importing packages and initializing variables
|
||||
|
||||
In this step, you will import the packages you need and initialize the variables.
|
||||
|
||||
#### Importing the protobuf library.
|
||||
|
||||
Waku v2 protocols use protobuf by default to encode and decode messages.
|
||||
The usage of how to use protobuf for the scope of this guide will explained in the coming sections.
|
||||
|
||||
```javascript
|
||||
import protobuf from "protobufjs";
|
||||
```
|
||||
|
||||
#### Importing the methods required from the js-waku package
|
||||
|
||||
```javascript
|
||||
import { createPrivacyNode } from "js-waku/lib/create_waku";
|
||||
import { waitForRemotePeer } from "js-waku/lib/wait_for_remote_peer";
|
||||
import { DecoderV0, EncoderV0 } from "js-waku/lib/waku_message/version_0";
|
||||
```
|
||||
|
||||
#### Initializing the content topic
|
||||
|
||||
```javascript
|
||||
const ContentTopic = `/js-waku-examples/1/chat/proto`;
|
||||
const Encoder = new EncoderV0(ContentTopic);
|
||||
const Decoder = new DecoderV0(ContentTopic);
|
||||
```
|
||||
|
||||
#### Initialize the protobuf schema
|
||||
|
||||
```javascript
|
||||
const SimpleChatMessage = new protobuf.Type("SimpleChatMessage")
|
||||
.add(new protobuf.Field("timestamp", 1, "uint32"))
|
||||
.add(new protobuf.Field("text", 2, "string"));
|
||||
```
|
||||
|
||||
## 3. Creating a Waku node
|
||||
|
||||
In this step, you will create a Waku node and connect to the WakuRelay protocol.
|
||||
|
||||
```javascript
|
||||
const waku = await createPrivacyNode({ defaultBootstrap: true });
|
||||
await waku.start();
|
||||
await waitForRemotePeer(waku, ["relay"]);
|
||||
```
|
||||
|
||||
## 4. Subscribing to messages
|
||||
|
||||
In this step, you will subscribe to messages on the content topic you chose.
|
||||
|
||||
#### Create a callback function to handle incoming messages
|
||||
|
||||
```javascript
|
||||
const processIncomingMessages = (wakuMessage) => {
|
||||
const { text, timestamp } = SimpleChatMessage.decode(wakuMessage.payload);
|
||||
|
||||
const message = { text, timestamp: new Date().setTime(timestamp) };
|
||||
};
|
||||
```
|
||||
|
||||
#### Subscribe to messages
|
||||
|
||||
```javascript
|
||||
waku.relay.subscribe(Decoder, processIncomingMessages);
|
||||
```
|
||||
|
||||
## 5. Publishing messages
|
||||
|
||||
In this step, you will publish messages to the content topic you chose.
|
||||
|
||||
#### Create a function to publish messages
|
||||
|
||||
```javascript
|
||||
function sendMessage(message, waku, timestamp) {
|
||||
const time = timestamp.getTime();
|
||||
|
||||
// Encode to protobuf
|
||||
const protoMsg = SimpleChatMessage.create({
|
||||
timestamp: time,
|
||||
text: message,
|
||||
});
|
||||
const payload = SimpleChatMessage.encode(protoMsg).finish();
|
||||
|
||||
// Send over Waku Relay
|
||||
return waku.relay.send(Encoder, { payload });
|
||||
}
|
||||
```
|
||||
|
||||
#### Publish messages
|
||||
|
||||
```javascript
|
||||
sendMessage(`Here is message #${sendCounter}`, waku, new Date()).then(() =>
|
||||
console.log("Message sent")
|
||||
);
|
||||
```
|
||||
|
||||
## 6. Run your app
|
||||
|
||||
You can wrap these functions in a React component or any other framework of your choice,
|
||||
and run your app to see the messages being sent and received.
|
||||
|
||||
We have created reference applications that can be used as a reference for your application.
|
||||
|
||||
## References
|
||||
|
||||
- [Implementation of Waku v2 in ReactJS](https://github.com/waku-org/js-waku-examples/tree/master/relay-reactjs-chat)
|
||||
- [Implementation of Waku v2 in vanilla JavaScript](https://github.com/waku-org/js-waku-examples/tree/master/relay-js)
|
||||
|
|
@ -1,5 +0,0 @@
|
|||
---
|
||||
title: TESTTT
|
||||
---
|
||||
|
||||
Home page for waku guide
|
||||
Loading…
Reference in New Issue