[jdev] Handling of MUC within Candy

[Michael Weibel]

Hi all,

We currently have an interesting discussion about the various compromises we did with the implementation of Candy (MUC client in javascript) in part of the refactoring issue I started (https://github.com/candy-chat/candy/issues/207). 

Currently Candy works with the semi-anonymous room jids (room at conference.example.com/nick) to send messages. We use this approach also to send direct messages to other occupants in a room. 
However, as Hypher, one of our users, mentioned, this is not the standard behaviour of XMPP clients and therefore he has some issues with the use case he wants to use Candy for (in-game chat). 

When we initially developed Candy, we had to make the decision whether to use the real jid of a user to send him a private message or to use the room jid. We decided to use the room jid because it’s much easier (without roster accept/declines) to display a user whether he’s still online or not. The tradeoff however is, that user A can have two conversations with user B (we have also some other issues with it, but they it’s root in this decision). 

Now what I would like to hear is your opinion about Candy’s behaviour and also what you think how we could solve the issue to (A) use the standard behaviour and (B) to be able to display a users’s online status. 
While we could for sure send roster requests and auto-accept them in case one wants to talk privately to another user, I don’t think this is a good behaviour because people might not want this. 

Also if we would change to always use the real jid of users, what would it mean for anonymous users (which a lot of our users use)?

Thanks,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.jabber.org/jdev/attachments/20140120/d16791b2/attachment.html>