feat_: use a single content-topic for all community chats #5864
Conversation
chaitanyaprem
requested review from
richard-ramos,
kaichaosun and
plopezlpz
Jenkins BuildsClick to see older builds (125)
|
chaitanyaprem
force-pushed
the
feat/comm-content-topic-poc
branch
2 times, most recently
from
48283d7 to
4f10919
Compare
chaitanyaprem
force-pushed
the
feat/comm-content-topic-poc
branch
3 times, most recently
from
b6aaaf3 to
29b3c44
Compare
chaitanyaprem
changed the title
chaitanyaprem
force-pushed
the
feat/comm-content-topic-poc
branch
from
29b3c44 to
8cb3323
Compare
|
Let's not merge it until the release branch for 2.31 is cut in status-go, seems PR might be very risky |
sure, and agreed that this PR needs more testing and dogfooding before merging. |
chaitanyaprem
force-pushed
the
feat/comm-content-topic-poc
branch
2 times, most recently
from
cfec7d4 to
d8fa686
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #5864 +/- ##
===========================================
+ Coverage 61.34% 61.40% +0.05%
===========================================
Files 833 833
Lines 109909 109934 +25
===========================================
+ Hits 67426 67506 +80
+ Misses 34591 34558 -33
+ Partials 7892 7870 -22
Flags with carried forward coverage won't be shown. Click here to find out more.
|
chaitanyaprem
force-pushed
the
feat/comm-content-topic-poc
branch
from
d8fa686 to
0eb01c3
Compare
chaitanyaprem
force-pushed
the
feat/comm-content-topic-poc
branch
from
d61d200 to
b5315d5
Compare
|
@igor-sirotin , @osmaczko there was a suggestion from @fryorcraken that for any new communities that are created we can start using approach of single conent-topic straight on whereas for existing communities, we can do it in a 2 phase manner. In order to do that shall we create some sort of attribute fields in the community-description to indicate such feature changes for communities so that we can apply new features to new communities quicker. Explained more here WDYT? can we add an attributes field in the community description which for now will have just a single flag |
chaitanyaprem
force-pushed
the
feat/comm-content-topic-poc
branch
from
b5315d5 to
103b415
Compare
@chaitanyaprem I'm worried that this PR makes it even more confusing 😄
I think we could take the opportunity of the new requirement and refactor this code, so that this change is not very harmful. |
@chaitanyaprem @fryorcraken Sorry, I don't think this is a good idea.
|
Let me think and see if there is any other way to make this change without refactor. I want to try and avoid it if possible. |
From reading the comment here, I think there needs to be a clearer path on how to untangle status-go at each PR. I agree with some of the comments trying to making it less hacky, while at the same time I get Prem's input that he may not have knowledge and confidence here to do further refactor. If we compare it to the more usual nwaku development flow. Prem is a researcher implementing a PoC for a protocol change (content topic community management). Usually, the expectation is for codebase owners/engineers to help the researcher harden this PoC and proceed with neeeded refactors.
Let's move this conversation to https://forum.vac.dev/t/breaking-changes-and-roll-out-strategies/338/5 I am not convinced that Status Communities is in a state where the cost of "ensuring that newly created communities are compatible with older software version" outweigh the benefits. This specific change helps with Community scaling, by reducing the resources used by a single community user on store. Moreover, we could always have a toggle for an owner creating a new community. "experimental creation: includes changes that improves efficiency but it means your members need to have the same version or new than you to join". This is probably to discussion to have more generally within Status team here. Speed of development and improvement vs letting your users keep an old app version. As stated in https://forum.vac.dev/t/breaking-changes-and-roll-out-strategies/338 there is also a clean way to handle it:
This sounds paradoxal. you are suggesting that we should not break things for current users (joining communities) because at the end of the day there is not enough users (creating communities). It is one or the other? Do you have not enough activity or too much activity to make this change viable? |
|
Final point: by creating a new code path for this, which is "cleaner", then you have the opportunity to deleted the "messy" code path in the future. Yes, it would mean that people "have to upgrade", but what is the alternative? |
|
@fryorcraken sorry if I was unclear, I think the order of my arguments was wrong. My main argument is this: So I thought why do more work, if we keep current solution for supporting both old and new communities, and remove this code in 3-6 months. I have nothing against making a new code path, but it doesn't seem to be easy in this case. @chaitanyaprem we can try to help you to find a better solution with the filters to avoid the |
So iiuc for now we will stick with the 2 phase plan of implementing this rather than doing it for new vs existing communities.
Sure, will ping one of you. Thanks! |
chaitanyaprem
force-pushed
the
feat/comm-content-topic-poc
branch
2 times, most recently
from
b4b929f to
e8877b1
Compare
chaitanyaprem
force-pushed
the
feat/comm-content-topic-poc
branch
from
eedb0da to
e49e585
Compare
Co-authored-by: osmaczko <33099791+osmaczko@users.noreply.github.com>
chaitanyaprem
force-pushed
the
feat/comm-content-topic-poc
branch
from
342a0da to
ae2cada
Compare
this PR is ready for testing and can be included in 2.33 releases of desktop and mobile. Please do necessary testing. Let me know if you need any additional info. |
|
This PR is ready and once validated by desktop and mobile QA, can be merged maybe for release 2.33. |
Minor typo, the related mobile PR is status-im/status-mobile#21407 instead of status-im/status-mobile#21458 |
|
I think until status-im/status-mobile#21850 is resolved, we're blocked on testing this one |
This PR is first step i moving towards using a single content-topic for all community chats and most of the control messages.
Once this is released , in a subsequent release we can disable installing filters using chatIDs for communities altogether.
Detailed proposal https://forum.vac.dev/t/status-communities-review-and-proposed-usage-of-waku-content-topics/335
Refer to waku-org/pm#268 ->
Implementation Detailsfor the plan of this feature.All channels shall use content-topic used for MemberUpdates which is being called UniversalChatID.
Important changes:
UniversalChatIDto filter while sending all community chat messages.