[Deliverable] Review usage of content topics in Status Communities protocol

[chair28980]

The usage of content topics in Status is aligned with Wakuv1. Waku v2 comes with a new recommended format that enables auto-sharding.

Moreover, single Status users currently use a high number of content topics, which may have an impact on performance of req-res protocols such as store and filter.

Such impact is to be measured in a previous milestone by Vac DST.

The output of this deliverable should be an RFC update on how content topics should be used, backed with simulations when performance improvement is expected.

It should include migration strategy and potential impact on the product.

Implementation Details

This is planned to be done in a phase-wise manner: 1 & 2. Identify and update communities content-topic usage in status app to match current filter criteria. Discussion and analysis in https://forum.vac.dev/t/status-communities-review-and-proposed-usage-of-waku-content-topics/335/29

3. Come up with recommendations as to how filter-criteria can be changed/updated for communities.

The idea is the PRs for phases 1&2 would be made ready one after the other and decision to release phase1b(n+2) is left to status app (probably based on number of users that are still using version n)

Phase-1 Update code to a version n+1 to send messages to a single content-topic in community for all chats, but listen on all existing content-topics. This is being tracked in https://github.com/status-im/status-go/pull/5864

Phase-2 Update the code to a version n+2 which would only use single content-topic for both sending/receiving of messages within a community. This would break compatibility with versions n and before of the status app.https://github.com/status-im/status-go/pull/5993

Phase-3 should be taken up as a separate deliverable under bandwidth optimizatinon.

[fryorcraken]

I see that the proposal is to simply apply the change across all communities.

This is the best way to get it across the board. However, it means that benefits for store queries (less content topics) will not be noticeable until n+2.

I would suggest to make it so that new communities from n+1 only use single content topic, for read and write, so that they can benefit from it directly.

It would mean being able to identify if a community uses a single content topic or not. This may need to be coded in community description and/or community link/invite.

See https://forum.vac.dev/t/breaking-changes-and-roll-out-strategies/338/5 for reference.

@chaitanyaprem cc @sunleos @iurimatias @ilmotta

[chaitanyaprem]

I would suggest to make it so that new communities from n+1 only use single content topic, for read and write, so that they can benefit from it directly.

It would mean being able to identify if a community uses a single content topic or not. This may need to be coded in community description and/or community link/invite.

Good Point, if we can somehow indicate this in community description that should suffice to merge both phases for new communities and rollout second phase later for existing communities. will discuss with @osmaczko on how to achieve this.