AtHeartEngineer/vac-book
1
0
Fork 0
mirror of https://github.com/vacp2p/vac-book.git synced 2026-01-07 22:33:51 -05:00
Code Issues Packages Projects Releases Wiki Activity

Update

Browse Source
This commit is contained in:
oskarth
2023-02-06 13:01:08 +08:00
parent add509c6fb
commit b871f82de9
14 changed files with 1638 additions and 30 deletions
Download Patch File Download Diff File Expand all files Collapse all files

127
.obsidian/workspace.json vendored
View File

@@ -20,7 +20,79 @@
}
},
{
"id": "656283cc8de0b6d4",
"id": "07afe2d17ec47e58",
"type": "leaf",
"state": {
"type": "markdown",
"state": {
"file": "scratch/vac-book-migration.md",
"mode": "source",
"source": false
}
}
},
{
"id": "dc53f4912a093f7d",
"type": "leaf",
"state": {
"type": "markdown",
"state": {
"file": "topics/waku-operator-outreach.md",
"mode": "source",
"source": false
}
}
},
{
"id": "5c4bb7e8be464a3e",
"type": "leaf",
"state": {
"type": "markdown",
"state": {
"file": "scratch/vac-book-migration.md",
"mode": "source",
"source": false
}
}
},
{
"id": "2e57851fc2d050a6",
"type": "leaf",
"state": {
"type": "markdown",
"state": {
"file": "topics/waku-v2-training.md",
"mode": "source",
"source": false
}
}
},
{
"id": "c1ef4c5ef7c4da47",
"type": "leaf",
"state": {
"type": "markdown",
"state": {
"file": "topics/nwaku.md",
"mode": "source",
"source": false
}
}
},
{
"id": "97b7db56953f6c22",
"type": "leaf",
"state": {
"type": "markdown",
"state": {
"file": "topics/nwaku-coding-guide.md",
"mode": "source",
"source": false
}
}
},
{
"id": "03fdba3fcb63f72e",
"type": "leaf",
"state": {
"type": "markdown",
@@ -37,14 +109,50 @@
"state": {
"type": "markdown",
"state": {
"file": "scratch/vac-book-migration.md",
"file": "topics/secure-messaging-overview.md",
"mode": "source",
"source": false
}
}
},
{
"id": "8f52f11ae36c2955",
"type": "leaf",
"state": {
"type": "markdown",
"state": {
"file": "plan/secure-messaging-2023-prios.md",
"mode": "source",
"source": false
}
}
},
{
"id": "6709ed85d60759db",
"type": "leaf",
"state": {
"type": "markdown",
"state": {
"file": "README.md",
"mode": "source",
"source": false
}
}
},
{
"id": "3759563bd449e8c2",
"type": "leaf",
"state": {
"type": "markdown",
"state": {
"file": "topics/secure-messaging-team-allocation.md",
"mode": "source",
"source": false
}
}
}
],
"currentTab": 2
"currentTab": 3
}
],
"direction": "vertical"
@@ -171,10 +279,17 @@
"command-palette:Open command palette": false
}
},
"active": "4e258b0332457c2a",
"active": "5c4bb7e8be464a3e",
"lastOpenFiles": [
"README.md",
"topics/nwaku-coding-guide.md",
"topics/secure-messaging-overview.md",
"Untitled.md"
"topics/onboarding-guide.md",
"topics/waku-operator-outreach.md",
"topics/waku.md",
"scratch/vac-book-migration.md",
"topics/nwaku.md",
"topics/waku-v2-training.md",
"README.md",
"plan/nwaku-2023-prios.md"
]
}

7
README.md
View File

@@ -3,10 +3,11 @@ Welcome to the Vac book! This acts as a knowledge base for https://vac.dev/.
This replaces the somewhat-outdated Vac overview here: https://hackmd.io/@vac/main/
## About
## Organization
- **topics** - Notes on various topics.
- **scratch** - Temporary, throw-away stuff.
- **topics** - Notes on various topics; atemporal.
- **scratch** - Misc scratchpad, temporary; throw-away stuff.
- **plan** - plans for yearly/quarterly etc goals; temporal.
## Contribute

99
plan/nwaku-2023-prios.md Normal file
View File

@@ -0,0 +1,99 @@
# 2023 nwaku priorities
> **Note:** I have identified 12 focus areas for nwaku to focus on in 2023 supporting our vision of Waku being used everywhere. Our ultimate goal is to have the nwaku client be a suitable way to achieve this. Under each focus area, I've extracted the first milestones where possible and if already defined. 12 focus areas are too much for a small team to handle, so I have condensed these points into three main priorities. It is important for the nwaku team to be mindful of taking on too much and to prioritise tasks that directly contribute to our vision for Waku. I've also considered the wider activities of Status, Vac, and Logos in the planning.
## Priorities TL;DR
1. Increase the reach of Waku and nwaku, by targeting node programs and supporting Status milestones.
2. Optimise nwaku for more environments and stabilise protocols.
3. Work with Vac Research and Logos Devops to build out capabilities to scale securely, provide service incentivisation and create an integrated network testing and simulation environment.
## Detailed focus areas
### 1. Target node programs for community-run nodes
Our main long-term goal as a team is to see Waku running everywhere and the nwaku client to be a suitable and reliable client in as many environments as possible. One way to reach out to more operators is to target node programs.
#### First milestones
- Milestone 1: Integrate nwaku into DappNode
- Milestone 2: Get to 100 user-run nodes, excluding Status clients.
- Milestone 3: Launch an incentivised node program (we could take inspiration here from [Kusama](https://thousand-validators.kusama.network/#/getting-started) or past [Status node program](https://our.status.im/status-node-program-launch/))
### 2. Support Status milestones
Improve collaboration here with Status to meet their ambitious milestones, especially for the Status Communities project.
#### First milestones
- Milestone 1: Status Mobile MVP: [Status Core Contributors use Status Mobile](https://github.com/waku-org/pm/issues/8)
### 3. Run nwaku in more places
We want to make it easuer to integrate nwaku into existing/new applications, allowing us to reach a larger potential user base. For example, adding C bindings, wrapping in Rust, etc.
#### First milestones
- Milestone 1: Expose C bindings for nwaku
### 4. Nwaku low-level performance optimisations
This could be related to the previous point. One of our goals with nwaku is to create a client that is suitable to run in resource-restricted environments. There are many parts of the existing client that can be significantly optimised in terms of resource (memory/CPU) and bandwidth usage.
We'd preferably get a new hire to focus on this.
### 5. Stable specification and implementation of restricted-run protocols
With `relay` reaching maturity and `store` well on its way, we want to focus on the main protocols required by resource-restricted devices, e.g. `filter`, `lightpush` and `waku-peer-exchange` to stabilise both the protocol specifications and implementations
#### First milestones
- Milestone 1: Store v3 protocol [stabilisation and beta implementation](https://github.com/vacp2p/rfc/issues/552)
- Milestone 2: Filter protocol [stabilisation and beta implementation](https://github.com/waku-org/pm/issues/5)
### 6. Secure scaling (collab with Vac Research)
Many applications using nwaku, such as Status, have ambitious scaling targets. The _Secure Messaging_ project in Vac Research is focusing on secure scaling strategies as a separate track. We want to be involved with these developments to ensure nwaku remains a useful client in very large networks and assist researchers in implementing scaling strategies in nwaku as reference implementation.
Overal roadmap is set by the Secure Messaging project in Vac Research.
### 7. Service incentivisation (collab with Vac Research)
Since we want to see Waku running everywhere, nwaku will benefit from any progress in adding incentivisation/disincentivisation mechanisms to protocols. As the reference implementation we want to be useful in helping the research effort reach production-readiness.
Overall roadmap is set from within Vac Research.
### 8. Peer management
Proper [peer and connection management](https://github.com/waku-org/pm/issues/6) is crucial to ensure reliable message delivery in a Waku network, ensure network integrity, enhance security, etc.
#### First milestones
- Milestone 1: [Networking MVP](https://github.com/waku-org/nwaku/issues/1353)
### 9. Hiring
We want to add at least three new hires within the year to solidify our team and expand our capabilities. We roughly need two general software developers to help with development, devops, and support work, and a third with specific low-level programming and optimization skills.
### 10. Network testing/Kurtosis simulations (collab with Wakurtosis)
The main aim of network testing is twofold:
- simulate and benchmark Waku performance as it scales
- test Waku network robustness against adverse and difficult network conditions
#### First milestones
- Milestone 1: [First network test](https://github.com/logos-co/wakurtosis/issues/7)
### 11. Integrated testing environment (collab with Logos Devops)
This could benefit from the network testing infrastructure created in collab with Wakurtosis. We have very few regular tests that cover the integrated functionality of a nwaku clients, interoperability with other clients and no tests that ensure that our compiled binaries function as expected. In short, we need proper ["black-box testing"](https://www.wikiwand.com/en/Black-box_testing)that run at regular intervals and tests interoperability with other Waku clients.
### 12. Improved processes
There are several internal processes that can be streamlined and automated to free the team up to focus on more pressing productionisation and support issues. Many of these are related to devops and are already summarised in our [DevOps wishlist for 2023](https://notes.status.im/nwaku-devops-work).
#### First milestones
- Milestone 1: [Automate release process](https://github.com/waku-org/nwaku/issues/611)

72
plan/secure-messaging-2023-prios.md Normal file
View File

@@ -0,0 +1,72 @@
# 2023 Secure Messaging Research (SeM) Priorities
> **Note:** These are *research* focus areas.
We cannot guarantee positive results, especially for highly explorative tasks.
## 1. Secure Scaling
The main research focus for SeM in 2023 is scaling [Waku Relay](https://rfc.vac.dev/spec/11/) to 1 million nodes.
This comprises several research challenges and tasks:
* efficient and privacy-preserving mapping of content topics to pubsub topics;
* discovery of pubsub topics;
* DoS mitigation.
We see DoS mitigation as the biggest challenge and potential blocker.
Depending on results, we might not be able to solve DoS issues satisfactory within 2023.
Our long-term approach to solving (spam-based) DoS is RLN,
which is mainly researched within [RLNp2p](https://rlnp2p.vac.dev/),
collaborating with the *SeM protocol incentivization* track.
Our [secure scaling roadmap](https://github.com/vacp2p/research/issues/154)
list issues leading towards our goals and will be kept up-to-date.
When scaling Waku Relay to 1 million nodes,
we expect other parts of Waku (besides discovery) to become bottlenecks;
especially the store, whose related research is part of the SeM *data synchronization* track.
We will identify new bottlenecks and think of ad-hoc fixes,
but will not focus research on these this year (not enough resources).
SeM will synchronize and collaborate with Waku product to keep research goals in line with practical needs.
SeM will also collaborate with [Kurtosis](https://roadmap.logos.co/roadmap/networking/status-waku-kurtosis/),
which will yield valuable test results, which can verify (and be verified by) our calculations.
## 2. Restriced Run
Aligned with our secure scaling goals, we will research allowing the restricted run protocols
* [Light Push](https://rfc.vac.dev/spec/11/)
* [Filter](https://rfc.vac.dev/spec/12/)
* [Peer Exchange](https://rfc.vac.dev/spec/34/)
to keep up with the above stated scaling goals.
## 3 Discovery
While the *discovery* track is not in focus as a driver this year,
discovery issues facilitating progress in secure scaling will be part of the focus.
This will comprise working on capability discovery,
as we plan to advertise pubsub topics as capabilities (or part of a hierarchical relay capability).
## 4. Privacy&Anonymity
We aim to progress on Waku Relay anonymity research.
We will continue working on [Waku Tor push](https://rfc.vac.dev/spec/47/), and tackle research problems coming up in the process.
SeM will integrate Tor push into nwaku, collaborating with the Nwaku team.
We will also work on a [Nym](https://nymtech.net/)-based solution (including an RFC), and a prototype.
## 5. Incentivization
We will work on a Service Credentials solution for service-offering protocols such as Store and Filter.
This will comprise both a specification and a prototype.
## 6. RLN
RLN is our long-term solution for protecting against spam-based DoS.
This is very important to achieve our scaling goals.
We will continue working on RLN.
More specifics: TBD.

43
scratch/vac-book-migration.md
View File

@@ -1,25 +1,26 @@
https://hackmd.io/@vac/main
- [ ] Vac overview
- [ ] Tools and workfows
- [ ] Waku v2 training
- [ ] Research
- [ ] Intro
- [ ] Waku v1 vs Waku v2
- [ ] Secure Messaging
- [ ] Overview
- [ ] 2023 priorities
- [ ] Team allocation
- [ ] nwaku
- [ ] Intro
- [ ] Waku Connect
- [ ] Intro, Waku Connect PM, Bounty ideas, Presentations
- [x] Vac overview
- [x] Tools and workfows
- [x] Waku v2 training
- [x] Research
- [x] Intro (meh)
- [x] Waku v1 vs Waku v2 (captured in vac.dev)
- [x] Secure Messaging
- [x] Overview
- [x] 2023 priorities
- [x] Team allocation
- [x] nwaku
- [x] Intro
- [x] Waku Connect
- [x] Intro, Waku Connect PM, Bounty ideas, Presentations
- captured elsewhere?
- [ ] Outreach
- [ ] Platform
- [ ] Operator
- [ ] Research
- [ ] Other
- [ ] Vac PM notes
- [ ] Onboarding guide
- [x] Outreach
- out of date / captured elsewhere
- [x] Platform
- [x] Operator
- [x] Research
- [x] Other
- [x] Vac PM notes
- [x] Onboarding guide

87
topics/nwaku-coding-guide.md Normal file
View File

@@ -0,0 +1,87 @@
# Coding conventions for nwaku
## Background
This guide aims to document the most important coding conventions followed in the [nwaku codebase](https://github.com/status-im/nwaku). This includes, but is not limited, to styling, formatting and code organisation. Since most of the repo is based on Nim, this is the main focus of the guide. This should become a handy reference when contributing to the codebase and help us refactor existing code to improve overall consistency.
## General
The nwaku codebase uses the [Status Nim style guide](https://status-im.github.io/nim-style-guide/) for styling. This guide, in turn, is based on [NEP-1](https://nim-lang.org/docs/nep1.html). _These two documents remain the ground truth for styling decisions._ Some easily-overlooked guidelines from these two guides are repeated below.
## Logging
Also see the [_Nimbus logging strategy_](https://github.com/status-im/nimbus-eth2/blob/031780b612fd589e724f7e837db4c9f7a233f2c3/docs/logging.md).
- Define a `logScope` for each module that uses chronicles logging.
- Nim chronicles' log topics should be understood as log message labels.
- Log topics should contain "whole words" separated by spaces. In the case of a composed word, it should follow the `snake_case` style.
- Log topics should be ordered from more general to less general (e.g., `waku node message_store sqlite_store`)
- Multiple `logScope` topic labels are optional. More than one label should be avoided if it does not aid debugging. Think carefully of your use case.
- Log scopes/topics are meant for humans and machines to find logs that belong together when debugging. If there's no debugging use case to separate a subgroup of logs, there's no reason for a sublevel. Logs for a protocol, even across different modules, can simply be scoped together with `waku <protocol>`, e.g. `waku store`.
- The modules' log topics within `waku` module should have `waku` as the first topic. This will allow any user of waku (as a library) to mute all logs by filtering the `waku` topic. The `whisper` module is the exception.
- The apps' log topics should start with the name of the app (e.g., `wakunode2 rest`)
- Waku protocols' log topics should be specified without the "waku" prefix (e.g., `waku filter client`)
- Logs that _could_ be high rate (even under an error condition), should not be logged at a level higher than `TRACE`. One rule-of-thumb here is that per-message logs must always be `TRACE`.
- Keep log messages as succinct as possible - very long log messages are often difficult to read in most log renderers. Rather split a long log into separate log messages.
## Imports/exports
_see [related section](https://status-im.github.io/nim-style-guide/language.import.html) in Status Nim style guide_
- Nim `import`s and `export`s are very difficult to keep clean, so do your part by continuously cleaning unused imports, keeping your `import` set minimal and your `export` set reasonable.
- Avoid circular imports. The direction of importing is (usually) from a more specific module to a more general module, e.g. the "general" `wakunode` module importing several more specific protocol modules (but never in the opposite direction), which may in turn import even more specific `util` modules. There should be no application-level modules imported in the waku protocol modules.
- @lnsd compiled this partial list of rules to help avoid circular imports:
* `utils` MUST NOT import any module from `protocol` or `node`.
* `protocol` CAN import modules from `utils`.
* `protocol` MUST NOT import modules from `node`.
* `node` CAN import modules from `utils` and `protocol`.
* `apps` modules (e.g. `config.nim`) MUST NOT be imported by any module.
- use `std/` prefix for any `import` from stdlib
- use explicit `import` paths (e.g. `./` for modules in same path)
## Error handling
_see [related section](https://status-im.github.io/nim-style-guide/errors.html) in Status Nim style guide_
- Use a top level
```
when (NimMajor, NimMinor) < (1, 4):
{.push raises: [Defect].}
else:
{.push raises: [].}
```
in all modules
- Use `Result` return type for each function where multiple failure paths exists
- Use `Opt` return type for each function where return may be empty/null
- Add an explicit `{.raises.}` for each applicable public (*) function. Prefer using `Result` return type and result error checks above exceptions and catchable errors.
- Avoid using `{raises: [Exception, CatchableError]}`
- Don't rely on empty initialisation to check for empty return - use options!
## Constants
- Constant names should be in `PascalCase`.
## Proc call/object property parenthesis conventions
Follow these rules for the sake of consistency and readability:
- Verbs must be followed by the parenthesis, since it denotes a "question" (e.g., `isSomething()`, `isOk()`, `isNil()`)
- Nouns must go without the parenthesis. A `proc` with a noun name should go without parenthesis. They describe "properties" (or "derived properties" in the `proc` with a noun name) of certain object. (e.g., `Result.error`, `Result.value`)
## Unit testing
- Whenever a bug is encountered it's an indication that unit test coverage has not been sufficient. Ensure therefore that every bugfix is accompanied by extended unit tests that detects the issue and prove the fix.
- Unit tests should be _deterministic_. That is, it should not rely on values or conditions from the runtime environment, but should be exactly repeatable on any platform or environment. For example, a unit test that adds random sleeps to wait for another process to finish is nondeterministic (this process may take longer/shorter to finish in other environments). Tests that use "current time" are also nondeterministic (this value differs each time the test is run).
## Miscellaneous
- Don't use Nim's `result` returns (reasoning [here](https://status-im.github.io/nim-style-guide/language.result.html))
- Never dispatch futures with `discard` or `asyncCheck`; use `asyncSpawn`
- Try to avoid using `discard` where error must be properly handled
- Use `new()` instead of `init()` for constructors of `ref object` types
- Avoid leaving trailing whitespaces, both at the end of a line and in empty lines. This rule is already specified in [.editorconfig](https://github.com/status-im/nwaku/blob/master/.editorconfig) so it can be enforced automatically every time you save.
- VS Code: Install [EditorConfig for VS Code](https://marketplace.visualstudio.com/items?itemName=EditorConfig.EditorConfig) extension. Now every time you save, trailing whitespaces are removed.
- Vim: Install [editorconfig-vim](https://github.com/editorconfig/editorconfig-vim)

9
topics/nwaku.md Normal file
View File

@@ -0,0 +1,9 @@
# nwaku
Implementation of Waku in Nim. Overlaps with the research team, which is also ensuring this is production-ready. Initial research goes here, tight feedback loops and synergies with other research projects such as nim-libp2p, Nimbus, Dagger, etc.
We are in the process of building out a production team here.
Repo: https://github.com/status-im/nwaku/
Board: https://github.com/orgs/waku-org/projects/2

63
topics/onboarding-guide.md Normal file
View File

@@ -0,0 +1,63 @@
# Onboarding guide
Welcome to Vac! There's quite a lot to learn so take your time. Here are a few links and some things to start with:
## Collaboration Guideline
Have a read of the link provided below to acquaint yourself with our collaboration best practices.
https://hackmd.io/phMs2XiOQD-NhNc-hHquLQ
## Starter tasks
- Try out the [Status app](http://status.im/)
- Get familiar with Nim
- Build [nwaku](https://hackmd.io/@vac/main/%2FXzV9Sap2S8SbVY15V8Ph-A). We encourage all core contributors to run a long-lived nwaku node as an operator. More details [here](https://hackmd.io/sSoTB3bmSDGtPnoCGtmYoQ?view).
- Skim specs (primarily Vac, but also Status) and try to get a picture of how things fit together. You do not have to read all the specifications all at once (it may get a bit confusing). We suggest start reading them in the following order, it is just a suggestion, feel free to do it the way you want!:).
* 1/COSS
* 10/WAKU2
* 16/WAKU2-RPC
* 11/WAKU2-RELAY | 14/WAKU2-MESSAGE | 23/WAKU2-TOPICS | 26/WAKU2-PAYLOAD
* 12/WAKU2-FILTER
* 19/WAKU2-LIGHTPUSH
* 13/WAKU2-STORE
* 18/WAKU2-SWAP
* 27/WAKU2-PEERS
* 15/WAKU2-BRIDGE
While reading RFCs note that there are two versions of WAKU namely WAKU1 and WAKU2. Vac RFCs related to WAKU2 are WAKU2 prefixed whereas other ones are prefixed by WAKU or WAKU1. For example, 8/WAKU-MAIL and 13/WAKU2-STORE are RFCs for WAKU1 and WAKU2, respectively.
- Join the [Vac](https://discord.gg/zRKyr8ve92), Status and [Nimbus](https://discord.gg/XRxWahP) Discord servers and say hi!
## Resources
### Vac
- [Vac overview](https://hackmd.io/@vac/main/https%3A%2F%2Fhackmd.io%2Fz-YmYxhXTSqNVZjnbWYHxw)
- [Vac.dev writeups](https://vac.dev/)
- [Vac RFCs/Specs](https://rfc.vac.dev/)
- [COSS process](https://rfc.vac.dev/spec/1/)
- [10/WAKU2 main spec](https://rfc.vac.dev/spec/10/)
- [Vac forum](https://forum.vac.dev)
- [Vac 2021 Q3 priorities](https://forum.vac.dev/t/vac-teams-priorities-for-q3-2021/86)
- [Waku v2 training session](https://drive.google.com/file/d/19P3oDNXGBDClfcS6Sgp0t9LYr3UbIFGt/view)
- [Vac Sustainability and business workshop](https://forum.vac.dev/t/vac-sustainability-and-business-workshop/116)
### Status
- [Status whitepaper](https://status.im/files/whitepaper.pdf)
- [Status principles](https://status.im/about/)
- [Status main client spec](https://specs.status.im/spec/1)
- [Status specs](https://specs.status.im)
- [Status Discuss](https://discuss.status.im/)
- [Nimbus team](https://nimbus.team/)
- [nim-libp2p](https://github.com/status-im/nim-libp2p)
### Ecosystem
- [Ethereum](https://ethereum.org/en/)
- [libp2p](https://libp2p.io/)
- [libp2p specs](https://github.com/libp2p/specs/
)
### Nim
- [Nim language](https://nim-lang.org/)
- [Status Nim styleguide](https://status-im.github.io/nim-style-guide/)

21
topics/secure-messaging-team-allocation.md Normal file
View File

@@ -0,0 +1,21 @@
# SeM Team Allocation
| Role | CC | Projects | SeM tasks |
| --- | --- | --- | --- |
| protocol research engineer | Ksr | 80% SeM, 20% RAD | lead, anonymity, secure scaling |
| protocol research engineer | new hire (searching) | 100% SeM | secure scaling, restricted run |
| protocol research engineer | new hire (searching) | 100% SeM | discovery, secure scaling, restricted run |
| smart contract & tokeneconomics research engineer | new hire (searching) | 100% SeM | protocol incentivization |
| protocol research engineer | new hire (future) | 100% SeM | data synchronization |
| protocol research engineer | new hire (future) | 100% SeM | conversational security, app protocols |
### Partially in SeM but mainly in other projects
| Role | CC | Projects | SeM tasks |
| --- | --- | --- | --- |
| cryptography research engineer | s1fr | 70% AZEK, 30% SeM | conversational security, incentive, RLN |
| ZK/protocol engineer | p1ge0nh8er | 60% Nwaku, 40% SeM | app protocols, RLN |
| protocol engineer | alrevuelta | 70% Nwaku, 30% SeM | secure scaling |

50
topics/tools-and-workflows.md Normal file
View File

@@ -0,0 +1,50 @@
# Tools and workflows
This is a stub. The goal is to list some commonly used tools and workflows. Please edit this page directly.
## Tools for communication
Because Vac is collaborating with many different teams we use different communication mediums for different areas of work.
The primary ones are that you'll use on a daily basis are:
- Vac Discord
- Github (issues, PRs, etc)
Here's a non-exhaustive list of other tools that are used:
- Command line Waku app (for dogfooding)
- Status and Nimbus discord (for conversations related to Status and Nimbus)
- Status app
- Vac Forum (for long term posts)
- Status
- Telegram (for example in collaboration with other projects)
- Signal (for example in collaboration with other projects)
- Google Meet or Jitsi (for video calls)
## Work principles
- Async over sync (atemporal vs temporal, different timezones)
- Public over private
- Proactively reaching out vs waiting for something to happen or asking for permission
For example, if you have a problem it is better to create a Github issue, try to solve it yourself and ping a few people.
## Workflows
When it comes to code contributions we are generally quite process-light, but follow generally accepted principles around separation of concerns, testing code etc. As well as:
- Kanban style development with Github project boards
- Trunk based development https://trunkbaseddevelopment.com/ and small, incremental PRs
- Don't break master (revert commit, then fix)
- 1-2 PR reviews
Please squash to a single commit and rebase before merging to `master` (Github's `Squash and Merge` option for PRs is sufficient). Use a [semantic commit message](chore/update-submodules) for the merged commit. We also use code signing for commits.
For Nim development, follow the [Status Nim style guide](https://status-im.github.io/nim-style-guide/).
It is expected that you watch your GH inbox and do PR reviews every day in order to unblock other team members.
## Channel overview
This is a stub and should eventually contain a brief overview of various channels.

31
topics/vac-overview.md Normal file
View File

@@ -0,0 +1,31 @@
# Vac overview
Vac builds [public good](https://en.wikipedia.org/wiki/Public_good) protocols for the decentralized web.
We do applied research based on which we build protocols, libraries and publications. Custodians of protocols that reflect [a set of principles](https://vac.dev/principles).
While Vac has a core team, it is an open and permission-less organization.
# Projects
There are several projects under Vac Research.
These are largely independent and can be seen as specific bets.
## Secure Messaging
We design modular, p2p protocols for private, anonymous, secure and censorship-resistant communications. The main focus is [Waku](https://waku.org), the communication layer for Web3.
## zk-WASM
Research into making private and provable computation using WASM that is verified using zero-knowledge proofs.
## RAD - RFCs & Dissemination
**RFCs**: We build [specifications](https://rfc.vac.dev) for self-sustainable robust protocols with strong and modular privacy guarantees. [Rough consensus and running code](https://www.ietf.org/about/participate/tao/).
**Dissemination**: We write papers and collaborate closely with other projects/institutions, and aim to build a bridge between industry and academia.
## Applied ZK & Explorations
We build tools to enable new fundamental building blocks using cutting-edge zero-knowledge proof systems. For example, [Zerokit](https://github.com/vacp2p/zerokit/).

29
topics/waku-operator-outreach.md Normal file
View File

@@ -0,0 +1,29 @@
# Waku operator outreach
We want to push for operators to run and maintain their own Waku v2 nodes, preferably contributing to the default Waku v2 network as described by the default pubsub topic (`/waku/2/default-waku/proto`). Amongst other things, a large fleet of stable operator-run Waku v2 nodes will help secure the network, provide valuable services to a variety of platforms and ensure the future sustainability of both Vac as a research organization and the Waku suite of protocols.
Possible motivations for operators to run their own Waku v2 node, include:
1. **own use** - platforms and other users of the Waku v2 network that want to contribute to its usability
2. **incentives** - financial incentives can be tied to the provision of various services through an operator-run node
3. **altruism** - operators who support our principles and want to contribute to a decentralized, censorship-resistant network
We want to focus on all three these motivations in our operator outreach program.
## The role of `nwaku`
We are targeting the `nwaku` (formerly `nim-waku`) client as the main option for operator-run nodes.
Specifically our aim is to provide through `nwaku`:
1. a lightweight and robust Waku v2 client. This client must be first in line to support innovative and new Waku v2 protocols, but configurable enough to serve the adaptive needs of various operators.
2. an easy-to-follow guide for operators to configure, set up and maintain their own nodes
3. a set of operator-focused tools to monitor and maintain a running node
## Metrics
To measure our progress in reaching out to operators, we want to collect metrics that indicate how the stable "backbone" of the network grows over time. This is not necessarily an easy task, as at any given time we expect a large number of ephemeral peers in the network making use of, but not providing any, services themselves.
Two metrics that may give an indication:
1. Growth in `total connections` over time as measured by the set of known bootstrap nodes (our own, and those provided by Status).
2. Current `total content topics` in use, which gives an indication of the number of applications using the network at a given time.
As we incorporate ambient peer discovery mechanisms into `nwaku`, these will provide us with a better measurement of total discoverable nodes in the network. This could even be combined with aliveness checks, to get an idea of the number of _active_ nodes participating over time.

1030
topics/waku-v2-training.md Normal file
View File

File diff suppressed because it is too large Load Diff

0
topics/waku.md Normal file
View File