Status Communities: CommunityDescription and shards

[richard-ramos]

When an user creates a community, a CommunityDescription message is broadcasted in the default waku topic. Users that want to join a community have several ways to do so:

1. The community owner invites a contact. The invitee's status app will then ask the store node for the CommunityDescription so they can be able to spectate the community and join.
2. A special link is published in a chat. This is a link that contains the Community ID that follows this format: https://join.status.im/c/<community-id->. Clients that receive a message with this link will automatically attempt to retrieve the CommunityDescription from the store node.
3. The Community ID is published into the curated communities smart contract. Just like in previous scenarios, the clients will retrieve the community description from store node

In #3528 and https://rfc.vac.dev/spec/57/ Communities are expected to have their messages sent into a specific shard index, i.e. /waku/2/rs/16/<some-index>. This means that a client will not be able to retrieve the CommunityDescription without knowing on which index it was published.

The following changes are proposed:

• Community links will contain the shard index: https://join.status.im/c/<community-id->/<index>. This will unfortunately mean that existing links will stop working. (Requires modifying the website join.status.im to expect an index as part of the community link, and the clients to include the index in the link.
• Modify CommunityInvitation protobuffer to include uint16 relay_shard_index, so clients receiving this message will be able to know in which pubsub topic the CommunityDescription are being published
• The curated communities smart contract will require storing the shard index. Also the DApp that uses this contract and the Curated Communities section within status-desktop will need to be modified to handle this shard index

cc: @jm-clius @kaiserd @John-44 @cammellos @iurimatias

[richard-ramos]

One of the requirements described in #3528 say that each community should have their own shard. Since each cluster is limited to 1024 shards as defined in https://rfc.vac.dev/spec/51/#static-sharding, we cannot use a single cluster as defined in https://rfc.vac.dev/spec/57/#relay-shards.

This means we have to include also the shard cluster as part of the community link, invitations and curated communities smart contract, otherwise this requirement of unique shards per community is not possible

[richard-ramos]

Also, it seems that CommunityNFTs will require to store the shard cluster and index as well to be able to retrieve the description:
https://github.com/status-im/status-go/blob/develop/services/ext/service.go#L550-L562

[richard-ramos]

@kaiserd @jm-clius In https://rfc.vac.dev/spec/51/#index-list it is described that the rs or rsv key of the ENR is only capable of handling a single cluster. If i understood correctly this part of the RFC, this is not compatible with @John-44 requirement of having each community belong to its own shard as just having a single cluster means we're limited to a max of 1024 communities

[chaitanyaprem]

@richard-ramos anything pending to be done wrt this?

else we can close this ticket.