Moderation is an important feature for building a safe community that encourages user participation and engagement. Moderation tools should be used carefully, as excessive moderation can achieve the opposite effect of preventing or deterring users from participating in conversations. We encourage a tiered incident escalation policy, where a user first receive a verbal warning, then a temporary mute, then a permenant ban.
Users do not have access to these moderation methods by default: any call to these methods will return with an incorrect permissions error. To give a user moderation permissions, first create a role
in the SDK admin panel, attach moderation permissions to that role, and then assign that role to the user via the setRoles
method. See Miscellaneous for more details.
The SDK can also create new roles by assigning them to users via the
setRoles
method. However, these role won't have any special permission until assigned via the SDK admin panel.
The moderation functionality in the SDK are enabled on a per channel basis, this gives you the ability to define different moderation parameters for each individual channel. In order to access moderation methods, you must first create a EkoChannelModeration
instance via your EkoClient
object:
let repository = EkoChannelModeration(client: client, andChannel: "channel1")
When a user is muted, all messages sent by that user to that channel will be rejected. This method is useful for preventing certain users from sending inappropriate messages, but still allowing them to participate in the conversation in a read-only manner. The timeout property allows you to make the timeout temporary, or permanent by until unset by passing in -1
.
// mute user with id `user1` for 10 minutesrepository.muteUsers(["user1"], mutePeriod: 600) { (success, error) in...}
If you want to permanently mute an user, pass in
-1
as the mutePeriod. The user will stay muted until you explicitly unmute that user.
To unmute an user, call unmuteUsers:
:
repository.unmuteUsers(["user1"]) { (success, error) in...}
Banning users is a more heavy handed moderation method. When a user is banned, all its messages are retroactively deleted, it will be removed from the channel, and it will not be allowed to join the channel again until he is explicitly unbanned.
repository.banUsers(["user1"]) { success, errror in...}
There is a seperate unban call to unban an user:
repository.unbanUsers(["user1"]) { success, errror in...}
Rate limiting a channel lets you control the channel message flow size, a.k.a. lets you limit how many messages can be published, by any users, within a certain time frame. This method is useful when there is a large amount of messages going through the channel, which can make the message stream hard to follow. Setting a rate limit enables the SDK to queue up messages once the amount of message in a specified window
exceeds the defined limit
, allowing a slower stream of messages to be published to the user at the expense of adding more latency (because newer messages will be sent to the queue first and not delivered until all previous queued messages are delivered).
There is an internal limit of 1000 messages that can be queued by the rate limit service, if more than 1000 messages are queued up, the system may skip publishing the older messages in order to make room for newer messages. We think this is the perferred behavior for users, as users will most likely want to see newer messages in a real-time conversation instead of waiting for a significant amount of time for old messages to be published to them first.
Note that the SDK permanently stores all messages it receives in the system before the rate limit comes into effect: in the case of a large spike of incoming messages, even if a message did not get published to a user in real-time, that user can still scroll up to see message history and see that past message.
repository.rateLimitPeriod(600, rateLimit: 5, rateLimitWindow: 60) { success, error in...}
The above method enables a rate limit of 5 messages every 60 seconds: once there are more than 5 messages sent, from any user, within 60 seconds, those messages will be queued on the server and not published to other channel members until 60 seconds have passed. The rate limit will last as long as the period specified in the method call: in the example above the rate limit will be active for 10 minutes (600 seconds).
If you would like to have a permanent rate limit, call the method above with a period of -1 seconds.
In order to disable the rate limit, simply call remoteRateLimitWithCompletion:
:
repository.removeRateLimit { success, error in...}
While having moderators surveying your chats is great, this doesn't scale well. A way to overcome this is to let your users do the work for your moderators: by letting users flag other users or specific messages, the work of moderators goes from scanning each message in each channel to investigate each user flag (to both users and messages) and react only when deemed necessary.
In order to flag a message, create an instance of EkoMessageFlagger
first:
// badMessage is an instance of EkoMessagelet messageFlagger = EkoMessageFlagger(client: client, message: badMessage)
The EkoMessageFlagger
lets you flag and unflag a message, and it also exposes a asynchronous way to check wheter the current user has flagged the given message already:
// flag the messagemessageFlagger.flag { success, error in...}​// unflag the message​messageFlagger.unflag { success, error in...}​// check whether we already have flagged this messagemessageFlagger.isFlagByMe { [weak self] isFlagByMe inif isFlagByMe {...} else {...}}
Remeber that each
EkoMessageFlagger
is tied to one specific message.
In order to flag a user, create an instance of EkoUserFlagger
first:
let userRepository: EkoUserRepository = EkoUserRepository(client: client)let userToBeFlaggedObject: EkoObject<EkoUser> = userRepository.user(forId: "badUser")​guard let userToBeFlagged: EkoUser = userToBeFlaggedObject.object else { return }​let userFlagger = EkoUserFlagger(client: client, user: userToBeFlagged)
The EkoUserFlagger
lets you flag and unflag a user, and it also exposes a asynchronous way to check wheter the current logged-in user has already flagged the given user or not:
// flag the useruserFlagger.flag { success, error in...}​// unflag the user​userFlagger.unflag { success, error in...}​// check whether we already have flagged this useruserFlagger.isFlagByMe { [weak self] isFlagByMe inif isFlagByMe {...} else {...}}
Remember that each
EkoUserFlagger
is tied to one specific user.