List view
Peer discovery for mixnet was descoped from the previous milestones due to upcoming challenges around ENR usage and modification to libp2p needed to support mix peers in rendezvous. Web apps have been a strong dogfooding and adoption driver for Waku, especially for edge nodes. Adding mix will not only enable wider dogfooding, but also increase anonymity for browser users.
Due by March 31, 2026•0/2 issues closed- Overdue by 28 day(s)•Due by October 24, 2025•2/3 issues closed
Improve usage of Nim related tooling and design patterns by proceedings with PoCs to discover potential gains and caveats. This includes adoption of Nimble, dogfooding VSCode plugin and iteration on C-Binding methodology.
Due by December 19, 2025•0/1 issues closedDeliver 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.
Overdue by 25 day(s)•Due by October 27, 2025•0/5 issues closedProceed with follow-up step once the [incentivisation light push PoC](https://github.com/waku-org/pm/issues/245) is delivered. The exact commitments and deliverables are to be defined as part of the [incentivisation roadmap output](https://github.com/waku-org/pm/issues/246) This includes progress towards both incentivisation and marketplace problems.
No due dateOnce done, apps like Status can build a chat experience which includes support for multiple device, and multiple participants in a given group chat. The features to said group chat will be limited, and extended with further milestones. Support to plug Status Communities on top of this SDK is not expected. Further group size scaling and extension of membership management API would be needed.
No due date•0/3 issues closedBy 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.
Overdue by 3 month(s)•Due by July 31, 2025A PoC implementation to improve anonymity in Waku message publishing by mixing Waku Lightpush requests and responses.
Overdue by 1 month(s)•Due by September 30, 2025•1/1 issues closedComplete 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. Provide a similar harness to deploy a local RLN dev environment. Finalize the integration of nwaku in Status application by setting up nwaku-based build for Mobile platforms. Lastly, develop a PoC protocol to demonstrate the usage of Waku as a Signal network, using WebRTC as example. This was identified as a demanded demonstration of Waku's capabilities as part of the [Waku MVP analysis](https://www.notion.so/Waku-MVP-1838f96fb65c8039acabf8a6a1e689e7).
Due by November 30, 2025•0/6 issues closedProceed 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 - Testing quic as new transport
Overdue by 25 day(s)•Due by October 27, 2025•3/8 issues closedThe SDK is intentionally minimal—focused solely on proving the usability of the core approach. It supports 1:1 chat with out-of-band contact discovery and includes supporting implementations to help developers get up and running quickly. The primary goal is to deliver a usable library that developers can build with today, while laying a flexible foundation for future extensions such as group chats and identity. Releasing early as possible maximizes feedback time and interaction speed. Motivations for development of a new chat protocol are described [here](https://forum.vac.dev/t/chatsdk-motivations/501). This milestone is complete when a development preview of the Chat SDK is published and made available to the community.
Overdue by 1 month(s)•Due by September 30, 2025•0/4 issues closedHarden select Waku Web apps by extracting libraries and writing protocol specifications: - Qaku (Q&A over Waku): harden Waku to MVP level, so it can be used for IFT Town Halls, and Logos physical events. - Integrate SDS and write specs. - Logos Operators Forum: Build a web forum PoC over Waku to serve as a basis for a decentralized Logos forum (opchan). - Added: Extend the Forum PoC to new FURPS, to align with Logos Movement needs. Explore Codex x Waku integration, in Qaku and one other application. Develop 10 Waku Web Apps PoC, and push them to the community to "teach them how to hunt" as well as inspire developers to build over Waku.
Due by December 19, 2025•2/7 issues closedhttps://roadmap.logos.co/waku/milestones/open/2025-hardening-and-scaling-foundations-for-private-chats 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.
No due date•4/5 issues closedhttps://roadmap.logos.co/waku/milestones/open/2024-incentivise-running-infra-node 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.
Overdue by 1 month(s)•Due by October 10, 2025•3/4 issues closedWith 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.
Overdue by 1 month(s)•Due by October 17, 2025•1/3 issues closedhttps://roadmap.logos.co/waku/milestones/open/2025-foundation-for-communities-optimization Once completed, the usage of content topics by Communities will be simplified, enabling both improvements in terms of store queries and light mode message receival, 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.
Overdue by 21 day(s)•Due by October 31, 2025•6/7 issues closed(Renamed "e2e reliability protocol " milestone, but work as per scope, only split a deliverable) To solve reliability is to solve two problems: High heuristic that messages are received and sent 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.
Overdue by 2 month(s)•Due by August 31, 2025•2/4 issues closed