[Standards] MUC Invites are no MUC PMs (Was: Multi-client operation and read-until-X markers)
georg at op-co.de
Tue Sep 20 06:35:09 UTC 2016
Nothing is better than a corner case hidden inside of a corner case.
* Georg Lukas <georg at op-co.de> [2015-05-05 16:35]:
> 4. Carbons of MUC private messages. If user at host/A has joined to a MUC
> and receives a private message from muc at domain/participant, that message
> is carbon-copied to the other resource user at host/B (not joined to the
> MUC). Now /B has no way to know that it is a PM from a MUC, and not a
> regular message from a user muc at domain, using resource /participant, and
> is utterly confused.
> One possible workaround would be to mark all MUC PMs, like it is done by
> prosody: http://hg.prosody.im/trunk/rev/09151d26560a
Both prosody and ejabberd MUC implementations now mark PMs with an
<x http://jabber.org/protocol/muc#user> element, and the respective
carbon implementations filter away duplicates, which is good.
Unfortunately, this logic also affects MUC invitations, as these also
have the same <x> element. However, invitations should be delivered to
all clients. Therefore, if you are implementing an XMPP server with
carbons support, please fix your MUC PM suppression logic.
|| 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...
Size: 811 bytes
Desc: Digital signature
More information about the Standards