[Milestone] Scalable 1:1 and private group chats in Status

[jm-clius]

Description

By the end of this milestone the 1:1 chat function in Status should work over Waku in a scalable, reliable and DoS-protected manner. This includes publishing a specification or set of specifications that defines the Status 1:1 chat procedures, explains reliability and encryption mechanisms, and documents Waku as transport with scalability and DoS protection mechanisms.

Note that private group chats in Status currently function as a "chain" of 1:1 chats. They are implicitly included in this milestone, but excluded from the descriptions below for brevity's sake.

The milestone covers at least the following features:

Scalable transport

The 1:1 chat feature should be scalable to tens of thousands of users. This implies that the selected Waku routing protocols (Relay as backbone, Filter/Lightpush for resource-restricted clients) and Waku Store should be used in a scalable manner. Much work has been done to scale the Status Communities feature, mainly using sharding. The main difference is that 1:1 chats must be on global, shared shard(s). To scale the feature to thousands of users will probably require a multi-shard approach with autosharding. The feature should preferably use the Waku Network. It's possible to imagine a separate Status "1:1 Chat" Network with autosharding, although we should aim for the networks to converge in terms of workable parameters, rate limits, etc. Content topic usage must also be revised as it affects the scalability of especially Store and Filter protocol.

RLN for DoS protection

Although statically-sharded Communities can be protected with simple signatures, 1:1 chats on public shards require stronger DoS protection. Waku's proposed solution is rate-limiting with RLN. The main challenge in this milestone is incorporating RLN in Status 1:1 chat. There are different possible models:

1. RLN memberships for each Status client: In this model, every Status client (Desktop or Mobile) owns its own membership. Desktop (Relay) nodes additionally acts as RLN validators. This model should be our end goal, but will also require designing an RLN membership mechanism that allows frictionless joining (e.g. Status-sponsored memberships), RLN secret/key management, etc. This will require coordination with the App teams to assess product and user impact.
2. RLN proofs as a service: In this model, Status 1:1 chat clients publish to a rate-limited network via service nodes that attach RLN proofs to messages on their behalf. Status or other service providers run the service nodes that attach RLN proofs to messages received via lightpush requests. This can be a temporary model that postpones some of the complexity around RLN memberships while redesigning the rest of the protocol stack to be compatible with a rate-limited network.

RLN productionisation

Since RLN rate-limiting is the selected DoS protection mechanism, this milestone depends on the continuing work to productionise RLN and deploy to a L2 mainnet. If Status is to provide either RLN service nodes or distribute RLN membership to Chat clients, the pricing model should be clear.

1:1 chat protocol

Status 1:1 chat procedures must be specified and revised to ensure compatibility with a rate-limited network and to address any scalability concerns. Messages may have to be split between control and content messages. Some messages unrelated to 1:1 chats, such as Community Join Requests, also use 1:1 chats and should be taken into consideration. Different types of content, especially larger messages such as images, should be considered.

Encryption

Encryption and related procedures (e.g. key exchange) must be specified and revised to be compatible with a rate-limited network.

Reliability

Status 1:1 chats currently use MVDS for end-to-end reliability. This must be specified and revised to ensure compatibility with a rate-limited network. MVDS is also known to scale badly and must be replaced, if need be.

Other considerations/open questions

1. The UI/different App teams may have to be involved and kept abreast of any changes, especially those affecting user flows. For example, if some 1:1 chat procedures are redesigned or blocked due to scalability concerns, this could affect the status-go API used by the UI and what features are presented to users of the app. RLN procedures should preferably not have any user-facing impact, but may require membership and key management.
2. The scope of this milestone is such that incremental deliverables have to be defined. A reasonable first step would be a 1:1 chat PoC that uses existing RLN service nodes to showcase compatibility of the protocol with a rate-limited network.