Wednesday Aug 08, 2007

File transfer to an MUC

We recently submitted a proposal to XSF to standardize what was a proprietary implementation for message moderation ... which we have had for a couple of years now. The other effort which we should probably kick off soon is file transfer to multi-user chat room - this is another custom implementation which we have been carrying on for a few releases now ...
This has come up time and again in JIG as part of other threads, and yet we never got much farther that 'yep, we should document it'. I know of atleast one other server who have their own implementation to support this .... so maybe it is time we standardized this !
To give a basic idea of what we do:
Currently, our client supports IBB - so does the server, and the muc (which is part of the server). So idea is simple - essentially stream the data from the client to the server, store it locally (if content filtering, etc is enabled) post-process it (if enabled), and then the component streams it to the recipients.
As all the participants who can understand this are Sun IM clients - we just use IBB for now.
The caveats are obvious - potentially very heavy server traffic due to the IBB. But the main advantages are:
  1. The sender transmits only a single copy of the file - in comparison to a p2p model (imagine streaming a 512 KB file to a muc with 100 participants from a moderately low b/w connection).
  2. It will always work for all cases - irrespective of firewall, nat, etc. IBB is the lowest common denominator.
  3. Ability to analyze the content before sending it on to the recipients - including the possibility of archiving it (for participants who might join the room 'later').
There are ofcourse other means of achieving the same while satisfying the requirements above - including other means of file transfer which are yet to be standardized (custom, future additions).
File transfer in general was unfortunately not a very strong point in xmpp, and we are still working on the details ... so I am not very sure if we have to wait for the churn to subside, before proceeding - or start work on this in parallel, so that the requirements for multicasting file(s) to a room are kept in mind while tackling the file transfer problem.

Saturday Jul 28, 2007

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.



« April 2014

No bookmarks in folder