On Wed, Sep 25, 2013 at 4:47 PM, Matt Miller <linuxw...@outer-planes.net> wrote: > > On Sep 25, 2013, at 2:24 PM, Waqas Hussain <waqa...@gmail.com> wrote: > >> On Wed, Sep 25, 2013 at 4:00 PM, Kim Alvefur <z...@zash.se> 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. >
Prosody does support that. The missing pieces is that new resources need to discover which chatrooms the other resources are in, and when a resource joins or leaves a room, the others need to be notified. There is no standard mechanism for this, and leaving the up to the clients (as opposed to the MUC host) leads to various race conditions that I'm thinking through. Another missing piece was figuring out which nicks in a chatroom were owned by you. Luckily Prosody's MUC always shows you your own real JID even if you are not an admin. Multiple sessions behind a nick are still invisible (Prosody's implementation currently completely hides other nick-sessions from the client behind the same nick, for compat reasons). -- Waqas Hussain
