migrate the blog template

This commit is contained in:
jinhojang6 2023-09-06 00:38:38 +09:00
commit c8c2644b11
22 changed files with 15473 additions and 0 deletions

129
.github/labels.yml vendored Normal file
View File

@ -0,0 +1,129 @@
# Official labels
- name: bug
description: Something isn't working
color: d73a4a
- name: documentation
description: Improvements or additions to documentation
color: 0075ca
- name: duplicate
description: This issue or pull request already exists
color: cfd3d7
- name: enhancement
description: New feature or request
color: a2eeef
- name: good first issue
description: Good for newcomers
color: 7057ff
- name: help wanted
description: Extra attention is needed
color: 008672
- name: invalid
description: This doesn't seem right
color: e4e669
- name: question
description: Further information is requested
color: d876e3
- name: wontfix
description: This will not be worked on
color: ffffff
# Generally useful labels
- name: blocked
description: This issue is blocked by some other work
color: e0af74
- name: critical
description: This issue needs critical attention
color: B60205
- name: infra
description: Infra, devops, CI and related tasks
color: 277196
- name: milestone
description: Milestone issue with a subset of issues within a specific track
color: 1CC0B0
# Waku Product labels
- name: rqt:platforms
description: Requirement coming from a platform
color: A51BB5
# Tracks primarily within Secure Messaging or Waku Product project
- name: track:rln
description: RLN Track - (Secure Messaging/Applied ZK), relay and applications
color: C89BC6
- name: track:anonymity
description: Anonymity track (Secure Messaging)
color: 06B6C8
- name: track:operator-outreach
description: Operator outreach track (Secure Messaging/Waku Product)
color: B888AB
- name: track:ft-store
description: FT-Store track (Secure Messaging)
color: F5FD62
- name: track:discovery
description: Discovery track (Secure Messaging/Waku Product)
color: 6BEB61
- name: track:protocol-incentivization
description: Protocol Incentivization track (Secure Messaging), e.g. service credentials
color: 0037E3
- name: track:restricted-run
description: Restricted run track (Secure Messaging/Waku Product), e.g. filter, WebRTC
color: D91C35
- name: track:conversational-security
description: Conversational security track (Secure Messaging)
color: CC6B00
- name: track:nwaku-productionization
description: nwaku-productionization track (Waku Product)
color: 9DEA79
- name: track:nwaku-maintenance
description: nwaku-maintenance track (Waku Product)
color: 40F9F0
- name: track:network-testing
description: network-testing track (Secure Messaging/Waku Product)
color: bfd4f2
- name: track:platform-outreach
description: Platform outreach track (Waku Product)
color: 06B6C8
- name: track:sdks
description: SDKS track (Waku Product), including bindings
color: 34D557
- name: track:go-waku-productionization
description: go-waku-productionization track (Waku Product)
color: 9DEA79
# Tracks within zk-WASM project
- name: track:kickoff
description: Kickoff track (zk-WASM)
color: 06B6C8
# Tracks within RAD project
- name: track:waku-specs
description: Waku specs track (RAD)
color: 1d76db
- name: track:logos-specs
description: Logos specs track (RAD)
color: CA105D
- name: track:codex-specs
description: Codex specs track (RAD)
color: D9714D
- name: track:rfc-process
description: RFC process track (RAD)
color: BB9BAD
- name: track:status-specs
description: Status specs track (RAD)
color: 0052CC
- name: track:research-outreach
description: Research outreach track (RAD)
color: ACAD2D
# Tracks primarily within Applied ZK/Explorations project
- name: track:validator-privacy
description: Validator privacy track (Applied ZK/Explorations)
color: 53AE45
- name: track:zerokit
description: Zerokit track (Applied ZK/Explorations)
color: DF1D12
# Meta track for Vac org
- name: track:vac-org
description: Vac Org track (Meta)
color: 1A28E8

22
.github/workflows/add-to-project.yml vendored Normal file
View File

@ -0,0 +1,22 @@
name: Add new issues and PRs to Vac Research project board
on:
issues:
types: [opened]
pull_request:
types: [opened]
jobs:
add-to-project:
name: Add issue to project
runs-on: ubuntu-latest
steps:
- uses: actions/add-to-project@v0.3.0
with:
# You can target a repository in a different organization
# to the issue
project-url: https://github.com/orgs/vacp2p/projects/6
github-token: ${{ secrets.ADD_TO_PROJECT_PAT }}
# NOTE Currently all issues are added, might want to limit this
#labeled: bug, needs-triage
#label-operator: OR

17
.github/workflows/sync-labels.yml vendored Normal file
View File

@ -0,0 +1,17 @@
name: Sync labels
on:
push:
branches:
- master
paths:
- .github/labels.yml
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: micnncim/action-label-syncer@v1
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
manifest: .github/labels.yml

26
.gitignore vendored Normal file
View File

@ -0,0 +1,26 @@
# Dependencies
/node_modules
# Production
/build
# Generated files
.docusaurus
.cache-loader
# Misc
.DS_Store
.env
.env.local
.env.development.local
.env.test.local
.env.production.local
npm-debug.log*
yarn-debug.log*
yarn-error.log*
.yalc
yalc.lock
.idea
static/search-index.json

2
.husky/commit-msg Executable file
View File

@ -0,0 +1,2 @@
#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

5
.husky/pre-commit Executable file
View File

@ -0,0 +1,5 @@
#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"
# yarn prettier:staged
yarn typecheck

2
.prettierignore Normal file
View File

@ -0,0 +1,2 @@
*.mdx
*.md

6
.prettierrc Normal file
View File

@ -0,0 +1,6 @@
{
"tabWidth": 2,
"semi": false,
"singleQuote": true,
"trailingComma": "all"
}

61
Jenkinsfile vendored Normal file
View File

@ -0,0 +1,61 @@
pipeline {
agent { label 'linux' }
options {
disableConcurrentBuilds()
/* manage how many builds we keep */
buildDiscarder(logRotator(
numToKeepStr: '20',
daysToKeepStr: '30',
))
}
environment {
GIT_COMMITTER_NAME = 'status-im-auto'
GIT_COMMITTER_EMAIL = 'auto@status.im'
PROD_SITE = 'blog.waku.org'
DEV_SITE = 'dev-blog.waku.org'
DEV_HOST = 'jenkins@node-01.do-ams3.sites.misc.statusim.net'
SCP_OPTS = 'StrictHostKeyChecking=no'
}
stages {
stage('Install') {
steps {
sh "yarn install"
}
}
stage('Build') {
steps {
sh 'yarn build'
sh "echo ${env.PROD_SITE} > build/CNAME"
}
}
stage('Publish Prod') {
when { expression { env.GIT_BRANCH ==~ /.*master/ } }
steps {
sshagent(credentials: ['status-im-auto-ssh']) {
sh "ghp-import -p build"
}
}
}
stage('Publish Devel') {
when { expression { env.GIT_BRANCH ==~ /.*develop/ } }
steps {
sshagent(credentials: ['jenkins-ssh']) {
sh """
rsync -e 'ssh -o ${SCP_OPTS}' -r --delete build/. \
${env.DEV_HOST}:/var/www/${env.DEV_SITE}/
"""
}
}
}
}
post {
cleanup { cleanWs() }
}
}

100
README.md Normal file
View File

@ -0,0 +1,100 @@
# Waku Blog
The template repository for blogs using [logos-docusaurus-plugins](https://github.com/acid-info/logos-docusaurus-plugins)
## How to Run Locally
1. Clone this repository
```bash
$ git clone https://github.com/acid-info/logos-blog-template.git
```
2. Install the dependencies:
```bash
$ yarn install
```
3. Start the website:
```bash
$ yarn start
```
4. Visit `http://localhost:3000/` in your browser
## Configuration
Edit the `docusaurus.config.js` file in the repository's root directory, and update the value of the `businessUnit` field in presets section; below is a list of valid values:
- Logos
- Codex
- Waku
- Nimbus
- Nomos
- VacResearch
- Acid.info
Example:
```js
presets: [
[
'@acid-info/logos-docusaurus-preset',
{
businessUnit: 'Codex',
},
],
],
```
This is typically sufficient for most cases, as the Logos plugins will automatically populate other configurations related to the specified business unit. If you encounter any errors in the information provided by Logos Plugins, please visit the [Logos Docusaurus Plugins](https://github.com/acid-info/logos-docusaurus-plugins) repository and open an issue.
## Blog Setup
The blog utilizes the Docusaurus blog plugin configured in `docusaurus.config.js`.
```js
[
'@docusaurus/plugin-content-blog',
/** @type {import('@docusaurus/plugin-content-blog').PluginOptions} */
({
id: 'blog',
routeBasePath: '/',
path: 'posts',
blogTitle: 'Research Log',
blogSidebarCount: 0,
authorsMapPath: 'authors.yml',
remarkPlugins: [math],
rehypePlugins: [katex],
}),
]
```
A list of authors can be defined in `/posts/authors.yml`.
For additional customization options, please refer to the [Docusaurus Blog Plugin documentation](https://docusaurus.io/docs/blog).
## Adding posts
To publish in the blog, create a `.md` or `mdx` file within the `posts` directory. You can use [Frontmatter](https://docusaurus.io/docs/markdown-features#front-matter) to add metadata to your markdown file.
## Customization
You can find instructions for adding additional documentation sections, implementing localization, and managing versioning on the [Docusaurus](https://docusaurus.io/docs) website.
> Please note that theme customization is somewhat restricted; for more detailed instructions on customizing your theme, visit the [Logos Docusaurus Theme](https://github.com/acid-info/logos-docusaurus-plugins/tree/main/packages/logos-docusaurus-theme/) repository.
## CI/CD
- The `master` branch is automatically deployed to the production server (e.g., logos.co) through [CI](https://ci.infra.status.im)
- The `develop` branch is automatically deployed to the staging server (e.g., dev.logos.co) through [CI](https://ci.infra.status.im)
## Change Process
1. Create a new working branch from `develop`: `git checkout develop; git checkout -b my-changes`.
2. Make your changes, push them to the `origin`, and open a Pull Request against the `develop` branch.
3. After approval, merge the pull request, and verify the changes on the staging server (e.g., https://dev.vac.dev).
4. When ready to promote changes to the live website, rebase the `master` branch on the staging changes: `git checkout master; git pull origin master; git rebase origin/develop; git push`.

3
babel.config.js Normal file
View File

@ -0,0 +1,3 @@
module.exports = {
presets: [require.resolve("@docusaurus/core/lib/babel/preset")],
};

0
docs/index.md Normal file
View File

135
docusaurus.config.js Normal file
View File

@ -0,0 +1,135 @@
// @ts-check
// Note: type annotations allow type checking and IDEs autocompletion
require('dotenv').config()
const math = require('remark-math')
const katex = require('rehype-katex')
/** @type {import('@docusaurus/types').Config} */
const config = {
title: 'Logos',
url: 'https://logos.co/',
baseUrl: '/',
markdown: {
mermaid: true,
},
// 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'],
},
presets: [
[
'@acid-info/logos-docusaurus-preset',
/** @type {import('@acid-info/logos-docusaurus-preset').PluginOptions} */
({
businessUnit: 'Waku',
theme: {
name: 'default',
options: {
customCss: [require.resolve('./src/css/custom.scss')],
},
},
docs: {
id: 'Docs',
routeBasePath: '/docs',
remarkPlugins: [math],
rehypePlugins: [katex],
},
og: {},
}),
],
],
plugins: [
[
'@docusaurus/plugin-content-blog',
/** @type {import('@docusaurus/plugin-content-blog').PluginOptions} */
({
id: 'blog',
routeBasePath: '/',
path: 'posts',
blogTitle: 'Research Log',
blogSidebarCount: 0,
authorsMapPath: 'authors.yml',
remarkPlugins: [math],
rehypePlugins: [katex],
}),
],
[
'@docusaurus/plugin-client-redirects',
{
redirects: [{ from: '/blog', to: '/' }],
createRedirects(existingPath) {
return existingPath.startsWith('/blog') && existingPath !== '/blog'
? [existingPath.replace('/blog', '')]
: undefined
},
},
],
],
themeConfig:
/** @type {import('@acid-info/logos-docusaurus-preset').ThemeConfig} */
({
navbar: {
items: [
{
type: 'search',
},
{
label: 'About',
href: 'https://waku.org/',
},
],
},
footer: {
links: [
{
items: [
{
label: 'Twitter',
href: 'https://twitter.com/waku_org',
},
{
label: 'Discord',
href: 'https://discord.waku.org',
},
{
label: 'Github',
href: 'https://github.com/waku-org',
},
],
},
{
items: [
{
label: 'Work With Us',
href: 'https://jobs.status.im/',
},
{
label: 'Terms & Conditions',
to: '/terms',
},
],
},
],
},
}),
stylesheets: [
{
href: 'https://cdn.jsdelivr.net/npm/katex@0.13.24/dist/katex.min.css',
type: 'text/css',
integrity:
'sha384-odtC+0UGzzFL/6PNoE8rX/SPcQDXBJ+uRepguP4QkPCm2LBxH3FA3y+fKSiJ+AmM',
crossorigin: 'anonymous',
},
],
}
module.exports = config

57
package.json Normal file
View File

@ -0,0 +1,57 @@
{
"name": "blog.waku.org",
"version": "0.0.0",
"private": true,
"scripts": {
"docusaurus": "docusaurus",
"start": "docusaurus start",
"build": "docusaurus build",
"swizzle": "docusaurus swizzle",
"deploy": "docusaurus deploy",
"clear": "docusaurus clear",
"serve": "docusaurus serve",
"write-translations": "docusaurus write-translations",
"write-heading-ids": "docusaurus write-heading-ids",
"typecheck": "tsc"
},
"dependencies": {
"@acid-info/logos-docusaurus-preset": "^1.0.0-alpha.97",
"@docusaurus/core": "2.4.1",
"@docusaurus/plugin-client-redirects": "^2.4.1",
"@docusaurus/preset-classic": "2.4.1",
"@docusaurus/theme-mermaid": "^2.4.1",
"@emotion/react": "^11.11.0",
"@emotion/styled": "^11.11.0",
"@mdx-js/react": "^1.6.22",
"clsx": "^1.2.1",
"dotenv": "^16.0.3",
"hast-util-is-element": "1.1.0",
"prism-react-renderer": "^1.3.5",
"react": "^17.0.2",
"react-dom": "^17.0.2",
"rehype-katex": "5",
"remark-math": "3",
"sass": "^1.62.1",
"tsdx": "^0.14.1"
},
"devDependencies": {
"@docusaurus/module-type-aliases": "2.4.1",
"@tsconfig/docusaurus": "^1.0.5",
"typescript": "^4.7.4"
},
"browserslist": {
"production": [
">0.5%",
"not dead",
"not op_mini all"
],
"development": [
"last 1 chrome version",
"last 1 firefox version",
"last 1 safari version"
]
},
"engines": {
"node": ">=16.14"
}
}

View File

@ -0,0 +1,136 @@
---
layout: post
name: 'The Future of Waku Network: Scaling, Incentivization, and Heterogeneity'
title: 'The Future of Waku Network: Scaling, Incentivization, and Heterogeneity'
date: 2023-04-03 00:00:00
authors: franck
published: true
slug: future-of-waku-network
categories: platform, operator, network
image: /img/black-waku-logo-with-name.png
discuss: https://forum.vac.dev/t/discussion-the-future-of-waku-network-scaling-incentivization-and-heterogeneity/173
hide_table_of_contents: false
---
Learn how the Waku Network is evolving through scaling, incentivization, and diverse ecosystem development and what the future might look like.
<!--truncate-->
Waku is preparing for production with a focus on the Status Communities use case. In this blog post, we will provide an
overview of recent discussions and research outputs, aiming to give you a better understanding of how the Waku network
may look like in terms of scaling and incentivization.
## DOS Mitigation for Status Communities
Waku is actively exploring DOS mitigation mechanisms suitable for Status Communities. While RLN
(Rate Limiting Nullifiers) remains the go-to DOS protection solution due to its privacy-preserving and
censorship-resistant properties, there is still more work to be done. We are excited to collaborate with PSE
(Privacy & Scaling Explorations) in this endeavor. Learn more about their latest progress in this [tweet](https://twitter.com/CPerezz19/status/1640373940634939394?s=20).
## A Heterogeneous Waku Network
As we noted in a previous [forum post](https://forum.vac.dev/t/waku-payment-models/166/3), Waku's protocol
incentivization model needs to be flexible to accommodate various business models. Flexibility ensures that projects
can choose how they want to use Waku based on their specific needs.
### Reversing the Incentivization Question
Traditionally, the question of incentivization revolves around how to incentivize operators to run nodes. We'd like to
reframe the question and instead ask, "How do we pay for the infrastructure?"
Waku does not intend to offer a free lunch.
Ethereum's infrastructure is supported by transaction fees and inflation, with validators receiving rewards from both sources.
However, this model does not suit a communication network like Waku.
Users and platforms would not want to pay for every single message they send. Additionally, Waku aims to support instant
ephemeral messages that do not require consensus or long-term storage.
Projects that use Waku to enable user interactions, whether for chat messages, gaming, private DeFi, notifications, or
inter-wallet communication, may have different value extraction models. Some users might provide services for the
project and expect to receive value by running nodes, while others may pay for the product or run infrastructure to
contribute back. Waku aims to support each of these use cases, which means there will be various ways to "pay for the
infrastructure."
In [his talk](https://vac.dev/building-privacy-protecting-infrastructure), Oskar addressed two strategies: RLN and service credentials.
### RLN and Service Credentials
RLN enables DOS protection across the network in a privacy-preserving and permission-less manner: stake in a contract,
and you can send messages.
Service credentials establish a customer-provider relationship. Users might pay to have messages they are interested in
stored and served by a provider. Alternatively, a community owner could pay a service provider to host their community.
Providers could offer trial or limited free services to Waku users, similar to Slack or Discord. Once a trial is expired or outgrown,
a community owner could pay for more storage or bandwidth, similar to Slack's model.
Alternatively, individual users could contribute financially, akin to Discord's Server Boost, or by sharing their own
resources with their community.
We anticipate witnessing various scenarios across the spectrum: from users sharing resources to users paying for access to the network and everything in between.
## Waku Network: Ethereum or Cosmos?
Another perspective is to consider whether the Waku network will resemble Ethereum or Cosmos.
For those not familiar with the difference between both, in a very concise manner:
- Ethereum is a set of protocols and software that are designed to operate on one common network and infrastructure
- Cosmos is a set of protocols and software (SDKs) designed to be deployed in separate yet interoperable networks and infrastructures by third parties
We want Waku to be decentralized to provide censorship resistance and privacy-preserving communication.
If each application has to deploy its own network, we will not achieve this goal.
Therefore, we aim Waku to be not only an open source set of protocols, but also a shared infrastructure that anyone can leverage to build applications on top, with some guarantees in terms of decentralization and anonymity.
This approach is closer in spirit to Ethereum than Cosmos.
Do note that, similarly to Ethereum, anyone is free to take Waku software and protocols and deploy their own network.
Yet, because of the difference in the fee model, the Waku Network is unlikely to be as unified as Ethereum's.
We currently assume that there will be separate gossipsub networks with different funding models.
Since there is no consensus on Waku, each individual operator can decide which network to support, enabling Waku to maintain its permission-less property.
Most likely, the Waku network will be heterogeneous, and node operators will choose the incentivization model they prefer.
## Scalability and Discovery Protocols
To enable scalability, the flow of messages in the Waku network will be divided in shards,
so that not every node has to forward every message of the whole network.
Discovery protocols will facilitate users connecting to the right nodes to receive the messages they are interested in.
Different shards could be subject to a variety of rate limiting techniques (globally, targeted to that shard or something in-between).
Marketplace protocols may also be developed to help operators understand how they can best support the network and where
their resources are most needed. However, we are still far from establishing or even assert that such a marketplace will be needed.
## Open Problems
Splitting traffic between shards reduces bandwidth consumption for every Waku Relay node.
This improvement increases the likelihood that users with home connections can participate and contribute to the gossipsub network without encountering issues.
However, it does not cap traffic.
There are still open problems regarding how to guarantee that someone can use Waku with lower Internet bandwidth or run critical services, such as a validation node, on the same connection.
We have several ongoing initiatives:
- Analyzing the Status Community protocol to confirm efficient usage of Waku [[4]](https://github.com/vacp2p/research/issues/177)
- Simulating the Waku Network to measure actual bandwidth usage [[5]](https://github.com/waku-org/pm/issues/2)
- Segregating chat messages from control and media messages [[6]](https://rfc.vac.dev/spec/57/#control-message-shards)
The final solution will likely be a combination of protocols that reduce bandwidth usage or mitigate the risk of DOS attacks, providing flexibility for users and platforms to enable the best experience.
## The Evolving Waku Network
The definition of the "Waku Network" will likely change over time. In the near future, it will transition from a single
gossipsub network to a sharded set of networks unified by a common discovery layer. This change will promote scalability
and allow various payment models to coexist within the Waku ecosystem.
In conclusion, the future of Waku Network entails growth, incentivization, and heterogeneity while steadfastly
maintaining its core principles. As Waku continues to evolve, we expect it to accommodate a diverse range of use cases
and business models, all while preserving privacy, resisting censorship, avoiding surveillance, and remaining accessible
to devices with limited resources.
## References
1. [51/WAKU2-RELAY-SHARDING](https://rfc.vac.dev/spec/51/)
2. [57/STATUS-Simple-Scaling](https://rfc.vac.dev/spec/57/)
3. [58/RLN-V2](https://rfc.vac.dev/spec/58/)
4. [Scaling Status Communities: Potential Problems](https://github.com/vacp2p/research/issues/177)
5. [Waku Network Testing](https://github.com/waku-org/pm/issues/2)
6. [51/WAKU2-RELAY-SHARDING: Control Message Shards](https://rfc.vac.dev/spec/57/#control-message-shards)

View File

@ -0,0 +1,61 @@
---
layout: post
name: 'Device Pairing in Js-waku and Go-waku'
title: 'Device Pairing in Js-waku and Go-waku'
date: 2023-04-24 12:00:00
authors: rramos
published: true
slug: device-pairing-in-js-waku-and-go-waku
categories: platform
---
Device pairing and secure message exchange using Waku and noise protocol.
<!--truncate-->
As the world becomes increasingly connected through the internet, the need for secure and reliable communication becomes paramount. In [this article](https://vac.dev/wakuv2-noise) it is described how the Noise protocol can be used as a key-exchange mechanism for Waku.
Recently, this feature was introduced in [js-waku](https://github.com/waku-org/js-noise) and [go-waku](https://github.com/waku-org/go-waku), providing a simple API for developers to implement secure communication protocols using the Noise Protocol framework. These open-source libraries provide a solid foundation for building secure and decentralized applications that prioritize data privacy and security.
This functionality is designed to be simple and easy to use, even for developers who are not experts in cryptography. The library offers a clear and concise API that abstracts away the complexity of the Noise Protocol framework and provides an straightforward interface for developers to use. Using this, developers can effortlessly implement secure communication protocols on top of their JavaScript and Go applications, without having to worry about the low-level details of cryptography.
One of the key benefits of using Noise is that it provides end-to-end encryption, which means that the communication between two parties is encrypted from start to finish. This is essential for ensuring the security and privacy of sensitive information
### Device Pairing
In today's digital world, device pairing has become an integral part of our lives. Whether it's connecting our smartphones with other computers or web applications, the need for secure device pairing has become more crucial than ever. With the increasing threat of cyber-attacks and data breaches, it's essential to implement secure protocols for device pairing to ensure data privacy and prevent unauthorized access.
To demonstrate how device pairing can be achieved using Waku and Noise, we have examples available at https://examples.waku.org/noise-js/. You can try pairing different devices, such as mobile and desktop, via a web application. This can be done by scanning a QR code or opening a URL that contains the necessary data for a secure handshake.
The process works as follows:
Actors:
- Alice the initiator
- Bob the responder
1. The first step in achieving secure device pairing using Noise and Waku is for Bob generate the pairing information which could be transmitted out-of-band. For this, Bob opens https://examples.waku.org/noise-js/ and a QR code is generated, containing the data required to do the handshake. This pairing QR code is timeboxed, meaning that after 2 minutes, it will become invalid and a new QR code must be generated
2. Alice scans the QR code using a mobile phone. This will open the app with the QR code parameters initiating the handshake process which is described in [43/WAKU2-DEVICE-PAIRING](https://rfc.vac.dev/spec/43/#protocol-flow). These messages are exchanged between two devices over Waku to establish a secure connection. The handshake messages consist of three main parts: the initiator's message, the responder's message, and the final message, which are exchanged to establish a secure connection. While using js-noise, the developer is abstracted of this process, since the messaging happens automatically depending on the actions performed by the actors in the pairing process.
3. Both Alice and Bob will be asked to verify each other's identity. This is done by confirming if an 8-digits authorization code match in both devices. If both actors confirm that the authorization code is valid, the handshake concludes succesfully
4. Alice and Bob receive a set of shared keys that can be used to start exchanging encrypted messages. The shared secret keys generated during the handshake process are used to encrypt and decrypt messages sent between the devices. This ensures that the messages exchanged between the devices are secure and cannot be intercepted or modified by an attacker.
The above example demonstrates device pairing using js-waku. Additionally, You can also try building and experimenting with other noise implementations like nwaku, or go-waku, with an example available at https://github.com/waku-org/go-waku/tree/master/examples/noise in which the same flow described before is done with Bob (the receiver) using go-waku instead of js-waku.
### Conclusion
With its easy to use API built on top of the Noise Protocol framework and the LibP2P networking stack, if you are a developer looking to implement secure messaging in their applications that are both decentralized and censorship resistant, Waku is definitely an excellent choice worth checking out!
Waku is also Open source with a MIT and APACHEv2 licenses, which means that developers are encouraged to contribute code, report bugs, and suggest improvements to make it even better.
Don't hesitate to try the live example at https://examples.waku.org/noise-js and build your own webapp using https://github.com/waku-org/js-noise, https://github.com/waku-org/js-waku and https://github.com/waku-org/go-waku. This will give you a hands-on experience of implementing secure communication protocols using the Noise Protocol framework in a practical setting. Happy coding!
### References
- [Noise handshakes as key-exchange mechanism for Waku](https://vac.dev/wakuv2-noise)
- [Noise Protocols for Waku Payload Encryption](https://rfc.vac.dev/spec/35/)
- [Session Management for Waku Noise](https://rfc.vac.dev/spec/37/)
- [Device pairing and secure transfers with Noise](https://rfc.vac.dev/spec/43/)
- [go-waku Noise's example](https://github.com/waku-org/go-waku/tree/master/examples/noise)
- [js-waku Noise's example](https://github.com/waku-org/js-waku-examples/tree/master/examples/noise-js)
- [js-noise](https://github.com/waku-org/js-noise/)
- [go-noise](https://github.com/waku-org/js-noise/)

48
posts/authors.yml Normal file
View File

@ -0,0 +1,48 @@
circe:
name: 'Circe'
twitter: 'vacp2p'
github: 'thecirce'
dean:
name: 'Dean'
twitter: 'DeanEigenmann'
github: 'decanus'
website: 'https://dean.eigenmann.me'
franck:
name: 'Franck'
twitter: 'fryorcraken'
github: 'fryorcraken'
hanno:
name: 'Hanno Cornelius'
twitter: '4aelius'
github: 'jm-clius'
kaiserd:
name: 'Daniel'
github: 'kaiserd'
oskarth:
name: 'Oskar'
twitter: 'oskarth'
github: 'oskarth'
rramos:
name: 'Richard'
twitter: 'richardramos_me'
github: 'richard-ramos'
website: 'https://richard-ramos.github.io/'
s1fr0:
name: 's1fr0'
github: 's1fr0'
sanaz:
name: 'Sanaz'
twitter: 'sanaz2016'
github: 'staheri14'
moudy:
name: 'Moudy'
github: 'moudyellaz'

View File

@ -0,0 +1 @@
export * from '@acid-info/logos-docusaurus-theme/lib/client/components/mdx'

13
src/css/custom.scss Normal file
View File

@ -0,0 +1,13 @@
:root {
}
body,
html {
overflow-x: hidden;
}
.blog-wrapper {
main {
margin-left: 0 !important;
}
}

Binary file not shown.

After

Width:  |  Height:  |  Size: 56 KiB

4
tsconfig.json Normal file
View File

@ -0,0 +1,4 @@
{
// This file is not used in compilation. It is here just for a nice editor experience.
"extends": "@tsconfig/docusaurus/tsconfig.json"
}

14645
yarn.lock Normal file

File diff suppressed because it is too large Load Diff