## [Waku Network Can Support 10K Users](https://github.com/waku-org/pm/issues/12)
- _achieved:_
- final PostgreSQL optimisations completed. Benchmarks published: https://www.notion.so/Postgres-e33d8e64fa204c4b9dcb1514baf9c582
- added "debug nodes" with trace-level message logging to each Status fleet to allow for easier e2e message traceability
- confirmed no unknown blockers from Waku's side to continue dogfooding in conversation with Status Communities
- _next:_
- continue integration of static sharding in status-go.
- dogfooding of Status Desktop with Status staging fleet. Will aim to create a small internal Waku community
- _risks:_
- Dependency on Vac/DST to conclude ~1k nodes simulations.
- Implementation of static sharding in Status Communities and design decisions mostly driven by go-waku developer, with minimal input from Status dev ([1](https://github.com/status-im/status-go/pull/4161), [2](https://github.com/status-im/status-go/pull/4094), [3](https://github.com/status-im/status-go/pull/4093)). See [status-go#4057](https://github.com/status-im/status-go/issues/4057) for remaining work. Mitigation by on-boarding Chat SDK lead on 6 Nov to drive effort.
- lack of confidence in simulation results: results so far exhibits various artifacts and anomalies seemingly related to tooling limitations. It is therefore difficult to draw certain conclusions re Waku scalability.
- lack of clarity in terms of Status fleet ownership, monitoring and maintenance, which is an integral part of the solution.
### [Targeted dogfooding for Status Communities](https://github.com/waku-org/pm/issues/97)
- _achieved_: deployed bridge between default pubsub topic and shard 32, added `UseShardAsDefaultTopic` node config option to indicate whether the client should use a shard or the default waku topic. Merged open status-go PRs related to sharding. Initial connection to peers + dns-discovery no longer blocks the login. Updated open status-desktop PR for dogfooding to take into account status-go latest sharding related changes.
- _next_: get https://github.com/status-im/status-desktop/pull/12344 merged.
## [Waku Network can Support 1 Million Users](https://github.com/waku-org/pm/issues/83) - 2023-11-30
- _achieved_:
- Basic Postgresql optimizations completed and benchmarks published. See 10k milestone.
- First version of the 10k-tool by DST is ready and is being tested with simulation running a small nim-libp2p/gossipsub binary.
- _risks_:
- Dependency on Vac/DST to run 10k nodes simulations. Tracked under [`vac:dst:eng-10ktool`](https://roadmap.logos.co/tags/vac-updates).
- Wakutorsis tool is being dropped, meaning new tooling needs to be developed for 10k nodes simulations. It is currently uncertain whether such tool can be developed.
- Large scale simulations done by Vac/DST only covered nwaku relay. go-waku, status-go simulations are not planned short term (theoretical review of Status Communities messages is), nor are simulations including request-response protocols such as store and filter.
- lack of real world feedback/dogfooding: the complete static sharding solution involves significant changes to the Waku protocol and tech stack. Although each element is unit tested, dogfooding may hit corner cases in the integrated solution that cannot be foreseen/recreated in lab conditions.
## [Waku Network Gen 0](https://github.com/waku-org/pm/issues/50) - 2023-12-01
- _achieved_:
- Started internal dogfooding of proto-network and started to work on documentation.
- Progressed on capability and sharding discovery.
- _risks_:
- Usage of RLN in js-waku and dependency on a (centralized?) Web3Provider remains unclear as one needs to know the merkle tree state (on chain) to generate proofs.
- We are progressively moving a nwaku engineer to a solution engineer role we need to backfill the role.
- js-waku team is juggling between dev ex and gen 0 with only 2 engineers (3rd one just joined) so delivery in this client is likely to lag behind other clients.
- Uncertainty as to how RLN membership mechanism would hinder application adoption, if memberships need to be distributed or obtained by registration, if staking is necessary to prevent abuse, etc.
### [3.2: Basic DoS protection in production](https://github.com/waku-org/pm/issues/70)
**[go-waku] [bug: handle errors generated in gm.rootTracker.UpdateLatestRoot(pair.Key.(uint64))](https://github.com/waku-org/go-waku/issues/738)**
- _achieved_: task complete
### [1.5: Launch and dogfood integrated public Waku Network MVP](https://github.com/waku-org/pm/issues/68)
- _achieved_:
- Launched team-internal CC dogfooding with nwaku nodes and RLN Sepolia contract
- Introduced landing page and tutorials to join the network and publish using nwaku-compose
- _next_:
- Soft launch of the network at Devconnect Istanbul
- Extend dogfooding to other clients (js-waku, go-waku)
### [1.4: Sharded peer management and discovery](https://github.com/waku-org/pm/issues/67)
**[nwaku] [feat: Peer management with shard as a dimension](https://github.com/waku-org/nwaku/issues/1940)**
- _achieved_: discv5 filter peer by capability, misc. improvement w.r.t sharding and tests, sharded peer management improvement
- _next_: run more simulations
**[go-waku] [feat(discv5): filter peer by capability](https://github.com/waku-org/go-waku/issues/863)**
- _achieved_: added capacility in discv5 to filter out peers that do not have waku2 ENR field
### [1.2: Autosharding for autoscaling](https://github.com/waku-org/pm/issues/65)
**[go-waku] [feat: Changes to Store protocol APIs for Autosharding](https://github.com/waku-org/go-waku/issues/786)**
- _achieved_: API updates for autosharding
- _achieved_: added functions for validating content topic, determining shard index and pubsub topic for autosharding
- _next_: configure js-waku node to use either static or auto sharding
- _blocker_: need my PRs approved/merged. Also best to merge in other open PRs, especially https://github.com/waku-org/js-waku/pull/1697
## Other Work
### Enhancements
**[nwaku] [chore: allow text/plain contentType for rest request's body types](https://github.com/waku-org/nwaku/issues/2207)**
- _next_: Allow text/plain contentType on RestApi is on PR, libwaku Fedora build issue
**[nwaku] [chore: decouple listen and announced addresses](https://github.com/waku-org/nwaku/issues/2148)**
- _achieved_: implemented, tested and raised PR
- _next_: get PR reviewed, implement feedback and merge
