A MUC invite that is sent to a bare JID is misclassified as a MUC PM and thus not carbon-copied to secondary clients:
Primary client receives this:
<message to="georg@yax.im" id=".." type="normal" from="...@conference.jabber.fu-berlin.de"><x xmlns="http://jabber.org/protocol/muc#user"><invite from="..."><reason /></invite></x><x xmlns="jabber:x:conference" jid="...@conference.jabber.fu-berlin.de" /><body>... invites you to the room ...@conference.jabber.fu-berlin.de</body></message>
prosody logs for the message:
Sep 19 20:07:16 s2sinab07f90 debug Received[s2sin]: <message type='normal' to='georg@yax.im' from='.....@conference.jabber.fu-berlin.de'>
Sep 19 20:07:16 yax.im:carbons debug MUC PM, ignoring
Accordingly, the second client never receives the eagerly awaited invitation.
Possible solutions to this are:
1. Use a different namespace for MUC PMs (will break interop with other MUC services like ejabberd and current prosodies).
2. Explicitly check for the presence of an <invite/> element before quitting mod_carbons.
3. Only apply the MUC-PM logic to messages addressed at a full-JID (you can't MUC-PM a bare JID). This will have a corner-case-in-a-corner-case though where MUC invites addressed at a full JID will be mistreated as PMs.
I would prefer the second solution.
mod_track_muc_joins instead of using the <x> element in mod_carbons, to determine which messages are MUC PM and must be suppressed? That might work.
Don't forget to take care of the corner case where you send yourself a MUC invitation so your mobile client can easily join! :D
MattJ
on
In option 2 you discuss checking for whether the 'to' JID is full/bare. Don't invites always come from the bare JID? While PMs always come from a full JID.
Ge0rG
on
@MattJ, indeed, I haven't thought about the sender JID, only about the receiver. From a brief look, this should work and doesn't affect direct invitations either.
A MUC invite that is sent to a bare JID is misclassified as a MUC PM and thus not carbon-copied to secondary clients: Primary client receives this: <message to="georg@yax.im" id=".." type="normal" from="...@conference.jabber.fu-berlin.de"><x xmlns="http://jabber.org/protocol/muc#user"><invite from="..."><reason /></invite></x><x xmlns="jabber:x:conference" jid="...@conference.jabber.fu-berlin.de" /><body>... invites you to the room ...@conference.jabber.fu-berlin.de</body></message> prosody logs for the message: Sep 19 20:07:16 s2sinab07f90 debug Received[s2sin]: <message type='normal' to='georg@yax.im' from='.....@conference.jabber.fu-berlin.de'> Sep 19 20:07:16 yax.im:carbons debug MUC PM, ignoring Accordingly, the second client never receives the eagerly awaited invitation. Possible solutions to this are: 1. Use a different namespace for MUC PMs (will break interop with other MUC services like ejabberd and current prosodies). 2. Explicitly check for the presence of an <invite/> element before quitting mod_carbons. 3. Only apply the MUC-PM logic to messages addressed at a full-JID (you can't MUC-PM a bare JID). This will have a corner-case-in-a-corner-case though where MUC invites addressed at a full JID will be mistreated as PMs. I would prefer the second solution.
4th option: Use https://modules.prosody.im/mod_track_muc_joins.html to know what rooms are joined. Also solves the issue of things that don't use tag PMs.
mod_track_muc_joins instead of using the <x> element in mod_carbons, to determine which messages are MUC PM and must be suppressed? That might work. Don't forget to take care of the corner case where you send yourself a MUC invitation so your mobile client can easily join! :D
In option 2 you discuss checking for whether the 'to' JID is full/bare. Don't invites always come from the bare JID? While PMs always come from a full JID.
@MattJ, indeed, I haven't thought about the sender JID, only about the receiver. From a brief look, this should work and doesn't affect direct invitations either.
How about https://hg.prosody.im/0.10/rev/2be85cb3bc66 / https://hg.prosody.im/prosody-modules/rev/ad7f87bd30c8
Changes