The Status community is growing day by day, and though we are still far from the 10K limit, or even the 5K switch to on request, we need to think how we are gonna address it before it’s too late.
Right now, there is no way to tell which user is active or not.
In a centralized community app like Discord, it’s not a big issue, because inactive users are just an entry in a table, but in Status, each user is a key in the community description that gets sent over the network. Also, we do have a 10K limit on the number of users because if everyone was active, the Waku network does have a limit.
So this brings me to my possible solution: We should add a button in the admin screen called “Kick inactive users”. This would call a function on the Control node that removes all users that haven’t sent a message since that date.
Clicking it would open a small form that would have two fields: “Last active” and “Date of joining”.
“Last active” is trackable using any message sent by that user in that community. This includes emoji reactions, so it’s pretty forgiving.
“Date of joining” is necessary as well, because if someone just joined today and didn’t send a message yet, they’d be kicked as well.
The combination of both these fields makes sure we only remove people that joined some time ago that haven’t posted in a while.
Using that feature, we could make sure the Status community (and user communities) can keep growing with actual active users.
Admins could send an announcement before doing it using @everyone
to warn people that they are gonna use that feature and leave them some time to send an emoji reaction so that they don’t get kicked (for example if if they are only lurkers).
We don’t have to implement it straight away, but we need to think about it before too long, because once the community reaches 10K users, new users will just be automatically rejected.
As for the time to implement, I don’t think it would be too difficult, we already have all the tools in place in terms of admin messages that get sent to the control node. If we want to make it iterative, we could even make it only available for the control node side at first.
The query itself if pretty simple to implement and then it’s only about sending the updated community once the members are removed, which is something we already have in place.
So IMO, it could be implemented in less than a week. Maybe 2 weeks if we include the user stories creation, design, implementation and testing.