Scaling Status Communities : Potential Problems

[kaiserd]

This issue tracks potential problems in regards to scaling Status Communities. (Writing the status communities spec is tracked in #166.) This issue will be updated if we detect yet unknown problems.

Note : These are potential problems as identified by SeM. (For some of these) We need confirmation from Status.

Control Message Size

Status Communities use control messages with fields do not scale. An example is the message disseminating CommunityDescription. This doc shows the scaling behaviour. Here is a proposal for optimizing CommunityDescription. (Both documents authored by @rymnc )

Messages as a Means of Persisting

Nodes that are part of a Status Community send messages to themselves, in order to make store nodes persist configuration. These messages can grow in size and effect the whole pubsub mesh they are sent in.

A simple solution for the MVP: Direct store request to a store node without using Waku relay. We could introduce a new simple req/resp protocol for this. This might impact privacy, but is a KISS solution for the MVP.

Community Join Flow (peer requests to join a Community)

We have to take this into consideration for DoS mitigation. This message has to be relayed within the community, even though the sender is not part of the community.

A simple solution (maybe OK for the MVP?) would be limiting community access to invite only, and not allowing to request invites.

CC @Samyoul @cammellos @felicio @richard-ramos @fryorcraken

[fryorcraken]

Messages as a Means of Persisting

@John-44 has mentioned a post MVP solution for metadata (e.g. community profile image, description) where community owner could post the data on IPFS and community members and owner could pin the data on IPFS. This would involved including an IPFS client in the Status software.