[Standards] XEP-280 and MUC private chats

Mathieu Pasquet mathieui at mathieui.net
Sun Jul 14 19:13:57 UTC 2013


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.

Or even better, maybe the server could perform that disco, although I
get that making changes to already-deployed implementations might be
painful.

-- 
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/20130714/cda33404/attachment.sig>


More information about the Standards mailing list