Minimal Community Specification

[plopezlpz]

Specify community procedures, including the encryption, reliability and functional scope of each. This forum post serves as a starting point. (regarding reliability, probably E2E protocol will be used).

Focus on the functional scope, we can categorize messages like so:

1. Content (any content a user wants to send: text, reactions, images, gifs...). What would be the maximum size? How are they transfered with waku?, etc.
2. Community Control (e.g.: online status, membership update...), some of these might be ephemeral like the online status, so what storage strategy are we using and what should we use since ephemeral messages don't need to live long. We know community description messages take a lot of bandwidth. Some of these community control messages need to be global (e.g.: request to join could be considered a special 1:1 case, these should be routed globally in the network since any peer could be messaging any other peer)

We can start defining this procedure: "Community description update" since it takes high bandwidth.

• What messages are involved?
• What triggers it?

Goal

The goal of this document should be to find out how to improve bandwidth and storage by the communities' protocol in Waku.
One way to do so is to split Content and Control in different shards so that not all members of a community need to be subscribed to the Control shard, they could just retrieve them using store query.

[plopezlpz]

First part of this deliverable: waku-org/pm#197
FYI @qfrank @kaichaosun