On Sep 25, 2013, at 2:24 PM, Waqas Hussain <[email protected]> wrote:
> On Wed, Sep 25, 2013 at 4:00 PM, Kim Alvefur <[email protected]> wrote: >> Hello, >> >> On 2013-06-09 20:40, Mathieu Pasquet wrote: >>> I was starting to implement carbons in poezio when I came across some >>> kind of design issue that I haven’t been able to work out. >>> >>> However, in the case of private MUC messages (XEP-0045, 7.5), the >>> messages are also of type 'chat', causing them to be forwarded as normal >>> chat messages. But the other resources are not necessarily present on >>> that MUC, so they will receive the messages just fine, as with any >>> direct conversation with a fulljid, but they won’t be able to reply, >>> because I believe most MUC implementations will check the fulljid and >>> reply with an error. >> >> I would like to propose that the MUC server shall stamp something like >> <x xmlns='http://jabber.org/protocol/muc#user'> on private messages >> passing through, similar to what is already done to <presence>. >> >> This would allow a Carbons implementation to treat those differently, eg >> by not copying them to Carbons-interested resources, or a client >> receiving a carbon copied message can indicate to the user that replying >> won't be possible. >> >> Aside: I also think this would be useful for message archives, to help >> not record duplicated PMs if the user has joined a room from multiple >> clients. >> > > Ignoring the protocol for a bit, what do users want? There's a lot of > user interest in having the same chats available across devices. I > would assume users would want the same for chatrooms and MUC PMs… > > We also have mutli-party chats where a one-to-one chat is upgraded to > a MUC [1]. Would that mean users are happily chatting across multiple > devices, they add a person to the chat and are suddenly stuck to one > device? > > I think MUC is just incompatible with carbons with no clean way to > combine them, however a carbons-like XEP for MUC would be highly > desirable. Coincidentally, this was a problem I was attempting to > solve today for a service I'm working on: Multiple clients (BOSH > clients on multiple tabs, devices, native application) which needed to > have the same chatrooms open (It's like [1], but starting out with MUC > from the start). I'm starting out with broadcasts on join/leave from > the MUC service to users' resources, which may or may not be the ideal > design. > > [1] http://xmpp.org/extensions/xep-0045.html#continue I think one could do achieve carbons-like behavior in MUC today if the service supported multiple joins (say, different resourceparts under the same bare JID) to the same nickname. It looks like most (if not all) of the protocol bits are already in XEP-0045 to allow for that. Such behavior is underspecified, and that could be addressed by an informational XEP. - m&m Matthew A. Miller < http://goo.gl/LK55L >
smime.p7s
Description: S/MIME cryptographic signature
