<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255);"><span><div><div>Well, yes. I should note that my arguments are based on general usage<span class="Apple-converted-space"> </span><br>on the XMPP network. I think closed environments (for example Michael<span class="Apple-converted-space"> </span><br>mentioned an in-game chat) are able to make their own decisions about<span class="Apple-converted-space"> </span><br>these kinds of things, as they ultimately control the whole thing from<span class="Apple-converted-space"> </span><br>the server to the protocol, client and overall user experience. I'm<span class="Apple-converted-space"> </span><br>quite certain there are scenarios where messaging user-to-user using<span class="Apple-converted-space"> </span><br>only real JIDs would work better.<span class="Apple-converted-space"> </span></div></div></span></blockquote></div><p>I guess that’s part of the problem here: Candy is developed for general usage and, because they like certain things about Candy, some users are adapting it to their own custom environments (which is perfectly fine and I’m really glad it’s happening). However, if such basic decisions (like real vs. room jid) need to be different, a fork of Candy or an own implementation might be more the way to go. </p><p>I don’t know if I can support both ways without a lot of code. </p><div></div></body></html>