[Standards] XEP-280 and MUC private chats

Mathieu Pasquet mathieui at mathieui.net
Tue Jul 23 22:15:03 UTC 2013

On Tue, Jul 16, 2013 at 01:02:36PM -0600, Peter Saint-Andre 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?

No, I don’t have anything to add, apart from this issue it was quite
straightforward to implement.

> > 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.)

That was only an idea, but after thinking about it, it would be quite
bad to have the server perform such a query on behalf on the user.

Of course, the disco info is only useful if we never got any presence
and caps from the other user (if we did, then it’s not a MUC in any

Mathieu Pasquet (mathieui)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20130724/f4b60a6d/attachment.sig>

More information about the Standards mailing list