There is a need in a project I’'m working in to create moderated chat rooms using the MUC service so that room occupants (not “voiced” participants) can send messages that are approved or rejected by the moderator(s) in real time. The moderator would have some means of making their decision and letting the server know if the message should be broadcasted as a standard, approved message or not.
My idea was to create a type of message seen as a ModeratedMessage. All ModeratedMessages would be stored in a server memory. That type would be listened to by the moderator’‘s client and the client would send a special IQ packet holding message’'s ID and decision concerning it. The server would then remove this message from its memory and broadcast it or not.
Another idea would be to selectively broadcast the moderated messages only to moderators but I don’'t know if there are any standard means for that defined in current standards.
What do you think of this idea? How about extending JEP-0045?
I did this in a little more elegant manner, reusing existing standards, tweaking the 0045 a little bit (muc#admin IQ provider and class in smack, admin IQ handler in the Messenger so it holds the moderated messages to be decided upon), added a new Message extension (ns: muc#moderatedmessage). If anyone’‘s interested I’'ll describe it in detail soon.
I think it would be really great to extend the Multi User Chat standard since it’‘s still a draft and there’'s currently no way to provide a real-time moderated chat in XMPP.
Sorry for the late reply! We’‘ve long wanted to see a real-time moderation extension to MUC. We’'d be happy to work with you and anyone else on the effort.
Good question. Do you have any ideas already on how the existing JEP would be extended? Or maybe even more basic – could you type up the use case and workflow that you see for moderation. Agreeing on that would be a good first step.
Unvoiced user (Visitor) sends a message to the Real-Time Moderated room. The server checks if it’'s a real-time moderated room or a “classic” one. If classic, message is rejected.
If it’'s a moderated room, the server checks if there are any moderators Available (Available by the means of XMPP presence). If not, message is rejected.
else
The server puts the sent message under a computed unique key to a Map of messages to be decided upon. Adds a moderatedmessage extension to that message and broadcasts it to all occupants or just the moderators (this is to be determined - my implementation broadcasts it to everyone in the room but the latter shouldn’'t be too difficult).
The client application looks for the extension - it it’'s there and recipient is a moderator - it displays the message in some distinct way and gives an option to either accept or reject the message.
The decision is sent in a form of a muc#admin IQ query with a child element (in my implementation at least) and server’'s muc#admin handler recognizes it and checks if the iq sender is a moderator, if the message still exists in the moderation map and acts accordingly. Rejected message is removed from the query and its original sender could be informed with an error (not-authorized or other appropriate). An accepted message is broadcast to everyone without the moderatedmessage extension so that all occupants can see it.
The fact of accepting or rejecting the message could be broadcast to all moderators so their clients remove it from their interface (whether it’'s a list of messages to be moderated or some buttons).
Of course muc#admin’'s moderatedmessage child could be extended so it handles the mentioned situations and signals - accepting and rejecting the message, information about a message being accepted and rejected and so on.
There should be an additional MUC configuration form field saying if a moderated room is “classic” or “real-time”, maybe just a boolean “real-time-moderated”.