Initial commit
This commit is contained in:
Jinho Jang
GitHub
commit
151df05b99
|
|
@ -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
|
||||
|
|
@ -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
|
||||
|
|
@ -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
|
||||
|
|
@ -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
|
||||
|
|
@ -0,0 +1,2 @@
|
|||
#!/usr/bin/env sh
|
||||
. "$(dirname -- "$0")/_/husky.sh"
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
#!/usr/bin/env sh
|
||||
. "$(dirname -- "$0")/_/husky.sh"
|
||||
|
||||
# yarn prettier:staged
|
||||
yarn typecheck
|
||||
|
|
@ -0,0 +1,2 @@
|
|||
*.mdx
|
||||
*.md
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
{
|
||||
"tabWidth": 2,
|
||||
"semi": false,
|
||||
"singleQuote": true,
|
||||
"trailingComma": "all"
|
||||
}
|
||||
|
|
@ -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 = 'vac.dev'
|
||||
DEV_SITE = 'dev.vac.dev'
|
||||
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() }
|
||||
}
|
||||
}
|
||||
|
|
@ -0,0 +1,126 @@
|
|||
# Logos Blog Template
|
||||
|
||||
The template repository for blogs using [logos-docusaurus-plugins](https://github.com/acid-info/logos-docusaurus-plugins).
|
||||
|
||||
|
||||
## Use Cases
|
||||
- [Vac Research log](https://vac.dev/rlog)
|
||||
|
||||
|
||||
## 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.
|
||||
|
||||
|
||||
## Docusaurus Config
|
||||
|
||||
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.
|
||||
|
||||
|
||||
## Custom CSS
|
||||
|
||||
By default, this template utilizes the CSS styles defined in the [logos-docusaurus-plugins](https://github.com/acid-info/logos-docusaurus-plugins/tree/main/packages/logos-docusaurus-theme/src/client/css) package. You have the option to define custom CSS in `src/css/custom.scss`.
|
||||
|
||||
|
||||
## How to Run a Static Build (Production Build)
|
||||
|
||||
1. Generate static files for production:
|
||||
|
||||
```bash
|
||||
$ yarn build
|
||||
```
|
||||
|
||||
The static files will be created in the `build` directory.
|
||||
|
||||
2. Serve the static build:
|
||||
|
||||
```bash
|
||||
$ yarn serve
|
||||
```
|
||||
|
||||
|
||||
## 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`.
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
module.exports = {
|
||||
presets: [require.resolve("@docusaurus/core/lib/babel/preset")],
|
||||
};
|
||||
|
|
@ -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: 'VacResearch',
|
||||
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/vacp2p',
|
||||
},
|
||||
{
|
||||
label: 'Discord',
|
||||
href: 'https://discord.gg/PQFdubGt6d',
|
||||
},
|
||||
{
|
||||
label: 'Github',
|
||||
href: 'https://github.com/vacp2p',
|
||||
},
|
||||
],
|
||||
},
|
||||
{
|
||||
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
|
||||
|
|
@ -0,0 +1,57 @@
|
|||
{
|
||||
"name": "logos-blog-template",
|
||||
"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"
|
||||
}
|
||||
}
|
||||
|
|
@ -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)
|
||||
|
|
@ -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/)
|
||||
|
|
@ -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'
|
||||
|
|
@ -0,0 +1 @@
|
|||
export * from '@acid-info/logos-docusaurus-theme/lib/client/components/mdx'
|
||||
|
|
@ -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 |
|
|
@ -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"
|
||||
}
|
||||
Loading…
Reference in New Issue