[Standards] XEP-280 and MUC private chats

Kevin Smith kevin at kismith.co.uk
Wed Jul 17 06:40:19 UTC 2013


On Tue, Jul 16, 2013 at 10:31 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> On 7/16/13 3:23 PM, Kevin Smith wrote:
>> On Tue, Jul 16, 2013 at 8:02 PM, Peter Saint-Andre <stpeter at stpeter.im> 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 <mathieui at mathieui.net> 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



More information about the Standards mailing list