Week 6: The Problem of Evil (part 3)

So, for improving a social system, I’m going to look at Telegram. First, though, let’s state the context, our problems, and our goals.

Telegram is most often used in a direct-message manner, but it also offers “channels” or group messaging. I’m specifically going to look at a channel with a group of people who are all involved in a specific task. Everybody has the ability to post messages.

In this context, the problems I see mostly revolve around what people post. This is a non-exhaustive list, but they may:

• post hurtful content without prompting
• post hurtful content in reaction to the posts of others
• spread rumors (outside of the channel) to instigate a mob response within the channel

The ideal, of course, would be to stop or trap harmful content before it can be seen. But in my experience, an automated solution will not be as effective here as could be desired–the context of the channel may not fit the assumptions of whoever coded the bot or trained the model, and that could lead to a mismatch between the automated solution and what should be permitted or blocked.

My goal, then, is to allow participants to, in essence, selectively withdraw their commentary from other participants in the group. I would like to do this in a way that isn’t as catastrophic as leaving the entire group, and ideally in a way that doesn’t try to force the group to “choose sides” (which could lead to the group fracturing repeatedly).

One solution I might propose is what I will call “silencing.” This works similarly to blocking somebody, except that ideally, the block goes both ways–if Participant A silences Participant B, then not only does A stop seeing B, but B should also stop seeing A’s posts and responses. This handily prevents the first two points on my list of goals, as B’s hurtful content will no longer be visible to A, and B will also be deprived of A’s posts–there is no need to provide A’s information to B for B to use in others hurtful ways. No notification of this action need be provided to either participant, or to any channel participants at large, to avoid the action creating more agitation.

A second solution I might propose is a “time out” function. In concept, this is similar to muting a channel (by disallowing notifications for a general time period) or leaving a channel altogether. The difference is, even when muted, the temptation remains to check the channel and see what people are doing–only notifications have ceased. In “time out,” the channel is no longer even visible or accessible. This function should be available to individual users (to put themselves in time out) and to channel admins (to put any user into time out). Where an individual has put themselves into time out, they should be able to navigate into their settings menu and explicitly choose to “time in”. Where an admin has placed somebody into time out, user override is not permitted.

This creates a stage in between disabling notifications and having to depart the channel altogether, and can be used in different ways:

1. The individual user is feeling “ganged up on” or mobbed, and chooses to time out with the intention of coming back later. Other channel participants can see that the user has “departed” and can no longer be messaged via the channel. The client should not prompt the user or automatically time back in of its own accord. Given the user’s curiosity might lead to trying to “sneak a peek,” the “time in” option is placed in the settings menu to ensure that the user is fully ready to re-enter participation. Upon timing back in, the user resumes participation as desired. Other channel participants can see the user has returned, but no channel-wide “join” announcement is made.
2. An admin sees somebody posting harmful content, and they will not be dissuaded. From past experience, the admin knows this is atypical behavior for the participant, and suspects the participant is suffering some form of altered experience (whether by substance intoxication, mental strain, or otherwise). They place the participant into “time out” as a way of isolating the participant until they are ready to return without causing further damage. This is less damaging than outright evicting the participant from the channel. Other channel participants see the same messages as described above in scenario #1. The participant who was placed into time out sees an administrative message indicating that they were placed into time out by an admin, with the ability to directly contact that admin. Any channel admin should be able to time the user back in, but the originating admin’s info is given for accountability and to allow the timed-out user to be able to speak directly to the person who placed them into that state.

There are, of course, some loopholes that remain. Even if A silences B, A’s posts are still visible to Participant C, who can act as a relay. If C does act as a relay, this act of relaying may also not be visible to A. This is, therefore, not a complete solution on its own–group norms should be established to ask before relaying information that somebody “missed” or “didn’t see.” Even so, this still doesn’t solve the problem of actual malevolence, but I judge that dealing with actual malevolence would likely require much stronger measures anyhow.

“Time out” is vulnerable to abuse by admins. It might be tempting to use this as a sort of “silencing” group-wide, short of actually kicking somebody out. But by its design, the message shown to other group participants is that the user in time out has “departed” the channel; there’s no benefit to an admin to put somebody in time out if their intent is to silence them permanently, as it looks like the same thing as having kicked them out fully. Potential abuse is also limited by allowing other admins to time the user back in, and by making the originating admin’s identity clear to the timed out user (with that admin also being able to be directly contacted).