# Status Communities MVP: scaling to 10K

10000 users (? communities)
100% Desktop?
Store, bootstrapping, discovery, sharding, support for resource-restricted protocols

NB: add to roadmap nwaku hardening with CI/CD and integration testing

Extracted questions:
1. What about 1:1 chat support in this timeline?
2. What is proportion of chat messages vs control messages vs bandwidth usage from store/archive queries?
3. Does message rate increase linearly with increase in network size?
4. What about filter/lightpush?
5. Requirement: nodes see all messages in community and all control messages that make experience consistent (latter implies not necessarily seeing all control messages)

## Overview

- 10K users spread across 10-100 communities
- [ ] the community # is completely thumbsuck. Need confirmation that this is a realistic choice.
- 100% Desktop users, primarily using Relay, but with experimental (perhaps beta?) Filter/Lightpush for badly connected clients
- Message rate?
- Control message rate?
- What is the proportion of control vs community message rate?
- Does message rate increase linearly with an increase in network size? (I.e. no control messages increasing combinatorially, etc)
- No 1:1 chat supported?

## What is required of the network?
I.e. what would be required in a Waku network to support Status Communities reaching 10000 users. Note this does not propose a design, but tries to get clarity on what is required in Waku network...

- Message delivery and sharding:
- Nodes should receive live all community-published messages of the community they're part of and all control messages that makes their experience of the community consistent.
- Assume: nodes only form part of one community _at a time_ (i.e. we don't plan scaling for nodes who choose to be actively part of several communities simultaneously)
- Community can utilise a single or multiple shards for control and community messages, as long as requirement (1) still holds
- Require (or assume?): there is proper peer and connection management to help nodes within a shard maintain a healthy set of connections
- Discovery:
- Nodes should be able to discover peers within each shard they're interested in.
- Discovery method can operate within a single or multiple shards, as long as:
- nodes can bootstrap discovery into the shards they're interested in
- requirement (1) still holds
- discovery method does not add an unreasonable resource burden on nodes, especially if shared between shards
- Nodes are able to use discv5 as main discovery method (assumption)
- Bootstrapping:
- Nodes should be able to initiate connection to bootstrap nodes within the shards they're interested in
- Bootstrap nodes can belong to a single or multiple shards, as long as they can handle the added resource burden.
- Assume: Status provide initial bootstrapping infrastructure. DNS discovery is sufficient for this.
- Store nodes:
- Nodes should be able to find capable store nodes and query history within the shards they're interested in
- Store nodes can serve a single or multiple shards, as long as they can handle the query rate and resource burden, and are discoverable as stated in requirement (1)
- Assume: Status provide initial store infrastructure. DNS discovery is sufficient to discover capable store nodes (these may or may not be the same nodes as used for bootstrapping, but discovery will be simpler if they are)
- Security:
- Community should not be vulnerable to DoS attacks or failures in other communities
- Archive:
- store nodes for a community should only store messages actually originating from the community
- store nodes for a community should only serve history queries actually originating from the community (this may be complex!)
- Relay:
- community relay nodes should only relay messages actually originating in the community
- Assumption: application has some method to validate messages against community membership

## What is required outside of the network (operationally, etc.)

Kurtosis testing
Community Protocol hardening
- move the specifications
- what else here within this MVP milestone?
Nwaku hardening with CI/CD and integration testing to better trust releases
Fleet ownership: upgrade process, monitoring, support
Other processes:
- staging network for upgrades where clients can progressively be redirected to?

## Initial work:

- Agreement on requirements
- A viable, simplest design for network adhering to requirements above
- Breakdown of each item and assigning ownership

## Notes on task breakdown:

- sharding strategy one of the first steps and has to be done in collaboration with App team