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
