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
On 20.01.2014, at 19:25, Michael Weibel michael.weibel+x...@gmail.com wrote:
Currently Candy works with the semi-anonymous room jids
(r...@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
Hi Michael,
On 20 January 2014 18:25, Michael Weibel michael.weibel+x...@gmail.com 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
On 20.01.2014, at 21:03, Matthew Wild mwi...@gmail.com wrote:
I personally think if you start a message with a room occupant in the
UI, the protocol should do the same, converse with that occupant in
that room. If I have a chat open with someone already, I am generally
unlikely to open a
On Mon, Jan 20, 2014 at 6:38 PM, Stefan Strigler
stefan.strig...@gmail.comwrote:
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
On 20 January 2014 20:28, Stefan Strigler stefan.strig...@gmail.com wrote:
On 20.01.2014, at 21:03, Matthew Wild mwi...@gmail.com wrote:
I personally think if you start a message with a room occupant in the
UI, the protocol should do the same, converse with that occupant in
that room. If I
On Mon, Jan 20, 2014 at 3:03 PM, Matthew Wild mwi...@gmail.com wrote:
Hi Michael,
On 20 January 2014 18:25, Michael Weibel michael.weibel+x...@gmail.com
wrote:
Hi all,
We currently have an interesting discussion about the various compromises we
did with the implementation of Candy (MUC
Hi Stefan,
Why is that non standard behaviour? What is considered to be the standard here?
I don’t want to say it’s non standard according to the XEPs. When developing
Candy initially we tested some clients (well, mainly Adium/Pidgin) how they
behave in MUC rooms and they usually send private
Hi Matthew,
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).
Ok (as mentioned in the other reply), I more or
One alternative approach could be to
a1) make all rooms be non-anonymous to know the real-jid of each participant
OR
a2) make sure users can't change their nickname and use the same throughout all
rooms
b) have a hidden default room (a lobby) that acts as a central hub sharing
information
Hi Dave,
By talking to the same person in two different rooms, or once in a room and
once using the real jid.
exactly.
I'm not sure this is actually a problem generally, but I imagine it could be in
some cases.
Depending on what you display to your users it might be a problem or not.
Usually,
Well, yes. I should note that my arguments are based on general usage
on the XMPP network. I think closed environments (for example Michael
mentioned an in-game chat) are able to make their own decisions about
these kinds of things, as they ultimately control the whole thing from
the server to
Am 21.01.2014 um 06:57 schrieb Michael Weibel michael.weibel+x...@gmail.com:
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
13 matches
Mail list logo
