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.
As I understand it (and in the use case explained in the introduction), Carbons provide a way to minimize the nuisance of changing devices, by providing all the messages with 'chat' type to all the carbon-enabled clients. The requirements also state that “All clients that turn on the new protocol MUST be able to see all inbound chat-type messages”. 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 can’t think of a straightforward solution to this issue, as the server doesn’t know about MUC, neither does the other resource. On the sender part, it might be solved by including a <private/> with each message sent through such chats, but on the receiving part, AFAIK there is no way to distinguish those. I think the XEP should cover that case, because it is rather common to have private conversations with people in a groupchat, and letting clients guess how they should handle the message is very error-prone. -- Mathieu Pasquet - poezio developer
