# **The Waku Roadmap**

What's an explorer without its compass, a network without roadmap?

With the ongoing efforts of teams to scale Waku, you and others following Waku might be wondering where we are going. This article contains a pocket guide to our current technical goals throughout 2023 and parts of 2024. Mainly curious about our specific milestones and roadmap? [Jump directly to it.](#Waku-Network-Gen-0)

We are not just promising that we’re not running your messages through a Firebase backend --- no need to only trust our words. Find out for yourself instead, follow our work closely. Curious what we've done for this year yet? Have a read **here**. [ADD LINK OF PUBLISHED WAKU HALFYEAR OVERVIEW ARTICLE]

## Waku

What is this network, and why does it matter what we're building? Isn't [whisper already a thing that's there to do what we aim to do](https://our.status.im/peer-to-peer-messaging-where-whisper-falls-short-and-waku-picks-up/)?

[Waku](https://waku.org) is a decentralised, open-source suite of privacy-preserving, peer-to-peer messaging protocols. It is designed for general messaging with humans, machines, or a hybrid situation. Waku runs everywhere. On your phone, a server, or through your browser.

We apply [Waku Relay](https://hackmd.io/@vac/main/%2FYYlZYBCURFyO_ZG1EiteWg#11WAKU2-RELAY-gossipsub) on top of the gossip protocol [GossipSub](https://docs.libp2p.io/concepts/pubsub/overview/) from libp2p to route messages & information with a subset of connected peers. We apply this variation to increase our required levels of security and privacy. - **A gossip protocol** is a peer-to-peer protocol in which nodes periodically exchange information about themselves and other nodes they know. *I recommend playing with this [(web)simulator by flopezluis](https://flopezluis.github.io/gossip-simulator/) to visually understand how a gossip protocol intends to work.*

Currently, it's possible to use the Waku Network and join a public gossipsub network in a permission-less manner. Some projects using Waku opt to do so (Status Desktop, 0.13.0). This comes with its own [limitations](#Limitations).

### Limitations

The current Waku Network comes with limitations that aren't only limited to restricted devices. These also come from having a public Waku Network.

* **Unscalable**: having all users on one gossipsub network means that every user needs to relay the traffic of all apps. This means that as the adoption of Waku increases, bandwidth usage does so too. Stopping those with limited bandwidth to fully participate in the Waku Relay network, and have to use light client protocols. As for blockchain nodes, to be fully decentralised, Waku needs to keep the resource consumption of relay nodes low so it can run on a household bandwidth

* **No DOS/Spam protection**: Similarly to the lack of scalability in normal conditions, currently, the Waku network is not protected against an attacker trying to flood the network with data to the point that normal users would be unable to use the network.

Restricted devices such as your phone or browser come with additional limitations. They cannot easily participate in the relay network due to bandwidth consumption and have the requirement to be mostly online. To facilitate this participation, we have a set of light client protocols (light push, filter, store) that consume resources from the network. With their own set of limitations:

* It claims disk space or memory for a node to provide these services.
* A node consuming these services does not contribute to the scalability of the network; it subtracts from it.


### Waku Fixes

The Waku protocols solve the above issues by:

* **Sharding the network** Instead of having one relay network, we split the "Waku network" into several relay (gossipsub) networks so that the application user does not have to relay all applications' traffic but just the ones on the same shard.
* **Rate limiting** A user (or attacker) cannot flood the network beyond the maximum expected bandwidth usage.

Those solutions come with a cap on scalability alongside certain caveats. The [Waku Network Gen 0](#Waku-Network-Gen-0) aims to remove those through:

* **Automating shard allocation**: The auto-sharding protocol automatically allocates messages for an application.

* **Privacy-preserving rate limiting**: We intend to use RLN (Rate Limited Nullifer) protocol to enable rate-limiting of messages being sent by individuals over the network. Individuals get a membership by joining a zero-knowledge group on-chain. The number of members in the group will be capped to guarantee maximum bandwidth usage by the network.

* **Optimizing Nodes**: Running nodes that fully participate in the Waku Relay Network should be optimised because:
* It is permission-less
* It is a neutral contribution to the network, hence the backbone of a secure, scalable network
* It provides sender and recipient anonymity

---
We have developed static sharding and opt-in messaged signing as stopgap solutions to match the Status app timeline and needs. **INSERT LINK UNDER WE HAVE DEVELOPED** This, in addition to additional protocols and software improvement, will enable us to launch a public network with reasonable bandwidth usage, even under active attacks.

It's important to note that all current and future issues need to be solved while preserving our principles:

* Decentralised
* Privacy preserving
* Permission-less

## Milestones & Roadmap
Within Waku, we divide our work into epics and tasks within strategic milestones.

[Epics](#Gen-0-Epic-Summaries-amp-Keys) are larger tasks often collaborated on; compare it to an epic quest, where you'll need a ship and crew to conquer unknown waters. Within these epic quests, each crew member gets specific tasks linked to their particular skills.

We are currently tracking and planning towards four core milestones, of which Gen 0 is our primary objective:

- [Waku Network Gen 0](https://github.com/waku-org/pm/milestone/1)
- [Waku Network Can Support 1 Million Users](https://github.com/waku-org/pm/milestone/4)
- [Support Many Platforms](https://github.com/waku-org/pm/milestone/2)
- [Quality Assurance processes are in place](https://github.com/waku-org/pm/milestone/3)

Waku Network Gen 0 milestone owns this priority due to its relevance to launching Waku's MVP. Within this milestone, we have 20 epics, divided through 3 tracks.
INSERT ROADMAP VISUAL HERE

## Waku Network Gen 0

Why Gen 0? While this new set of protocols will enable Waku to be scalable and use reasonable resources, it is not the end of our journey. More work will be required to decentralise the network, especially around incentivisation and decentralising light client services. We also set a limited number of shards. In the future, we may "upgrade" the network to Gen 1 to either increase scalability, introduce new protocols or both. **-REVIEW and CLEAN**

### Tracks

In Waku, we have organised our Research & Development work towards the Waku Network Gen 0 Milestone into three tracks; click on the title to get a more detailed summary of each involved epic in these tracks or follow the overview link to see our progress live updated directly:

- [General Track](#General-Track)
- The foundational work focuses on creating a scalable and autosharded Waku Network. Here, we determine specifications, design, and implement strategies based on our research and development that aid in scaling the Waku Network. It also tracks our primary goal of the [Waku Network MVP launch](https://github.com/waku-org/research/issues/1).

| Epic & Task Overview |
| -------- |
| [Link](https://github.com/orgs/waku-org/projects/2/views/2?filterQuery=E%3A+1.+) | |

- [Service Protocols](#Service-Protocols-Track)
- Our focus within [Service protocols](https://docs.waku.org/overview/concepts/protocols) is required to upkeep and expand protocols such as filter, lightpush, peer-exchange and store within the public network through a decentralised manner. Work within this track also involves ongoing efforts to incentivise our network.

| Epic & Task Overview |
| -------- |
[Link](https://github.com/orgs/waku-org/projects/2/views/2?filterQuery=E%3A+2.+) | |

- [DOS Protection](#DoS-Protection-Track)
- Denial Of Service (DOS) mitigation is a challenge within any network. Not only does it interfere with users' usability, it also eats up the bandwidth of the Network. This track covers consensus mechanisms such as our epoch designs, and if we do, how do we fairly allow free traffic? We must implement measures to ensure the overall bandwidth usage is feasible for additional protocol-wide DOS protection. We need to assist node operators in maximising the usage of their resources and allocate shard support depending on current traffic so that we can assure ongoing service guarantees.
| Epic & Task Overview |
| -------- |
| [Link](https://github.com/orgs/waku-org/projects/2/views/2?filterQuery=E%3A+3.+) |

---

## Gen 0 Epic Summaries & Keys
#### **General Track**

- **[Epic 1.1: Network requirements and design](https://github.com/waku-org/research/issues/6)**
* Goal: 22 Sept 2023
* Key Activities:
- Determine network specifications and design.

The blueprint for the entire network. The design decisions made in this phase, such as bandwidth expectations and shard numbers, will drive subsequent developments.

- **[Epic 1.2: Autosharding for autoscaling](https://github.com/waku-org/pm/issues/65)**
* Goal: 30 Sept 2023
* Key Activities:
- Design & implement autosharding strategy.
- Launch a limited number of shards.

Following 1.1, we track the designing and implementing an [autosharding](https://rfc.vac.dev/spec/51/#automatic-sharding) strategy based on content topics and the design requirements established in 1.1.

- **[Epic 1.3: Node bandwidth management mechanism](https://github.com/waku-org/pm/issues/66)**
* Goal: 31 Oct 2023
* Key Activities:
- Implement bandwidth management to dynamically choose a number of shards based on availability for relay nodes.
- Design predictable bandwidth limits per shard.

[Having already improved our initial bandwidth usage](https://vac.dev/rlog/waku-v1-v2-bandwidth-comparison/), we expect the autosharded network to grow. Alongside the increase in traffic, we aim to deliver a mechanism to foster this continuation.

- **[Epic 1.4: Peer management and discovery](https://github.com/waku-org/pm/issues/67)**
* Goal: 30 Nov 2023
* Key Activities:
- Design transparent interaction between applications and shards.
- Peer management system to track & discover public shared peers

As this traffic further increases, it's important shards and applications can [discover each other.](https://vac.dev/rlog/wakuv2-apd/) Either they could subscribe to shards carrying relevant content, or the peer manager should be able to track peers from all **public** shards to be able to discover them on demand. To facilitate this, the Waku research team has to enhance existing protocols to enable shard and service discovery of Waku nodes.-

- **[Epic 1.5: Launch and dogfood integrated public Waku Network MVP](https://github.com/waku-org/research/issues/1)**
* Goal: 31 Jan 2024
* Key Activities:
- Launch Waku Network MVP.
- Gather feedback and improve.

At the end of a treasure map, after conquering wild, unknown territories and challenges. There supposedly lays a chest of gold. For Waku's Gen0 milestone, rather than hunting gold, it is the launch of the Waku Network MVP.

---

#### **Service Protocols Track**

- **[Epic 2.1: Production testing of existing protocols](https://github.com/waku-org/pm/issues/49)**
* Goal: 30 Nov 2023
* Key Activities:
- Test and improve existing service protocols: [filter](https://rfc.vac.dev/spec/12/), [lightpush](https://rfc.vac.dev/spec/19/), and [peer-exchange](https://rfc.vac.dev/spec/34/).

As we move forward, we have added the new PostgreSQL archive backend for our store protocol and have redesigned our Filter protocol. We continue with the implementation phase for dogfood and their use in production environments. A battle test for our new vessels before we fully sent them to their maiden voyage.

- **[Epic 2.2: Sharded capability discovery for light protocols](https://github.com/waku-org/pm/issues/63)**
* Goal: 30 Sept 2023
* Key Activities:
- Peer selection mechanism that translates content topics to their underlying shard

As our protocols are being dogfed into our production environment, we're working on the ability to [discover peers](https://docs.waku.org/overview/concepts/peer-discovery) providing filter, lightpush, and peer-exchange services, which translates to applications having a peer selection mechanisms translating content topics to underlying shards.

- **[Epic 2.3: Basic distributed store services](https://github.com/waku-org/pm/issues/64)**
* Goal: 30 Nov 2023 (integrate in 2024)
* Key Activities:
- Discover Store nodes for specific content topics and time ranges.
- Service nodes to advertise their store services

Once we have evolved our previous service protocols, we aim to allow [store nodes](https://rfc.vac.dev/spec/13/) to discover services for specific content topics and time ranges so their service nodes can advertise their store services.

- **[Epic 2.4: Basic design for service incentivization](https://github.com/waku-org/pm/issues/80)**
* Goal: 31 Dec 2023
* Key Activities:
- Incentivize service provision of the Waku Network
- Tokenomics implementation

What's a state-of-the-art ship or protocol, without the manpower or power to fuel its engines? Waku aims at long-term sustainability, which comes with incentives for node operators to keep the ship afloat. We work alongside Logos's internal Tokenomics team to design a model that keeps the wind in our sails and stays aligned with our [principles](https://docs.waku.org/#motivation-and-goals).

---

#### **DoS Protection Track**

- **[Epic 3.1: DoS requirements and design](https://github.com/waku-org/pm/issues/69)**
* Goal: 22 Sept 2023
* Key Activities:
- Define DoS/spam protection specifications.
- Design initial membership mechanisms.
- [Free and or paid traffic design](https://hackmd.io/@alrevuelta/rkqbPKaoo)

We don't want our ship to sink under the pressure of undesired attention. Dos and spam protection is a real problem within communication protocols and applications. We aim to answer questions regarding epoch sizes, member mechanisms, and free traffic allowances.

- **[Epic 3.2: Basic DoS protection in production](https://github.com/waku-org/pm/issues/70)**
* Goal: 31 Oct 2023
* Key Activities:
- Implement and launch the RLN mechanism.
- Implement rate limiting.

Once we've found answers to our hull-creating questions, we provide an RLN implementation with a membership mechanism and a rate-limiting system. This will allow applications to provide their own mechanisms through a message validation API.

- **[Epic 3.3: Membership for Status Communities](https://github.com/waku-org/pm/issues/71)**
* Goal: 30 Nov 2023
* Key Activities:
- Design membership assignments for community members

Here, we dogfeed our designed mechanisms into a membership system aimed at Status communities. Community owners will be able to assign the RLN membership to their community members.

- **[Epic 3.4: Further memberships](https://github.com/waku-org/pm/issues/72)**
* Goal: 31 Dec 2023
* Key Activities:
- Expanding memberships to third parties

Once we've achieved the successful maiden voyage, we will expand memberships alongside high QoS access of the public Waku Network to third parties. There might be a need for a staking mechanism depending on the needs of these 3rd parties.

---

## **Decoding Roadmap Risks**

The Waku Network Gen 0 is foundational to having a censorship-resistant, privacy-preserving, resource-restricted, device-inclusive network. However, much is yet to be defined when bringing this theoretical work to life. We have yet to answer the questions part, and beyond this roadmap, Clarity is our best ally. And for one to obtain such clarity, one should also be present and mindful of risks. We also see certain risks in our plans and assess those.

**1. A lack of straightforward process design**

Without a structured design, we're navigating without a compass. A solid design provides direction and coherence. Sometimes, when one is at sea, a captain must rely on it's surroundings rather than plans.

Each epic contains several topics that are dependent on the previous completion of tasks. Each of these deliverables is subject to change based on new research results or previous tasks' completion. Depending on those results, we might need to adjust our course to ensure we reach our final destination

We are committed to building in the open. It is not easy to navigate the Waku RFCs or our [project management process](https://github.com/waku-org/pm/blob/master/README.md). This is why we are dedicating effort to easily digestible content such as this article and our documentation [docs.waku.org](https://docs.waku.org)

***Risks**:* Ambiguity can lead to misaligned team efforts, confuse external stakeholders or interested peers, and thus create potential development inefficiencies.

**2. The Uncertainties of Waku Network Operations**

The Waku Realy is our backbone for decentralised communications. A spine that just as much also needs a motoric system to function. We don't know what the future brings, nor do we know certain answers to how we will run our Future Waku Network on an operational network.

***Risk**:* Clear internal and external operations promise success. This is a point we still need to declutter.

**3. Navigating Bandwidth Management**

Bandwidth in peer-to-peer networks is a luxury as much as a tight grip on it is necessary. To have a large group of peers host their nodes, we'll need to keep tight control of how much bandwidth they allocate to their nodes. We've all had issues trying to run a node, and our family complains about their Netflix buffering. This still needs to be clarified for us.

***Risks**:* System bottlenecks, reduced efficiency, potentially hampering the user experience, and the chance of excluding peers due to data bandwidth limitations.

**4. The lack of Key Rotation Mechanisms for Status Communities**

Security isn't a buzzword; it's our fort. The absence of a key rotation mechanism leaves the doors open to vulnerabilities.

***Risk**:* This leads to an increased security risk that can affect our security promise.

---
Our roadmap should serve as a lucid guide. Addressing these technical intricacies upfront isn't just smart; it's essential for a smooth journey through undiscovered waters.

## Help us navigate these waters

To ship out features continuously, we need strong arms and capable minds on deck. Keen to give us a hand?

Say hello to us, ask your questions on [Discord](https://discord.gg/GdJJh38sZR), [join our team](https://jobs.status.im/), or crack some of our [bounties](https://github.org/waku-org/bounties) --- No need to remain shy!

You may see yourself more as a fellow captain. Help us to ensure that we are staying decentralised by [running your own Waku Node!](https://docs.waku.org/guides/run-nwaku-node)

Rather follow our adventures from safe shores? Follow our [Twitter](https://twitter.com/Waku_org) to keep yourself updated on new launches.

### Ship with us

| | Integrate Waku in your application |
| --- | --- |
| docs | https://docs.waku.org |
| nwaku | https://github.com/waku-org/nwaku |
| browser (JS/TS) | https://github.com/waku-org/js-waku |
| Go | https://github.com/waku-org/go-waku |
| Rust | https://github.com/waku-org/waku-rust-bindings |

# --- Notes

-----------

## **Waku Network MVP Overview: Unified Timeline**
[is going to become a visual] [Needs timeline updates]

---