mirror of https://github.com/logos-co/roadmap.git
Waku milestones and deliverables update (#137)
* move milestones to open and closed folders * move rln mainnet to open milestones folder * update all deliverables for all milestones * small edit
This commit is contained in:
chair
GitHub
parent
292d06fe0f
commit
19245346a3
|
|
@ -1,32 +0,0 @@
|
|||
---
|
||||
title: Bandwidth optimization and protocol review
|
||||
tags:
|
||||
- waku-milestone
|
||||
date: 2024-09-07
|
||||
---
|
||||
|
||||
[Milestone Bandwidth optimization and protocol review](https://github.com/waku-org/pm/milestone/31)
|
||||
|
||||
Due Date: TBD
|
||||
|
||||
Bandwidth measurement from the previous milestone may lead to improvement that should be tackled with this milestone. This should be done in tandem with tackling low-hanging/high value items of the [Status Community protocols potential scaling problems](https://github.com/vacp2p/research/issues/177).
|
||||
|
||||
Finally, usage of content topics should be reviewed to align with Waku’s recommendation, clear migration strategy, caveat and benefits should be outlined, such as future usage of auto-sharding and reduction of topics used by a single user for more efficient use of services.
|
||||
|
||||
### Deliverable: [Status Communities protocol scaling/bandwidth optimization recommendation](https://github.com/waku-org/pm/issues/197)
|
||||
|
||||
Some of the [Status Communities protocols potential scaling problems](https://github.com/vacp2p/research/issues/177) have already been mitigated. However, further work may be needed and identified from simulations and telemetry.
|
||||
|
||||
The output of this deliverable is to compile a list of recommendations, for both Waku and Status Communities protocol. This should include potential benefits of changes and enable scheduling the work between Status and Waku teams.
|
||||
Decision on the work to be done and planning it should be part of the output of this milestone.
|
||||
|
||||
This could include review of discv5 implementation in go-waku and nwaku if bandwidth usage is excessive.
|
||||
|
||||
### Deliverable: [Review usage of content topics in Status Chat and Communities protocol](https://github.com/waku-org/pm/issues/198)
|
||||
|
||||
The usage of content topics in Status is aligned with Wakuv1. Waku v2 comes with a new recommended format that enables auto-sharding.
|
||||
Moreover, single Status users currently use a high number of content topics, which may have an impact on performance of req-res protocols such as store and filter.
|
||||
Such impact is to be measured in a previous milestone by Vac DST.
|
||||
|
||||
The output of this deliverable should be an RFC update on how content topics should be used, backed with simulations when performance improvement is expected.
|
||||
It should include migration strategy and potential impact on the product.
|
||||
|
|
@ -1,38 +0,0 @@
|
|||
---
|
||||
title: Nwaku in Status Desktop
|
||||
tags:
|
||||
- waku-milestone
|
||||
date: 2024-09-07
|
||||
---
|
||||
|
||||
[Milestone Nwaku in Status Desktop (Relay, *nix)](https://github.com/waku-org/pm/milestone/33)
|
||||
|
||||
Due Date: TBD
|
||||
|
||||
With this milestone, Status Desktop builds on Linux and Mac can use nwaku instead of go-waku.
|
||||
Go-waku will still be used for Windows (Desktop) and Status Mobile.
|
||||
|
||||
### Deliverable: [Nwaku in Golang desktop](https://github.com/waku-org/pm/issues/201)
|
||||
|
||||
Provide a Golang library that uses the nwaku bindings (relay+store API) in a desktop environment. The bindings must be usable without RLN for the context of Status Desktop application.
|
||||
|
||||
### Deliverable: [Nwaku in Golang: Relay](https://github.com/waku-org/pm/issues/202)
|
||||
|
||||
Expose and demonstrate the usage of relay protocols/API usef on go-waku by status-go in the Golang nwaku bindings.
|
||||
Build on the previous by adding the APIs used by status-go in relay mode. Proceed with dogfooding of said APIs in PoC app to confirm their behaviour in Golang Desktop environment.
|
||||
This includes work to ensure that the relay reliability protocol implemented in nwaku is used and other libp2p protocols such as autonat, circuit-relay client and hole-punching.
|
||||
|
||||
Light client protocols are out of scope.
|
||||
|
||||
### Deliverable: [Nwaku in Status Desktop (Relay, *nix)](https://github.com/waku-org/pm/issues/203)
|
||||
|
||||
Use nwaku instead of go-waku in Status Desktop and produce a working and distributable special (no light client) build for Linux and Mac OS environments.
|
||||
“Light client” mode should be disabled for this build as only relay protocols are implemented.
|
||||
Windows builds are also out of scope.
|
||||
|
||||
This includes an abstraction layer to enable the other builds to still use go-waku:
|
||||
- Desktop Windows
|
||||
- Desktop “prod” (with both light client and relay modes, via go-waku)
|
||||
- Mobile
|
||||
|
||||
CLIs created for Vac/QA should also be produced with nwaku to enable QA and DST to run tests/simulations.
|
||||
|
|
@ -112,6 +112,7 @@ Epic: RLN validation in production
|
|||
|
||||
Epic: Autosharding - dogfooding
|
||||
- Link: https://github.com/waku-org/pm/issues/58
|
||||
|
||||
### Milestone: Quality Assurance processes are in place
|
||||
-Link: https://github.com/waku-org/pm/milestone/3
|
||||
Due by: 2024-03-31
|
||||
|
|
@ -138,6 +139,7 @@ Epic: End-to-end testing
|
|||
- Issues in Epic:
|
||||
- https://notes.status.im/s/iylE6wdli#
|
||||
- https://github.com/waku-org/go-waku/issues/608
|
||||
|
||||
### Milestone: Support Many Platforms
|
||||
Link: https://github.com/waku-org/pm/milestone/2
|
||||
Due by: 2024-04-30
|
||||
|
|
@ -0,0 +1,33 @@
|
|||
---
|
||||
title: Quality Assurance processes are in place
|
||||
tags:
|
||||
- waku-milestone
|
||||
date: 2024-09-07
|
||||
lastmod: 2024-09-29
|
||||
---
|
||||
|
||||
Link: https://github.com/waku-org/pm/milestone/3
|
||||
Due by: 2024-03-31
|
||||
|
||||
## Epic: Comprehensive Dev Testing
|
||||
- Link: https://github.com/waku-org/pm/issues/90
|
||||
- Issues in Epic:
|
||||
- https://github.com/fryorcraken/milestone-update/
|
||||
- https://github.com/waku-org/js-waku/issues/1589
|
||||
- https://github.com/waku-org/js-waku/issues/1435
|
||||
- https://github.com/waku-org/js-waku/issues/337
|
||||
- https://github.com/waku-org/js-waku/issues/1595
|
||||
- https://github.com/waku-org/js-waku/issues/1597
|
||||
|
||||
## Epic: Automated Release processes
|
||||
- Link: https://github.com/waku-org/pm/issues/86
|
||||
- Issues in Epic:
|
||||
- https://github.com/waku-org/nwaku/issues/1889
|
||||
- https://github.com/waku-org/js-waku/issues/1543
|
||||
- https://github.com/waku-org/waku-rust-bindings/issues/67
|
||||
|
||||
## Epic: End-to-end testing
|
||||
- Link: https://github.com/waku-org/pm/issues/34
|
||||
- Issues in Epic:
|
||||
- https://notes.status.im/s/iylE6wdli#
|
||||
- https://github.com/waku-org/go-waku/issues/608
|
||||
|
|
@ -0,0 +1,33 @@
|
|||
---
|
||||
title: Support 1 Million Users
|
||||
tags:
|
||||
- waku-milestone
|
||||
date: 2024-09-07
|
||||
lastmod: 2024-09-29
|
||||
---
|
||||
|
||||
Link: https://github.com/waku-org/pm/milestone/4
|
||||
Due by: 2023-11-30
|
||||
|
||||
## Epic: Cater for professional operators (Status Communities)
|
||||
- Link: https://github.com/waku-org/pm/issues/92
|
||||
- Issues in Epic:
|
||||
- https://github.com/waku-org/nwaku/issues/1929
|
||||
- https://github.com/fryorcraken/milestone-update/
|
||||
|
||||
## Epic: Simulation with 10k nodes
|
||||
- Link: https://github.com/waku-org/pm/issues/85
|
||||
- Issues in Epic:
|
||||
- https://github.com/vacp2p/research/issues/191
|
||||
|
||||
## Epic: PostgreSQL in service node: Further optimisations
|
||||
- Link: https://github.com/waku-org/pm/issues/84
|
||||
- Issues in Epic:
|
||||
- https://github.com/waku-org/nwaku/issues/1894
|
||||
- https://github.com/waku-org/nwaku/issues/1893
|
||||
- https://github.com/waku-org/nwaku/issues/1888
|
||||
- https://github.com/waku-org/nwaku/issues/1885
|
||||
- https://github.com/waku-org/nwaku/issues/1842
|
||||
- https://github.com/waku-org/nwaku/issues/1841
|
||||
- https://github.com/waku-org/nwaku/issues/1840
|
||||
- https://github.com/waku-org/nwaku/issues/1604
|
||||
|
|
@ -0,0 +1,37 @@
|
|||
---
|
||||
title: Support Many Platforms
|
||||
tags:
|
||||
- waku-milestone
|
||||
date: 2024-09-07
|
||||
lastmod: 2024-09-29
|
||||
---
|
||||
|
||||
Link: https://github.com/waku-org/pm/milestone/2
|
||||
Due by: 2024-04-30
|
||||
|
||||
## Epic: Ship RLN as part of non-native SDKs
|
||||
- Link: https://github.com/waku-org/pm/issues/88
|
||||
- Issues in Epic:
|
||||
- https://github.com/waku-org/go-zerokit-rln/issues/5
|
||||
- https://github.com/waku-org/go-waku/issues/732
|
||||
- https://github.com/waku-org/nwaku/issues/2033
|
||||
- https://github.com/fryorcraken/milestone-update/
|
||||
|
||||
## Epic: REST API service node
|
||||
- Link: https://github.com/waku-org/pm/issues/82
|
||||
- Issues in Epic:
|
||||
- https://github.com/waku-org/nwaku/issues/1988
|
||||
- https://github.com/waku-org/nwaku/issues/1985
|
||||
- https://github.com/waku-org/nwaku/issues/1910
|
||||
- https://github.com/waku-org/nwaku/issues/1909
|
||||
- https://github.com/waku-org/nwaku/issues/1872
|
||||
- https://github.com/waku-org/nwaku/issues/1652
|
||||
- https://github.com/waku-org/nwaku/issues/1214
|
||||
- https://github.com/waku-org/nwaku/issues/1076
|
||||
- https://github.com/waku-org/nwaku/issues/938
|
||||
- https://github.com/waku-org/go-waku/issues/264
|
||||
|
||||
## Epic: NodeJS Library
|
||||
- Link: https://github.com/waku-org/pm/issues/81
|
||||
- Issues in Epic:
|
||||
- https://github.com/waku-org/nwaku/issues/1332
|
||||
|
|
@ -0,0 +1,87 @@
|
|||
---
|
||||
title: Waku Network Gen 0
|
||||
tags:
|
||||
- waku-milestone
|
||||
date: 2024-09-07
|
||||
lastmod: 2024-09-29
|
||||
---
|
||||
|
||||
Link: https://github.com/waku-org/pm/milestone/1
|
||||
Due by: 2023-12-01
|
||||
|
||||
## Epic: 3.4: Production and memberships on mainnet
|
||||
- Link: https://github.com/waku-org/pm/issues/87
|
||||
|
||||
## Epic: 3.4: Further memberships
|
||||
- Link: https://github.com/waku-org/pm/issues/72
|
||||
|
||||
## Epic: 3.3: Membership for Status Communities
|
||||
- Link: https://github.com/waku-org/pm/issues/71
|
||||
|
||||
## Epic: 3.2: Basic DoS protection in production
|
||||
- Link: https://github.com/waku-org/pm/issues/70
|
||||
- Issues in Epic:
|
||||
- https://github.com/waku-org/go-waku/issues/732
|
||||
- https://github.com/waku-org/go-waku/issues/731
|
||||
- https://github.com/waku-org/go-waku/issues/655
|
||||
|
||||
## Epic: 1.5: Launch and dogfood integrated public Waku Network MVP
|
||||
- Link: https://github.com/waku-org/pm/issues/68
|
||||
- Issues in Epic:
|
||||
- https://github.com/waku-org/research/issues/1
|
||||
|
||||
## Epic: 1.4: Sharded peer management and discovery
|
||||
- Link: https://github.com/waku-org/pm/issues/67
|
||||
- Issues in Epic:
|
||||
- https://github.com/waku-org/nwaku/issues/1941
|
||||
- https://github.com/waku-org/nwaku/issues/1940
|
||||
- https://github.com/waku-org/js-waku/issues/1505
|
||||
- https://github.com/waku-org/js-waku/issues/1504
|
||||
- https://github.com/waku-org/go-waku/issues/727
|
||||
- https://github.com/waku-org/go-waku/issues/680
|
||||
- https://github.com/waku-org/go-waku/issues/679
|
||||
- https://github.com/waku-org/go-waku/issues/678
|
||||
|
||||
## Epic: 1.3: Node bandwidth management mechanism
|
||||
- Link: https://github.com/waku-org/pm/issues/66
|
||||
- Issues in Epic:
|
||||
- https://github.com/waku-org/nwaku/issues/1947
|
||||
- https://github.com/waku-org/nwaku/issues/1946
|
||||
- https://github.com/waku-org/nwaku/issues/1945
|
||||
- https://github.com/waku-org/nwaku/issues/1938
|
||||
- https://github.com/waku-org/js-waku/issues/1503
|
||||
- https://github.com/waku-org/go-waku/issues/677
|
||||
|
||||
## Epic: 1.2: Autosharding for autoscaling
|
||||
- Link: https://github.com/waku-org/pm/issues/65
|
||||
- No issues in Epic description.
|
||||
|
||||
## Epic: 2.3: Basic distributed Store services
|
||||
- Link: https://github.com/waku-org/pm/issues/64
|
||||
|
||||
|
||||
## Epic: 2.2: Sharded capability discovery for light protocols
|
||||
- Link: https://github.com/waku-org/pm/issues/63
|
||||
- Issues in Epic:
|
||||
- https://github.com/waku-org/js-waku/issues/1506
|
||||
|
||||
## Epic: 2.1: Production testing of existing protocols
|
||||
- Link: https://github.com/waku-org/pm/issues/49
|
||||
- Issues in Epic:
|
||||
- https://github.com/waku-org/nwaku/issues/1950
|
||||
- https://github.com/waku-org/nwaku/issues/1948
|
||||
- https://github.com/waku-org/nwaku/issues/1888
|
||||
- https://github.com/waku-org/js-waku/issues/1463
|
||||
- https://github.com/waku-org/js-waku/issues/914
|
||||
|
||||
## Epic: Dogfood RLN in production
|
||||
- Link: https://github.com/waku-org/pm/issues/51
|
||||
|
||||
## Epic: Open membership mechanism
|
||||
- Link: https://github.com/waku-org/pm/issues/52
|
||||
|
||||
## Epic: RLN validation in production
|
||||
- Link: https://github.com/waku-org/pm/issues/55
|
||||
|
||||
## Epic: Autosharding - dogfooding
|
||||
- Link: https://github.com/waku-org/pm/issues/58
|
||||
|
|
@ -0,0 +1,60 @@
|
|||
---
|
||||
title: Bandwidth optimization and protocol review
|
||||
tags:
|
||||
- waku-milestone
|
||||
date: 2024-09-07
|
||||
---
|
||||
|
||||
[Milestone Bandwidth optimization and Communities protocol review](https://github.com/waku-org/pm/milestone/31)
|
||||
|
||||
Estimated Date of Completion: Q2 2025, Precise date to be provided as part of 2024 H1 planning.
|
||||
|
||||
Once completed, further specification and analysis of Status Communities and some chat protocols will be available; as well as a recommendation on how Status Communities protocol should use Waku in a scalable and bandwidth efficient manner.
|
||||
|
||||
Moreover, low hanging-fruits and temporary solutions to improve bandwidth consumption would have been implemented.
|
||||
|
||||
### Deliverable: [Minimal Community Specification and Implementation]()
|
||||
|
||||
1. Specify community procedures, including the encryption, reliability and functional scope of each. [This forum post](https://forum.vac.dev/t/chat-protocol-work-for-2025-codex-integration-organisation-proposal/311) serves as a starting point.
|
||||
2. Using spec from (1) as a basis, define message flows to be moved to separate shards (e.g. community control + content messages). Extracting community messages off the common open shard (also used by 1:1 chats) should be considered.
|
||||
|
||||
As well as other low-hanging fruit improvements previously identified.
|
||||
|
||||
Breaking changes and migration plans, if necessary, should be specified as part of this output.
|
||||
|
||||
Finally, proceed with the implementation of (2).
|
||||
|
||||
### Deliverable: [Telemetry review](https://github.com/waku-org/pm/issues/264)
|
||||
|
||||
Using the output of [Telemetry: Measure Bandwidth]() and [Minimal Community Specification and Implementation]() (traffic separated by shards), analyse the distribution of traffic on relay, and data in store. Providing a report in terms of Status Chat functionality.
|
||||
|
||||
### Deliverable: [Minimal solution for greedy messages](https://github.com/waku-org/pm/issues/265)
|
||||
|
||||
Based on [telemetry review](), specify and implement a workaround solution (light push + store) that removes most data greedy functionality from the relay network.
|
||||
|
||||
At the time of writing, we assume that self-addressed messages (backup/sync) and community description messages would be affected by this change.
|
||||
|
||||
### Deliverable: [Define long-term solution](https://github.com/waku-org/pm/issues/267)
|
||||
|
||||
The output of this deliverable is to compile a list of recommendations, for Waku, Status Communities and chat protocols. This should include potential benefits of changes and enable scheduling the work between Status and Waku teams.
|
||||
Decision on the work to be done and planning it should be part of the output of this deliverable.
|
||||
|
||||
The recommendation should be grounded in the output of the previous deliverables of this milestone.
|
||||
|
||||
The recommendation is unlikely to encompass the entire chat protocol, and all status message types due to the amount of work it would entailed. Instead, an empirical approach should be taken where changes are prioritised based on the user impact, known limitations and functionalities (e.g. profile backup and device pairing usage of Waku), and telemetry metrics.
|
||||
|
||||
This would impact any current usage of Waku by the Status app. Which does include communities, 1:1 chat but profile back and device pairing.
|
||||
|
||||
This could include review of discv5 implementation in go-waku and nwaku if bandwidth usage is excessive.
|
||||
|
||||
### Deliverable: [Review usage of content topics in Status Communities protocol](https://github.com/waku-org/pm/issues/268)
|
||||
|
||||
The usage of content topics in Status is aligned with Wakuv1. Waku v2 comes with a new recommended format that enables auto-sharding.
|
||||
|
||||
Moreover, single Status users currently use a high number of content topics, which may have an impact on performance of req-res protocols such as store and filter.
|
||||
|
||||
Such impact is to be measured in a previous milestone by Vac DST.
|
||||
|
||||
The output of this deliverable should be an RFC update on how content topics should be used, backed with simulations when performance improvement is expected.
|
||||
|
||||
It should include migration strategy and potential impact on the product.
|
||||
|
|
@ -0,0 +1,86 @@
|
|||
---
|
||||
title: Demonstrate product market-fit
|
||||
tags:
|
||||
- waku-milestone
|
||||
date: 2024-09-07
|
||||
---
|
||||
|
||||
## Milestone: [Demonstrate product market-fit](https://github.com/waku-org/pm/milestone/36)
|
||||
|
||||
To demonstrate the viability of Waku as a self-sustainable independent project, user traction and market fitness must be proven. Validation against the market of Waku’s technology and potential USP is needed.
|
||||
|
||||
Such validation can enable prioritisation of work and potentially dropping undesired features.
|
||||
|
||||
### Deliverable: [Define cost (self-host)](https://github.com/waku-org/pm/issues/247)
|
||||
|
||||
Cost of using Waku needs to be assessed to enable projects, including Status, to understand the potential ROI in using Waku.
|
||||
|
||||
The output of this deliverable should provide an estimate, in terms of infrastructure costs of using Waku for running:
|
||||
- Status 1:1 chats
|
||||
- Also cover RPC API prices
|
||||
- a community (whether done by Status or an external community owner)
|
||||
- Also cover RPC API prices
|
||||
- vanilla Waku, by using existing integration (e.g. railgun or the graph) as a reference.
|
||||
- all the above, adding RLN cost
|
||||
|
||||
Note: depends on PostgreSQL Optimisation - phase 2 deliverable for infrastructure costs.
|
||||
|
||||
### Deliverable: [The Waku Whitepaper](https://github.com/waku-org/pm/issues/248)
|
||||
|
||||
Write an academically rigorous whitepaper explaining the what, why and how of Waku protocols and ensure the coherence of the Waku technology.
|
||||
|
||||
As set out in [research#7](https://github.com/waku-org/research/issues/7). The document itself may source from one or more academic papers published and presented throughout the year. Total length should be around 15 pages.
|
||||
|
||||
### Deliverable: [Define potential USPs](https://github.com/waku-org/pm/issues/249)
|
||||
|
||||
Define Waku products and features, and potential problems they may solve. Some of it is already captured in the validation matrix.
|
||||
|
||||
This can be used as a basis when proceeding with market and product research.
|
||||
|
||||
Items can be validated, invalidated or new items can be recorded as part of research.
|
||||
|
||||
This deliverable includes an update of the waku.org website to ensure that the USPs are clear to potential customers.
|
||||
|
||||
### Deliverable: [Define target customers](https://github.com/waku-org/pm/issues/250)
|
||||
|
||||
Target customers and segments have been identified and presented in Athens all-hands.
|
||||
|
||||
A more formal capture should be done, with tracking in IFT CRM (using Segment attribute for example). IFT’s recommendation suggested a focus on the DeFi segment; experience has shown that intent and AI inference networks are promising.
|
||||
|
||||
A document should capture:
|
||||
- Customer segments
|
||||
- Market size of each segment
|
||||
- Potential problems and Waku USPs potentially relevant to segment
|
||||
- Competitors to Waku, other solutions in use
|
||||
- Learning so far, including interviews (next deliverable)
|
||||
- Rational in favour/against pursuing segment
|
||||
|
||||
This document + IFT CRM + Validation matrix are the core material for Waku GTM.
|
||||
~5 segments must be identified to proceed with customer interviews.
|
||||
|
||||
### Deliverable: [Customer Interviews](https://github.com/waku-org/pm/issues/251)
|
||||
|
||||
Proceed with ~10 interviews of current and interested customers, spread across the ~5 identified segments.
|
||||
|
||||
Understand their problems around peer-to-peer networking and capture in the validation matrix which of Waku’s offering may be of interest, or new problems related to peer-to-peer networking to be covered by Waku.
|
||||
|
||||
Interviews should have a dedicated ~5 questions to get answers:
|
||||
- Role of p2p network protocol
|
||||
- Current problems
|
||||
- etc.
|
||||
|
||||
To help establish the product-fit and identify potential blockers. This is should be detached from Waku, more about discussing p2p network and messaging role in the project’s protocol and their challenges.
|
||||
|
||||
When synthesising the interviews, a review of segments should be done to select and focus on segments with most potential.
|
||||
|
||||
### Deliverable: [Co-design sessions](https://github.com/waku-org/pm/issues/252)
|
||||
|
||||
At Devcon 2024, organise 3-4 co-design sessions to sit down to discuss potential Waku integration in more detail. Targeting customers in most promising segments deduced from customer interviews. This acts as a follow-up to the customer interviews deliverable and will require Waku engineers to attend.
|
||||
|
||||
### Deliverable: [Review Waku MVP](https://github.com/waku-org/pm/issues/253)
|
||||
|
||||
Based on customer interviews and co-design sessions, identify the Waku USPs with most potential and outline an MVP.
|
||||
|
||||
Based on Waku’s current state and roadmap, review if additional deliverables to fill technical gaps (if any) are needed, or what currently planned deliverables must be completed.
|
||||
|
||||
Communicate with targeted customers on MVP.
|
||||
|
|
@ -6,7 +6,7 @@ date: 2024-09-07
|
|||
---
|
||||
[Milestone Direct Message Reliability](https://github.com/waku-org/pm/milestone/28)
|
||||
|
||||
Due Date: 2024-09-02
|
||||
Estimated Date of Completion: 2024-10-30
|
||||
|
||||
With this milestone, connectivity issues in Status Mobile and Desktop are solved and tested.
|
||||
Usage of store v3-beta casts a wide net on potential message loss, at the cost of bandwidth overhead (but still lower than current usage of storev2).
|
||||
|
|
@ -68,7 +68,22 @@ In this particular instance, **js-waku will be the reference implementation** of
|
|||
This deliverable includes the implementation of this protocol in go-waku (nwaku excluded). Work should be done in parallel and feed from each other.
|
||||
The intent is to compose light push, filter and store v3-beta in combination.
|
||||
|
||||
### Deliverable: [User apps for large scale dogfooding](https://github.com/waku-org/pm/issues/188)
|
||||
### Deliverable: [PostgreSQL Optimisation phase 1](https://github.com/waku-org/pm/issues/260)
|
||||
|
||||
Continue work to improve PostgreSQL query performance. Focus on queries with direct impact on UX. E.g. hash query to get store message confirmation.
|
||||
|
||||
Stress-testing of store queries by the Waku testing engineer has started and can be used as a baseline. Also, a dashboard will be built to better track store performance over time.
|
||||
|
||||
Following activities will be performed:
|
||||
- Review of store stressing test results and tackle inconsistency and poor performance
|
||||
- Review with PostgreSQL expert (IFT CC) potential improvements and implement them
|
||||
|
||||
Stress testing of Waku Store can be used as a base to measure the gains from the optimization. Two phases are expected:
|
||||
- Preliminary work with IFT CC to cover basis and prepare for consultation (phase 1)
|
||||
- Consultation with an external agency for fine tuning. (phase 2, separate deliverable and milestone)
|
||||
|
||||
|
||||
### Deliverable: [Dogfooding app PoC](https://github.com/waku-org/pm/issues/188)
|
||||
|
||||
Note: new deliverable, stemmed from discussion with js-waku team who have been working on resource-restricted reliability since earlier this year. Yet to be estimated and planned.
|
||||
|
||||
|
|
@ -7,7 +7,7 @@ date: 2024-09-07
|
|||
|
||||
[Milestone End-to-end reliability protocol](https://github.com/waku-org/pm/milestone/29)
|
||||
|
||||
Due Date: 2024-09-02
|
||||
Estimated Date of Completion: 2024-11-25
|
||||
|
||||
To solve reliability is to solve two problems:
|
||||
|
||||
|
|
@ -21,14 +21,6 @@ To solve (2), is to create an end-to-end protocol, sender to recipient, that ena
|
|||
With this milestone, we design and deliver a first PoC for an end-to-end reliability protocol.
|
||||
This protocol will be specified and implemented in the Status app for Status Communities chat rooms.
|
||||
|
||||
### Deliverable: [Telemetry: multicast message reliability](https://github.com/waku-org/pm/issues/192)
|
||||
|
||||
Review and ensure the telemetry service can provide accurate statistics on message reliability with a mix of online presence report, message sending and receiving.
|
||||
The measurement should be specific to multicast messages to ensure that deliverables above do improve reliability in real usage.
|
||||
This should include content topic data, to be used for later optimization.
|
||||
For both Desktop and Mobile.
|
||||
Note that from Status’ team experience, the telemetry statistics have usually been more optimistic than reality, especially when there is a full network drop (ie, no messages going out).
|
||||
|
||||
### Deliverable: [End-to-end reliability protocol - PoC](https://github.com/waku-org/pm/issues/193)
|
||||
|
||||
Design a protocol that enables end-to-end reliability for Status Communities channels.
|
||||
|
|
@ -0,0 +1,38 @@
|
|||
---
|
||||
title: Nwaku in Status Desktop
|
||||
tags:
|
||||
- waku-milestone
|
||||
date: 2024-09-07
|
||||
---
|
||||
|
||||
[Milestone Nwaku in Status Desktop (Relay mode)](https://github.com/waku-org/pm/milestone/33)
|
||||
|
||||
Estimated date of delivery: 2025-01-31
|
||||
|
||||
There is work duplication in go-waku and nwaku due to the common area of concern: relay usage and native library.
|
||||
|
||||
With this milestone, Status Desktop builds can use nwaku instead of go-waku. However, it should be seen as a MVP as further hardening and implementation of light client mode will be missing.
|
||||
Go-waku will still be used for Status Mobile.
|
||||
|
||||
This strategy enables concrete steps toward sunsetting go-waku in a short period of time, avoiding a perpetual prototyping phase where many high risk problems (e.g. mobile bundle size, etc) have to be solved before the switch can be made.
|
||||
|
||||
The next milestone will then focus on hardening the nwaku Desktop build and implement missing features such as [Reliability Protocol for resource-restricted](). Once done, it will reduce the scope of go-waku maintenance to light clients only and drastically reduce the duplicate work done between nwaku and go-waku.
|
||||
|
||||
Note that we want to draw the line to RLN in terms of go-waku maintenance, meaning that if Status were to use RLN (see [Scale 1:1 chat messages PoC]()), then it should happen with nwaku.
|
||||
|
||||
### Deliverable: [Nwaku on Windows](https://github.com/waku-org/pm/issues/239)
|
||||
|
||||
Ensure that nwaku can build and run on Windows. This includes regular PR CI and test run done on Windows environments.
|
||||
|
||||
### Deliverable: [Nwaku in Status Desktop (Relay)](https://github.com/waku-org/pm/issues/203)
|
||||
|
||||
Use nwaku instead of go-waku in Status Desktop and produce a working and distributable special (no light client) build for Linux and Mac OS environments.
|
||||
“Light client” mode should be disabled for this build as only relay protocols are implemented.
|
||||
Windows builds are also out of scope.
|
||||
|
||||
This includes an abstraction layer to enable the other builds to still use go-waku:
|
||||
- Desktop Windows
|
||||
- Desktop “prod” (with both light client and relay modes, via go-waku)
|
||||
- Mobile
|
||||
|
||||
CLIs created for Vac/QA should also be produced with nwaku to enable QA and DST to run tests/simulations.
|
||||
|
|
@ -5,9 +5,9 @@ tags:
|
|||
date: 2024-09-07
|
||||
---
|
||||
|
||||
# [RLN Mainnet](https://github.com/waku-org/pm/milestone/34)
|
||||
## [RLN Mainnet](https://github.com/waku-org/pm/milestone/34)
|
||||
|
||||
Due Date: 2024-12-31
|
||||
Estimated date of Completion: 2024-12-31
|
||||
|
||||
Once complemented, the economical behaviour of RLN will have been specified, implemented and discussed with the Status team.
|
||||
An implementation of RLN for light clients will also be done, to demonstrate RLN’s UX with onchain Merkle tree.
|
||||
|
|
@ -15,13 +15,13 @@ Finally, the smart contract will be deployed on mainnet.
|
|||
|
||||
It will be then possible to design the usage of RLN in Status 1:1 chats.
|
||||
|
||||
## Deliverable: [RLNv2 in nwaku](https://github.com/waku-org/pm/issues/204)
|
||||
### Deliverable: [RLNv2 in nwaku](https://github.com/waku-org/pm/issues/204)
|
||||
|
||||
Improved flexibility of the rate limit (from 1 msg/epoch to N msg/epoch), providing better dimensioning for bandwidth capping.
|
||||
Moving from RLNv1 to RLNv2 to allow better bandwidth dimensioning in the network. This will allow a message allocation per hour or day per registered publisher, providing better statistical guarantees for network bandwidth usage.
|
||||
Note this only concerns native libraries using nwaku.
|
||||
|
||||
## Deliverable: [Maturing RLN variables/parameters revision (staking, contract/chain, token) - roadmap](https://github.com/waku-org/pm/issues/205)
|
||||
### Deliverable: [Maturing RLN variables/parameters revision (staking, contract/chain, token) - roadmap](https://github.com/waku-org/pm/issues/205)
|
||||
|
||||
*A review of RLN security parameters and functionality in preparation for mainnet deployment.*
|
||||
Analyse RLN deployment in the Waku proto-network and evaluate its DoS protection performance as well as review with the Status app team the potential cost mode of RLN:
|
||||
|
|
@ -31,8 +31,15 @@ Analyse RLN deployment in the Waku proto-network and evaluate its DoS protection
|
|||
- What token should be used?
|
||||
- Do we need a combination of msg/sec and msg allocation/day rate limiting?
|
||||
|
||||
### Deliverable: [Provision RLN for light push clients POC](https://github.com/waku-org/pm/issues/206)
|
||||
|
||||
## Deliverable: [Implement RLN smart contract for paid, multilevel memberships](https://github.com/waku-org/pm/issues/256)
|
||||
Design and implement a protocol that attaches RLN proof for messages received by light push services, enabling light clients to use the network without RLN.
|
||||
|
||||
With this deliverable, nwaku nodes deployed as service nodes lend their RLN memberships to light clients. Enabling Status app to offer a free tiers usage of RLN Relay for 1:1 chat messages.
|
||||
|
||||
This is a first PoC, learnings around RLN rate limit parameters, need of multiple RLN managements and service capability are expected to drive further development.
|
||||
|
||||
### Deliverable: [Implement RLN smart contract for paid, multilevel memberships](https://github.com/waku-org/pm/issues/256)
|
||||
|
||||
This deliverable is an output of Maturing RLN variables/parameters revision (staking, contract/chain, token) - roadmap.
|
||||
|
||||
|
|
@ -44,12 +51,12 @@ Expiry of memberships to prevent hogging
|
|||
Support for RLN in resource-restricted clients, i.e. lightweight proof generation and validation
|
||||
The exact set of features is to be defined in a RFC, as output of Maturing RLN variables/parameters revision (staking, contract/chain, token) - roadmap.
|
||||
|
||||
## Deliverable: [RLN contract revision and audit](https://github.com/waku-org/pm/issues/257)
|
||||
### Deliverable: [RLN contract revision and audit](https://github.com/waku-org/pm/issues/257)
|
||||
|
||||
Once a minimal set of smart contract features for RLN has been implemented, the contract needs to be thoroughly revised (and possibly audited) by a group of experts before it can be used in production.
|
||||
The Waku team will rely on Vac/SC to proceed/organise the smart contract review and audit
|
||||
|
||||
## Deliverable: [Deploy RLN smart contract to a L2 mainnet](https://github.com/waku-org/pm/issues/258)
|
||||
### Deliverable: [Deploy RLN smart contract to a L2 mainnet](https://github.com/waku-org/pm/issues/258)
|
||||
|
||||
The RLN smart contract should be deployed to a Layer 2 mainnet.
|
||||
|
||||
|
|
@ -57,7 +64,7 @@ A first step here may be to deploy to a Layer 2 testnet first. However, we could
|
|||
|
||||
This deliverable tracks all steps to deployment of a production version of the contract to a L2.
|
||||
|
||||
## Deliverable: [Public dogfooding RLNaaS web app](https://github.com/waku-org/pm/issues/259)
|
||||
### Deliverable: [Public dogfooding RLNaaS web app](https://github.com/waku-org/pm/issues/259)
|
||||
Second part of original scope of dogfooding web app.
|
||||
|
||||
One of the proposed strategies to roll out RLN for Status 1:1 chats is to use RLNaaS where a service node attaches RLN proof for light clients. This would enable a roll out of RLN without impacting UX or UI.
|
||||
|
|
@ -7,7 +7,7 @@ date: 2024-09-07
|
|||
|
||||
[Milestone Scale up number of Communities](https://github.com/waku-org/pm/milestone/32)
|
||||
|
||||
Due Date: TBD
|
||||
Estimated Date of Completion: 2024-11-30
|
||||
|
||||
Proceed with next steps to scale up the number of communities with a focus on testing and configure rendezvous which would enable a large number of communities on their own shard, with the caveat of a more federated global topology.
|
||||
The rendezvous nodes of a community would be a centralised infra to a community.
|
||||
|
|
@ -7,7 +7,7 @@ date: 2024-09-07
|
|||
|
||||
[Milestone Static Sharding - dedicated shards](https://github.com/waku-org/pm/milestone/30)
|
||||
|
||||
Due Date: 2024-09-30
|
||||
Estimated Date of Completion: 2024-12-31
|
||||
|
||||
Creating a new community on its dedicated shard would be tested and working, including assigning a pre-shared key for opt-in message signing (weak DoS protection).
|
||||
|
||||
|
|
@ -22,6 +22,13 @@ Finally, telemetry service will be updated to include bandwidth usage statistics
|
|||
Add bandwidth measurements to the self-report (opt-in) telemetry service, including a message type breakdown (ctrl, chat, etc) when possible as well as other protocols such as discovery.
|
||||
Usage of non-waku bandwidth should also be considered (bittorrent, RPC) to have a full picture in case of report of high bandwidth usage by users.
|
||||
|
||||
### Deliverable: [Telemetry: Sharding](https://github.com/waku-org/pm/issues/261)
|
||||
|
||||
Improve telemetry service to capture shard information. Particularly relevant for discovery and connection.
|
||||
|
||||
Improve API to display shard information to users in the node management tab, to provide more accurate health metrics.
|
||||
|
||||
|
||||
### Deliverable: [Sharding peer management and discovery hardening](https://github.com/waku-org/pm/issues/172)
|
||||
|
||||
Further testing and improvement of peer management in the context of sharding in all Waku implementations. The aim is to ensure that nodes are connected to other nodes of interested shards. As the number of shards (several communities) increase, some improvement on the logic should be needed.
|
||||
|
|
@ -44,3 +51,21 @@ This includes the setup of a pre-shared key to protect the shard and fixing any
|
|||
Note that the ability to create communities on a custom shard and assign a pre-shared key for DoS protection is already implemented in status-go.
|
||||
|
||||
Note that telemetry service should include shard specific reports.
|
||||
|
||||
### Deliverable: [Setup Waku Community on dedicated shard with pre-shared key dos protection](https://github.com/waku-org/pm/issues/262)
|
||||
|
||||
Create a Waku token-gated community on its own dedicated shard to further dog food sharding, find and fix any Waku related bugs as well as providing support to the Status app team.
|
||||
|
||||
The outputs of this deliverable are:
|
||||
- Waku token-gated community created on dedicated shard. While this community may not be advertised publicly at first, it will be set up as if, with Waku CC and IFT CCs roles being defined etc.
|
||||
- Document that summarises the steps to setup a dedicated community, where IFT devops are provisioning the new shard, and setting pre-shared key in coordination with community owner.
|
||||
|
||||
### Deliverable: [PostgreSQL Optimisation phase 2](https://github.com/waku-org/pm/issues/263)
|
||||
|
||||
With phase 1, feedback from test stressing and IFT CC has been tackled.Preparation has been done to consult an external agency to fine tune PostgreSQL setup.
|
||||
|
||||
Phase 2 tracks the consultation with the external agency and follow-up work:
|
||||
|
||||
- Once all suggestions from IFT PostgreSQL expert are implemented, setup an agreement with consulting agency specialised in PostgreSQL performance to improve performance
|
||||
|
||||
This should include a better understanding of hardware requirements expectations to run Waku infra for Status.
|
||||
|
|
@ -6,7 +6,7 @@ date: 2024-09-07
|
|||
---
|
||||
[Milestone Store Service Upgrade](https://github.com/waku-org/pm/milestone/27)
|
||||
|
||||
Due Date: 2024-09-20
|
||||
Estimated date of completion: 2024-09-20
|
||||
|
||||
With this milestone, the store protocol becomes more easily usable for reliability purposes.
|
||||
Moreover, nwaku PostgreSQL implementation will enable better disk space management and enable operators to hard cap the used disk space.
|
||||
|
|
@ -0,0 +1,27 @@
|
|||
---
|
||||
title: Acquire first 10 customers
|
||||
tags:
|
||||
- waku-milestone
|
||||
date: 2024-09-07
|
||||
---
|
||||
|
||||
## Milestone: [Acquire first 10 Customers](https://github.com/waku-org/pm/milestone/37)
|
||||
|
||||
Onboard Waku first 10 customers. Customers are projects using Waku for their peer-to-peer communication stack.
|
||||
First 10 customers assume involvement from the engineering team to get things right and help co-design.
|
||||
|
||||
Status, Railgun, TheGraph and Portrait should count as the first four.
|
||||
|
||||
### Deliverable: [5-10 Highly qualified leads](https://github.com/waku-org/pm/issues/254)
|
||||
|
||||
Identify 5-10 leads that have strong chances to go with Waku:
|
||||
- How many recurring co-design meetings have been scheduled.
|
||||
- How many collaboration Discord bridges have been setup
|
||||
- Moved to the Solutioning column in IFT BD CRM.
|
||||
|
||||
|
||||
### Deliverable: [Review current integrations](https://github.com/waku-org/pm/issues/255)
|
||||
|
||||
Organise monthly catch-up calls with Railgun, TheGraph, Portrait and any other integrated customers to review their usage of Waku. Discuss their current problems and future goals.
|
||||
|
||||
Cover latest Waku development, including RLN mainnet contract parameters.
|
||||
Loading…
Reference in New Issue