mirror of
https://github.com/logos-messaging/pm.git
synced 2026-01-02 14:13:09 +00:00
Rework milestones, group dev ex together
This commit is contained in:
fryorcraken
parent
81937a0a89
commit
7e0f272e27
27
FURPS/application/js-waku.md
Normal file
27
FURPS/application/js-waku.md
Normal file
@ -0,0 +1,27 @@
|
||||
# JS-Waku FURPS
|
||||
|
||||
TODO
|
||||
|
||||
## Functionality
|
||||
|
||||
1. ...
|
||||
|
||||
## Usability
|
||||
|
||||
1. ...
|
||||
|
||||
## Reliability
|
||||
|
||||
1. ...
|
||||
|
||||
## Performance
|
||||
|
||||
1. ...
|
||||
|
||||
## Supportability
|
||||
|
||||
1. ...
|
||||
|
||||
## + (Privacy, Anonymity, Deployments)
|
||||
|
||||
1. ...
|
||||
@ -29,3 +29,4 @@ Assuming messages in a group are sent at least every `S` seconds.
|
||||
## Supportability
|
||||
|
||||
1. Applied to Communities channels on Status Desktop
|
||||
2. For Web apps as a developer library.
|
||||
34
FURPS/core/waku_api.md
Normal file
34
FURPS/core/waku_api.md
Normal file
@ -0,0 +1,34 @@
|
||||
# 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 specificy the protocols used to send and receive messages; it is deduced from the mode of operation.
|
||||
|
||||
## Reliability
|
||||
|
||||
1. Sends a message using peer-to-peer reliability (service node redundancy, optional store confirmation)
|
||||
2. Receives messages using peer-to-peer reliability (service node redundancy, periodic store query, periodic filter ping)
|
||||
|
||||
## Performance
|
||||
|
||||
## Supportability
|
||||
|
||||
1. Nim library
|
||||
2. Golang library
|
||||
3. Browser
|
||||
|
||||
## + (Privacy, Anonymity, Deployments)
|
||||
|
||||
1. ...
|
||||
@ -122,9 +122,9 @@ A _Deliverable_:
|
||||
- docs
|
||||
|
||||
Finally, for _Tasks_ that do not belong to a _Deliverable_:
|
||||
- MUST qualify either as (with related GitHub labels)
|
||||
- `bug`: bugs reported by users or discovered internally, SHOULD be linked back to a corresponding _FURPS_ and _Milestone_
|
||||
- `test`: maintaining and fixing broken tests, SHOULD ideally be linked back to a corresponding _FURPS_ and _Milestone_
|
||||
- MUST qualify either as (with related GitHub labels):
|
||||
- `bug`: bugs reported by users or discovered internally, SHOULD be linked back to a corresponding _FURPS_ and _Milestone_.
|
||||
- `test`: maintaining and fixing broken tests, SHOULD ideally be linked back to a corresponding _FURPS_ and _Milestone_.
|
||||
- `release`: work associated with releasing new versions.
|
||||
- `dependencies`: work associated with updating dependency versions.
|
||||
|
||||
|
||||
@ -15,14 +15,9 @@ Period in planning: 2025 H2
|
||||
### 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 by simplifying the API
|
||||
and including p2p reliability. This is critical to enable fast Chat SDK development.
|
||||
1. Deliver this API in nim (chat SDK), and Rust SDK, identified as the most promising SDK for community adoption;
|
||||
in addition to Browser and nim (libwaku)
|
||||
3. **Harden TWN for Web apps**: Web applications built on The Waku Network suffer from unreliable bootstrapping,
|
||||
continue investigation and resolution of this as planned in *Upgrade Waku for the Web* milestone.
|
||||
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.
|
||||
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).
|
||||
@ -79,36 +74,39 @@ Testing out new format, once approved:
|
||||
- Deliverables are moved to GitHub issues
|
||||
- Waku FURPS remains in [FURPS](/FURPS/README.md)
|
||||
|
||||
- [Define and Implement Peer-To-Peer Reliability Strategies](./define_p2p_reliability.md)
|
||||
- [Introduce E2E Reliability in Status Communities](./introduce_e2e_reliability_in_status.md)
|
||||
- [Foundation for Communities Optimisation](/draft-roadmap/foundation_for_communities_optimisation.md)
|
||||
- [Hardening and Scaling Foundations for Private Chat]()
|
||||
- [Deploy RLN Onchain Tree on L2 Testnet](/draft-roadmap/deploy_rln_onchain_tree_on_l2_testnet.md)
|
||||
- [Integrate nwaku in Status Desktop, relay mode only](/draft-roadmap/integrate_nwaku_in_status_desktop_relay_mode_only.md)
|
||||
- [Define Incentivisation for RLNaaS](/draft-roadmap/define_incentivisation_for_rlnaas.md)
|
||||
- [Measure Waku Usage](/draft-roadmap/measure_waku_usage.md)
|
||||
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]()
|
||||
9. [Formalize Logos Web Apps]()
|
||||
10. [Introduce Chat SDK by enabling basic one-to-one chats]()
|
||||
11. [Streamline DevEx: Mobile, Rust and Web dev]()
|
||||
|
||||
#### P2P Reliability Implementation in the Browser
|
||||
not planned yet:
|
||||
- Move DST/QA to Waku API (REST API)
|
||||
- Performance for mobile
|
||||
- webtransport
|
||||
- quic
|
||||
|
||||
TODO: It's actually done?
|
||||
## Gantt
|
||||
|
||||
**Owner**: js-waku
|
||||
|
||||
**Feature**: [P2P Reliability](/FURPS/application/p2p_reliability.md)
|
||||
|
||||
**FURPS**:
|
||||
- F1. Improves probability of message propagation through redundant publishing and receiving.
|
||||
- F2. Enables detection and remedy of message losses between peers using Store or Filter based reliability strategies.
|
||||
- F3. Enhances Lightpush reliability through service node pooling, redundant publishing, and failure detection.
|
||||
- F4. Improves Filter reliability through redundant subscriptions and subscription health monitoring.
|
||||
- U1. Provides feedback on message delivery status leveraging store protocol.
|
||||
- U2. Automatically handles reconnection and retransmission when failures are detected.
|
||||
|
||||
For
|
||||
- S1. Within browser environments (edge node mode)
|
||||
|
||||
**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)
|
||||
```mermaid
|
||||
gantt
|
||||
title Waku 2025H2
|
||||
dateFormat YYYY-MM-DD
|
||||
axisFormat %b
|
||||
section core research
|
||||
e2e reliability: 2025-07-01, 2025-08-01
|
||||
RLN: 2025-07-01, 2025-08-01
|
||||
Incentivization: 2025-07-01, 2025-08-01
|
||||
Mixnet: 2025-07-01, 2025-12-31
|
||||
section nwaku
|
||||
p2p reliability: 2025-07-01, 2025-08-01
|
||||
Status Desktop: 2025-07-01, 2025-08-01
|
||||
RLN: 2025-07-01, 2025-08-01
|
||||
Dev
|
||||
```
|
||||
@ -1,5 +1,12 @@
|
||||
# [Define Incentivisation for RLNaaS](https://github.com/waku-org/pm/milestone/35)
|
||||
|
||||
**Estimated date of completion**: {Enter date}
|
||||
|
||||
**Resources Required for 2025H2**:
|
||||
- {roles and % application to it}
|
||||
- {external services consumed (Vac/IFT)}
|
||||
- {infrastructure}
|
||||
|
||||
By the end of this milestone, we will have defined a roadmap and implemented a working proof of concept to incentivise node operators running Waku infrastructure for shared shards.
|
||||
|
||||
In general, Waku infrastructure consists of RLN Relay nodes both forming the decentralised routing backbone for Waku messages and providing a set of services on top of Waku that might be useful for applications.
|
||||
@ -28,7 +35,7 @@ This is the first step to providing a sustainable way to scale the Status applic
|
||||
- U2. A consumer node can select an RLNaaS provider based on their price and local reputation.
|
||||
- R1. A consumer prefers new providers to known unreliable providers.
|
||||
- R2. In a stable network, a client can find, pay and send a message via a RLNaaS provider (**Vac-QA**)
|
||||
in 90% of cases **(Vac-DST)**
|
||||
in 90% of cases **(Vac-DST)**.
|
||||
- R3. A client can assess whether an RLNaaS provider has relayed their message (**Vac-QA**)
|
||||
in 90% of cases **(Vac-DST)**.
|
||||
- P1. Assuming a block time of 5 seconds,
|
||||
|
||||
@ -1,88 +0,0 @@
|
||||
# Define and Implement Peer-To-Peer Reliability Strategies
|
||||
|
||||
**Estimated completion date: TBD**
|
||||
|
||||
Last remains of *Direct Message Reliability* milestone.
|
||||
|
||||
Once delivered, the reliability of the Waku protocols will be maximised when used with decentralised light push and filter service nodes;
|
||||
in mostly offline or frequently disconnected environments (mobile, laptop).
|
||||
|
||||
This may include some bandwidth overhead that can later be optimized when rolling out enhanced end-to-end reliability strategies.
|
||||
This includes a high reliance on centralized store nodes.
|
||||
|
||||
User experience is catered for, in terms of delay of message retrieval and retention,
|
||||
which is why store performance is also review and maximized for the current circumstances.
|
||||
Limited effort will be spent on store performance as its relevance is expected to reduce mid-long term.
|
||||
|
||||
**FURPS** (see deliverables)
|
||||
|
||||
**Deliverables**:
|
||||
|
||||
<!--
|
||||
Once the deliverables are created as GitHub issues, we can delete the content below
|
||||
and just provide a list of GitHub issues, or even simpler, a link to the GitHub milestone that contain them.
|
||||
|
||||
Also copy the FURPS from deliverable here.
|
||||
-->
|
||||
|
||||
## 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.
|
||||
- R3. Status codes indicate the best recovery method (retry, discard service node or irrecoverable failure).
|
||||
- R4. 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
|
||||
- [ ] 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.
|
||||
- R3. 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
|
||||
- [ ] Code: link to GitHub issues/PRs/Epic
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
|
||||
## PostgreSQL Optimisation Phase 1
|
||||
|
||||
**Owner**: nwaku
|
||||
|
||||
**Feature**: [Store](/FURPS/core/store.md)
|
||||
|
||||
**FURPS**:
|
||||
- F6. Industry practices are applied to PostgreSQL setup to reach appropriate performance
|
||||
- P5. Hash query of less than 10 hashes are served under 400ms; for a database less than 250 GB size and average message size under 500KiB **(Vac-DST)**.
|
||||
- P6. Time range queries of less than 24 hours, with less than 10 content topics, are served under 400 ms; for a database less than 250 GB size and average message size under 500KiB **(Vac-DST)**.
|
||||
|
||||
Fora
|
||||
- S1. Linux amd64 CLI as service node; and
|
||||
- S2. PostgreSQL as database engine.
|
||||
|
||||
**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)
|
||||
149
draft-roadmap/improve_devex_api_twn_metrics_docs.md
Normal file
149
draft-roadmap/improve_devex_api_twn_metrics_docs.md
Normal file
@ -0,0 +1,149 @@
|
||||
# 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)
|
||||
|
||||
## 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.
|
||||
- R3. Status codes indicate the best recovery method (retry, discard service node or irrecoverable failure).
|
||||
- R4. 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
|
||||
- [ ] 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.
|
||||
- R3. 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
|
||||
- [ ] 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 specificy the protocols used to send and receive messages; it is deduced from the mode of operation.
|
||||
- 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
|
||||
- [ ] 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.
|
||||
- F. 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 specificy the protocols used to send and receive messages; it is deduced from the mode of operation.
|
||||
- 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
|
||||
- [ ] 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
|
||||
|
||||
## {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
|
||||
- [ ] Code: link to GitHub issues/PRs/Epic
|
||||
- [ ] Dogfood: link to dogfooding session/artefact
|
||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||
@ -1,19 +0,0 @@
|
||||
# {Milestone Title - use verb}
|
||||
|
||||
_Extracted from TODO_
|
||||
|
||||
**Estimated date of completion**: {Enter date}
|
||||
|
||||
**Resources Required**:
|
||||
- {roles and % application to it}
|
||||
- {external services consumed (Vac/IFT)}
|
||||
- {infrastructure}
|
||||
|
||||
|
||||
{Milestone Description - what do we get once done}
|
||||
|
||||
**FURPS**:
|
||||
|
||||
- [Network Metrics Tracker](/FURPS/application/network_metrics_tracker.md): all
|
||||
|
||||
**deliverable**: https://github.com/waku-org/pm/issues/295
|
||||
0
draft-roadmap/streamline_dev_ex_local_dev_rust.md
Normal file
0
draft-roadmap/streamline_dev_ex_local_dev_rust.md
Normal file
Loading…
x
Reference in New Issue
Block a user