[Standards] Securely converting a 1:1 chat into a MUC

Georg Lukas georg at op-co.de
Tue Dec 20 18:18:50 UTC 2016


a modern XMPP messenger needs to provide a seamless way to create a
"privte" group, either by inviting a bunch of folks or by upgrading a
1:1 chat into a conference.

XEP-0045 §7.9 explicitly defines this use case as follows:

| Now the first person decides to include a third person in the
| discussion, so she does the following:
| 1. Creates a new multi-user chatroom
| 2. Sends history of the one-to-one chat to the room (this is purely
|    discretionary; however, because it might cause information leakage,
|    the client ought to warn the user before doing so)
| 3. Sends an invitation to the second person and the third person,
|    including a <continue/> element (optionally including a 'thread'
|    attribute).

Unfortunately, all of these points are flawed, or as an xsf@ regular
wrote "a bit of a pain to implement sanely".

#1 omits precise instructions on how to make a non-public invite-only
MUC. It mentions §10.1.2 "Creating an Instant Room", but there it is
only described how to send back an empty form; the actual parameters
for an "instant room" are never defined.

#2 breaks message attribution in the history (for plain-text messages,
and it also violates the other user's privacy) and wreaks havoc if any
kind of encryption is in place.

#3 is using mediated invitations which can not be securely attributed
to the initiating user. While a direct invitation (§7.8.1) can be
checked for an according presence subscription from the sending JID, a
mediated invitation might contain "the bare JID, full JID, or occupant
JID of the inviter", making it essentially useless.

Existing implementations don't speak a common language here, and many
are susceptible to auto-join-on-invite, leading to exposure of presence
or other sensitive information.

I'd like to see a coherent UX and protocol specification for how a
client should convert a 1:1 chat into a MUC, which kind of messages
should be sent in this use case and how a client should react to such
invitations without leaking sensitive information.

Maybe somebody could write it down here or extend the page at

Then we could improve the UX of XMPP a bit more.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: Digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20161220/fdf67dc7/attachment.sig>

More information about the Standards mailing list