mirror of https://github.com/acid-info/vac.dev.git
jeangovil
GitHub
parent
e576ae7840
commit
4ca1be8454
|
|
@ -1,6 +1,26 @@
|
|||
vendor/
|
||||
.bundle/
|
||||
# Dependencies
|
||||
/node_modules
|
||||
|
||||
# Production
|
||||
/build
|
||||
|
||||
# Generated files
|
||||
.docusaurus
|
||||
.cache-loader
|
||||
|
||||
# Misc
|
||||
.DS_Store
|
||||
node_modules
|
||||
.vscode
|
||||
.idea
|
||||
.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"
|
||||
}
|
||||
|
|
@ -3,8 +3,6 @@ pipeline {
|
|||
|
||||
options {
|
||||
disableConcurrentBuilds()
|
||||
/* Necessary for logos-side-builder local_folder source type. */
|
||||
checkoutToSubdirectory('src')
|
||||
/* manage how many builds we keep */
|
||||
buildDiscarder(logRotator(
|
||||
numToKeepStr: '20',
|
||||
|
|
@ -13,10 +11,6 @@ pipeline {
|
|||
}
|
||||
|
||||
environment {
|
||||
/* Mode of logos-site-builder for copying site source from already checked out repo.
|
||||
* TODO: Avoid copying anything at all, make checkout site of into `docs` folder work. */
|
||||
CONTENT_SOURCE_TYPE = 'local_folder'
|
||||
CONTENT_SOURCE_URL = '../src'
|
||||
GIT_COMMITTER_NAME = 'status-im-auto'
|
||||
GIT_COMMITTER_EMAIL = 'auto@status.im'
|
||||
PROD_SITE = 'vac.dev'
|
||||
|
|
@ -26,41 +20,24 @@ pipeline {
|
|||
}
|
||||
|
||||
stages {
|
||||
stage('Clone Builder') {
|
||||
steps {
|
||||
dir('builder') {
|
||||
checkout([$class: 'GitSCM',
|
||||
branches: [[name: 'v0']],
|
||||
userRemoteConfigs: [[url: 'https://github.com/acid-info/logos-site-builder']]])
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
stage('Install') {
|
||||
steps {
|
||||
dir('builder') {
|
||||
sh 'yarn install'
|
||||
}
|
||||
sh "yarn install"
|
||||
}
|
||||
}
|
||||
|
||||
stage('Build') {
|
||||
steps {
|
||||
dir('builder') {
|
||||
sh 'yarn build'
|
||||
sh "echo ${env.PROD_SITE} > out/CNAME"
|
||||
}
|
||||
sh 'yarn build'
|
||||
sh "echo ${env.PROD_SITE} > build/CNAME"
|
||||
}
|
||||
}
|
||||
|
||||
stage('Publish Prod') {
|
||||
when { expression { env.GIT_BRANCH ==~ /.*master/ } }
|
||||
steps {
|
||||
dir('src') {
|
||||
sh 'cp -r ../builder/out ./'
|
||||
sshagent(credentials: ['status-im-auto-ssh']) {
|
||||
sh "ghp-import -p out"
|
||||
}
|
||||
sshagent(credentials: ['status-im-auto-ssh']) {
|
||||
sh "ghp-import -p build"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
@ -68,13 +45,11 @@ pipeline {
|
|||
stage('Publish Devel') {
|
||||
when { expression { env.GIT_BRANCH ==~ /.*develop/ } }
|
||||
steps {
|
||||
dir('builder') {
|
||||
sshagent(credentials: ['jenkins-ssh']) {
|
||||
sh """
|
||||
rsync -e 'ssh -o ${SCP_OPTS}' -r --delete out/. \
|
||||
${env.DEV_HOST}:/var/www/${env.DEV_SITE}/
|
||||
"""
|
||||
}
|
||||
sshagent(credentials: ['jenkins-ssh']) {
|
||||
sh """
|
||||
rsync -e 'ssh -o ${SCP_OPTS}' -r --delete build/. \
|
||||
${env.DEV_HOST}:/var/www/${env.DEV_SITE}/
|
||||
"""
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
|
|||
51
README.md
51
README.md
|
|
@ -1,19 +1,46 @@
|
|||
# Vac.dev Website
|
||||
- [Description](#description)
|
||||
- [How to Run Locally](#how-to-run-locally)
|
||||
- [Configuration](#configuration)
|
||||
- [Customization](#customization)
|
||||
|
||||
Made and deployed with [logos site-builder](https://github.com/acid-info/logos-site-builder).
|
||||
## Description
|
||||
|
||||
# Continuous Deloyment
|
||||
This repository contains the content of your documentation website.
|
||||
|
||||
* `master` branch is deployed to https://vac.dev by [CI](https://ci.infra.status.im/job/website/job/vac.dev/)
|
||||
- `develop` branch is deployed to https://dev.vac.dev by [CI](https://ci.infra.status.im/job/website/job/dev.vac.dev/)
|
||||
## How to Run Locally
|
||||
|
||||
# Change Process
|
||||
1. Clone this repository.
|
||||
2. Install the dependencies:
|
||||
```bash
|
||||
$ yarn
|
||||
```
|
||||
3. Start and open the website in your browser:
|
||||
```bash
|
||||
$ yarn start
|
||||
```
|
||||
|
||||
1. Create a new working branch from `develop`: `git checkout develop; git checkout -b my-changes`;
|
||||
2. Proceed with changes, push to `origin` and open a Pull Request against `develop`;
|
||||
3. Once approved, merge pull request, check changes on [dev.vac.dev](https://dev.vac.dev);
|
||||
4. Once ready to promote to live website, rebase master on staging: `git checkout master; git pull master; git rebase origin/develop; git push`.
|
||||
## 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
|
||||
|
||||
# Copyright
|
||||
Example:
|
||||
```js
|
||||
presets: [
|
||||
[
|
||||
'@acid-info/logos-docusaurus-preset',
|
||||
{
|
||||
businessUnit: 'Codex',
|
||||
},
|
||||
],
|
||||
],
|
||||
```
|
||||
|
||||
For all research posts under https://vac.dev/research, copyright and related rights are waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
|
||||
This is probably enough in most cases, as the Logos plugins will fill in other configurations related to the specified business unit. If you find any error in the information coming from Logos Plugins, please head over to [Logos Docusaurus Plugins](https://github.com/acid-info/logos-docusaurus-plugins) and create an issue.
|
||||
|
||||
## Customization
|
||||
|
||||
You can find the instructions on adding more documentation sections, localization, and versioning on the [Docusaurus](https://docusaurus.io/docs) website.
|
||||
|
||||
> Note that theme customization is limited; for further instructions on customizing your theme, head over to [Logos Docusaurus Theme](https://github.com/acid-info/logos-docusaurus-plugins/tree/main/packages/logos-docusaurus-theme/).
|
||||
|
|
|
|||
|
|
@ -1,7 +0,0 @@
|
|||
---
|
||||
layout: author
|
||||
short_name: circe
|
||||
name: Circe
|
||||
twitter: vacp2p
|
||||
github: thecirce
|
||||
---
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
---
|
||||
layout: author
|
||||
short_name: dean
|
||||
name: Dean
|
||||
twitter: DeanEigenmann
|
||||
github: decanus
|
||||
website: https://dean.eigenmann.me
|
||||
---
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
---
|
||||
layout: author
|
||||
short_name: franck
|
||||
name: Franck
|
||||
twitter: fryorcraken
|
||||
github: fryorcraken
|
||||
---
|
||||
|
|
@ -1,55 +0,0 @@
|
|||
---
|
||||
layout: author
|
||||
short_name: hanno
|
||||
name: Hanno Cornelius
|
||||
twitter: 4aelius
|
||||
github: jm-clius
|
||||
---
|
||||
```ascii
|
||||
%%%%%#***++++++++-........::-===----:::::::--:::-%%%%%%%%%+++++++++++++**#%%%%%%%%%%%#####
|
||||
%%%%%#**+++++++++:.........:::----:::::::---:::.-%%%%%%%%%*+++++++++++++*#%%%%%%%%%%%#####
|
||||
%%%%%#**+++++++++-............:-:::::::---:::::.-%%%%%%%%%++++++++++++++*%%%%%%%%%%%%#####
|
||||
#%@@%#**+++++++++-:...........:::::::---:::::::.-%%%%%%%%%+++++++++++++**%%%%%%%%%%%%#####
|
||||
#%@@%#**+++++++++-:...........::::::::::::::::::=**#%%%%%%++++++++++++++*%%%%%%%%%%%%#####
|
||||
#%%%%#****+++++++-.............::---::::::::=*****+++*#%%%+++++++++++++**%%%%%%%%%%%%#####
|
||||
#%%#**+++++++++++-:...........:---:::::::-*##%%%%##*++**##+++++++++++++**%%%%%%%%%%%%#####
|
||||
#%+-----::::::----:::.........:::::::::=*%%%%@@%%%##*##**#*+++++++++++++*%%%%%%%%%%%%#####
|
||||
*#*+=---------------:.........:::::::-*%%%###**#***######*#*+++++********%%%%%%%%%%%%#####
|
||||
:-**+-::::::------:............:::::=%%#**++====-----=+*#%#%#*+**********%%%%%%%%%%%%#####
|
||||
-=***=::::::::::::.............::::=%%##*++====-----:::--+###**##########%%%%%%%%%%%%#####
|
||||
*+++*+-::::::::::..............::-*%%###**++====-----:::---****++++******%%%%%%%%%%%%#####
|
||||
-++===--------:-::............::-=%%%##***++====----:::::--=**#*+++++****%%%%%%%%%%%%#####
|
||||
.:===**++++++===:..............:-*%%###*+++===-=----:::::--=****+********%%%%%%%%%%%%#####
|
||||
..-==+#*++++++++-::............-+%%%###**###*++====+++=-----*#***********%%%%%%%%%%%%#####
|
||||
..-==*#*++++++++=--:......:-:::-+%%%###*****##*=-=***+==----#%%#*********%%%%%%%%%%%%#####
|
||||
..:*#%%#++++++++-:::......:::::=#%%%#**#*****#*-:-+***++=---###**********%%%%%%%%%%%%#####
|
||||
..:**#%*+====+++:..............-+%%%#*++=+++##*-:--=+=---:--**#+*********%%%%%%%%%%%%#####
|
||||
..:#*#%#+=-----=-:.............:=#####+==-=*#*+-::-==--:::--*==+*********%%%%%%%%%%%%#####
|
||||
..:###%#+++========-:.....:=-::::+####*+=+###%#++=-+*+--::--=--**********%%%%%%%%%%%%#####
|
||||
..:#*#%#++++++++=:::......:-:::::=*###*+*##%%#**++==*#+=------+**********%%%%%%%%%%%%#####
|
||||
..:###%*++++++++-:.............:::-+##*+*#%##*+====**#*=---==+***********%%%%%%%%%%%%#####
|
||||
.:-#*#%+========-:.............:::-=*##*+*#****+==-++#+---=**************%%%%%%%%%%%%#####
|
||||
.:-#*#%+===========-:.....:--:::-----*###**#*+==----=+=--=##*********++++%%%%%%%%%%%%#####
|
||||
.:-#*#%+==---====-::......::::::-----+####*****+=---=--==####**********+*%%%%%%%%%%%%#####
|
||||
::=#*#%+==--=-==-:.............:---::+##%%#*+====-----==+%###############%%%%%%%%%%%%#####
|
||||
::=#*#%+==--:-==-:.............::::::*##%%%##*++=======-*%#**************%%%%%%%%%%%%#####
|
||||
::+#*#%+=========-:::::..:::::::::::-####%%%%%##***+==--*%#**************%%%%%%%%%%%%%###%
|
||||
::+#*#%+==----====-===-:::=+=---::--=#####%%%%##**+=----#%#**************%%%%%%%%%%%%%##%%
|
||||
::+##%%+==----===-:-==-:.:==-----==-*#######**++=-------#%#********+++++*%%%%%%%%%%%%%##%%
|
||||
::+##%%+==--=====-::--:..:----------###**###*++=--------*%#********+++++*%%%%%%%%%%%%%#%%%
|
||||
::+%#%%+==--=====-:.:::...:::::=+**####***##***=---------=+******+++++++*%%%%%%%%%%%%%#%%%
|
||||
::*###%*=++=--====::--:..:-==*%%@@%##*********+=----------=***#**+++++++*%%%%%%%%%%%%%%%%%
|
||||
:-*#*#%*=++=--===+=+*###*#%%%@@@@@@@%##*****++===------=+*####%%%#*+++++*%%%%%%%%%%%%%%%%%
|
||||
:-*#*%%*===++=++*%%%%%%%%%%@@@@@@@@@@@@@%%#***++++++**########%%%%%%##**#%%%%%%%%%%%%%%%%%
|
||||
:-*#*#%*==---*%%%%@@@@@@@@@@@@@@@@@@@@@@@@@%%%%%################%#%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
--#%##%*===+%@@%%%%%%@@@@@@@@@@@@@@@@@@%%@@@@@%%%%%%################%%%%%%%%%%@@@@@@@%%%%%
|
||||
-=%%##%*==#@@@@@%%%%%%@%@@@@@@@@@@@@@@%%%%%%%%%%%%%#######################%##%%%@@@@@%%%%%
|
||||
-=%%*#%*=#@@@@%%%@@%%%%%@@@@@%%%%@@%@@@%%########%%%%%%%########################%@@@@%%%%%
|
||||
-=#%*#%*#@@@@@@%%%%@%%@@@@@@%%%%%%@%%%%%%%%################%%%%%%%%%############%%@@@%%%%%
|
||||
-=##**%#@@@@@@@@%%%%%@@@@%%%%%%%%%%%%%%%%%%###***********#######%%%%%%%####%%#%%%%@@@%%%%%
|
||||
-=##**#@@@@@@@@@%%%@@@%%%%%%%%%%%%%%%%%%%%%%##*****************#####%%%%##%%%%%%%%@@@%%%%%
|
||||
-=##**%@@@@@@@@@%%@@@@%@%%%%%%%%%%%%%%%%%%%%%##***************+++*###%@%#%%%%%%%%%%@@%%%%%
|
||||
-=##*#@@@@@@@@@@@@@@@@@@%%%%%%%%%%%%%%@%#%%%%###****++++*****#*++=+*##%%#%%%%%%%%%%@@%%%%%
|
||||
-=##*@@@@@@@@@@@@@@@@@@@%%%%%%%#%%%%%%%%##%%%%###***+++++*******#*+++#%%#@%%%%%%%%%@@%%%%%
|
||||
|
||||
```
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
---
|
||||
layout: author
|
||||
short_name: kaiserd
|
||||
name: Daniel
|
||||
github: kaiserd
|
||||
---
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
---
|
||||
layout: author
|
||||
short_name: oskarth
|
||||
name: Oskar
|
||||
twitter: oskarth
|
||||
github: oskarth
|
||||
---
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
---
|
||||
layout: author
|
||||
short_name: rramos
|
||||
name: Richard
|
||||
twitter: richardramos_me
|
||||
github: richard-ramos
|
||||
website: https://richard-ramos.github.io/
|
||||
---
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
---
|
||||
layout: author
|
||||
short_name: s1fr0
|
||||
name: s1fr0
|
||||
github: s1fr0
|
||||
---
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
---
|
||||
layout: author
|
||||
short_name: sanaz
|
||||
name: Sanaz
|
||||
twitter: sanaz2016
|
||||
github: staheri14
|
||||
---
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
---
|
||||
layout: author
|
||||
short_name: sanaz
|
||||
name: Sanaz
|
||||
twitter: sanaz2016
|
||||
github: staheri14
|
||||
---
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
module.exports = {
|
||||
presets: [require.resolve("@docusaurus/core/lib/babel/preset")],
|
||||
};
|
||||
82
config.json
82
config.json
|
|
@ -1,82 +0,0 @@
|
|||
{
|
||||
"theme":{
|
||||
"palettes":{
|
||||
"dark":{
|
||||
"background":"#FFFFFF",
|
||||
"text":"#000000",
|
||||
"accentActive":"#7187ff",
|
||||
"accentMute":"#F7F7F7"
|
||||
},
|
||||
"light":{
|
||||
"background":"#000000",
|
||||
"text":"#FFFFFF",
|
||||
"accentActive":"#7187ff",
|
||||
"accentMute":"#30363d"
|
||||
}
|
||||
},
|
||||
"fontFamily":"sans-serif",
|
||||
"codeTheme":"prism/duotone-dark"
|
||||
},
|
||||
"template": "academia",
|
||||
"static_assets_folder": "static-assets",
|
||||
"external_sources": [],
|
||||
"navigation":{
|
||||
"home":"vac.md",
|
||||
"fileOrdersInSidenav": [
|
||||
"vac.md",
|
||||
"principles.md",
|
||||
"research-areas.md",
|
||||
"projects.md",
|
||||
"open-problems.md",
|
||||
"publications.md",
|
||||
"contribute.md",
|
||||
"media.md"
|
||||
],
|
||||
"folderOrdersInSidenav": [
|
||||
"research"
|
||||
],
|
||||
"external_links": [
|
||||
{
|
||||
"text": "Specs/RFCs",
|
||||
"url": "https://rfc.vac.dev/",
|
||||
"category": "Resources"
|
||||
},
|
||||
{
|
||||
"text": "Forum",
|
||||
"url": "https://forum.vac.dev/",
|
||||
"category": "Resources"
|
||||
},
|
||||
{
|
||||
"text": "Waku.org",
|
||||
"url": "https://waku.org",
|
||||
"category": "Resources"
|
||||
}
|
||||
|
||||
]
|
||||
},
|
||||
"ds_id": "vac",
|
||||
"seo": {
|
||||
"title": "Vac Research",
|
||||
"description": "Vac - Communication, Privacy, Etc.",
|
||||
"cc": "Vac - Communication, Privacy, Etc",
|
||||
"image": "vac-site-preview-image.png",
|
||||
"url": "https://staging.vac.dev",
|
||||
"social_media": [
|
||||
{
|
||||
"provider": "twitter",
|
||||
"handler": "vacp2p"
|
||||
},
|
||||
{
|
||||
"provider": "discord",
|
||||
"handler": "PQFdubGt6d"
|
||||
},
|
||||
{
|
||||
"provider": "github",
|
||||
"handler": "vacp2p"
|
||||
}
|
||||
]
|
||||
},
|
||||
"markdown": {
|
||||
"autoEmbedYoutube": false
|
||||
}
|
||||
}
|
||||
|
|
@ -0,0 +1,65 @@
|
|||
/** @type {import('@acid-info/logos-docusaurus-theme').ThemeOptions['docs'][string]['content']['authors']} */
|
||||
const authors = [
|
||||
{
|
||||
key: 'circe',
|
||||
name: 'Circe',
|
||||
twitter: 'vacp2p',
|
||||
github: 'thecirce',
|
||||
},
|
||||
{
|
||||
key: 'dean',
|
||||
name: 'Dean',
|
||||
twitter: 'DeanEigenmann',
|
||||
github: 'decanus',
|
||||
website: 'https://dean.eigenmann.me',
|
||||
},
|
||||
{
|
||||
key: 'franck',
|
||||
name: 'Franck',
|
||||
twitter: 'fryorcraken',
|
||||
github: 'fryorcraken',
|
||||
},
|
||||
{
|
||||
key: 'hanno',
|
||||
name: 'Hanno Cornelius',
|
||||
twitter: '4aelius',
|
||||
github: 'jm-clius',
|
||||
},
|
||||
{
|
||||
key: 'kaiserd',
|
||||
name: 'Daniel',
|
||||
github: 'kaiserd',
|
||||
},
|
||||
{
|
||||
key: 'oskarth',
|
||||
name: 'Oskar',
|
||||
twitter: 'oskarth',
|
||||
github: 'oskarth',
|
||||
},
|
||||
{
|
||||
key: 'rramos',
|
||||
name: 'Richard',
|
||||
twitter: 'richardramos_me',
|
||||
github: 'richard-ramos',
|
||||
website: 'https://richard-ramos.github.io/',
|
||||
},
|
||||
{
|
||||
key: 's1fr0',
|
||||
name: 's1fr0',
|
||||
github: 's1fr0',
|
||||
},
|
||||
{
|
||||
key: 'sanaz',
|
||||
name: 'Sanaz',
|
||||
twitter: 'sanaz2016',
|
||||
github: 'staheri14',
|
||||
},
|
||||
{
|
||||
key: 'sanaz',
|
||||
name: 'Sanaz',
|
||||
twitter: 'sanaz2016',
|
||||
github: 'staheri14',
|
||||
},
|
||||
]
|
||||
|
||||
module.exports = authors
|
||||
|
|
@ -3,12 +3,19 @@ title: "P2P Data Sync for Mobile"
|
|||
date: 2019-07-19 12:00:00
|
||||
author: oskarth
|
||||
published: true
|
||||
permalink: /p2p-data-sync-for-mobile
|
||||
slug: p2p-data-sync-for-mobile
|
||||
categories: research
|
||||
summary: A research log. Reliable and decentralized, pick two.
|
||||
image: /img/mvds_interactive.png
|
||||
|
||||
toc_min_heading_level: 2
|
||||
toc_max_heading_level: 5
|
||||
---
|
||||
|
||||
import { DocMetadata } from '@site/src/components/mdx'
|
||||
|
||||
<DocMetadata />
|
||||
|
||||
Together with decanus, I've been working on the problem of data sync lately.
|
||||
|
||||
In building p2p messaging systems, one problem you quickly come across is the problem of reliably transmitting data. If there's no central server with high availability guarantees, you can't meaningfully guarantee that data has been transmitted. One way of solving this problem is through a synchronization protocol.
|
||||
|
|
@ -5,11 +5,15 @@ title: "Vac - A Rough Overview"
|
|||
date: 2019-08-02 12:00:00
|
||||
author: oskarth
|
||||
published: true
|
||||
permalink: /vac-overview
|
||||
slug: vac-overview
|
||||
categories: research
|
||||
summary: Vac is a modular peer-to-peer messaging stack, with a focus on secure messaging. Overview of terms, stack and open problems.
|
||||
---
|
||||
|
||||
import { DocMetadata } from '@site/src/components/mdx'
|
||||
|
||||
<DocMetadata />
|
||||
|
||||
Vac is a **modular peer-to-peer messaging stack, with a focus on secure messaging**. What does that mean? Let's unpack it a bit.
|
||||
|
||||
## Basic terms
|
||||
|
|
@ -5,12 +5,16 @@ title: "P2P Data Sync with a Remote Log"
|
|||
date: 2019-10-04 12:00:00
|
||||
author: oskarth
|
||||
published: true
|
||||
permalink: /remote-log
|
||||
slug: remote-log
|
||||
categories: research
|
||||
summary: A research log. Asynchronous P2P messaging? Remote logs to the rescue!
|
||||
image: /img/remote-log.png
|
||||
---
|
||||
|
||||
import { DocMetadata } from '@site/src/components/mdx'
|
||||
|
||||
<DocMetadata />
|
||||
|
||||
A big problem when doing end-to-end data sync between mobile nodes is that most devices are offline most of the time. With a naive approach, you quickly run into issues of 'ping-pong' behavior, where messages have to be constantly retransmitted. We saw some basic calculations of what this bandwidth multiplier looks like in a [previous post](https://vac.dev/p2p-data-sync-for-mobile).
|
||||
|
||||
While you could do some background processing, this is really battery-draining, and on iOS these capabilities are limited. A better approach instead is to loosen the constraint that two nodes need to be online at the same time. How do we do this? There are two main approaches, one is the *store and forward model*, and the other is a *remote log*.
|
||||
|
|
@ -5,13 +5,20 @@ title: "Feasibility Study: Semaphore rate limiting through zkSNARKs"
|
|||
date: 2019-11-08 12:00:00
|
||||
author: oskarth
|
||||
published: true
|
||||
permalink: /feasibility-semaphore-rate-limiting-zksnarks
|
||||
slug: feasibility-semaphore-rate-limiting-zksnarks
|
||||
categories: research
|
||||
summary: A research log. Zero knowledge signaling as a rate limiting mechanism to prevent spam in p2p networks.
|
||||
image: /img/peacock-signaling.jpg
|
||||
discuss: https://forum.vac.dev/t/discussion-feasibility-study-semaphore-rate-limiting-through-zksnarks/21
|
||||
|
||||
toc_min_heading_level: 2
|
||||
toc_max_heading_level: 5
|
||||
---
|
||||
|
||||
import { DocMetadata } from '@site/src/components/mdx'
|
||||
|
||||
<DocMetadata />
|
||||
|
||||
**tldr: Moon math promising for solving spam in Whisper, but to get there we need to invest more in performance work and technical upskilling.**
|
||||
|
||||
## Motivating problem
|
||||
|
|
@ -5,13 +5,17 @@ title: "Fixing Whisper with Waku"
|
|||
date: 2019-12-03 12:00:00
|
||||
author: oskarth
|
||||
published: true
|
||||
permalink: /fixing-whisper-with-waku
|
||||
slug: fixing-whisper-with-waku
|
||||
categories: research
|
||||
summary: A research log. Why Whisper doesn't scale and how to fix it.
|
||||
image: /img/whisper_scalability.png
|
||||
discuss: https://forum.vac.dev/t/discussion-fixing-whisper-with-waku/27
|
||||
---
|
||||
|
||||
import { DocMetadata } from '@site/src/components/mdx'
|
||||
|
||||
<DocMetadata />
|
||||
|
||||
This post will introduce Waku. Waku is a fork of Whisper that attempts to
|
||||
addresses some of Whisper's shortcomings in an iterative fashion. We will also
|
||||
introduce a theoretical scaling model for Whisper that shows why it doesn't
|
||||
|
|
@ -5,13 +5,17 @@ title: "Waku Update"
|
|||
date: 2020-02-14 12:00:00
|
||||
author: oskarth
|
||||
published: true
|
||||
permalink: /waku-update
|
||||
slug: waku-update
|
||||
categories: research
|
||||
summary: A research log. What's the current state of Waku? How many users does it support? What are the bottlenecks? What's next?
|
||||
image: /img/waku_infrastructure_sky.jpg
|
||||
discuss: https://forum.vac.dev/t/waku-update-where-are-we-at/34
|
||||
---
|
||||
|
||||
import { DocMetadata } from '@site/src/components/mdx'
|
||||
|
||||
<DocMetadata />
|
||||
|
||||
Waku is our fork of Whisper where we address the shortcomings of Whisper in an iterative manner. We've seen a in [previous post](https://vac.dev/fixing-whisper-with-waku) that Whisper doesn't scale, and why. In this post we'll talk about what the current state of Waku is, how many users it can support, and future plans.
|
||||
|
||||
## Current state
|
||||
|
|
@ -5,11 +5,15 @@ title: "DNS Based Discovery"
|
|||
date: 2020-02-7 12:00:00
|
||||
author: dean
|
||||
published: true
|
||||
permalink: /dns-based-discovery
|
||||
slug: dns-based-discovery
|
||||
categories: research
|
||||
summary: A look at EIP-1459 and the benefits of DNS based discovery.
|
||||
---
|
||||
|
||||
import { DocMetadata } from '@site/src/components/mdx'
|
||||
|
||||
<DocMetadata />
|
||||
|
||||
Discovery in p2p networks is the process of how nodes find each other and specific resources they are looking for. Popular discovery protocols, such as [Kademlia](https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf) which utilizes a [distributed hash table](https://en.wikipedia.org/wiki/Distributed_hash_table) or DHT, are highly inefficient for resource restricted devices. These methods use short connection windows, and it is quite battery intensive to keep establishing connections. Additionally, we cannot expect a mobile phone for example to synchronize an entire DHT using cellular data.
|
||||
|
||||
Another issue is how we do the initial bootstrapping. In other words, how does a client find its first node to then discover the rest of the network? In most applications, including Status right now, this is done with a [static list of nodes](https://specs.status.im/spec/1#bootstrapping) that a client can connect to.
|
||||
|
|
@ -5,13 +5,17 @@ title: "What Would a WeChat Replacement Need?"
|
|||
date: 2020-04-16 12:00:00
|
||||
author: oskarth
|
||||
published: true
|
||||
permalink: /wechat-replacement-need
|
||||
slug: wechat-replacement-need
|
||||
categories: research
|
||||
summary: What would a self-sovereign, private, censorship-resistant and open alternative to WeChat look like?
|
||||
image: /img/tianstatue.jpg
|
||||
discuss: https://forum.vac.dev/t/discussion-what-would-a-wechat-replacement-need/42
|
||||
---
|
||||
|
||||
import { DocMetadata } from '@site/src/components/mdx'
|
||||
|
||||
<DocMetadata />
|
||||
|
||||
What would it take to replace WeChat? More specifically, what would a self-sovereign, private, censorship-resistant and open alternative look like? One that allows people to communicate, coordinate and transact freely.
|
||||
|
||||
## Background
|
||||
|
|
@ -5,12 +5,16 @@ title: "Feasibility Study: Discv5"
|
|||
date: 2020-04-27 12:00:00
|
||||
author: dean
|
||||
published: true
|
||||
permalink: /feasibility-discv5
|
||||
slug: feasibility-discv5
|
||||
categories: research
|
||||
summary: Looking at discv5 and the theoretical numbers behind finding peers.
|
||||
discuss: https://discuss.status.im/t/discv5-feasibility-study/1632
|
||||
---
|
||||
|
||||
import { DocMetadata } from '@site/src/components/mdx'
|
||||
|
||||
<DocMetadata />
|
||||
|
||||
> Disclaimer: some of the numbers found in this write-up could be inaccurate. They are based on the current understanding of theoretical parts of the protocol itself by the author and are meant to provide a rough overview rather than bindable numbers.
|
||||
|
||||
This post serves as a more authoritative overview of the discv5 study, for a discussionary post providing more context make sure to check out the corresponding [discuss post](https://discuss.status.im/t/discv5-feasibility-study/1632). Additionally, if you are unfamiliar with discv5, check out my previous write-up: ["From Kademlia to Discv5"](https://vac.dev/kademlia-to-discv5).
|
||||
|
|
@ -5,11 +5,15 @@ title: "From Kademlia to Discv5"
|
|||
date: 2020-04-9 16:00:00
|
||||
author: dean
|
||||
published: true
|
||||
permalink: /kademlia-to-discv5
|
||||
slug: kademlia-to-discv5
|
||||
categories: research
|
||||
summary: A quick history of discovery in peer-to-peer networks, along with a look into discv4 and discv5, detailing what they are, how they work and where they differ.
|
||||
---
|
||||
|
||||
import { DocMetadata } from '@site/src/components/mdx'
|
||||
|
||||
<DocMetadata />
|
||||
|
||||
If you've been working on Ethereum or adjacent technologies you've probably heard of [discv4](https://github.com/ethereum/devp2p/blob/master/discv4.md) or [discv5](https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md). But what are they actually? How do they work and what makes them different? To answer these questions, we need to start at the beginning, so this post will assume that there is little knowledge on the subject so the post should be accessible for anyone.
|
||||
|
||||
## The Beginning
|
||||
|
|
@ -5,18 +5,22 @@ title: "What's the Plan for Waku v2?"
|
|||
date: 2020-07-01 12:00:00
|
||||
author: oskarth
|
||||
published: true
|
||||
permalink: /waku-v2-plan
|
||||
slug: waku-v2-plan
|
||||
categories: research
|
||||
summary: Read about our plans for Waku v2, moving to libp2p, better routing, adaptive nodes and accounting!
|
||||
image: /img/status_scaling_model_fig4.png
|
||||
discuss: https://forum.vac.dev/t/waku-version-2-pitch/52
|
||||
---
|
||||
|
||||
import { DocMetadata } from '@site/src/components/mdx'
|
||||
|
||||
<DocMetadata />
|
||||
|
||||
**tldr: The Waku network is fragile and doesn't scale. Here's how to solve it.**
|
||||
|
||||
*NOTE: This post was originally written with Status as a primary use case in mind, which reflects how we talk about some problems here. However, Waku v2 is a general-purpose private p2p messaging protocol, especially for people running in resource restricted environments.*
|
||||
|
||||
# Problem
|
||||
## Problem
|
||||
|
||||
The Waku network is fragile and doesn't scale.
|
||||
|
||||
|
|
@ -57,7 +61,7 @@ Doing this means the Waku network will be able to scale, and doing so in the rig
|
|||
- deliberately ignore most of our principles
|
||||
- risk the network being shut down when we run out of cash
|
||||
|
||||
# Appetite
|
||||
## Appetite
|
||||
|
||||
Our initial risk appetite for this is 6 weeks for a small team.
|
||||
|
||||
|
|
@ -65,7 +69,7 @@ The idea is that we want to make tangible progress towards the goal in a limited
|
|||
|
||||
It is likely some elements of a complete solution will be done separately. See later sections for that.
|
||||
|
||||
# Solution
|
||||
## Solution
|
||||
|
||||
There are two main parts of the solution. One is to reduce amplification factors, and the other is incentivization to get more user run full nodes with desktop, etc.
|
||||
|
||||
|
|
@ -127,7 +131,7 @@ Basically what mailservers are currently doing. This likely looks slightly diffe
|
|||
|
||||
Also see section below on adaptive nodes and capabilities.
|
||||
|
||||
### 6. Waku v1 <> Libp2p bridge
|
||||
### 6. Waku v1 <\> Libp2p bridge
|
||||
|
||||
To make the transition complete, there has to a be bridge mode between current Waku and libp2p. This is similar to what was done for Whisper and Waku, and allows any nodes in the network to upgrade to Waku v2 at their leisure. For example, this would likely look different for Core, Desktop, Research and developers.
|
||||
|
||||
|
|
@ -240,7 +244,7 @@ For full nodes:
|
|||
|
||||
Can be done after phase 2 if so desired. Basically integrate payments based on accounting and policy.
|
||||
|
||||
# Out of scope
|
||||
## Out of scope
|
||||
|
||||
1. We assume the Status Base model requirements are accurate.
|
||||
2. We assume Core will improve retention rates.
|
||||
|
|
@ -5,16 +5,20 @@ title: "Waku v2 Update"
|
|||
date: 2020-09-28 12:00:00
|
||||
author: oskarth
|
||||
published: true
|
||||
permalink: /waku-v2-update
|
||||
slug: waku-v2-update
|
||||
categories: research
|
||||
summary: A research log. Read on to find out what is going on with Waku v2, a messaging protocol. What has been happening? What is coming up next?
|
||||
image: /img/vac.png
|
||||
discuss: https://forum.vac.dev/t/discussion-waku-v2-update/56
|
||||
---
|
||||
|
||||
import { DocMetadata } from '@site/src/components/mdx'
|
||||
|
||||
<DocMetadata />
|
||||
|
||||
It has been a while since the last post. It is time for an update on Waku v2. Aside from getting more familiar with libp2p (specifically nim-libp2p) and some vacation, what have we been up to? In this post we'll talk about what we've gotten done since last time, and briefly talk about immediate next steps and future. But first, a recap.
|
||||
|
||||
# Recap
|
||||
## Recap
|
||||
|
||||
In the last post ([Waku v2 plan](https://vac.dev/waku-v2-plan)) we explained the rationale of Waku v2 - the current Waku network is fragile and doesn't scale. To solve this, Waku v2 aims to reduce amplification factors and get more user run nodes. We broke the work down into three separate tracks.
|
||||
|
||||
|
|
@ -22,9 +26,9 @@ In the last post ([Waku v2 plan](https://vac.dev/waku-v2-plan)) we explained the
|
|||
2. Track 2 - Better routing
|
||||
3. Track 3 - Accounting and user-run nodes
|
||||
|
||||
As well as various rough components for each track. The primary initial focus is track 1. This means things like: moving to FloodSub, simplify the protocol, core integration, topic interest behavior, historical message caching, and Waku v1<>v2 bridge.
|
||||
As well as various rough components for each track. The primary initial focus is track 1. This means things like: moving to FloodSub, simplify the protocol, core integration, topic interest behavior, historical message caching, and Waku v1<\>v2 bridge.
|
||||
|
||||
# Current state
|
||||
## Current state
|
||||
|
||||
Let's talk about the state of specs and our main implementation nim-waku. Then we'll go over our recent testnet, Nangang, and finish off with a Web PoC.
|
||||
|
||||
|
|
@ -64,7 +68,7 @@ Using the current stack, with nim-waku, would require quite a lot of ground work
|
|||
|
||||
It consists of a brower implementation, a NodeJS implementation and a bootstrap server that acts as a signaling server for WebRTC. It is largely a bastardized version of GossipSub, and while it isn't completely to spec, it does allow messages originating from a browser to eventually end up at a nim-waku node, and vice versa. Which is pretty cool.
|
||||
|
||||
# Coming up
|
||||
## Coming up
|
||||
|
||||
Now that we know what the current state is, what is still missing? what are the next steps?
|
||||
|
||||
|
|
@ -5,13 +5,17 @@ title: "[Talk] Vac, Waku v2 and Ethereum Messaging"
|
|||
date: 2020-11-10 12:00:00
|
||||
author: oskarth
|
||||
published: true
|
||||
permalink: /waku-v2-ethereum-messaging
|
||||
slug: waku-v2-ethereum-messaging
|
||||
categories: research
|
||||
summary: Talk from Taipei Ethereum Meetup. Read on to find out about our journey from Whisper to Waku v2, as well as how Waku v2 can be useful for Etherum Messaging.
|
||||
image: /img/taipei_ethereum_meetup_slide.png
|
||||
discuss: https://forum.vac.dev/t/discussion-talk-vac-waku-v2-and-ethereum-messaging/60
|
||||
---
|
||||
|
||||
import { DocMetadata } from '@site/src/components/mdx'
|
||||
|
||||
<DocMetadata />
|
||||
|
||||
*The following post is a transcript of the talk given at the [Taipei Ethereum meetup, November 5](https://www.meetup.com/Taipei-Ethereum-Meetup/events/274033344/). There is also a [video recording]( https://www.youtube.com/watch?v=lUDy1MoeYnI).*
|
||||
|
||||
---
|
||||
|
|
@ -5,13 +5,21 @@ title: "Privacy-preserving p2p economic spam protection in Waku v2"
|
|||
date: 2021-03-05 12:00:00
|
||||
author: sanaztaheri
|
||||
published: true
|
||||
permalink: /rln-relay
|
||||
categories: research
|
||||
slug: rln-relay
|
||||
categories: reserach
|
||||
summary: This post is going to give you an overview of how spam protection can be achieved in Waku Relay through rate-limiting nullifiers. We will cover a summary of spam-protection methods in centralized and p2p systems, and the solution overview and details of the economic spam-protection method. The open issues and future steps are discussed in the end.
|
||||
image: /img/rain.png
|
||||
discuss: https://forum.vac.dev/t/privacy-preserving-p2p-economic-spam-protection-in-waku-v2-with-rate-limiting-nullfiers/66
|
||||
|
||||
toc_min_heading_level: 2
|
||||
toc_max_heading_level: 5
|
||||
---
|
||||
# Introduction
|
||||
|
||||
import { DocMetadata } from '@site/src/components/mdx'
|
||||
|
||||
<DocMetadata />
|
||||
|
||||
## Introduction
|
||||
This post is going to give you an overview of how spam protection can be achieved in Waku Relay protocol[^2] through Rate-Limiting Nullifiers[^3] [^4] or RLN for short.
|
||||
|
||||
Let me give a little background about Waku(v2)[^1]. Waku is a privacy-preserving peer-to-peer (p2p) messaging protocol for resource-restricted devices. Being p2p means that Waku relies on **No** central server. Instead, peers collaboratively deliver messages in the network. Waku uses GossipSub[^16] as the underlying routing protocol (as of the writeup of this post). At a high level, GossipSub is based on publisher-subscriber architecture. That is, *peers, congregate around topics they are interested in and can send messages to topics. Each message gets delivered to all peers subscribed to the topic*. In GossipSub, a peer has a constant number of direct connections/neighbors. In order to publish a message, the author forwards its message to a subset of neighbors. The neighbors proceed similarly till the message gets propagated in the network of the subscribed peers. The message publishing and routing procedures are part of the Waku Relay[^17] protocol.
|
||||
|
|
@ -63,12 +71,12 @@ We set M to 1 for now, but this can be any arbitrary value. You may be thinking
|
|||
|
||||
The remainder of this post is all about the story of how to enforce this limit on each user's messaging rate as well as how to impose the financial cost when the limit gets violated. This brings us to the Rate Limiting Nullifiers and how we integrate this technique into Waku v2 (in specific the Waku Relay protocol) to protect our valuable users against spammers.
|
||||
|
||||
# Technical Terms
|
||||
## Technical Terms
|
||||
**Zero-knowledge proof**: Zero-knowledge proof (ZKP)[^14] allows a *prover* to show a *verifier* that they know something, without revealing what that something is. This means you can do the trust-minimized computation that is also privacy-preserving. As a basic example, instead of showing your ID when going to a bar you simply give them proof that you are over 18, without showing the doorman your id. In this write-up, by ZKP we essentially mean zkSNARK[^15] which is one of the many types of ZKPs.
|
||||
|
||||
**Threshold Secret Sharing Scheme**: (m,n) Threshold secret-sharing is a method by which you can split a secret value s into n pieces in a way that the secret s can be reconstructed by having m pieces (m <= n). The economic-incentive spam protection utilizes a (2,n) secret sharing realized by Shamir Secret Sharing Scheme[^13].
|
||||
|
||||
# Overview: Economic-Incentive Spam protection through Rate Limiting Nullifiers
|
||||
## Overview: Economic-Incentive Spam protection through Rate Limiting Nullifiers
|
||||
**Context**: We started the idea of economic-incentive spam protection more than a year ago and conducted a feasibility study to identify blockers and unknowns. The results are published in our prior [post](https://vac.dev/feasibility-semaphore-rate-limiting-zksnarks). Since then major progress has been made and the prior identified blockers that are listed below are now addressed. Kudos to [Barry WhiteHat](https://github.com/barryWhiteHat), [Onur Kilic](https://github.com/kilic), [Koh Wei Jie](https://github.com/weijiekoh/perpetualpowersoftau) for all of their hard work, research, and development which made this progress possible.
|
||||
- the proof time[^22] which was initially in the order of minutes ~10 mins and now is almost 0.5 seconds
|
||||
- the prover key size[^21] which was initially ~110MB and now is ~3.9MB
|
||||
|
|
@ -86,7 +94,7 @@ Now that you have more context, let's see how the final solution works. The fund
|
|||
|
||||
A high-level overview of the economic spam protection is shown in Figure 1.
|
||||
|
||||
# Flow
|
||||
## Flow
|
||||
In this section, we describe the flow of the economic-incentive spam detection mechanism from the viewpoint of a single peer. An overview of this flow is provided in Figure 3.
|
||||
|
||||
## Setup and Registration
|
||||
|
|
@ -97,7 +105,7 @@ The following relation holds between the `sk` and `pk` i.e., `pk = H(sk)` where
|
|||
|
||||
|
||||
## Maintaining the membership Merkle Tree
|
||||
The ZKP of membership that we mentioned before relies on the representation of the entire group as a [Merkle Tree](). The tree construction and maintenance is delegated to the peers (the initial idea was to keep the tree on the chain as part of the contract, however, the cost associated with member deletion and insertion was high and unreasonable, please see [Feasibility and Open Issues](#Feasibility-and-Open-Issues) for more details). As such, each peer needs to build the tree locally and sync itself with the contract updates (peer insertion and deletion) to mirror them on its tree.
|
||||
The ZKP of membership that we mentioned before relies on the representation of the entire group as a [Merkle Tree](/#). The tree construction and maintenance is delegated to the peers (the initial idea was to keep the tree on the chain as part of the contract, however, the cost associated with member deletion and insertion was high and unreasonable, please see [Feasibility and Open Issues](#Feasibility-and-Open-Issues) for more details). As such, each peer needs to build the tree locally and sync itself with the contract updates (peer insertion and deletion) to mirror them on its tree.
|
||||
Two pieces of information of the tree are important as they enable peers to generate zero-knowledge proofs. One is the root of the tree and the other is the membership proof (or the authentication path). The tree root is public information whereas the membership proof is private data (or more precisely the index of the peer in the tree).
|
||||
|
||||
## Publishing
|
||||
|
|
@ -134,7 +142,7 @@ In order to enable local spam detection and slashing, routing peers MUST record
|
|||
An overview of the slashing procedure is provided in Figure 3.
|
||||
|
||||
|
||||
# Feasibility and Open Issues
|
||||
## Feasibility and Open Issues
|
||||
We've come a long way since a year ago, blockers resolved, now we have implemented it end-to-end. We learned lot and could identify further issues and unknowns some of which are blocking getting to production. The summary of the identified issues are presented below.
|
||||
|
||||
## Storage overhead per peer
|
||||
|
|
@ -146,7 +154,7 @@ Currently, the cost associated with RLN-Relay membership is around 30 USD[^10].
|
|||
## Exceeding the messaging rate via multiple registrations
|
||||
While the economic-incentive solution has an economic incentive to discourage spamming, we should note that there is still **expensive attack(s)**[^23] that a spammer can launch to break the messaging rate limit. That is, the attacker can pay for multiple legit registrations e.g., k, hence being able to publish k messages per epoch. We believe that the higher the membership fee is, the less probable would be such an attack, hence a stronger level of spam-protection can be achieved. Following this argument, the high fee associated with the membership (which we listed above as an open problem) can indeed be contributing to a better protection level.
|
||||
|
||||
# Conclusion and Future Steps
|
||||
## Conclusion and Future Steps
|
||||
As discussed in this post, Waku RLN Relay can achieve a privacy-preserving economic spam protection through rate-limiting nullifiers. The idea is to financially discourage peers from publishing more than one message per epoch. In specific, exceeding the messaging rate results in a financial charge. Those who violate this rule are called spammers and their messages are spam. The identification of spammers does not rely on any central entity. Also, the financial punishment of spammers is cryptographically guaranteed.
|
||||
In this solution, privacy is guaranteed since: 1) Peers do not have to disclose any piece of personally identifiable information in any phase i.e., neither in the registration nor in the messaging phase 2) Peers can prove that they have not exceeded the messaging rate in a zero-knowledge manner and without leaving any trace to their membership accounts.
|
||||
Furthermore, all the computations are light hence this solution fits the heterogenous p2p messaging system. Note that the zero-knowledge proof parts are handled through zkSNARKs and the benchmarking result can be found in the RLN benchmark report[^5].
|
||||
|
|
@ -159,10 +167,10 @@ We are still at the PoC level, and the development is in progress. As our future
|
|||
- In line with the storage optimization, the full-node light-node structure is another path to follow.
|
||||
- Another possible improvement is to replace the membership contract with a distributed group management scheme e.g., through distributed hash tables. This is to address possible performance issues that the interaction with the Ethereum blockchain may cause. For example, the registration transactions are subject to delay as they have to be mined before being visible in the state of the membership contract. This means peers have to wait for some time before being able to publish any message.
|
||||
|
||||
# Acknowledgement
|
||||
## Acknowledgement
|
||||
Thanks to Onur Kılıç for his explanation and pointers and for assisting with development and runtime issues. Also thanks to Barry Whitehat for his time and insightful comments. Special thanks to Oskar Thoren for his constructive comments and his guides during the development of this PoC and the writeup of this post.
|
||||
|
||||
# References
|
||||
## References
|
||||
|
||||
[^1]: Waku v2: https://rfc.vac.dev/spec/10/
|
||||
[^2]: RLN-Relay specification: https://rfc.vac.dev/spec/17/
|
||||
|
|
@ -5,13 +5,17 @@ title: "Presenting JS-Waku: Waku v2 in the Browser"
|
|||
date: 2021-06-04 12:00:00
|
||||
author: franck
|
||||
published: true
|
||||
permalink: /presenting-js-waku
|
||||
slug: presenting-js-waku
|
||||
categories: platform
|
||||
summary: "JS-Waku is bringing Waku v2 to the browser. Learn what we achieved so far and what is next in our pipeline!"
|
||||
image: /img/js-waku-gist.png
|
||||
discuss: https://forum.vac.dev/t/discussion-presenting-js-waku-waku-v2-in-the-browser/81
|
||||
---
|
||||
|
||||
import { DocMetadata } from '@site/src/components/mdx'
|
||||
|
||||
<DocMetadata />
|
||||
|
||||
For the past 3 months, we have been working on bringing Waku v2 to the browser.
|
||||
Our aim is to empower dApps with Waku v2, and it led to the creation of a new library.
|
||||
We believe now is good time to introduce it!
|
||||
|
|
@ -5,13 +5,17 @@ title: "[Talk at COSCUP] Vac, Waku v2 and Ethereum Messaging"
|
|||
date: 2021-08-06 12:00:00
|
||||
author: oskarth
|
||||
published: true
|
||||
permalink: /waku-v2-ethereum-coscup
|
||||
slug: waku-v2-ethereum-coscup
|
||||
categories: research
|
||||
summary: Learn more about Waku v2, its origins, goals, protocols, implementation and ongoing research. Understand how it is used and how it can be useful for messaging in Ethereum.
|
||||
image: /img/coscup-waku/talk.png
|
||||
discuss: https://forum.vac.dev/t/discussion-talk-at-coscup-vac-waku-v2-and-ethereum-messaging/95
|
||||
---
|
||||
|
||||
import { DocMetadata } from '@site/src/components/mdx'
|
||||
|
||||
<DocMetadata />
|
||||
|
||||
*This is the English version of a talk originally given in Chinese at COSCUP in Taipei.*
|
||||
|
||||
[video recording with Chinese and English subtitles.](https://www.youtube.com/watch?v=s0ATpQ4_XFc)
|
||||
|
|
@ -214,7 +218,7 @@ WalletConnect v2 is currently in late alpha using Waku v2.
|
|||
- Gasless voting and vote aggregation off-chain
|
||||
- Dapp games using Waku as player discovery mechanism
|
||||
- Send encrypted message to someone with an Ethereum key
|
||||
- <Your dapp here>
|
||||
- <Your dapp here>
|
||||
|
||||
These are all things that are in progress / proof of concept stage.
|
||||
|
||||
|
|
@ -5,13 +5,17 @@ title: "Waku v1 vs Waku v2: Bandwidth Comparison"
|
|||
date: 2021-11-03 10:00:00
|
||||
author: hanno
|
||||
published: true
|
||||
permalink: /waku-v1-v2-bandwidth-comparison
|
||||
slug: waku-v1-v2-bandwidth-comparison
|
||||
categories: research
|
||||
summary: A local comparison of bandwidth profiles showing significantly improved scalability in Waku v2 over Waku v1.
|
||||
image: /img/waku1-vs-waku2/waku1-vs-waku2-overall-network-size.png
|
||||
discuss: https://forum.vac.dev/t/discussion-waku-v1-vs-waku-v2-bandwidth-comparison/110
|
||||
---
|
||||
|
||||
import { DocMetadata } from '@site/src/components/mdx'
|
||||
|
||||
<DocMetadata />
|
||||
|
||||
## Background
|
||||
|
||||
The [original plan](https://vac.dev/waku-v2-plan) for Waku v2 suggested theoretical improvements in resource usage over Waku v1,
|
||||
|
|
@ -5,13 +5,17 @@ title: "Opinion: Pseudo-ethics in the Surveillance Tech Industry"
|
|||
date: 2021-12-03 10:00:00
|
||||
author: circe
|
||||
published: true
|
||||
permalink: /ethics-surveillance-tech
|
||||
slug: ethics-surveillance-tech
|
||||
categories: research
|
||||
summary: A look at typical ethical shortfalls in the global surveillance tech industry.
|
||||
image: /img/vac.png
|
||||
discuss:
|
||||
---
|
||||
|
||||
import { DocMetadata } from '@site/src/components/mdx'
|
||||
|
||||
<DocMetadata />
|
||||
|
||||
_This is an opinion piece by pseudonymous contributor, circe._
|
||||
|
||||
## Preface
|
||||
|
|
@ -5,13 +5,19 @@ title: "Introducing nwaku"
|
|||
date: 2022-04-12 10:00:00
|
||||
author: hanno
|
||||
published: true
|
||||
permalink: /introducing-nwaku
|
||||
slug: introducing-nwaku
|
||||
categories: research
|
||||
summary: Introducing nwaku, a Nim-based Waku v2 client, including a summary of recent developments and preview of current and future focus areas.
|
||||
image: /img/vac.png
|
||||
discuss: https://forum.vac.dev/
|
||||
toc_min_heading_level: 2
|
||||
toc_max_heading_level: 5
|
||||
---
|
||||
|
||||
import { DocMetadata } from '@site/src/components/mdx'
|
||||
|
||||
<DocMetadata />
|
||||
|
||||
## Background
|
||||
|
||||
If you've been following our [research log](https://vac.dev/research-log/),
|
||||
|
|
@ -5,7 +5,7 @@ title: "Waku v2 Ambient Peer Discovery"
|
|||
date: 2022-05-09 10:00:00
|
||||
author: kaiserd
|
||||
published: true
|
||||
permalink: /wakuv2-apd
|
||||
slug: wakuv2-apd
|
||||
categories: research
|
||||
summary: Introducing and discussing ambient peer discovery methods currently used by Waku v2, as well as future plans in this area.
|
||||
image: /img/waku_v2_discv5_random_walk_estimation.svg
|
||||
|
|
@ -13,6 +13,10 @@ discuss: https://forum.vac.dev/t/discussion-waku-v2-ambient-peer-discovery/133
|
|||
_includes: [math]
|
||||
---
|
||||
|
||||
import { DocMetadata } from '@site/src/components/mdx'
|
||||
|
||||
<DocMetadata />
|
||||
|
||||
[Waku v2](https://rfc.vac.dev/spec/10/) comprises a set of modular protocols for secure, privacy preserving communication.
|
||||
Avoiding centralization, these protocols exchange messages over a P2P network layer.
|
||||
In order to build a P2P network, participating nodes first have to discover peers within this network.
|
||||
|
|
@ -160,7 +164,7 @@ $$P(W^q) = 1 - (1-p/100)^{kq} \iff q = log_{(1-p/100)^k}(1-P(W^q))$$
|
|||
|
||||
Figure 1 shows a log-log plot for $P(W^q) = 90\%$.
|
||||
|
||||
![Figure 1: log-log plot showing the number of queries necessary to retrieve a Waku v2 node with a probability of 90% in relation to the Waku v2 node concentration in the network.](/img/waku_v2_discv5_random_walk_estimation.svg")
|
||||
|
||||
|
||||
Assuming $p=0.1$, we would need
|
||||
|
||||
|
|
@ -5,14 +5,19 @@ title: "Noise handshakes as key-exchange mechanism for Waku"
|
|||
date: 2022-05-17 10:00:00
|
||||
author: s1fr0
|
||||
published: true
|
||||
permalink: /wakuv2-noise
|
||||
slug: wakuv2-noise
|
||||
categories: research
|
||||
summary: We provide an overview of the Noise Protocol Framework as a tool to design efficient and secure key-exchange mechanisms in Waku2.
|
||||
image: /img/noise/NM.png
|
||||
discuss: https://forum.vac.dev/t/discussion-noise-handshakes-as-key-exchange-mechanism-for-waku/137
|
||||
_includes: [math]
|
||||
---
|
||||
# Introduction
|
||||
|
||||
import { DocMetadata } from '@site/src/components/mdx'
|
||||
|
||||
<DocMetadata />
|
||||
|
||||
## Introduction
|
||||
In this post we will provide an overview of how [Waku v2](https://rfc.vac.dev/spec/10/) users can adopt [Noise handshakes](http://www.noiseprotocol.org/noise.html) to agree on cryptographic keys used to securely encrypt messages.
|
||||
|
||||
This process belongs to the class of _key-exchange_ mechanisms, consisting of all those protocols that, with different levels of complexity and security guarantees, allow two parties to publicly agree on a secret without letting anyone else know what this secret is.
|
||||
|
|
@ -72,7 +77,7 @@ Just to provide an example, let us suppose Alice and Bob perform the following c
|
|||
|
||||
In this protocol, if Alice's and/or Bob's static keys get compromised, it would not possible to derive the final secret key $\tilde{k}$, since at least one ephemeral key among $E_A$ and $E_B$ has to be compromised too in order to recover the secret $E_{AB}$. Furthermore, since Alice's and Bob's long-term static keys are encrypted, an attacker intercepting exchanged (encrypted) public keys will not be able to link such communication to Alice or Bob, unless one of the ephemeral key is compromised (and, even in such case, none of the messages encrypted under the key $\tilde{k}$ can be decrypted).
|
||||
|
||||
# The Noise Protocol Framework
|
||||
## The Noise Protocol Framework
|
||||
|
||||
In previous section we gave a small intuition on how multiple DH operations over ephemeral and static users' public keys can be combined to create different key-exchange protocols.
|
||||
|
||||
|
|
@ -149,7 +154,7 @@ These two Cipher states are used to encrypt and decrypt all outbound and inbound
|
|||
For more details on processing rules, we refer to [Noise specifications](http://www.noiseprotocol.org/noise.html).
|
||||
|
||||
|
||||
# Supported Noise Handshakes in Waku
|
||||
## Supported Noise Handshakes in Waku
|
||||
|
||||
|
||||
The Noise handshakes we provided support to in Waku address four typical scenarios occurring when an encrypted communication channel between Alice and Bob is going to be created:
|
||||
|
|
@ -231,7 +236,7 @@ The main difference with `XX` is that Alice's and Bob's static keys, when transm
|
|||
|
||||
**Security considerations on identity-hiding (active attacker)**: Alice's static key is encrypted with forward secrecy to an authenticated party for both `XX` and `XXpsk0` handshakes. In `XX`, Bob's static key is encrypted with forward secrecy but is transmitted to a non-authenticated user which can then be an active attacker. In `XXpsk0`, instead, Bob's secret key is protected by forward secrecy to a partially authenticated party (through the pre-shared secret `psk` but not through any static key), provided that `psk` was not previously compromised (in such case identity-hiding properties provided by the `XX` handshake applies).
|
||||
|
||||
# Session Management and Multi-Device Support
|
||||
## Session Management and Multi-Device Support
|
||||
|
||||
When two users complete a Noise handshake, an encryption/decryption session - or _Noise session_ - consisting of two Cipher States is instantiated.
|
||||
|
||||
|
|
@ -261,7 +266,7 @@ In the $NM$ session management scheme, instead, all pairs of Alice's and Bob's d
|
|||
|
||||
For more technical details on how Noise sessions are instantiated and managed within these two mechanisms and the different trade-offs provided by the latter, we refer to [37/WAKU2-NOISE-SESSIONS](https://rfc.vac.dev/spec/37/).
|
||||
|
||||
# Conclusions
|
||||
## Conclusions
|
||||
|
||||
In this post we provided an overview of Noise, a protocol framework for designing Diffie-Hellman based key-exchange mechanisms allowing systematic security and threat model analysis.
|
||||
|
||||
|
|
@ -278,7 +283,7 @@ The available [implementation](https://github.com/status-im/nwaku/tree/master/wa
|
|||
- formalize, implement and test performances of the two proposed $N11M$ and $NM$ session management mechanisms and their suitability for common use-case scenarios;
|
||||
- provide Waku network nodes a native protocol to readily support key-exchanges, strongly-encrypted communication and multi-device session management mechanisms with none-to-little interaction besides applications' connection requests.
|
||||
|
||||
# References
|
||||
## References
|
||||
|
||||
- [6/WAKU1](https://rfc.vac.dev/spec/6/)
|
||||
- [10/WAKU2](https://rfc.vac.dev/spec/10/)
|
||||
|
|
@ -5,14 +5,21 @@ title: "Waku Privacy and Anonymity Analysis Part I: Definitions and Waku Relay"
|
|||
date: 2022-07-22 10:00:00
|
||||
author: kaiserd
|
||||
published: true
|
||||
permalink: /wakuv2-relay-anon
|
||||
slug: wakuv2-relay-anon
|
||||
categories: research
|
||||
summary: Introducing a basic threat model and privacy/anonymity analysis for the Waku v2 relay protocol.
|
||||
image: /img/anonymity_trilemma.svg
|
||||
discuss: https://forum.vac.dev/t/discussion-waku-privacy-and-anonymity-analysis/149
|
||||
_includes: [math]
|
||||
|
||||
toc_min_heading_level: 2
|
||||
toc_max_heading_level: 5
|
||||
---
|
||||
|
||||
import { DocMetadata } from '@site/src/components/mdx'
|
||||
|
||||
<DocMetadata />
|
||||
|
||||
[Waku v2](https://rfc.vac.dev/spec/10/) enables secure, privacy preserving communication using a set of modular P2P protocols.
|
||||
Waku v2 also aims at protecting the user's anonymity.
|
||||
This post is the first in a series about Waku v2 security, privacy, and anonymity.
|
||||
|
|
@ -5,13 +5,17 @@ title: "Building Privacy-Protecting Infrastructure"
|
|||
date: 2022-11-04 12:00:00
|
||||
author: oskarth
|
||||
published: true
|
||||
permalink: /building-privacy-protecting-infrastructure
|
||||
slug: building-privacy-protecting-infrastructure
|
||||
categories: research
|
||||
summary: What is privacy-protecting infrastructure? Why do we need it and how we can build it? We'll look at Waku, the communication layer for Web3. We'll see how it uses ZKPs to incentivize and protect the Waku network. We'll also look at Zerokit, a library that makes it easier to use ZKPs in different environments. After reading this, I hope you'll better understand the importance of privacy-protecting infrastructure and how we can build it.
|
||||
image: /img/building_private_infra_intro.png
|
||||
discuss: https://forum.vac.dev/t/discussion-building-privacy-protecting-infrastructure/161
|
||||
---
|
||||
|
||||
import { DocMetadata } from '@site/src/components/mdx'
|
||||
|
||||
<DocMetadata />
|
||||
|
||||
*This write-up is based on a talk given at DevCon 6 in Bogota, a video can be found [here](https://www.youtube.com/watch?v=CW1DYJifdhs)*
|
||||
|
||||
### Intro
|
||||
|
|
@ -5,7 +5,7 @@ title: "Waku for All Decentralized Applications and Infrastructures"
|
|||
date: 2022-11-08 00:00:00
|
||||
author: franck
|
||||
published: true
|
||||
permalink: /waku-for-all
|
||||
slug: waku-for-all
|
||||
categories: waku, dapp, infrastructure, public good, platform, operator
|
||||
summary: |
|
||||
Waku is an open communication protocol and network. Decentralized apps and infrastructure can use Waku for their
|
||||
|
|
@ -17,7 +17,12 @@ image: /img/black-waku-logo-with-name.png
|
|||
discuss: https://forum.vac.dev/t/discussion-waku-for-all-decentralized-applications-and-infrastructures/163
|
||||
---
|
||||
|
||||
# Background
|
||||
import { DocMetadata } from '@site/src/components/mdx'
|
||||
|
||||
<DocMetadata />
|
||||
|
||||
## Background
|
||||
|
||||
|
||||
We have built Waku to be the communication layer for Web3. Waku is a collection of protocols to chose from for your
|
||||
messaging needs. It enables secure, censorship-resistant, privacy-preserving, spam-protected communication for its user.
|
||||
|
|
@ -51,7 +56,7 @@ and [PoCs](https://github.com/status-iM/gnosis-safe-waku).
|
|||
By discussing with Waku users and watching it being used, we learned a few facts:
|
||||
|
||||
1. The potential use cases for Waku are varied and many:
|
||||
- Wallet <> dApp communication: [WalletConnect](https://medium.com/walletconnect/walletconnect-v2-0-protocol-whats-new-3243fa80d312), [XMTP](https://xmtp.org/docs/dev-concepts/architectural-overview/)
|
||||
- Wallet <> dApp communication: [WalletConnect](https://medium.com/walletconnect/walletconnect-v2-0-protocol-whats-new-3243fa80d312), [XMTP](https://xmtp.org/docs/dev-concepts/architectural-overview/)
|
||||
- Off-chain (and private) marketplace:
|
||||
[RAILGUN](https://twitter.com/RAILGUN_Project/status/1556780629848727552?s=20&t=NEKQJiJAfg5WJqvuF-Ym_Q) &
|
||||
[Decentralized Uber](https://twitter.com/TheBojda/status/1455557282318721026)
|
||||
|
|
@ -89,7 +94,7 @@ From a market perspective, we identified several actors:
|
|||
- contributors: Developers and researchers with interests in decentralization, privacy, censorship-resistance,
|
||||
zero-knowledge, etc.
|
||||
|
||||
# Waku for All Decentralized Applications and Infrastructures
|
||||
## Waku for All Decentralized Applications and Infrastructures
|
||||
|
||||
In 2022, we shifted our focus to make the various Waku implementations **usable and used**.
|
||||
|
||||
|
|
@ -119,7 +124,7 @@ This way, we are adding reasons to run your own Waku node.
|
|||
For those who were following us in 2021, know that we are retiring the _Waku Connect_ branding in favour of the _Waku_
|
||||
branding.
|
||||
|
||||
# Waku for Your Project
|
||||
## Waku for Your Project
|
||||
|
||||
As discussed, Waku is now available on various platforms. The question remains: How can Waku benefit **your** project?
|
||||
|
||||
|
|
@ -133,7 +138,7 @@ Waku can help:
|
|||
- Provide a neutral marketplace for a mempool: If sequencers compete for L2 tx fees, they may not be incentivized to
|
||||
share transactions with other sequencers. Waku nodes can act as a neutral network to enable all sequences to access
|
||||
transactions.
|
||||
- Enable censorship-resistant wallet<>L2 communication,
|
||||
- Enable censorship-resistant wallet<>L2 communication,
|
||||
- Provide rate limiting mechanism for spam protection: Using [RLN](https://rfc.vac.dev/spec/32/) to prevent DDOS.
|
||||
|
||||
## Device pairing and communication
|
||||
|
|
@ -148,7 +153,7 @@ These two devices could be:
|
|||
|
||||
Check [js-waku#950](https://github.com/waku-org/js-waku/issues/950) for the latest update on this.
|
||||
|
||||
# Get Involved
|
||||
## Get Involved
|
||||
|
||||
Developer? Grab any of the Waku implementations and integrate it in your app: https://waku.org/platform.
|
||||
|
||||
|
|
@ -160,7 +165,7 @@ Otherwise, play around with the various [web examples](https://github.com/waku-o
|
|||
|
||||
If you want to help, we are [hiring](https://jobs.status.im/)!
|
||||
|
||||
# Moving Forward
|
||||
## Moving Forward
|
||||
|
||||
What you can expect next:
|
||||
|
||||
|
|
@ -5,15 +5,18 @@ title: "The Future of Waku Network: Scaling, Incentivization, and Heterogeneity
|
|||
date: 2023-04-03 00:00:00
|
||||
author: franck
|
||||
published: true
|
||||
permalink: /future-of-waku-network
|
||||
slug: future-of-waku-network
|
||||
categories: platform, operator, network
|
||||
summary: Learn how the Waku Network is evolving through scaling, incentivization, and diverse ecosystem development and what the future might look like.
|
||||
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
|
||||
---
|
||||
import { DocMetadata } from '@site/src/components/mdx'
|
||||
|
||||
# The Future of Waku Network: Scaling, Incentivization, and Heterogeneity
|
||||
|
||||
<DocMetadata />
|
||||
|
||||
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.
|
||||
|
|
@ -85,7 +88,7 @@ Since there is no consensus on Waku, each individual operator can decide which n
|
|||
|
||||
Most likely, the Waku network will be heterogeneous, and node operators will choose the incentivization model they prefer.
|
||||
|
||||
# Scalability and Discovery Protocols
|
||||
## 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.
|
||||
|
|
@ -112,7 +115,7 @@ We have several ongoing initiatives:
|
|||
|
||||
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 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
|
||||
|
|
@ -123,7 +126,7 @@ maintaining its core principles. As Waku continues to evolve, we expect it to ac
|
|||
and business models, all while preserving privacy, resisting censorship, avoiding surveillance, and remaining accessible
|
||||
to devices with limited resources.
|
||||
|
||||
# References
|
||||
## References
|
||||
|
||||
1. [51/WAKU2-RELAY-SHARDING](https://rfc.vac.dev/spec/51/)
|
||||
2. [57/STATUS-Simple-Scaling](https://rfc.vac.dev/spec/57/)
|
||||
|
|
@ -5,14 +5,17 @@ title: "Device Pairing in Js-waku and Go-waku"
|
|||
date: 2023-04-24 12:00:00
|
||||
author: rramos
|
||||
published: true
|
||||
permalink: /device-pairing-in-js-waku-and-go-waku
|
||||
slug: device-pairing-in-js-waku-and-go-waku
|
||||
categories: platform
|
||||
summary: Device pairing and secure message exchange using Waku and noise protocol
|
||||
---
|
||||
|
||||
import { DocMetadata } from '@site/src/components/mdx'
|
||||
|
||||
# Device Pairing in Js-waku and Go-waku
|
||||
|
||||
<DocMetadata />
|
||||
|
||||
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.
|
||||
|
|
@ -25,7 +25,7 @@ For code contributions, see our "good first issue" lists for various Vac related
|
|||
* [go-waku](https://github.com/status-im/go-waku/labels/good%20first%20issue)
|
||||
* [zerokit](https://github.com/vacp2p/zerokit/labels/good%20first%20issue)
|
||||
|
||||
# Contribute Pseudonymously
|
||||
## Contribute Pseudonymously
|
||||
|
||||
We welcome everyone to contribute to our projects by submitting an issue or a pull request to any of the repository hosted in our [Vac](https://github.com/vacp2p) GitHub page.
|
||||
|
||||
|
|
@ -98,7 +98,7 @@ Note that we automatically discard e-mails containing one or more attachments wh
|
|||
|
||||
Once received, we will review your contribution and eventually create a pull request on your behalf.
|
||||
|
||||
#### E-Mail Encryption
|
||||
### E-Mail Encryption
|
||||
|
||||
Our `contribute@vac.dev` e-mail address is based on [Proton](https://proton.me) services.
|
||||
|
||||
|
|
@ -1,3 +1,9 @@
|
|||
---
|
||||
title: Media
|
||||
---
|
||||
|
||||
#
|
||||
|
||||
[Waku v2 training session](https://drive.google.com/file/d/19P3oDNXGBDClfcS6Sgp0t9LYr3UbIFGt/view)
|
||||
|
||||
[Waku: Enabling a New Dimension for dApps](https://www.youtube.com/watch?v=GXU5Fd6gMVw&t=21692s)
|
||||
|
|
@ -1,8 +1,9 @@
|
|||
---
|
||||
title: Open Research Problems
|
||||
---
|
||||
#
|
||||
|
||||
# Open Research Problems
|
||||
## Open Research Problems
|
||||
|
||||
We are seeking to collaborate with researchers in the following topic areas.
|
||||
Feel free to join our [Discord](https://discord.gg/PQFdubGt6d) for discussion.
|
||||
|
|
@ -137,7 +138,7 @@ Peer-to-peer networks are made of multiple nodes or peers, typically in the rang
|
|||
This not only involves an efficient peer discovery strategy, which gives us a pool of peers to select from, but also strategies to select the ones we are interested in and drop connections with the ones we are not. Protocols like GossipSub have their [score](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md#the-score-function) and it's something that can be used as a baseline, but unfortunately does not take into account Waku specifics.
|
||||
|
||||
|
||||
# Further Research Collaboration Opportunities
|
||||
## Further Research Collaboration Opportunities
|
||||
|
||||
Besides the open research problems listed in the section above,
|
||||
you may browse our [Research Areas](https://vac.dev/research-areas) page
|
||||
|
|
@ -1,7 +1,14 @@
|
|||
---
|
||||
title: Principles
|
||||
---
|
||||
|
||||
#
|
||||
|
||||
*These principles have been inherited from https://our.status.im/our-principles/
|
||||
Only minor stylistic changes have been made to them.*
|
||||
|
||||
# Principles
|
||||
<br/>
|
||||
|
||||
The goal of Vac is widespread adoption of the decentralized web.
|
||||
Our challenge is achieving mass adoption while staying true to our principles outlined below.
|
||||
|
|
@ -2,7 +2,7 @@
|
|||
title: Research areas
|
||||
---
|
||||
|
||||
# Overview
|
||||
## Overview
|
||||
|
||||
Vac has several research areas it is interested in and has or is developing expertise in.
|
||||
Here’s an overview of some of these areas along with motivation and what type of topics are included.
|
||||
|
|
@ -0,0 +1,65 @@
|
|||
module.exports = {
|
||||
main: [
|
||||
'index',
|
||||
'principles',
|
||||
'research-areas',
|
||||
'projects',
|
||||
'open-problems',
|
||||
'publications',
|
||||
'contribute',
|
||||
'media',
|
||||
{
|
||||
Research: [
|
||||
'2023-04-24-device-pairing-in-js-waku-and-go-waku',
|
||||
'2023-04-03-waku-as-a-network',
|
||||
'2022-11-08-waku-for-all-decentralize-applications',
|
||||
'2022-11-04-building-privacy-protecting-infrastructure',
|
||||
'2022-07-22-relay-anonymity',
|
||||
'2022-05-17-noise',
|
||||
'2022-05-09-ambient-peer-discovery',
|
||||
'2022-04-12-introducing-nwaku',
|
||||
'2021-12-03-ethics-surveillance-tech',
|
||||
'2021-10-25-waku-v1-vs-waku-v2',
|
||||
'2021-08-06-coscup-waku-ethereum',
|
||||
'2021-06-04-presenting-js-waku',
|
||||
'2021-03-03-rln-relay',
|
||||
'2020-11-10-waku-v2-ethereum-messaging',
|
||||
'2020-09-28-waku-v2-update',
|
||||
'2020-07-01-waku-v2-pitch',
|
||||
'2020-04-27-feasibility-discv5',
|
||||
'2020-04-16-wechat-replacement-need',
|
||||
'2020-04-9-kademlia-to-discv5',
|
||||
'2020-02-14-waku-update',
|
||||
'2020-02-7-dns-based-discovery',
|
||||
'2019-12-03-fixing-whisper-with-waku',
|
||||
'2019-11-08-feasibility-semaphore-rate-limiting-zksnarks',
|
||||
'2019-10-04-remote-log',
|
||||
'2019-08-02-vac-overview',
|
||||
'2019-07-19-p2p-data-sync-for-mobile',
|
||||
],
|
||||
},
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Resources',
|
||||
collapsed: true,
|
||||
collapsible: true,
|
||||
items: [
|
||||
{
|
||||
type: 'link',
|
||||
label: 'Specs/RFCs',
|
||||
href: 'https://rfc.vac.dev/ ',
|
||||
},
|
||||
{
|
||||
type: 'link',
|
||||
label: 'Forum',
|
||||
href: 'https://forum.vac.dev/',
|
||||
},
|
||||
{
|
||||
type: 'link',
|
||||
label: 'Waku.org',
|
||||
href: 'https://waku.org',
|
||||
},
|
||||
],
|
||||
},
|
||||
],
|
||||
}
|
||||
|
|
@ -0,0 +1,71 @@
|
|||
---
|
||||
displayed_sidebar: main
|
||||
---
|
||||
|
||||
# Terms of Use
|
||||
|
||||
These terms and conditions (“**Website Terms of Use**”) are entered into by you and us, and they govern your access and use of the Website, including any content and functionality contained in the Website.
|
||||
|
||||
It is your responsibility to read the Website Terms of Use carefully before your use of the Website and your use of the Website means you have agreed to be bound and comply with these Website Terms of Use.
|
||||
|
||||
If you do not agree with these Website Terms of Use, you must not access or use the Website.
|
||||
|
||||
### Content provided for informational purposes only
|
||||
|
||||
Content available on the Website is for informational purposes only and is not intended to address the specific circumstances of any particular individual or entity. Such content may not always be entirely accurate, complete, or up to date and may also include inaccuracies or typographical errors. You are solely responsible for verifying their adequacy, completeness and accuracy and any reliance you place on such content is at your own risk.
|
||||
|
||||
None of the content on this Website should be considered by you as legal, tax, investment, financial, professional or any other type of advice. You should always conduct your own research and seek independent professional advice if necessary. You are solely responsible for the decisions or actions you might take in this respect. We are not liable for any loss resulting from your action (or inaction) and decisions based on this content on this Website.
|
||||
|
||||
Additionally, we are not responsible for any information, content, or services contained in any third-party content or on any third-party websites accessible or linked through this website.
|
||||
|
||||
### Intellectual property rights
|
||||
|
||||
The Website and its contents are made available under free and open source licences. This means that anyone can use, share, and modify such content, as long as they follow the terms of the applicable licence.
|
||||
|
||||
### Third party website links
|
||||
|
||||
To the extent the Website provides any links to a third party website, then their terms and conditions, including privacy policies, govern your use of those third party websites. We have no control over such third party websites and will not be liable for your use of or activities on any third party websites accessed through the Website. If you access such third party websites through the Website, it is at your own risk and you are solely responsible for your activities on such third party websites.
|
||||
|
||||
### Disclaimer
|
||||
|
||||
The Website is provided by us on an ‘as is’ basis and you use the Website at your own sole discretion and risk.
|
||||
|
||||
We disclaims all warranties of any kind, express or implied, including without limitation the warranties of merchantability, fitness for a particular purpose, and non-infringement of intellectual property or other violation of rights. We do not warrant or make any representations concerning the completeness, accuracy, legality, utility, reliability, suitability or availability of the use of the Website, the content on this Website or otherwise relating to the Website, such content or on any sites linked to this site.
|
||||
|
||||
We make no claims that the Website or any of its content is accessible, legally compliant or appropriate in your jurisdiction. Your access or use of the Website is at your own sole discretion and you are solely responsible for complying with any applicable local laws. These disclaimers will apply to the maximum extent permitted by applicable law.
|
||||
|
||||
### Limitation of liability
|
||||
|
||||
We will not be held liable to you under any contract, negligence, strict liability, or other legal or equitable theory for any lost profits, cost of procurement for substitute services, or any special, incidental, or consequential damages related to, arising from, or in any way connected with these Website Terms of Use, the Website, the content on the Website, or your use of the Website, even if we have been advised of the possibility of such damages. In any event, our aggregate liability for such claims is limited to EUR 100 (one hundred Euros). This limitation of liability will apply to the maximum extent permitted by applicable law.
|
||||
|
||||
### Indemnity
|
||||
|
||||
You shall indemnify us and hold us harmless from and against any and all claims, damages and expenses, including attorneys’ fees, arising from or related to your use of the Website, the content on the Website, including without limitation your violation of these Website Terms of Use.
|
||||
|
||||
### Modifications
|
||||
|
||||
We may modify or replace any part of this Website Terms of Use at any time and without notice. You are responsible for checking the Website periodically for any changes. The new Website Terms of Use will be effective immediately upon its posting on the Website.
|
||||
|
||||
### Governing law
|
||||
|
||||
Swiss law governs these Website Terms of Use and any disputes between you and us, whether in court or arbitration, without regard to conflict of laws provisions.
|
||||
|
||||
### Disputes
|
||||
|
||||
In these terms, “dispute” has the broadest meaning enforceable by law and includes any claim you make against or controversy you may have in relation to these Website Terms of Use, the Website, the content on the Website, or your use of the Website
|
||||
|
||||
We prefer arbitration over litigation as we believe it meets our principle of resolving disputes in the most effective and cost effective manner. You are bound by the following arbitration clause, which waives your right to litigation and to be heard by a judge. Please note that court review of an arbitration award is limited. You also waive all your rights to a jury trial (if any) in any and all jurisdictions.
|
||||
|
||||
If a (potential) dispute arises, you must first use your reasonable efforts to resolve it amicably with us. If these efforts do not result in a resolution of such dispute, you shall then send us a written notice of dispute setting out (i) the nature of the dispute, and the claim you are making; and (ii) the remedy you are seeking.
|
||||
|
||||
If we and you are unable to further resolve this dispute within sixty (60) calendar days of us receiving this notice of dispute, then any such dispute will be referred to and finally resolved by you and us through an arbitration administered by the Swiss Chambers’ Arbitration Institution in accordance with the Swiss Rules of International Arbitration for the time being in force, which rules are deemed to be incorporated herein by reference. The arbitral decision may be enforced in any court. The arbitration will be held in Zug, Switzerland, and may be conducted via video conference virtual/online methods if possible. The tribunal will consist of one arbitrator, and all proceedings as well as communications between the parties will be kept confidential. The language of the arbitration will be in English. Payment of all relevant fees in respect of the arbitration, including filing, administration and arbitrator fees will be in accordance with the Swiss Rules of International Arbitration.
|
||||
|
||||
Regardless of any applicable statute of limitations, you must bring any claims within one year after the claim arose or the time when you should have reasonably known about the claim. You also waive the right to participate in a class action lawsuit or a classwide arbitration against us.
|
||||
|
||||
### About these Website Terms of Use
|
||||
|
||||
These Website Terms of Use cover the entire agreement between you and us regarding the Website and supersede all prior and contemporaneous understandings, agreements, representations and warranties, both written and oral, with respect to the Website.
|
||||
|
||||
The captions and headings identifying sections and subsections of these Website Terms of Use are for reference only and do not define, modify, expand, limit, or affect the interpretation of any provisions of these Website Terms of Use.
|
||||
|
||||
If any part of these Website Terms of Use is held invalid or unenforceable, that part will be severable from these Website Terms of Use, and the remaining portions will remain in full force and effect. If we fail to enforce any of these Website Terms of Use, that does not mean that we have waived our right to enforce them.
|
||||
|
|
@ -0,0 +1,112 @@
|
|||
// @ts-check
|
||||
// Note: type annotations allow type checking and IDEs autocompletion
|
||||
require('dotenv').config()
|
||||
|
||||
const authors = require('./data/authors')
|
||||
|
||||
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: {
|
||||
default: {
|
||||
content: {
|
||||
authors,
|
||||
authorPage: {
|
||||
sidebar: 'main',
|
||||
},
|
||||
},
|
||||
},
|
||||
},
|
||||
},
|
||||
},
|
||||
docs: {
|
||||
routeBasePath: '/',
|
||||
sidebarPath: 'docs/sidebars.js',
|
||||
remarkPlugins: [math],
|
||||
rehypePlugins: [katex],
|
||||
},
|
||||
}),
|
||||
],
|
||||
],
|
||||
themes: ['@docusaurus/theme-mermaid'],
|
||||
themeConfig:
|
||||
/** @type {import('@acid-info/logos-docusaurus-preset').ThemeConfig} */
|
||||
({
|
||||
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: 'Contact Us',
|
||||
to: '/',
|
||||
},
|
||||
{
|
||||
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,56 @@
|
|||
{
|
||||
"name": "vac-dev",
|
||||
"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.29",
|
||||
"@docusaurus/core": "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 @@
|
|||
export * from '@acid-info/logos-docusaurus-theme/lib/client/components/mdx'
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
:root {
|
||||
}
|
||||
|
||||
body,
|
||||
html {
|
||||
overflow-x: hidden;
|
||||
}
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 10 KiB |
|
Before Width: | Height: | Size: 3.0 KiB After Width: | Height: | Size: 3.0 KiB |
|
Before Width: | Height: | Size: 56 KiB After Width: | Height: | Size: 56 KiB |
|
Before Width: | Height: | Size: 487 KiB After Width: | Height: | Size: 487 KiB |
|
Before Width: | Height: | Size: 784 KiB After Width: | Height: | Size: 784 KiB |
|
Before Width: | Height: | Size: 359 KiB After Width: | Height: | Size: 359 KiB |
|
Before Width: | Height: | Size: 390 KiB After Width: | Height: | Size: 390 KiB |
|
Before Width: | Height: | Size: 230 KiB After Width: | Height: | Size: 230 KiB |
|
Before Width: | Height: | Size: 1.1 MiB After Width: | Height: | Size: 1.1 MiB |
|
Before Width: | Height: | Size: 498 KiB After Width: | Height: | Size: 498 KiB |
|
Before Width: | Height: | Size: 157 KiB After Width: | Height: | Size: 157 KiB |
|
Before Width: | Height: | Size: 735 KiB After Width: | Height: | Size: 735 KiB |
|
Before Width: | Height: | Size: 560 KiB After Width: | Height: | Size: 560 KiB |
|
Before Width: | Height: | Size: 204 KiB After Width: | Height: | Size: 204 KiB |
|
Before Width: | Height: | Size: 386 KiB After Width: | Height: | Size: 386 KiB |
|
Before Width: | Height: | Size: 2.7 MiB After Width: | Height: | Size: 2.7 MiB |
|
Before Width: | Height: | Size: 563 KiB After Width: | Height: | Size: 563 KiB |
|
Before Width: | Height: | Size: 912 KiB After Width: | Height: | Size: 912 KiB |
|
Before Width: | Height: | Size: 855 KiB After Width: | Height: | Size: 855 KiB |
|
Before Width: | Height: | Size: 533 KiB After Width: | Height: | Size: 533 KiB |
|
Before Width: | Height: | Size: 144 KiB After Width: | Height: | Size: 144 KiB |
|
Before Width: | Height: | Size: 35 KiB After Width: | Height: | Size: 35 KiB |
|
Before Width: | Height: | Size: 34 KiB After Width: | Height: | Size: 34 KiB |
|
Before Width: | Height: | Size: 14 KiB After Width: | Height: | Size: 14 KiB |
|
Before Width: | Height: | Size: 24 KiB After Width: | Height: | Size: 24 KiB |
|
Before Width: | Height: | Size: 97 KiB After Width: | Height: | Size: 97 KiB |
|
Before Width: | Height: | Size: 92 KiB After Width: | Height: | Size: 92 KiB |
|
Before Width: | Height: | Size: 134 KiB After Width: | Height: | Size: 134 KiB |
|
Before Width: | Height: | Size: 485 KiB After Width: | Height: | Size: 485 KiB |
|
Before Width: | Height: | Size: 1.0 MiB After Width: | Height: | Size: 1.0 MiB |
|
Before Width: | Height: | Size: 17 KiB After Width: | Height: | Size: 17 KiB |
|
Before Width: | Height: | Size: 485 KiB After Width: | Height: | Size: 485 KiB |
|
Before Width: | Height: | Size: 211 KiB After Width: | Height: | Size: 211 KiB |
|
Before Width: | Height: | Size: 333 KiB After Width: | Height: | Size: 333 KiB |
|
Before Width: | Height: | Size: 45 KiB After Width: | Height: | Size: 45 KiB |
|
Before Width: | Height: | Size: 58 KiB After Width: | Height: | Size: 58 KiB |
|
Before Width: | Height: | Size: 42 KiB After Width: | Height: | Size: 42 KiB |
|
Before Width: | Height: | Size: 48 KiB After Width: | Height: | Size: 48 KiB |
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue