Proposal on how to manage inactive users in a community

Communities
1

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.

1 Like
2

Copying the discussion between Jen and me:

hydrojen — Aujourd’hui à 14:49

Agree, except we’d need a way to exclude certain token holders ideally. And this would ideally be part of the wished for logs because we will have folks asking eventually why they were removed and we have no way currently to track if it’s for a reason or inactivity,

Jo — Aujourd’hui à 14:51

Good point. Maybe we need to do the admin logs first

As for excluding token holders, it’s way more work, as it would need UI changes and more backend code to verify who owns what etc. I’d propose to do it iteratively with only the dates at first.

hydrojen — Aujourd’hui à 14:55

Can we get a list to review once the dates are selected before confirming? I’d want to verify I’m not removing staff essentially. One could argue should be active but some roles aren’t needed in app as much or CCs from other projects, don’t want to undo all the permissions.

Jo — Aujourd’hui à 14:58

Yes that’s a good idea. I actually thought of that when I imagined the feature when I was unable to sleep because of jetlag, but I forgot about it when writing the proposal So, yes it’s doable and shouldn’t be too hard and indeed, it’s necessary to do before, because it’s such a destructive action, a dry run is necessary.

3

i like this!

just one thing to note is that the @ everyone tag isnt working yet as a push notification on mobile. would be nice to get this implemented together, because push notifications are probably the most effective way to get people active on the app again. this also solidifies justification to remove if they wont even reactivate after that.

1 Like
4

The practical solution proposed here provides a good lens to approach large group scalability design.

The issue here is that the user trace data, ie, the residual data that an inactive user leave on the system, is large as it is included in community description messages, and is more than just a key: it includes profile image, socials. See Napkin math for Community description message sizes - HackMD.

When designing scalable group, one needs to review the cost of every inactive user in said group.
In the case of Waku, the cost is low as a node that is offline does not inject new data in the system nor do they take more connection slots.

However, we can see that for communities, it is large.
As well as private groups for that matter. For each (inactive) member in a private group, a message is sent to its members even tho they will not read it; in private groups, we don’t have one encryption channel for all members, but one per member; when sending a message to a group of 10 people, 10 messages are sent, potentially more if members have several devices paired.

A different approach is to reduced the trace data by limiting to authorisation data (I am allow to write here) and make the social layer more ephemeral, as proposed here:

The list could then be constructed from member’s messages.

Where members information (nickname, profile picture, social) is sent only when member are active.

The product downside is that Alice may not access Bob’s information if Bob hasn’t started their app since Alice joined the group - but is it really an issue?

5

I need to correct you here: what is included in the community description message itself is just the key and the role(s) of the member.
The images, name, etc. are added by the app layer to send to the client.

You can see it here:

(RevealedAccounts is deprecated so won’t be there much longer)

However, the amount of members does have an exponential impact on the community description size, because if all your channels are private, then you will have a certain number of members times the number of private channels being repeated.

Apart from the bandwidth cost, those members have a cost in terms of provider computation, since the control node needs to periodically check if they own the right tokens.

This is 100% true though.

This is kinda already the case. Like I said, the community description does not contain this info.
The clients must construct it themselves. How that works is that when you encounter another user for the same time, we save their information in the contacts database table. We then have their info.
What happens often is that someone joins a community, but never posts, so they appear on the member list, but your client never saw the user’s info, so you’ll see their name as a Three word name instead in the right bar.

I hope this clarifies some things.

6

read the linked vac discussion especially this part:

IMG_0661
IMG_06611125×2024 291 KB

tbh im kind of uncomfortable with not being able to interact with any old members of a community, certainly if old means the 30-day waku store limit. being able to mention all users that ever entered your community is imo a crucial feature bc its the way to draw back members to your community every once in a while when you have something interesting. this might then lead such members to explore other features of the app while online if they havent opened it for a while. are we sure there isnt any solution that can keep mentions for old users intact? i really do see the total pool of users that ever joined as a valuable resource even if not recently active

1 Like
7

Thanks for the clarification/correction!

Good to know! This demonstrate another scalability weakness in the current protocol. Will leave it off scope for now.

Excellent to know, so in the context of my initial proposal, the idea is that you would not have a list of members, but instead, the member by being able to encrypt messages in the community would manifest its presence.

Meaning that as long as the encryption layer allows you to properly manage your members, and is scalable, then you could proceed by removing the growing list.
Very theoretical at the moment, but would be good to review once efforts such as de-MLS are more mature.

Keen to get your insight, again, this is all very theoretical right now.

In this idea, you would not be able to interact with an old member of the community if your app instance did not see any message from this member, ever.

Ah, that’s different here.

Because having an @everyone tag does not mean you have to know details about every individual user. Having such a feature only mean that when the app receives a message in a community that has @everyone in it, then it gives a notification to the user.

Depends how you want to exploit the resource. Also note that the community owner would like have information of all users, as every user would ahve contacted their node to join the community in the first place.

I am talking about re-broadcasting the information to users that join later.