Merge pull request #310 from waku-org/2025H1

2025 H1 Roadmap

FURPS/README.md

@@ -0,0 +1,29 @@
+# Waku FURPS
+
+Some FURPS statement may contain the following postfixes:
+
+- (**Vac-DST**): Simulations to attest of this statement.
+- (**Vac-QA**): Additional test coverage by Vac-QA to verify this statement.
+
+All Waku core FURPS are assumed to be deployed and enabled on The Waku Network.
+
+## Core Protocols
+
+- [Light Push](core/light_push.md)
+- [Store](core/store.md)
+- [Rendezvous](core/rendezvous.md)
+- [RLN Relay](core/rln_relay.md)
+- [RLN Smart Contract](core/rln_smart_contract.md)
+- [Incentivisation](core/incentivisation.md)
+- [Mix](core/mix.md)
+
+## Application Protocols
+
+- [P2P Reliability](application/p2p_reliability.md)
+- [Scalable Data Sync](application/sds.md)
+- [js-waku](application/js-waku.md)
+- [nwaku](application/nwaku.md)
+- [RLN Membership Management](application/rln_membership_management.md)
+- [Status Communities](application/status_communities.md)
+- [status-go](application/status_go.md)
+- [Status Private Chats](application/status_private_chats.md)

FURPS/TEMPLATE.md

@@ -0,0 +1,25 @@
+# {Feature Name} FURPS
+
+## Functionality
+
+1. ...
+
+## Usability
+
+1. ...
+
+## Reliability
+
+1. ...
+
+## Performance
+
+1. ...
+
+## Supportability
+
+1. ...
+
+## + (Privacy, Anonymity, Deployments)
+
+1. ...

FURPS/application/js-waku.md

@@ -0,0 +1,27 @@
+# JS-Waku FURPS
+
+TODO
+
+## Functionality
+
+1. ...
+
+## Usability
+
+1. ...
+
+## Reliability
+
+1. ...
+
+## Performance
+
+1. ...
+
+## Supportability
+
+1. ...
+
+## + (Privacy, Anonymity, Deployments)
+
+1. ...

FURPS/application/nwaku.md

@@ -0,0 +1,27 @@
+# nwaku FURPS
+
+## Functionality
+
+1. nwaku can be compiled as a library, `libwaku`.
+2. libwaku exposes c-bindings.
+
+## Usability
+
+1. ...
+
+## Reliability
+
+1. ...
+
+## Performance
+
+1. ...
+
+## Supportability
+
+1. libwaku, wakunode2 can build on Windows
+2. libwaku supports relay functionalities.
+
+## + (Privacy, Anonymity, Deployments)
+
+1. Every nwaku release includes a Windows binary for wakunode2.

FURPS/application/p2p_reliability.md

@@ -0,0 +1,26 @@
+# P2P Reliability
+
+## Functionality
+
+1. Improves probability of message propagation through redundant publishing and receiving.
+2. Enables detection and remedy of message losses between peers using Store or Filter based reliability strategies.
+3. Enhances Light Push reliability through service node pooling, redundant publishing, and failure detection.
+4. Improves Filter reliability through redundant subscriptions and subscription health monitoring.
+
+## Usability
+
+1. Provides feedback on message delivery status leveraging store protocol.
+2. Automatically handles reconnection and retransmission when failures are detected.
+
+## Reliability
+
+TBD
+
+## Performance
+
+TBD
+
+## Supportability
+
+1. Within browser environments (edge node mode)
+2. Integrated in Status applications

FURPS/application/rln_membership_management.md

@@ -0,0 +1,32 @@
+# RLN Membership Management FURPS
+
+## Functionality
+
+1. Can generate RLN credentials.
+2. Can insert RLN membership in smart contract, with accompanying deposit. 
+3. Can extend RLN membership on smart contract.
+4. Can withdraw deposit from smart contract.
+5. Membership credentials are encrypted by default on local disk.
+
+## Usability
+
+1. RLN membership details can be exported and imported.
+2. Deployment details (address, chain id) are persisted by library and in exports.
+
+## Reliability
+
+1. Import and exports are interoperable across all implementations.
+
+## Performance
+
+1. ...
+
+## Supportability
+
+1. Browser application, using web3 wallet browser extensions.
+
+## + (Privacy, Anonymity, Deployments)
+
+1. Deployed on https://rln.waku.org
+2. Available for Linea Sepolia Testnet contracts.
+3. Proof generation and validation is out of scope.

FURPS/application/sds.md

@@ -0,0 +1,32 @@
+# Scalable Data Sync
+
+## Functionality
+
+1. Ability to know that a published message has been received by at least one member of the group (and could therefore eventually be retrieved by other members).
+2. Ability for participants to know when they have missed a message
+3. Ability to resend unacknowledged messages
+4. Ability to retrieve missed messages using Waku store protocol
+
+## Usability
+
+1. When sending a message to a large group, the application learns whether it was received by other group members.
+2. When being part of a large group, the application is able to know whether they are missing messages.
+3. When being part of a large group, the application is able to retrieve missed messages.
+
+## Reliability
+
+1. When sending a message in a group, the publisher can ascertain the message was received by at least one recipient **(Vac-QA)**.
+2. When receiving messages in a group, the receiver can ascertain most missed messages by receiving one recent message from the group. **(Vac-QA)**
+
+## Performance
+
+Assuming messages in a group are sent at least every `S` seconds, with `S` being no longer than `5 sec`.
+
+1. When sending a message in a group, the publisher can ensure the message was received by at least one recipient within `S` seconds **(Vac-DST)**.
+2. When receiving messages in a group, the receiver can detect 90% of missed messages within `3*S` seconds.
+3. When receiving messages in group, the receiver can reach eventual consistency within `6*S` seconds **(Vac-DST)**.
+
+## Supportability
+
+1. Applied to Communities channels on Status Desktop
+2. For Web apps as a developer library.

FURPS/application/status_communities.md

@@ -0,0 +1,34 @@
+# Status Communities FURPS
+
+Waku specific FURPS, before Chat SDK integration.
+
+## Functionality
+
+1. Waku traffic from Communities protocol is segregated from other traffic.
+2. Waku traffic from all Communities is routed through a common set of shards.
+3. Communities user content traffic is segregated from other Communities traffic.
+4. The usage of Waku content topic by Status Communities protocol is simplified.
+
+## Usability
+
+1. Users with Communities features deactivated are not impacted by Communities traffic of other users.
+2. It is possible to setup different Waku store databases, and different retention time for user content and other Communities messages.
+3. Store responsiveness and edge node readiness are improved.
+
+## Reliability
+
+1. No regression on Communities feature (Vac-QA).
+
+## Performance
+
+1. Time to setup filter subscriptions for Communities has improved by >20% (**Vac-DST**).
+2. Time to retrieve 24 hours of Communities messages has improved by >20% (**Vac-DST**).
+3. Increased community traffic does not increase bandwidth usage of 1:1 chat (**Vac-DST**).
+
+## Supportability
+
+1. Status Mobile, Desktop, Light and relay modes.
+
+## + (Privacy, Anonymity, Deployments)
+
+1. ...

FURPS/application/status_go.md

@@ -0,0 +1,27 @@
+# Status-go FURPS
+
+## Functionality
+
+1. Nwaku is the used Waku implementation for relay mode.
+
+## Usability
+
+1. Status Desktop CI run additional builds that uses nwaku. 
+
+## Reliability
+
+1. status-backend built with nwaku can pass the status-cli tests **(Vac-QA)**.
+
+## Performance
+
+1. status-backend built with nwaku has similar performance than go-waku based status-backend within 10% margin, 
+   on metrics measured by existing simulations (Vac-DST).
+
+## Supportability
+
+1. Status Desktop binary for Linux, Mac and Windows.
+2. Relay mode is supported; no edge/light mode.
+
+## + (Privacy, Anonymity, Deployments)
+
+1. Status Desktop CI builds binaries with nwaku, alongside go-waku-based binaries.

FURPS/application/status_private_chats.md

@@ -0,0 +1,31 @@
+# {Feature Name} FURPS
+
+Waku specific FURPS, **before** integration of the Chat SDK.
+
+## Functionality
+
+1. Features other than one-to-one chats are either removed or can be disabled.
+2. One-to-one chat’s traffic is not impacted by other features.
+3. One-to-one chats are functional when rate limited by 100 msg per 10min over Waku or less.
+
+## Usability
+
+1. Features other than one-to-one chat can be removed or disabled.
+2. A user with only one-to-one chat enabled can expect limited bandwidth and resource usage and a smooth experience.
+
+## Reliability
+
+1. One-to-one chat’s implementation behaves as specified (**Vac-QA**).
+
+## Performance
+
+1. 99% of one-to-one user messages are eventually received by their recipient, within 5 minutes of being online (**Vac-DST**).
+2. One-to-one chat’s non-user messages do not consume over 20% of the allocated quota (**Vac-DST**).
+
+## Supportability
+
+1. status-cli/backend
+
+## + (Privacy, Anonymity, Deployments)
+
+1. ...

FURPS/core/incentivisation.md

@@ -0,0 +1,31 @@
+# Incentivisation FURPS
+
+## Functionality
+
+1. RLNaaS clients proceed to pay RLNaaS providers for attaching RLN proof to published messages.
+2. RLNaaS clients can assess the quality of a provisioned RLNaaS and use it to build local reputation.
+3. RLNaaS clients can use local reputation of RLNaaS providers to select what provider to use.
+
+## Usability
+
+1. A consumer node can pay a service node for RLNaaS.
+2. A consumer node can select an RLNaaS provider based on local reputation.
+
+## Reliability
+ 
+1. A consumer prefers new providers to known unreliable providers.
+2. 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)**
+3. A client can assess whether an RLNaaS provider has relayed their message (**Vac-QA**)
+   in 90% of cases **(Vac-DST)**.
+
+## Performance
+
+1. Assuming a block time of 5 seconds,
+   a user can execute an RLNaaS payment and send a message within 30 seconds (Vac-DST)
+
+## Supportability
+
+1. A nwaku-based CLI on a testnet, interaction with a custodial wallet is out-of-scope.
+
+## + (Privacy, Anonymity, Deployments)

FURPS/core/light_push.md

@@ -0,0 +1,31 @@
+# Light Push FURPS
+
+## Functionality
+
+1. Enables light nodes to push messages to service nodes for relay to the network.
+2. Requests service nodes to publish messages to WAKU2-RELAY shards.
+3. Provides confirmation that a message has been received by at least one node.
+4. Supports comprehensive error codes for various failure scenarios.
+
+## Usability
+
+1. Implements simple async request/response pattern.
+2. Uses standard Waku Message format.
+3. Only requires an established libp2p connection.
+4. Provides descriptive error messages in responses.
+
+## Reliability
+
+1. Implements DoS protection through request rate limitation.
+2. Status codes indicate the best recovery method (retry, discard service node or irrecoverable failure).
+3. 80% message transmission success rate on live Status network (service node from both Status Desktop and fleet Waku instances)
+
+## Performance
+
+1. Only one network round trip is required per operation; including both configuration and message transmission.
+2. Minimizes protocol overhead for efficient resource usage.
+
+## Supportability
+
+1. Linux amd64 CLI as service node
+2. Browser as client

FURPS/core/rendezvous.md

@@ -0,0 +1,29 @@
+# Rendezvous FURPS
+
+## Functionality
+
+1. libp2p-rendezvous peer discovery protocol is used
+
+## Usability
+
+1. Relay nodes discover additional peers via libp2p-rendezvous
+
+## Reliability
+
+1. Relay nodes finds new peers when solely using rendezvous **(Vac-QA)**.
+
+## Performance
+
+1. In an established network of 1k relay nodes on 10 shards with 1 bootstrap node,
+   100 new relay nodes (relay + discv5 + Waku PX + rendezvous)
+   can connect to 20 relay peers in the right shard within 1 minute (**Vac-DST**)
+   ; run simulation without rendezvous to see the difference
+
+## Supportability
+
+1. Enabled in status-go using nwaku c-bindings
+2. Enabled in nwaku-compose
+
+## + (Privacy, Anonymity, Deployments)
+
+N/A

FURPS/core/rln_relay.md

@@ -0,0 +1,31 @@
+# RLN Relay FURPS
+
+## Functionality
+
+1. Light push service node can attach RLN proof for clients.
+
+## Usability
+
+1. Light push clients do not need RLN logic.
+
+## Reliability
+
+1. Relay node can fallback to alternative RPC endpoints
+   if the primary Web3 RPC provider becomes unavailable.
+
+## Performance
+
+1. In a network of 10k RLN Relay nodes with each node sending one 1-100KB message every 10-30s,
+   messages are propagated within 500ms, with 99.9% success **(Vac-DST)**.
+2. In a network of 10k RLN Relay nodes,
+   a spamming node will be disconnected from its peers in under 1 min. **(Vac-DST)**
+
+## Supportability
+
+1. Service node proof generation for light push clients is available in `wakunode2` for browser clients.
+
+## + (Privacy, Anonymity, Deployments)
+
+1. Service node proof generation for light push clients is deployed on TWN.
+2. Service node proof generation for light push clients is enabled by default in nwaku-compose.
+

FURPS/core/rln_smart_contract.md

@@ -0,0 +1,33 @@
+# RLN Smart Contract FURPS
+
+## Functionality
+
+1. RLN rate limit can be defined in terms of multiple messages per epoch.
+2. RLN rate limit is set at membership insertion
+3. RLN proof generation and validation only requires Web3 RPC `call`s, no blockchain events or initialisation are needed.
+4. An ERC-20 token deposit is needed to insert a membership
+
+## Usability
+
+1. Application developers can set RLN rate limit at insertion.
+2. User does not need to wait for merkle tree synchronization and building to start relaying
+   or sending messages.
+
+## Reliability
+
+1. ...
+
+## Performance
+
+1. New node setup with an RLN membership can be ready to verify RLN proof within 5s,
+   no matter the size of the membership set **(Vac-DST)**.
+
+## Supportability
+
+1. ...
+
+## + (Privacy, Anonymity, Deployments)
+
+1. Smart Contracts are deployed on Linea Sepolia.
+2. TWN uses smart contracts deployed on Linea Sepolia.
+

FURPS/core/store.md

@@ -0,0 +1,40 @@
+# Store
+
+## Functionality
+
+1. Provides historical message retrieval from the relay network, enabling nodes to query for messages they missed while offline.
+2. Supports multiple query types: time-based, content-topic filtered, and message hash lookups.
+3. Enables message presence verification without retrieving full message content.
+4. Supports pagination for efficient retrieval of large message sets, and resuming retrieval after disconnection.
+5. Supports comprehensive error codes for various failure scenarios.
+6. Industry practices are applied to PostgreSQL setup to reach appropriate performance
+7. Provides a retention policy mechanism that allows keeping the disk occupation constant.
+
+## Usability
+
+1. Implements simple async request/response pattern.
+2. Uses standard Waku Message format.
+3. Only requires an established libp2p connection.
+4. Provides descriptive error messages in responses.
+5. Supports query filtering to retrieve only relevant messages by content topic.
+
+## Reliability
+
+1. Implements DoS protection through request rate limitation.
+2. (limitation) No guarantees in terms of message presence or retention duration.
+3. Store node always provide a response; thanks to DoS protection.
+
+## Performance
+
+1. Only one network round trip is required for operation.
+2. Implements pagination to manage resource usage on both client and server.
+3. Allows presence queries to verify message existence without transferring full content.
+4. Targets query response times under 2 seconds for typical requests.
+5. 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)**.
+6. Time range queries of less than 1 hour, using up to 10 content topics, are served under 60 ms; for a database less than 250 GB size and average message size under 500KiB  **(Vac-DST)**.
+
+## Supportability
+
+1. Linux amd64 CLI as service node
+2. PostgreSQL as database engine.
+3. Browser support as client.

PROCESS.md

@@ -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.
 

ROADMAP.md

@@ -1 +0,0 @@
-Roadmap and milestones can be found on the [Logos roadmap](https://roadmap.logos.co/waku/).

draft-roadmap/README.md

@@ -0,0 +1,31 @@
+# Waku Draft Roadmap
+
+Finalised roadmap and milestones can be found on the [Logos roadmap](https://roadmap.logos.co/waku/).
+
+Period in planning: 2025 H1
+
+- [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. 
+- [Nwaku in Status Mobile](https://roadmap.logos.co/waku/milestones/open/2025-nwaku-in-status-mobile): deprioritized in favour of improving API for new Chat SDK
+- [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.
+
+## Draft Milestones
+
+Testing out new format, once approved:
+
+- Milestones are moved to Logos roadmap
+- 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)

draft-roadmap/TEMPLATE.md

@@ -0,0 +1,32 @@
+# {Milestone Title - use verb}
+
+**Estimated date of completion**: {Enter date}
+
+**Resources Required for 2025H2**:
+- {roles and % application to it}
+- {external services consumed (Vac/IFT)}
+- {infrastructure}
+
+
+{Milestone Description - what do we get once done}
+
+**FURPS**:
+
+- [{Feature Name}]({path/to/furps/file}): {list of furps: F1, etc}
+
+**deliverables**: 
+
+## {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)

draft-roadmap/define_incentivisation_for_rlnaas.md

@@ -0,0 +1,54 @@
+# [Define Incentivisation for RLNaaS](https://github.com/waku-org/pm/milestone/35)
+
+**Estimated date of completion**: 31 July 2025
+
+**Resources Required for 2025H2**:
+- 1.5 core researchers for 1 month
+
+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.
+A sustainable Waku infrastructure is necessary within Status to achieve scalability for 1:1 chats and permissionless communities.
+These Status features use RLN rate-limiting on shared shards as supported by the RLN relay nodes
+and require a set of decentralised services for Status Mobile and resource-restricted clients,
+including RLN proofs as a service, Store, Filter and Lightpush.
+This milestone encapsulates the efforts to distribute rewards for running RLN Relay nodes and getting paid for providing Waku services.
+This is the first step to providing a sustainable way to scale the Status application.
+
+**FURPS**: TODO
+
+**deliverables**: https://github.com/waku-org/pm/milestone/35 TODO adjust deliverables with FURPS
+
+## [Pay for RLN provision PoC](https://github.com/waku-org/pm/issues/245)
+
+**Owner**: core research
+
+**Feature**: [Incentivisation](/FURPS/core/incentivisation.md)
+
+**FURPS**:
+- F1. RLNaaS clients proceed to pay RLNaaS providers for attaching RLN proof to published messages.
+- F2. RLNaaS clients can assess the quality of a provisioned RLNaaS and use it to build local reputation.
+- F3. RLNaaS clients can use local reputation of RLNaaS providers to select what provider to use.
+- U1. A consumer node can pay a service node for RLNaaS.
+- U2. A consumer node can select an RLNaaS provider based on 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)**.
+- 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,
+  a user can execute an RLNaaS payment and send a message within 30 seconds (Vac-DST)
+
+For S1. A nwaku-based CLI on a testnet, interaction with a custodial wallet is out-of-scope.
+
+**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)
+
+## [Service incentivisation roadmap & spec](https://github.com/waku-org/pm/issues/246)
+
+**Owner**: core research
+
+**Output**: a roadmap document.

draft-roadmap/formalize_logos_web_apps.md

@@ -0,0 +1,19 @@
+# Formalize Logos Web Apps
+
+**Estimated date of completion**: 19 Dec 2025
+
+**Resources Required for 2025H2**:
+- 1.5 engineers for 6 months
+
+Develop Web applications for Logos, using the Logos technology stack:
+
+- Qaku (Q&A over Waku): harden Waku to MVP level, so it can be used for IFT Town Halls, and Logos physical events
+- Logos Operators Forum: Build a web forum PoC over Waku to serve as a basis for a decentralized Logos forum (opchan).
+
+As well as leveraging Qaku to explore Codex x Waku integration.
+
+**FURPS**:
+
+- [{Feature Name}]({path/to/furps/file}): {list of furps: F1, etc} TODO
+
+**Milestone and deliverables**: https://github.com/waku-org/pm/milestone/42 

draft-roadmap/foundation_for_communities_optimisation.md

@@ -0,0 +1,22 @@
+# [Foundation for Communities Optimisation](https://github.com/waku-org/pm/milestone/31)
+
+**Estimated date of completion**: 7-Apr-2025 - to be reviewed TODO
+
+**Resources Required for 2025H2**:
+- App/Chat engineer: Pablo 100% for X months - TODO
+
+Once completed, the usage of content topics by Communities will be simplified,
+enabling both improvements in terms of store queries and light mode message reception,
+but also enabling future optimization and improvements at a lower cost.
+Moreover, Communities traffic will be separated from other functionalities.
+This enables easy bandwidth and performance improvements (remove usage of relay for large messages,
+reduce message retention and hence DB size for control messages), as well as protecting users that do not
+use communities from Communities traffic.
+Finally, Communities traffic will be segregated in a few shards, per message types;
+enabling future bandwidth or performance optimization such as setting up different DB per message type,
+reducing retention time for control messages, or disabling the usage of relay for large messages.
+
+
+**FURPS**: [Status Communities](/FURPS/application/status_communities.md): all.
+
+**Milestone and deliverables**: https://github.com/waku-org/pm/milestone/31 

draft-roadmap/hardening_and_scaling_foundation_for_private_chat.md

@@ -0,0 +1,39 @@
+# [Hardening and Scaling Foundations for Private Chats](https://github.com/waku-org/pm/milestone/40)
+
+**Estimated date of completion**: TODO
+
+**Resources Required for 2025H2**: TODO
+- {roles and % application to it}
+- {external services consumed (Vac/IFT)}
+- {infrastructure}
+
+With this milestone, we establish a foundation for scaling one-to-one and private group chats to support a larger
+number of users. Additionally, we will harden the underlying protocols by studying and refining the current
+specifications, as well as isolating user traffic from other features.
+
+Our approach to RLN integration will involve two initial steps. First, we will implement a low rate limit and
+collaborate with the Status team to address the user experience challenges that arise. By combining this with clear
+specifications, we will be able to better understand scalability for one-to-one chats, including the relationships
+between user count, usage, and bandwidth/resource utilization.
+
+Furthermore, the enhanced specifications will enable the Vac-QA team to expand test coverage, increasing confidence in
+reliability and facilitating any future refactoring efforts.
+
+To achieve this milestone successfully, it is essential that one-to-one chats are isolated from other features using
+Waku, such as Communities, user settings backup, and device pairing/synchronization. Ideally, these features should be
+either removed or disabled by default to ensure accurate testing and evaluation.
+
+**Private chats refers to both one-to-one and private group chats.*
+
+**FURPS**:
+
+- [Status Private Chats](/FURPS/application/status_private_chats.md): all
+
+**Milestone and deliverables**: https://github.com/waku-org/pm/milestone/40
+
+TODO: [clean-up the deliverables](https://discord.com/channels/1110799176264056863/1337300409412489290/1379311090302980097):
+- specify private chat: drop
+- rate limit poc: finish it
+- network metrics: move it
+- baseline benchmarks: handover to DST
+- status-cli: review with QA

draft-roadmap/integrate_nwaku_in_status_desktop_relay_mode_only.md

@@ -0,0 +1,28 @@
+# Integrate nwaku in Status Desktop, relay mode only
+
+**Estimated date of completion**: 30 June
+
+**Resources Required for 2025H2**:
+- 1 nwaku engineer
+
+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.
+
+**FURPS**:
+
+- [nwaku](/FURPS/application/nwaku.md): F1-2, S1-2, +1
+- [status-go](/FURPS/application/status_go.md): F1, U1, R1, P1, S1-2, +1
+
+**GitHub Milestone and deliverables**: https://github.com/waku-org/pm/milestone/33

draft-roadmap/introduce_e2e_reliability_in_status.md

@@ -0,0 +1,69 @@
+# Introduce E2E Reliability in Status Communities
+
+**Estimated date of completion**: 31 Aug 2025
+
+**Resources Required for 2025H2**:
+- 1 app chat engineer for 2 months
+- (core research work finishes by end of June)
+
+(Renamed "e2e reliability protocol " milestone, but work as per scope, only split a deliverable)
+
+To solve reliability is to solve two problems:
+
+1. High heuristic that messages are received and sent
+2. Ability to know whether messages are received or sent
+
+Problem (1) can never be 100% reliable in a network environment. The previous milestones focused on it.
+To solve (2), is to create an end-to-end protocol, sender to recipient, that enables the ability to know whether recipient(s) have received messages.
+
+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;
+as well as in the browser for PoC Web Apps such as Qaku and Logos Forum.
+
+**FURPS** (see deliverables)
+
+**GitHub Milestone and deliverables**: https://github.com/waku-org/pm/milestone/29
+
+## [SDS protocol in Status - basic integration](https://github.com/waku-org/pm/issues/194)
+
+**Owner**: core research
+
+**Feature**: [SDS](/FURPS/application/sds.md)
+
+**FURPS**:
+- F1. Ability to know that a published message has been received by at least one member of the group (and could therefore eventually be retrieved by other members).
+- F2. Ability for participants to know when they have missed a message
+- U1. When sending a message to a large group, the application knows whether it was received by other group members, with high probability
+- U2. When being part of a large group, the application is able to know whether they are missing messages
+- R1. When sending a message in a group, the publisher can ascertain the message was received by at least one recipient **(Vac-QA)**
+- R2. When receiving messages in a group, the receiver can ascertain most missed messages by receiving one recent message from the group. **(Vac-QA)**
+- P1. When sending a message in a group, the publisher can ensure the message was received by at least one recipient within `S` seconds **(Vac-DST)**
+- P2. When receiving messages in a group, the receiver can detect 90% of missed messages within `3*S` seconds
+
+For S1. Applied to Communities channels on Status Desktop
+
+**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)
+
+## [SDS protocol in Status - basic recovery](https://github.com/waku-org/pm/issues/304)
+
+**Owner**: chat app dev
+
+**Feature**: [SDS](/FURPS/application/sds.md)
+
+**FURPS**:
+- F3. Ability to resend unacknowledged messages
+- F4. Ability to retrieve missed messages using Waku store protocol
+- U3. When being part of a large group, the application is able to retrieve missed messages
+- P3. When receiving messages in group, the receiver can reach eventual consistency within `6*S` seconds **(Vac-DST)**
+
+For S1. Applied to Communities channels on Status Desktop
+
+**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)

draft-roadmap/rln_mainnet.md

@@ -0,0 +1,80 @@
+# RLN Mainnet
+
+**Estimated date of completion**: 30 June 2025
+
+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 mainnet.
+
+It will then be possible to design the usage of RLN in Status.
+
+
+**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)