On Mon, Jan 20, 2014 at 3:03 PM, Matthew Wild <[email protected]> wrote: > Hi Michael, > > On 20 January 2014 18:25, Michael Weibel <[email protected]> > wrote: >> 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 >> ([email protected]/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). > > I wouldn't say it's not the standard behaviour of XMPP clients. In > fact the only client I can think of that will use real JIDs for > private messages in rooms is Pidgin (and, well, I think Adium too - > but they share a lot of code). > > As a user I find this behaviour extremely irritating. People who are > not on my roster message me, I don't know their nick or what room they > came from, and if their server doesn't allow messages from > non-contacts I also can't reply back to them. I can't see their > presence, and I might not want to add a stranger to my roster just for > one chat. >
I'd second this. Client which do this are irritating. It isn't possible to e.g., as a room admin to PM an occupant without revealing your JID. And PM'ing Gmail users doesn't work, because Gmail requires the other user be in your contact list, which is frequently not the case. -- Waqas Hussain _______________________________________________ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [email protected] _______________________________________________
