Squashed commit of the following:
commit dd5a32197457cdcb0c09f838cb05c5b5a3109b81
Author: fryorcraken.eth <git@fryorcraken.xyz>
Date: Tue Nov 8 10:28:31 2022 +1100
Remove unneeded sentence
commit af1a5415cd21b6a9d424ebe267a83944fbb84ff4
Author: fryorcraken.eth <git@fryorcraken.xyz>
Date: Tue Nov 8 10:26:05 2022 +1100
Fix typo
commit a51d98c64925c0d87695c8f49cbdb39d1461f13d
Author: fryorcraken.eth <git@fryorcraken.xyz>
Date: Tue Nov 8 10:23:26 2022 +1100
Fix spelling/terminology
commit 9bab3692854f510c429582c17ae41b6d5d753e44
Author: danisharora099 <danisharora099@gmail.com>
Date: Tue Nov 8 00:45:58 2022 +0530
fix: build
commit 3cb05f0115
Author: danisharora099 <danisharora099@gmail.com>
Date: Mon Nov 7 19:39:54 2022 +0530
resolve conflict
commit 7f2fa8969c
Merge: 726a397 d1c93ec
Author: danisharora099 <danisharora099@gmail.com>
Date: Mon Nov 7 19:39:47 2022 +0530
Merge remote-tracking branch 'refs/remotes/origin/danisharora/update-docs' into danisharora/update-docs
commit 726a397f04
Author: danisharora099 <danisharora099@gmail.com>
Date: Mon Nov 7 19:37:07 2022 +0530
address comments and clean up
commit d1c93ec03e
Author: Danish Arora <35004822+danisharora099@users.noreply.github.com>
Date: Mon Nov 7 19:34:35 2022 +0530
Update docs/Guide/01-Prerequisites/1.md
Co-authored-by: fryorcraken.eth <110212804+fryorcraken@users.noreply.github.com>
commit 7e86d1a08b
Author: Danish Arora <35004822+danisharora099@users.noreply.github.com>
Date: Mon Nov 7 19:34:25 2022 +0530
Update docs/Guide/01-Prerequisites/1.md
Co-authored-by: fryorcraken.eth <110212804+fryorcraken@users.noreply.github.com>
commit d94bd4a00c
Author: Danish Arora <35004822+danisharora099@users.noreply.github.com>
Date: Mon Nov 7 19:34:09 2022 +0530
Update docs/Guide/01-Prerequisites/1.md
Co-authored-by: fryorcraken.eth <110212804+fryorcraken@users.noreply.github.com>
commit 19d727518f
Author: Danish Arora <35004822+danisharora099@users.noreply.github.com>
Date: Mon Nov 7 19:33:58 2022 +0530
Update docs/Concepts/7.md
Co-authored-by: fryorcraken.eth <110212804+fryorcraken@users.noreply.github.com>
commit 3570c2ff64
Author: danisharora099 <danisharora099@gmail.com>
Date: Mon Nov 7 19:32:04 2022 +0530
rm: section
commit 576b5c1c2c
Author: danisharora099 <danisharora099@gmail.com>
Date: Mon Nov 7 19:31:06 2022 +0530
rm: protocol identifiers
commit 5a0ea01bdb
Author: Danish Arora <35004822+danisharora099@users.noreply.github.com>
Date: Mon Nov 7 19:26:03 2022 +0530
Update docs/Concepts/1.md
Co-authored-by: fryorcraken.eth <110212804+fryorcraken@users.noreply.github.com>
commit b60b0abaeb
Author: Danish Arora <35004822+danisharora099@users.noreply.github.com>
Date: Mon Nov 7 19:25:39 2022 +0530
Update docs/About/7.md
Co-authored-by: fryorcraken.eth <110212804+fryorcraken@users.noreply.github.com>
commit c280e4d6df
Author: Danish Arora <35004822+danisharora099@users.noreply.github.com>
Date: Mon Nov 7 19:25:24 2022 +0530
Update docs/About/6.md
Co-authored-by: fryorcraken.eth <110212804+fryorcraken@users.noreply.github.com>
commit ded38b4d79
Author: Danish Arora <35004822+danisharora099@users.noreply.github.com>
Date: Mon Nov 7 19:21:57 2022 +0530
Update docs/About/4.md
Co-authored-by: fryorcraken.eth <110212804+fryorcraken@users.noreply.github.com>
commit 85f6161aee
Author: Danish Arora <35004822+danisharora099@users.noreply.github.com>
Date: Mon Nov 7 19:21:46 2022 +0530
Update docs/About/4.md
Co-authored-by: fryorcraken.eth <110212804+fryorcraken@users.noreply.github.com>
commit 72c0cb9d28
Author: Danish Arora <35004822+danisharora099@users.noreply.github.com>
Date: Mon Nov 7 19:20:31 2022 +0530
Update docs/About/3.md
Co-authored-by: fryorcraken.eth <110212804+fryorcraken@users.noreply.github.com>
commit 6e4a067fe5
Author: danisharora099 <danisharora099@gmail.com>
Date: Mon Nov 7 19:20:20 2022 +0530
fix: gitignore
commit b2871014aa
Author: Danish Arora <35004822+danisharora099@users.noreply.github.com>
Date: Mon Nov 7 19:16:45 2022 +0530
Update docs/About/7.md
Co-authored-by: fryorcraken.eth <110212804+fryorcraken@users.noreply.github.com>
commit 66b7add730
Author: danisharora099 <danisharora099@gmail.com>
Date: Fri Nov 4 21:31:04 2022 +0530
fix: build
commit 11f17a726f
Author: danisharora099 <danisharora099@gmail.com>
Date: Fri Nov 4 21:18:43 2022 +0530
minor fixes
commit d4741551a0
Author: danisharora099 <danisharora099@gmail.com>
Date: Fri Nov 4 20:58:42 2022 +0530
add: guide: waku-relay
commit f67d3b26d6
Author: danisharora099 <danisharora099@gmail.com>
Date: Fri Nov 4 20:08:33 2022 +0530
address comments
commit 7eec7bcc72
Author: danisharora099 <danisharora099@gmail.com>
Date: Fri Nov 4 17:24:42 2022 +0530
add: content topic guide
commit bc958ddb18
Author: danisharora099 <danisharora099@gmail.com>
Date: Thu Nov 3 15:59:47 2022 +0530
address comments
commit 0adcdceaca
Author: danisharora099 <danisharora099@gmail.com>
Date: Thu Nov 3 12:42:49 2022 +0530
improve why waku
commit cba05cc434
Author: danisharora099 <danisharora099@gmail.com>
Date: Thu Nov 3 12:11:50 2022 +0530
rename concepts
commit a403a2dc6b
Author: danisharora099 <danisharora099@gmail.com>
Date: Thu Nov 3 12:05:43 2022 +0530
update gitignore
commit 57d7a79daf
Author: danisharora099 <danisharora099@gmail.com>
Date: Thu Nov 3 12:05:01 2022 +0530
add cspell.json
commit 05cbe6c9f5
Author: danisharora099 <danisharora099@gmail.com>
Date: Thu Nov 3 12:04:52 2022 +0530
address comments
commit b9afeeed90
Author: Danish Arora <35004822+danisharora099@users.noreply.github.com>
Date: Thu Nov 3 11:34:41 2022 +0530
Update docs/Development Concepts/3.md
Co-authored-by: fryorcraken.eth <110212804+fryorcraken@users.noreply.github.com>
commit 4404348570
Author: Danish Arora <35004822+danisharora099@users.noreply.github.com>
Date: Thu Nov 3 11:32:38 2022 +0530
Update docs/Development Concepts/2.md
Co-authored-by: fryorcraken.eth <110212804+fryorcraken@users.noreply.github.com>
commit 9d152946c7
Author: Danish Arora <35004822+danisharora099@users.noreply.github.com>
Date: Thu Nov 3 11:32:28 2022 +0530
Update docs/Development Concepts/2.md
Co-authored-by: fryorcraken.eth <110212804+fryorcraken@users.noreply.github.com>
commit cb74f57e96
Author: Danish Arora <35004822+danisharora099@users.noreply.github.com>
Date: Thu Nov 3 11:32:15 2022 +0530
Update docs/Development Concepts/2.md
Co-authored-by: fryorcraken.eth <110212804+fryorcraken@users.noreply.github.com>
commit a8b7dcaf9f
Author: Danish Arora <35004822+danisharora099@users.noreply.github.com>
Date: Thu Nov 3 11:32:02 2022 +0530
Update docs/Development Concepts/2.md
Co-authored-by: fryorcraken.eth <110212804+fryorcraken@users.noreply.github.com>
commit ec6a8f2399
Author: Danish Arora <35004822+danisharora099@users.noreply.github.com>
Date: Thu Nov 3 11:28:49 2022 +0530
Update docs/About/7.md
Co-authored-by: fryorcraken.eth <110212804+fryorcraken@users.noreply.github.com>
commit ed3f35959c
Author: Danish Arora <35004822+danisharora099@users.noreply.github.com>
Date: Thu Nov 3 11:28:42 2022 +0530
Update docs/About/7.md
Co-authored-by: fryorcraken.eth <110212804+fryorcraken@users.noreply.github.com>
commit 78ae346c05
Author: Danish Arora <35004822+danisharora099@users.noreply.github.com>
Date: Thu Nov 3 11:28:35 2022 +0530
Update docs/About/6.md
Co-authored-by: fryorcraken.eth <110212804+fryorcraken@users.noreply.github.com>
commit 2af69de576
Author: Danish Arora <35004822+danisharora099@users.noreply.github.com>
Date: Thu Nov 3 11:28:26 2022 +0530
Update docs/About/3.md
Co-authored-by: fryorcraken.eth <110212804+fryorcraken@users.noreply.github.com>
commit 7b3e3519d2
Author: danisharora099 <danisharora099@gmail.com>
Date: Thu Nov 3 00:39:49 2022 +0530
iterate
commit c37f84b91a
Author: Danish Arora <35004822+danisharora099@users.noreply.github.com>
Date: Wed Nov 2 15:30:56 2022 +0530
Update docs/Development Concepts/Protocols/2.md
Co-authored-by: fryorcraken.eth <110212804+fryorcraken@users.noreply.github.com>
commit b9b7c8f57e
Author: Danish Arora <35004822+danisharora099@users.noreply.github.com>
Date: Wed Nov 2 15:11:47 2022 +0530
Update docs/About/7.md
Co-authored-by: fryorcraken.eth <110212804+fryorcraken@users.noreply.github.com>
commit c0bf3a4778
Author: Danish Arora <35004822+danisharora099@users.noreply.github.com>
Date: Wed Nov 2 15:11:07 2022 +0530
Update docs/About/6.md
Co-authored-by: fryorcraken.eth <110212804+fryorcraken@users.noreply.github.com>
commit a30737bd7c
Author: Danish Arora <35004822+danisharora099@users.noreply.github.com>
Date: Wed Nov 2 15:10:43 2022 +0530
Update docs/About/6.md
Co-authored-by: fryorcraken.eth <110212804+fryorcraken@users.noreply.github.com>
commit 4a0851efeb
Author: Danish Arora <35004822+danisharora099@users.noreply.github.com>
Date: Wed Nov 2 14:59:05 2022 +0530
Update docs/About/2.md
Co-authored-by: fryorcraken.eth <110212804+fryorcraken@users.noreply.github.com>
commit 0ed49e6f2c
Author: Danish Arora <35004822+danisharora099@users.noreply.github.com>
Date: Wed Nov 2 14:58:56 2022 +0530
Update docs/About/1.md
Co-authored-by: fryorcraken.eth <110212804+fryorcraken@users.noreply.github.com>
commit 2793d8f8b7
Author: danisharora099 <danisharora099@gmail.com>
Date: Tue Nov 1 19:51:24 2022 +0530
restructure & add new docs
This commit is contained in:
fryorcraken.eth
parent
0e4e20d14b
commit
f840ceb0bd
|
|
@ -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"]
|
||||
}
|
||||
|
|
@ -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
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
{
|
||||
"cSpell.words": ["Waku"]
|
||||
}
|
||||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
@ -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
|
||||
|
|
@ -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. |
|
||||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
@ -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).
|
||||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 72 KiB |
|
|
@ -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.
|
||||
|
|
@ -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).
|
||||
|
|
@ -1,32 +0,0 @@
|
|||
---
|
||||
title: Protocols
|
||||
---
|
||||
|
||||
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="npm" label="npm">
|
||||
|
||||
```shell
|
||||
npm isntall js-waku
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="y" label="yarn">
|
||||
|
||||
```shell
|
||||
yarn isntall js-waku
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="pnpm" label="pnpm">
|
||||
|
||||
```shell
|
||||
pnpm isntall js-waku
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
|
@ -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
|
||||
}
|
||||
```
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
---
|
||||
title: Case study 1
|
||||
---
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
---
|
||||
title: Case study 2
|
||||
---
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
---
|
||||
title: Use cases
|
||||
---
|
||||
|
|
@ -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;
|
||||
|
|
|
|||
Loading…
Reference in New Issue