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="email@example.com" 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' firstname.lastname@example.org' 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
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.