Open richard-ramos opened 1 year ago
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
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
@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
@richard-ramos anything pending to be done wrt this?
else we can close this ticket.
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:CommunityDescription
so they can be able to spectate the community and join.https://join.status.im/c/<community-id->
. Clients that receive a message with this link will automatically attempt to retrieve theCommunityDescription
from the store node.In https://github.com/status-im/status-go/issues/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 theCommunityDescription
without knowing on whichindex
it was published.The following changes are proposed:
https://join.status.im/c/<community-id->/<index>
. This will unfortunately mean that existing links will stop working. (Requires modifying the websitejoin.status.im
to expect anindex
as part of the community link, and the clients to include the index in the link.CommunityInvitation
protobuffer to includeuint16 relay_shard_index
, so clients receiving this message will be able to know in which pubsub topic theCommunityDescription
are being publishedindex
. Also the DApp that uses this contract and the Curated Communities section within status-desktop will need to be modified to handle this shardindex
cc: @jm-clius @kaiserd @John-44 @cammellos @iurimatias