mirror of
https://github.com/logos-messaging/pm.git
synced 2026-01-02 14:13:09 +00:00
2025 H2 Roadmap
Roadmap, milestones and FURPS for 2025 H2
This commit is contained in:
fryorcraken
parent
9ebaee4b1c
commit
1b6db44e39
39
FURPS/application/network_metrics_tracker.md
Normal file
39
FURPS/application/network_metrics_tracker.md
Normal file
@ -0,0 +1,39 @@
|
||||
# Network Metrics Tracker FURPS
|
||||
|
||||
## Functionality
|
||||
|
||||
1. Metrics that can be learned from network observations are available
|
||||
2. Display number of nodes discovered over discv5, by shard
|
||||
3. Display number of nodes successfully connected to, by shard and user agent, in last hour, day, week
|
||||
4. Display number of light protocol clients fleet nodes had a inbound connection of, by libp2p protocol, user agent, libp2p transport, and shard, in last hour, day, week; using unique peer id as identifier
|
||||
5. Number of messages unique messages seen, by shard
|
||||
6. Inbound and outbound bandwidth, by shard
|
||||
7. Number of different content topics in last hour, day and week; considering full content topic and application name.
|
||||
8. Average and max message size by shard
|
||||
9. Messages stored by fleet store nodes: total size, number, oldest timestamp, by shard
|
||||
|
||||
## Usability
|
||||
|
||||
1. Metrics above are available publicly for the network of major integrations (Status, RAILGUN, TWN).
|
||||
|
||||
## Reliability
|
||||
|
||||
1. Metrics should be available 90% of the time.
|
||||
|
||||
## Performance
|
||||
|
||||
1. The data is updated at least hourly
|
||||
2. At least 3 months of data is available
|
||||
|
||||
## Supportability
|
||||
|
||||
1. Grafana dashboards
|
||||
2. Some metrics may be retrieved by a Waku monitor node with aggressive parameters, other from existing fleet nodes;
|
||||
this includes running limited fleet nodes for other networks.
|
||||
|
||||
## + (Privacy, Anonymity, Deployments)
|
||||
|
||||
1. No IP or Peer Ids are tracked or displayed.
|
||||
2. Dashboard deployed for The Waku Network
|
||||
3. Dashboard deployed for Status Waku Network
|
||||
4. Dashboard deployed for RAILGUN Waku Network
|
||||
20
FURPS/core/mix.md
Normal file
20
FURPS/core/mix.md
Normal file
@ -0,0 +1,20 @@
|
||||
# Mixnet FURPS
|
||||
|
||||
## Functionality
|
||||
|
||||
1. Relay nodes can mount mixnet protocol, acting as entry, exit or mixnet nodes.
|
||||
2. Nodes can discover mixnet relay and exit nodes using available peer discovery mechanisms.
|
||||
3. Client nodes can send light push requests over the mixnet before delivery to a service node.
|
||||
4. Client nodes can receive a response to a light push request over the mixnet.
|
||||
|
||||
## Usability
|
||||
|
||||
## Reliability
|
||||
|
||||
## Performance
|
||||
|
||||
## Supportability
|
||||
|
||||
1. nwaku CLI
|
||||
|
||||
## + (Privacy, Anonymity, Deployments)
|
||||
36
FURPS/core/waku_api.md
Normal file
36
FURPS/core/waku_api.md
Normal file
@ -0,0 +1,36 @@
|
||||
# Waku API FURPS
|
||||
|
||||
(proposing to move away from "messaging api" to avoid confusion)
|
||||
|
||||
## Functionality
|
||||
|
||||
1. Setup, start and stop a Waku node.
|
||||
2. Support edge node operation mode.
|
||||
3. Support relay node operation mode.
|
||||
4. Does automatic peer discovery based on the node platform and operation mode.
|
||||
5. Returns health and connectivity information using proven heuristics.
|
||||
|
||||
## Usability
|
||||
|
||||
1. When setting up a Waku node, no need to specify what protocols to mount, only an operational mode (edge or relay).
|
||||
2. Disconnection detection and recovery, and other peer management matters are automatically handled.
|
||||
3. Developers do not need to specify the protocols used to send and receive messages; it is deduced from the mode of operation.
|
||||
4. Developers pass and receive data to the API in types native to the wrapping language.
|
||||
5. By default, auto-sharding is applied, meaning developers do not need to be concerned by sharding; pubsub topics are never exposed.
|
||||
|
||||
## Reliability
|
||||
|
||||
1. Sends a message using peer-to-peer reliability (service node redundancy for edge, optional store confirmation)
|
||||
2. Receives messages using peer-to-peer reliability (service node redundancy for edge, periodic store query, periodic filter ping)
|
||||
|
||||
## Performance
|
||||
|
||||
## Supportability
|
||||
|
||||
1. Nim library
|
||||
2. Golang library
|
||||
3. Browser
|
||||
|
||||
## + (Privacy, Anonymity, Deployments)
|
||||
|
||||
1. ...
|
||||
@ -2,7 +2,59 @@
|
||||
|
||||
Finalised roadmap and milestones can be found on the [Logos roadmap](https://roadmap.logos.co/waku/).
|
||||
|
||||
Period in planning: 2025 H1
|
||||
Period in planning: 2025 H2
|
||||
|
||||
## Proposed Priorities
|
||||
|
||||
### Whole Team
|
||||
|
||||
1. **Support Status application**: continue integration of nwaku and provide new chat protocol stack.
|
||||
2. **Support Logos Core**: ensure that any library and API we push to developers can be consumed in Logos Core; review and prioritize any requirements coming from Logos Core project contributors and developers.
|
||||
3. **Developer and Contributor Experience:** Review and improve dev assets (docs) and set quality expectation across the team (docs provided with deliverables, etc); Review and take action to improve developer and contributor experience (nimble usage, vscode plugin, etc).
|
||||
|
||||
### Core Team
|
||||
|
||||
1. **Complete integration of nwaku in Status Desktop**.
|
||||
2. **Simplify a reliable Waku API:** aka Messaging API, make it easier to consume Waku library; critical to enable easy development of Chat SDK.
|
||||
3. **Upgrade Waku for the Web**: Ensure web applications built on The Waku Network are reliable.
|
||||
4. **RLN mainnet and API:** Continue RLN migration to onchain tree + L2 testnet, and necessary steps to get RLN on mainnet; provide simple API for Chat SDK.
|
||||
5. **[Nwaku in Status Mobile and Light Mode MVP](https://github.com/waku-org/pm/milestone/39)**: de-prioritised in favour of cleaning up Waku and RLN APIs for Chat SDK first.
|
||||
6. **nwaku performance improvement**: Performance on mobile is critical, hence we will review benchmarks and potentially dedicate effort to this topic
|
||||
(note there is some ongoing effort from Status fleet behaviour).
|
||||
|
||||
#### Research Items
|
||||
|
||||
1. RLN (as above)
|
||||
2. **Incentivisation:** Deliver incentivisation PoC for reliability, scalability, risk (running own fleet) and sustainability.
|
||||
3. **Decentralisation and privacy**: continue research work to further decentralised Waku protocols, specifically store, and increase anonymity properties with libp2p-mixnet
|
||||
|
||||
### Chat/App Team
|
||||
|
||||
1. **Chat SDK:** Build a chat SDK (new protocol), learning from Status’ experience. Focus for an iterative delivery of the foundational blocks. Targeting private chats and early RLN integration.
|
||||
1. Note that building blocks such as identity mgmt are being built for demos app like Qaku - alignment to define and provide common protocols is expected as we are not limited by existing Status chat protocol.
|
||||
2. Work in close partnership with the status-backend developers, to ensure that post-refactoring the SDK can be integrated with the least effort possible. Aim for early and iterative integration.
|
||||
3. Note that early Status backend design position chat SDK as backend for Communities too; early iteration may not provide the scale in terms of members per communities; but Status' requirement is noted.
|
||||
4. Minimum deliverable will be usability of Chat SDK in Logos Core; need to review the architecture expectation in terms of Logos Core plugin interaction chat sdk <> nwaku.
|
||||
2. **Build demos and PoC apps**: Continue building PoC apps to teach how to hunt, dogfood and battle test libraries; as well as throwing ideas in the wild, experimenting and seeing what sticks; promising apps will have lib and specs implemented (e.g. Qaku and Logos Forum).
|
||||
1. Potentially expand the relevant platforms: from Web to Logos core, Nim/seaqt, Rust, etc.
|
||||
2. Integration with Codex still planned under this umbrella
|
||||
3. Review Logos Forum (Opchan) requirements; the 2025 Logos Movement Strategy is the new customer.
|
||||
|
||||
### Business and Ecosystem Development Team (BD + Solution Eng)
|
||||
|
||||
1. **Measure Success:** Develop and deploy tools to measure Waku success in terms of users, developers and contributors across all known Waku networks (Status, RAILGUN, TWN, etc)
|
||||
1. In partnership with BI.
|
||||
2. **Waku Chat MVP:** Proceed with the same exercise done for [Waku MVP](https://www.notion.so/Waku-MVP-1838f96fb65c8039acabf8a6a1e689e7?pvs=21).
|
||||
Consult with current and new leads on their *ideal* Chat SDK.
|
||||
Understand how confident we are they would onboard on Waku if it is delivered and feedback to Chat/App team to take in account for prioritization.
|
||||
3. **Support integrations**: support projects that want to build with Waku SDK and Chat SDK.
|
||||
4. **Foster and join Nim ecosystem (nwaku):** Foster and participate in the Nim developer community inside and outside IFT.
|
||||
5. **Join FOSS ecosystem:** Be an active part of the FOSS developer community.
|
||||
6. **Continue planned Rust SDK work**: Messaging API and stable nwaku integration in Status Desktop and pre-requisites to a quality Rust SDK.
|
||||
|
||||
### Status Priorities Review
|
||||
|
||||
**Existing milestones**:
|
||||
|
||||
- [Hardening and Scaling Foundations for Private Chats](https://roadmap.logos.co/waku/milestones/open/2025-hardening-and-scaling-foundations-for-private-chats): finishing off the work and descoping items that have been identified as unneeded.
|
||||
- [Nwaku in Status Desktop (Relay only)](https://roadmap.logos.co/waku/milestones/open/2024-nwaku-in-status-desktop): work continues, close to completion.
|
||||
@ -10,6 +62,10 @@ Period in planning: 2025 H1
|
||||
- [e2e reliability protocol](https://roadmap.logos.co/waku/milestones/open/2024-e2e-reliability-protocol): work continues, close to completion.
|
||||
- [Foundation for Communities Optimization](https://github.com/waku-org/pm/milestone/31): this includes finishing a migration, and move community traffic away from 1:1 chat so we complete the work.
|
||||
|
||||
**New work and priorities**:
|
||||
|
||||
1. New Chat SDK (nim) and protocol stack
|
||||
|
||||
## Draft Milestones
|
||||
|
||||
Testing out new format, once approved:
|
||||
@ -18,14 +74,67 @@ Testing out new format, once approved:
|
||||
- Deliverables are moved to GitHub issues
|
||||
- Waku FURPS remains in [FURPS](/FURPS/README.md)
|
||||
|
||||
- [Foundation for Communities Optimization](foundation_for_communities_optimisation.md)
|
||||
- [RLN Mainnet](deploy_rln_onchain_tree_on_l2_testnet.md)
|
||||
- [Hardening and Scaling Foundations for Private Chats](hardening_and_scaling_foundation_for_private_chat.md)
|
||||
- [Upgrade Waku for the Web](https://github.com/waku-org/pm/milestone/43)
|
||||
- [Logos Web Apps](formalize_logos_web_apps.md)
|
||||
- [Explore Peer Discovery Gap](https://github.com/waku-org/pm/milestone/44)
|
||||
- [Nwaku in Status Desktop (Relay only)](integrate_nwaku_in_status_desktop_relay_mode_only.md)
|
||||
- [Nwaku in Status Mobile and Light Mode MVP](https://roadmap.logos.co/waku/milestones/open/2025-nwaku-in-status-mobile)https://github.com/waku-org/pm/milestone/44
|
||||
- [e2e reliability protocol](introduce_e2e_reliability_in_status.md)
|
||||
- [Debugging Tools](https://github.com/waku-org/pm/milestone/38)
|
||||
- [Messaging API](https://github.com/waku-org/pm/milestone/41)
|
||||
In order of priority.
|
||||
|
||||
1. [Introduce E2E Reliability in Status Communities](./introduce_e2e_reliability_in_status.md)
|
||||
2. [Foundation for Communities Optimisation](/draft-roadmap/foundation_for_communities_optimisation.md)
|
||||
3. [Hardening and Scaling Foundations for Private Chat](/draft-roadmap/hardening_and_scaling_foundation_for_private_chat.md)
|
||||
4. [Integrate nwaku in Status Desktop, relay mode only](/draft-roadmap/integrate_nwaku_in_status_desktop_relay_mode_only.md)
|
||||
5. [Deploy RLN Onchain Tree on L2 Testnet](/draft-roadmap/deploy_rln_onchain_tree_on_l2_testnet.md)
|
||||
6. [Define Incentivisation for RLNaaS](/draft-roadmap/define_incentivisation_for_rlnaas.md)
|
||||
7. [Improve DevEx: API, TWN, Metrics, Docs](/draft-roadmap/improve_devex_api_twn_metrics_docs.md)
|
||||
8. [Introduce mixnet for message sending](/draft-roadmap/introduce_mixnet_for_message_sending.md)
|
||||
9. [Formalize Logos Web Apps](/draft-roadmap/formalize_logos_web_apps.md)
|
||||
10. [Introduce Chat SDK by enabling basic one-to-one chats]() TODO: should be added by https://github.com/waku-org/pm/pull/303
|
||||
11. [Integrate RLN with Waku API](/draft-roadmap/integrate_rln_with_waku_api.md)
|
||||
12. [Streamline DevEx: Mobile, Rust and Web dev](/draft-roadmap/streamline_dev_ex_local_dev_rust.md)
|
||||
13. Incentivisation follow-up
|
||||
|
||||
Pushed to 2026
|
||||
- WebTransport: depending on nim-libp2p (delivery Q4)
|
||||
- REST API for Waku API: Useful for DST/QA, but let's focus on Status, Chat SDK, and Rust first
|
||||
|
||||
Not yet planned/not sure:
|
||||
- nwaku performance on mobile: let's focus on finishing desktop integration and getting API ready for Chat SDK + RLN
|
||||
- quic: need to review where to put it, should be easy.
|
||||
- Follow-up steps for incentivization: part of current milestone is to produce a roadmap.
|
||||
- RLN mainnet and audit -> probably wait for Status L2 mainnet?
|
||||
|
||||
### Business Development Milestones
|
||||
|
||||
TODO
|
||||
|
||||
## Gantt
|
||||
|
||||
TODO: fix dates
|
||||
|
||||
```mermaid
|
||||
gantt
|
||||
title Waku 2025H2
|
||||
dateFormat YYYY-MM-DD
|
||||
axisFormat %b
|
||||
section core research
|
||||
E2E Reliability: 2025-07-01, 2025-08-01
|
||||
RLN Onchain Tree: 2025-07-01, 2025-08-01
|
||||
Incentivization: 2025-07-01, 2025-08-01
|
||||
Mixnet: 2025-07-01, 2025-12-31
|
||||
section nwaku
|
||||
Status Desktop: 2025-07-01, 2025-08-01
|
||||
RLN Onchain Tree: 2025-07-01, 2025-08-01
|
||||
Improve DevEx (API): 2025-07-01, 2025-10-01
|
||||
Improve DevEx (TWN): 2025-07-01, 2025-09-01
|
||||
Streamline DevEx (Mobile, Rust): 2025-09-01, 2025-12-31
|
||||
RLN Library: 2025-08-01, 2025-12-31
|
||||
section js-waku
|
||||
Improve DevEx (API): 2025-07-01, 2025-10-01
|
||||
Improve DevEx (TWN): 2025-07-01, 2025-10-01
|
||||
RLN Library: 2025-07-01, 2025-09-01
|
||||
Streamline DevEx (Local dev): 2025-10-01, 2025-12-31
|
||||
section app-chat
|
||||
E2E Reliability: 2025-07-01, 2025-08-01
|
||||
Communities Opt: 2025-07-01, 2025-08-01
|
||||
Foundations Private Chats: 2025-07-01, 2025-08-01
|
||||
Improve DevEx (metrics): 2025-07-01, 2025-09-01
|
||||
Logos Web Apps: 2025-07-01, 2025-12-31
|
||||
Chat SDK: 2025-07-01, 2025-12-31
|
||||
```
|
||||
89
draft-roadmap/deploy_rln_onchain_tree_on_l2_testnet.md
Normal file
89
draft-roadmap/deploy_rln_onchain_tree_on_l2_testnet.md
Normal file
@ -0,0 +1,89 @@
|
||||
# Deploy RLN onchain tree on L2 Testnet
|
||||
|
||||
**Estimated date of completion**: 30 June 2025
|
||||
|
||||
**Resources Required for 2025H2**:
|
||||
- {roles and % application to it}
|
||||
- {external services consumed (Vac/IFT)}
|
||||
- {infrastructure}
|
||||
|
||||
This is a split of RLN mainnet milestone which grew too large in scope.
|
||||
|
||||
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.
|
||||
Finally, the smart contract will be deployed on a Linea-based L2 testnet and used by The Waku Network.
|
||||
|
||||
It will then be possible to design the usage of RLN in Chat SDK.
|
||||
|
||||
**deliverables**: https://github.com/waku-org/pm/milestone/34
|
||||
|
||||
## [Implement RLN smart contract for paid, multilevel memberships](https://github.com/waku-org/pm/issues/228)
|
||||
|
||||
**Owner**: research
|
||||
|
||||
**Feature**: [RLN Smart Contract](/FURPS/core/rln_smart_contract.md)
|
||||
|
||||
**FURPS**:
|
||||
|
||||
- F1. RLN rate limit can be defined in terms of multiple messages per epoch.
|
||||
- F2. RLN rate limit is set at membership insertion
|
||||
- F3. RLN proof generation and validation only requires Web3 RPC `call`s, no blockchain events or initialisation are needed.
|
||||
- F4. An ERC-20 token deposit is needed to insert a membership
|
||||
- U1. Application developers can set RLN rate limit at insertion.
|
||||
|
||||
**Checklist**:
|
||||
- [ ] Specs: link to specs and/or API definition
|
||||
- [ ] Code: link to GitHub issues/PRs/Epic
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
|
||||
## [TWN supports RLN onchain tree and deposits, existing memberships only](https://github.com/waku-org/pm/issues/286)
|
||||
|
||||
**Owner**: nwaku
|
||||
|
||||
**Feature**: [RLN Smart Contract](/FURPS/core/rln_smart_contract.md)
|
||||
|
||||
**FURPS**:
|
||||
|
||||
- F3. RLN initialization only requires Web3 RPC `call`s, no blockchain events are needed.
|
||||
- U2. User do not need to wait for merkle tree synchronization and building to start relaying
|
||||
or sending messages.
|
||||
- P1. New node setup with an RLN membership can be ready to verify RLN proof within 5s,
|
||||
no matter the size of the tree **(Vac-DST)**.
|
||||
- +1. Smart Contracts are deployed on Linea Testnet.
|
||||
- +2. TWN uses smart contracts deployed on Linea Testnet.
|
||||
|
||||
**Checklist**:
|
||||
- [ ] Specs: link to specs and/or API definition
|
||||
- [ ] Code: link to GitHub issues/PRs/Epic
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
|
||||
## [RLNv2 Web management interface](https://github.com/waku-org/pm/issues/281)
|
||||
|
||||
**Owner**: js-waku
|
||||
|
||||
**Feature**: [RLN Membership Management](/FURPS/application/rln_membership_management.md)
|
||||
|
||||
**FURPS**:
|
||||
|
||||
- F1. Can generate RLN credentials.
|
||||
- F2. Can insert RLN membership in smart contract, with accompanying deposit.
|
||||
- F3. Can extend RLN membership on smart contract.
|
||||
- F4. Can withdraw deposit from smart contract.
|
||||
- F5. Membership credentials are encrypted by default on local disk.
|
||||
- U1. RLN membership details can be exported and imported.
|
||||
- U2. Deployment details (address, chain id) are persisted by library and in exports.
|
||||
- R1. Import and exports are interoperable across all implementations.
|
||||
- +1. Deployed on https://rln.waku.org
|
||||
- +2. Available for Linea Sepolia Testnet contracts.
|
||||
- +3. Proof generation and validation is out of scope.
|
||||
|
||||
For S1. Browser application, using web3 wallet browser extensions.
|
||||
|
||||
**Checklist**:
|
||||
- [ ] Specs: link to specs and/or API definition
|
||||
- [ ] Code: link to GitHub issues/PRs/Epic
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
170
draft-roadmap/improve_devex_api_twn_metrics_docs.md
Normal file
170
draft-roadmap/improve_devex_api_twn_metrics_docs.md
Normal file
@ -0,0 +1,170 @@
|
||||
# Improve DevEx: API, TWN, Metrics, Docs
|
||||
|
||||
**Estimated date of completion**: {Enter date}
|
||||
|
||||
**Resources Required for 2025H2**:
|
||||
- {roles and % application to it}
|
||||
- {external services consumed (Vac/IFT)}
|
||||
- {infrastructure}
|
||||
|
||||
Proceed with a number of improvements to the developer experience on Waku, for both internal and external purposes.
|
||||
This includes:
|
||||
|
||||
- improving The Waku Network reliability for Logos apps and other web apps
|
||||
- simplifying the Waku API
|
||||
- measuring Waku usage across all integrations
|
||||
- review and setting strategy for Waku documentation
|
||||
|
||||
|
||||
**FURPS**:
|
||||
|
||||
- [{Feature Name}]({path/to/furps/file}): {list of furps: F1, etc}
|
||||
- [Network Metrics Tracker](/FURPS/application/network_metrics_tracker.md): all
|
||||
|
||||
**deliverables**:
|
||||
|
||||
(TODO: adjust FURPS for existing deliverables)
|
||||
- [Global Network Metrics](https://github.com/waku-org/pm/issues/295)
|
||||
- [Scalable Data Sync in Browser](https://github.com/waku-org/pm/issues/280)
|
||||
- [Improved Browser Bootstrap](https://github.com/waku-org/pm/issues/290)
|
||||
- [Waku Sync](https://github.com/waku-org/pm/issues/132)
|
||||
|
||||
TODO: quic PoC
|
||||
|
||||
## Define and Implement Light Push Error codes in nwaku
|
||||
|
||||
**Owner**: nwaku
|
||||
|
||||
**Feature**: [Light Push](/FURPS/core/light_push.md)
|
||||
|
||||
**FURPS**:
|
||||
- F4. Supports comprehensive error codes for various failure scenarios.
|
||||
- U4. Provides descriptive error messages in responses.
|
||||
- R2. Status codes indicate the best recovery method (retry, discard service node or irrecoverable failure).
|
||||
- R3. 80% message transmission success rate on live Status network (service node from both Status Desktop and fleet Waku instances)
|
||||
|
||||
For S1. Linux amd64 CLI as service node
|
||||
Includes spec delivery
|
||||
|
||||
**Checklist**:
|
||||
- [ ] Specs: link to specs and/or API definition
|
||||
- [ ] Code: link to GitHub issues/PRs/Epic
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
|
||||
## Implement Light Push Error codes in The Browser
|
||||
|
||||
**Owner**: js-waku
|
||||
|
||||
**Feature**: [Light Push](/FURPS/core/light_push.md)
|
||||
|
||||
**FURPS**:
|
||||
- F4. Supports comprehensive error codes for various failure scenarios.
|
||||
- U4. Provides descriptive error messages in responses.
|
||||
- R2. Status codes indicate the best recovery method (retry, discard service node or irrecoverable failure).
|
||||
|
||||
For S2. Browser as client
|
||||
Spec delivery not included.
|
||||
|
||||
**Checklist**:
|
||||
- [ ] Specs: link to specs and/or API definition
|
||||
- [ ] Code: link to GitHub issues/PRs/Epic
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
|
||||
## Introduce Waku API in the Browser
|
||||
|
||||
**Owner**: js-waku
|
||||
|
||||
**Feature**: [Waku API](/FURPS/core/waku_api.md)
|
||||
|
||||
**FURPS**:
|
||||
- F1. Setup, start and stop a Waku node.
|
||||
- F2. Support edge node operation mode.
|
||||
- F4. Does automatic peer discovery based on the node platform and operation mode.
|
||||
- F5. Returns health and connectivity information using proven heuristics.
|
||||
- U1. When setting up a Waku node, no need to specify what protocols to mount, only an operational mode (edge or relay).
|
||||
- U2. Disconnection detection and recovery, and other peer management matters are automatically handled.
|
||||
- U3. Developers do not need to specify the protocols used to send and receive messages; it is deduced from the mode of operation.
|
||||
- U4. Developers pass and receive data to the API in types native to the wrapping language.
|
||||
- U5. By default, auto-sharding is applied, meaning developers do not need to be concerned by sharding; pubsub topics are never exposed.
|
||||
- R1. Sends a message using peer-to-peer reliability (service node redundancy, optional store confirmation)
|
||||
- R2. Receives messages using peer-to-peer reliability (service node redundancy, periodic store query, periodic filter ping)
|
||||
|
||||
For S3. Browser
|
||||
|
||||
**Checklist**:
|
||||
- [ ] Specs: link to specs and/or API definition
|
||||
- [ ] Code: link to GitHub issues/PRs/Epic
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
|
||||
## Introduce Waku API in nwaku
|
||||
|
||||
**Owner**: nwaku
|
||||
|
||||
**Feature**: [Waku API](/FURPS/core/waku_api.md)
|
||||
|
||||
**FURPS**:
|
||||
- F1. Setup, start and stop a Waku node.
|
||||
- F3. Support relay node operation mode.
|
||||
- F4. Does automatic peer discovery based on the node platform and operation mode.
|
||||
- F5. Returns health and connectivity information using proven heuristics.
|
||||
- U1. When setting up a Waku node, no need to specify what protocols to mount, only an operational mode (edge or relay).
|
||||
- U2. Disconnection detection and recovery, and other peer management matters are automatically handled.
|
||||
- U3. Developers do not need to specify the protocols used to send and receive messages; it is deduced from the mode of operation.
|
||||
- U4. Developers pass and receive data to the API in types native to the wrapping language.
|
||||
- U5. By default, auto-sharding is applied, meaning developers do not need to be concerned by sharding; pubsub topics are never exposed.
|
||||
- R1. Sends a message using peer-to-peer reliability (service node redundancy, optional store confirmation)
|
||||
- R2. Receives messages using peer-to-peer reliability (service node redundancy, periodic store query, periodic filter ping)
|
||||
|
||||
For:
|
||||
- S1. Nim library; used by chat SDK
|
||||
- S2. Golang library; used by status-go
|
||||
|
||||
**Checklist**:
|
||||
- [ ] Specs: link to specs and/or API definition
|
||||
- [ ] Code: link to GitHub issues/PRs/Epic
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
|
||||
## Review Documentation and Define Guidelines
|
||||
|
||||
**Owner**: {one waku subteam}
|
||||
|
||||
(No FURPS)
|
||||
|
||||
- [ ] Review the current developer documentation
|
||||
- [ ] And contributor doc
|
||||
- [ ] Define a guideline for Waku teams to follow when contributing to documentation
|
||||
- [ ] Setup an initial structure
|
||||
|
||||
## Use Protobuf to transfer data from Wrapper to nwaku library PoC TBC
|
||||
|
||||
**Owner**: {one waku subteam}
|
||||
|
||||
**Feature**: [{Feature Name (only 1)}]({path/to/furps/file})
|
||||
|
||||
**FURPS**:
|
||||
- {F1. copy-paste full furps statement}
|
||||
|
||||
**Checklist**:
|
||||
- [ ] Specs: link to specs and/or API definition
|
||||
- [ ] Code: link to GitHub issues/PRs/Epic
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
|
||||
## {Name of deliverable 1 - eg "improve feature X for the browser"}
|
||||
|
||||
**Owner**: {one waku subteam}
|
||||
|
||||
**Feature**: [{Feature Name (only 1)}]({path/to/furps/file})
|
||||
|
||||
**FURPS**:
|
||||
- {F1. copy-paste full furps statement}
|
||||
|
||||
**Checklist**:
|
||||
- [ ] Specs: link to specs and/or API definition
|
||||
- [ ] Code: link to GitHub issues/PRs/Epic
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
120
draft-roadmap/integrate_rln_with_waku_api.md
Normal file
120
draft-roadmap/integrate_rln_with_waku_api.md
Normal file
@ -0,0 +1,120 @@
|
||||
# Integrate RLN With the Waku API
|
||||
|
||||
**Estimated date of completion**: {Enter date} TODO
|
||||
|
||||
**Resources Required for 2025H2**:
|
||||
- nwaku engineer TODO
|
||||
- 1 js-waku engineer for 2 months (til 30 Aug)
|
||||
- core research/test engineer? TODO
|
||||
- chat sdk engineer TODO
|
||||
- Support from Vac/ACZ to get zerokit working in the browser.
|
||||
- {infrastructure}
|
||||
|
||||
Deliver a native RLN library with a deliberate API to manage RLN memberships, as well as proof verification and generation.
|
||||
This includes extracting RLN Relay as a relay plugin validation strategy, that can then be passed internally to nwaku node
|
||||
as any other strategy.
|
||||
|
||||
Once delivered, usage of Chat SDK of RLN becomes possible, with clear API to instantiate nwaku library with RLN, as well
|
||||
as API to manage RLN membership.
|
||||
|
||||
Introduce RLN proof generation and validation in the Browser. RLN API should be similar across all implementations.
|
||||
|
||||
Finally, migrate to Status network L2 testnet and improve UX issues discovered via dogfooding such as rate of RPC Calls.
|
||||
|
||||
**FURPS**:
|
||||
|
||||
- [{Feature Name}]({path/to/furps/file}): {list of furps: F1, etc} TODO
|
||||
|
||||
**deliverables**:
|
||||
|
||||
## Implement RLN membership management in nwaku library
|
||||
|
||||
**Owner**: nwaku
|
||||
|
||||
**Feature**: [{Feature Name (only 1)}]({path/to/furps/file})
|
||||
|
||||
**FURPS**:
|
||||
- {F1. copy-paste full furps statement}
|
||||
|
||||
**Checklist**:
|
||||
- [ ] Specs: link to specs and/or API definition
|
||||
- [ ] Code: link to GitHub issues/PRs/Epic
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
|
||||
## Implement RLN Onchain Tree Proof generation and verification in the Browser
|
||||
|
||||
**Owner**: js-waku
|
||||
|
||||
**Feature**: [{Feature Name (only 1)}]({path/to/furps/file})
|
||||
|
||||
**FURPS**:
|
||||
- {F1. copy-paste full furps statement}
|
||||
|
||||
**Checklist**:
|
||||
- [ ] Specs: link to specs and/or API definition
|
||||
- [ ] Code: link to GitHub issues/PRs/Epic
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
|
||||
## Extract RLN as a plug-in library from nwaku
|
||||
|
||||
**Owner**: nwaku
|
||||
|
||||
**Feature**: [{Feature Name (only 1)}]({path/to/furps/file})
|
||||
|
||||
**FURPS**:
|
||||
- {F1. copy-paste full furps statement}
|
||||
|
||||
**Checklist**:
|
||||
- [ ] Specs: link to specs and/or API definition
|
||||
- [ ] Code: link to GitHub issues/PRs/Epic
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
|
||||
## Deploy RLN Contracts to Status L2 testnet
|
||||
|
||||
**Owner**: nwaku
|
||||
|
||||
**Feature**: [{Feature Name (only 1)}]({path/to/furps/file})
|
||||
|
||||
**FURPS**:
|
||||
- {F1. copy-paste full furps statement}
|
||||
|
||||
**Checklist**:
|
||||
- [ ] Specs: link to specs and/or API definition
|
||||
- [ ] Code: link to GitHub issues/PRs/Epic
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
|
||||
## Improve RLN UX by reducing Web3 RPC calls
|
||||
|
||||
TODO: other improvements may be flagged as we dogfood the previous RLN milestone.
|
||||
|
||||
**Owner**: nwaku
|
||||
|
||||
**Feature**: [{Feature Name (only 1)}]({path/to/furps/file})
|
||||
|
||||
**FURPS**:
|
||||
- {F1. copy-paste full furps statement}
|
||||
|
||||
**Checklist**:
|
||||
- [ ] Specs: link to specs and/or API definition
|
||||
- [ ] Code: link to GitHub issues/PRs/Epic
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
|
||||
## {Name of deliverable 1 - eg "improve feature X for the browser"}
|
||||
|
||||
**Owner**: {one waku subteam}
|
||||
|
||||
**Feature**: [{Feature Name (only 1)}]({path/to/furps/file})
|
||||
|
||||
**FURPS**:
|
||||
- {F1. copy-paste full furps statement}
|
||||
|
||||
**Checklist**:
|
||||
- [ ] Specs: link to specs and/or API definition
|
||||
- [ ] Code: link to GitHub issues/PRs/Epic
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
31
draft-roadmap/introduce_mixnet_for_message_sending.md
Normal file
31
draft-roadmap/introduce_mixnet_for_message_sending.md
Normal file
@ -0,0 +1,31 @@
|
||||
# Introduce Mixnet For Message Sending
|
||||
|
||||
**Estimated date of completion**: 30 Sep 2025
|
||||
|
||||
**Resources Required for 2025H2**:
|
||||
- 1 core research engineer for 3 months
|
||||
|
||||
A PoC implementation to improve anonymity in Waku message publishing by mixing Waku Lightpush requests and responses.
|
||||
|
||||
**FURPS** (see deliverables)
|
||||
|
||||
**GitHub Milestone and deliverables**:
|
||||
|
||||
## [Integrate libp2p mix into lightpush](https://github.com/waku-org/nwaku/issues/3280)
|
||||
|
||||
**Owner**: core research
|
||||
|
||||
**Feature**: [Mix](/FURPS/core/mix.md)
|
||||
|
||||
**FURPS**:
|
||||
- F1. Relay nodes can mount mixnet protocol, acting as entry, exit or mixnet nodes.
|
||||
- F2. Nodes can discover mixnet relay and exit nodes using available peer discovery mechanisms.
|
||||
- F3. Client nodes can send light push requests over the mixnet before delivery to a service node.
|
||||
- F4. Client nodes can receive a response to a light push request over the mixnet.
|
||||
|
||||
|
||||
**Checklist**:
|
||||
- [ ] Specs: link to specs
|
||||
- [ ] Code: link to GitHub issues/PRs/Epic
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
97
draft-roadmap/streamline_dev_ex_local_dev_rust.md
Normal file
97
draft-roadmap/streamline_dev_ex_local_dev_rust.md
Normal file
@ -0,0 +1,97 @@
|
||||
# Streamline DevEx: Mobile, Rust and Web dev
|
||||
|
||||
**Estimated date of completion**: {Enter date} TODO
|
||||
|
||||
**Resources Required for 2025H2**:
|
||||
- {roles and % application to it}
|
||||
- {external services consumed (Vac/IFT)}
|
||||
- {infrastructure}
|
||||
|
||||
Complete the Waku API implementation in nwaku by implementing edge node mode (Status' Light Mode).
|
||||
|
||||
Streamline the Developer Experience by delivering a Rust SDK that implements the full Waku API and is available on crates.io.
|
||||
As well as building an easy-to-use local dev environment from the browser, enabling developers to build web apps without
|
||||
relying on external connectivity; as well as opting in and out of RLN, and include a local RLN dev environment.
|
||||
|
||||
Finalize the integration of nwaku in Status application by setting up nwaku-based build for Mobile platforms.
|
||||
|
||||
**FURPS**:
|
||||
|
||||
- [{Feature Name}]({path/to/furps/file}): {list of furps: F1, etc}
|
||||
|
||||
**deliverables**:
|
||||
|
||||
## Edge Mode in Nwaku
|
||||
|
||||
**Owner**: nwaku
|
||||
|
||||
**Feature**: [{Feature Name (only 1)}]({path/to/furps/file}) TODO
|
||||
|
||||
**FURPS**:
|
||||
- {F1. copy-paste full furps statement}
|
||||
|
||||
**Checklist**:
|
||||
- [ ] Specs: link to specs and/or API definition
|
||||
- [ ] Code: link to GitHub issues/PRs/Epic
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
|
||||
## Nwaku in Status Mobile
|
||||
|
||||
**Owner**: nwaku
|
||||
|
||||
**Feature**: [{Feature Name (only 1)}]({path/to/furps/file}) TODO
|
||||
|
||||
**FURPS**:
|
||||
- {F1. copy-paste full furps statement}
|
||||
|
||||
**Checklist**:
|
||||
- [ ] Specs: link to specs and/or API definition
|
||||
- [ ] Code: link to GitHub issues/PRs/Epic
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
|
||||
## Waku Rust SDK
|
||||
|
||||
**Owner**: nwaku
|
||||
|
||||
**Feature**: [{Feature Name (only 1)}]({path/to/furps/file}) TODO
|
||||
|
||||
**FURPS**:
|
||||
- {F1. copy-paste full furps statement}
|
||||
|
||||
**Checklist**:
|
||||
- [ ] Specs: link to specs and/or API definition
|
||||
- [ ] Code: link to GitHub issues/PRs/Epic
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
|
||||
## Local RLN Dev Harness
|
||||
|
||||
**Owner**: ? (nwaku? core-research?) TODO
|
||||
|
||||
**Feature**: [{Feature Name (only 1)}]({path/to/furps/file})
|
||||
|
||||
**FURPS**:
|
||||
- {F1. copy-paste full furps statement}
|
||||
|
||||
**Checklist**:
|
||||
- [ ] Specs: link to specs and/or API definition
|
||||
- [ ] Code: link to GitHub issues/PRs/Epic
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)\
|
||||
|
||||
## Local Web Dev Harness
|
||||
|
||||
**Owner**: js-waku
|
||||
|
||||
**Feature**: [{Feature Name (only 1)}]({path/to/furps/file})
|
||||
|
||||
**FURPS**:
|
||||
- {F1. copy-paste full furps statement}
|
||||
|
||||
**Checklist**:
|
||||
- [ ] Specs: link to specs and/or API definition
|
||||
- [ ] Code: link to GitHub issues/PRs/Epic
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
Loading…
x
Reference in New Issue
Block a user