Message moderation specs

We recently submitted two proposals for message moderation - Message Moderated Conferences and Managing message moderators in MUC rooms - both of which are extensions to Multi-User Chat (muc) spec.
Taken together, they allow a message moderation system to be put in place. It has been a conscious decision not to introduce another set of acl's for this, but to reuse the affiliations and roles specified in muc. I will try to go through the basic intent and design decisions behind the specs.

Message Moderated Conferences

This proposal specifies how a conference which has message moderation enabled would interact with participants - particularly, participants who dont have 'voice' or the ability to post message to the room.
If message moderation is enabled, these occupants would be able to request the room for approving the messages they want to post - and on approval, room would publish them to all occupants of the room. Simple scenarios would be a celebrity chat, moderated webcast/presentation, etc.
The spec does not deal with how the message moderation happens - just the interaction between a occupant and the room - how they interact, state changes, notifications, etc. So in effect, you could have any number of backend moderation implementations - but the interface between the occupant and the room will remain the same.
The basic flow is as follows :
  1. Occupant sends message to room for approval.
  2. Room assigns a message id to the submitted message (which is then used to identify the submitted message for all further interaction, in this and other moderation related specs) and returns that to the user with message in pending state.
  3. After the backend moderation system decides on the message, room will inform the submitted about the 'decision' - approved, rejected (or error).
  4. If approved, room will then multicast it to all the occupants.
That is it !
The actual moderation might be quite involved, with multiple moderators/moderation modules chained, clustered/distributed rooms, etc in complex deployments - but the occupant will have a simple and clean interface to communicate with the room (room's bare jid actually).

The way we designed it, hopefully this will someday get rolled into XEP 45 itself :-)

Managing message moderators in MUC rooms

This spec defines one possible way in which message moderation can actually be implemented - where the moderation is done by participants who have sufficient rights (owner's and moderators of the room).
It defines how a room moderator/owner can become a message moderator (and other state changes), how they notify room of the moderation decision, and how the room is expected to manage these moderators and submitted messages for moderation.


Both of these specs are based on our implementation - though what we support currently is quite different from what we have submitted.

As a sidenote : It should be noted that, in both the specs we have tried to make sure that the interface between the various entities in question remains as simple as possible - while not precluding more complicated scenarios .. like usecases which are not specifically related to users chatting over a moderated conference (for example an approval workflow) - there could be custom configurations with extensions to room configurations which allow for more complicated scenarios while keeping the actual client interfaces (at both submitter and moderator side) constant.
Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
About

mridul

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
Bookmarks
Blogroll

No bookmarks in folder