Status Communities : Review and proposed usage of Waku content-topics

[fryorcraken]

@prem

migration strategy would be complex as we need to go with bridge mode approach as we will be using a new set of content-topics.

What is bridge mode? Do you mean someone runs a bridge software to copy messages from one content topic to another?

Or as per RLN roll out in Status - #2 by haelius you mean reading/writing from both old and new content topics for a while?

The “pros” of single content topic being that the “new” content topic is already part of the “old” content topic set?

One clarification: do the app process messages from different content topic indifferently? I am trying to understand how much code change would be necessary from app side if we move messages to a single preexisting content topic (beside sending the messages to a different content topic).

@prem

reasonable/max content-topics per user/community may change in future if app requirements change e.g: user being part of more communities.

I think this would be the case for any design when the number of content topic is different from 1.

@prem

if a user wants to be part of 20 communities and if we identify that we need to have 5/10 content-topics per community based on bucketed approach we may end up back in the situation of a user subscribed to 200 content-topics because of other content-topics a user would anyways have to be subscribed to such as contact-topics, push-notifications and other control message topics for communities such as communityDescription and communityShard publishing etc.

Yes, and I think that’s why we need to at least start thinking of optimisation around the subject such as message priority. Because in this case, the app should not be downloading/subscribing to all message of all communities.

Similar to what mentioned in Status Communities : Review and proposed usage of Waku content-topics - #15 by fryorcraken but for a per community basis:

1. If community is pinned/favorite: subscribe to all, download all
2. If community is not pinned but opened in last N days: same as (1) but as second priority
3. If community has not been opened in last N days: don’t subscribe, only retrieve mentions
4. if community is muted: don’t subscribe, don’t get mention

for 3/4: unless user clicks on community

This is an example of course. My point is we need to get the discussion ongoing in terms of prioritizing subscription/downloads based on user behaviors and we should already be assuming that no, the app will not subscribe to all content topics of all community all the time by default.

Discord does not download all messages of all your servers all the times, despite being a centralized entity.
A similar, more aggressive approach, should be applied on the basis that we are building on a decentralized infrastructure.