[Standards] XEP-0280 Carbon Rules for MUC-PMs

Georg Lukas georg at op-co.de
Fri Jan 27 13:36:56 UTC 2017


I know everybody hates MUC PMs, but still. People are using them, and
they are broken in the wild as soon as you have more than one client.
We need to fix XEP-0280 and our server implementations, and probably
also XEP-0045 and our MUC implementations, to tackle this.

Problems TL;DR

1. There is no defined way for a server to detect "messages sent by a
   MUC room or service", often causing incorrect behavior (spec).

2. Mediated MUC invitations are not allowed to be carbon-copied (spec).

3. Incoming MUC-PMs are wrongfully CCed if #1 fails (implementation).

4. Outgoing MUC-PMs are wrongfully CCed to non-joined clients (spec).

Fortunately, we can solve all of them with little work.

User Story / Problem Details

Let's say Alice is online with three clients as alice at xmpp.example/a, /b
and /c. /a and /b are joined to the MUC aliceboblove at muc.xmpp.example
as "Alice", using Multi-Session-Nicks.

First, Alice invites Bob using a mediated invitation, which is forwarded
by the MUC to Bob's bare JID. The rules in XEP-0280 §6 forbid this invitation
message ("sent by a MUC room or service") to get carbon-copied, so it
is only routed by §6121 § rules to Bob's primary client,
leading to a significant delay until Bob can join (see

Once he figured this out, Bob joins and complains with a MUC-PM to
aliceboblove at muc.xmpp.example/Alice. The MUC takes care of routing
copies of this PM to /a and to /b. If Alice's server follows XEP-0280
§6, it has to automagically detect these messages as "sent by a MUC room
or service" and not carbon-copy them.

If this works, the UX is fine. However, the carbon prevention is often
broken in practice, so the following messages arrive:

/a: MUC-PM to /a and carbon of MUC-PM to /b.
/b: MUC-PM to /b and carbon of MUC-PM to /a.
/c: carbon of MUC-PM to /a and carbon of MUC-PM to /b.

(see https://prosody.im/issues/issue/798 for a reallife example)

If Alice now responds to that PM from /a, this message is theoretically
eligible for Carbon delivery to /b and /c, because it is not *from* but
*to* a MUC. However, the spec is not very clear on this and I can
imagine servers doing this wrong. Furthermore, /c will receive a copy of
the PM and have no idea what it is about.


#1 Detect "messages sent by a MUC room or service"

Current best practice is for MUC implementations to add a tag to all
messages (groupchat and PMs) sent from the MUC:

	<x xmlns="http://jabber.org/protocol/muc#user">

Carbons implementations do check for presence of this tag and disable
CC'ing accordingly. We need to codify this, and it belongs into both
XEP-0045 (adding the <x/> tag) and into XEP-0280 (using the tag as a
filter criterion). I'm willing to create PRs for both once consensus is
reached ("45 version bump", anyone?).

#2 Mediated MUC invitations

XEP-0280 §6 needs to be extended with an invitation exemption. Possible

a) add "A <message/> is eligible for carbons delivery if it is a MUC

b) replace the MUC sentence with a set of less confusing sentences
covering all the possible MUC scenarios (e.g. sometimes you try to join
a MUC and receive a "normal" message from the MUC bare JID asking to
solve a captcha):

- A <message/> of type "groupchat" is not eligible.
- A <message/> of another type than "groupchat", originating from a MUC
  service or room (bare JID), as detected by the presence of an <x/>
  tag, is eligible.
- A <message/> from a MUC participant (full JID) containing an <x/> tag,
  is not eligible.
- A <message/> sent by the local user to a MUC participant is eligible.

I'm willing to make a PR for (b), with slightly better wording.

#3 and #4 Fixing MUC-PMs

Because incoming PMs are forwarded by the MUC to all joined clients, #3
will be eventually solved with #1. Until all the servers have upgraded,
I suggest that we add a client business rule to 0280 as follows:

"Clients SHOULD discard carbon copies of 'received' messages that
contain MUC private message, irregardless of the client being joined to
that MUC".

To fix outgoing PMs, these need to be carbon-copied only to the other
clients of the user which are joined under the same nickname. This is a
HARD problem. Possible solutions are:

a) Require carbon-enabled clients to tag outgoing MUC-PMs with <x/>,
carbon-copy the 'sent' MUC-PM to all clients, require carbon-enabled
clients to check for <x/> tag and to drop if they are not joined. This
is a 90% solution (it will still display outgoing PMs if you are
joined to the same MUC under different nicknames, as the other client
doesn't know which nickname the 'sent' message came from).

b) Require the user's server to track MUC joins, including nickname, and
make the carbons logic depend on that. This is a 100% solution, at least
once everybody has updated their servers, and it might add a significant
burden on the server (at least comparable to tracking directed
presence). Does not conflict with (a) so it might be a long-term
improvement for the last 10%.

c) Let the MUC generate 'sent' carbons to other MSN clients. This is a
security nightmare waiting to happen. I'm not going to go this route,
and I only mention it for sake of completeness.

My favorite is to mandate (a) now and possibly follow up with (b),
depending on server implementer feedback.

I'm willing to make a PR for the 'received' sentence and for (a).

Kind regards,


P.S: Sorry prosody, the issue reports linked are not meant to outline
that prosody is bad (it's great!), but merely as a reference with
further discussion of the individual issues.
|| http://op-co.de ++  GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N  ++
|| gpg: 0x962FD2DE ||  o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+  ||
|| Ge0rG: euIRCnet ||  X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y?   ||
++ IRCnet OFTC OPN ||_________________________________________________||
-------------- 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/20170127/8f09105b/attachment.sig>

More information about the Standards mailing list