On Tue, Jul 16, 2013 at 10:31 PM, Peter Saint-Andre <[email protected]> wrote: > On 7/16/13 3:23 PM, Kevin Smith wrote: >> On Tue, Jul 16, 2013 at 8:02 PM, Peter Saint-Andre <[email protected]> >> wrote: >>> On 7/14/13 1:13 PM, Mathieu Pasquet wrote: >>>> On Sun, Jul 14, 2013 at 05:36:51PM +0100, Kevin Smith wrote: >>>>> On Sun, Jun 9, 2013 at 7:40 PM, Mathieu Pasquet <[email protected]> >>>>> 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. >>>>>> >>>>>> 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. >>>>> >>>>> Could you disco any unknown JIDs to see if they're users or MUCs? >>>>> >>>>> /K >>>> >>>> Yeah, that’s what I went with (I had forgotten about it at the moment of >>>> writing that email). >>>> >>>> I think the XEP should indicate such a behavior, as a client developer >>>> might forget about this case. >>> >>> Sounds like a positive addition. It would be good to advance this spec >>> to Draft sometime. Do you have any other feedback? >>> >>>> Or even better, maybe the server could perform that disco, although I >>>> get that making changes to already-deployed implementations might be >>>> painful. >>> >>> How would it work for the server to perform service discovery on your >>> behalf? (BTW, you don't need to send the disco request if you're using >>> entity capabilities / XEP-0115.) >> >> No? > > I must be missing some context, then -- if you've received caps from > another entity, there's no need to send the disco request.
But if it's an unexpected message and you need to know if it's from a MUC or a user, you will need to disco. /K
