XEP-0045: Presences and messages arriving out of order; clients can interpret room join as complete before all <presence/>s landed

[ivucica]

Actors:

• example.org: host domain
• freenode.example.org: MUC domain (proxying traffic to IRC)
• [email protected]: bot joining the MUC room
• #[email protected]: MUC room being joined

This is the traffic received, anonymized and shortened, mildly formatted (note, all of this is listed under one RECV:):

<presence to='[email protected]/abcd-go' from='#[email protected]/_joe'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item jid='[email protected]' affiliation='none' role='participant'/>
  </x>
</presence>

<presence to='[email protected]/abcd-go' from='#[email protected]/abc'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <status code='110'/>
    <item jid='[email protected]/[email protected]' affiliation='none' role='participant'/>
  </x>
</presence>

<message type='groupchat' to='[email protected]/abcd-go' from='#[email protected]/PersonSettingSubject'>
  <subject>this is some subject</subject>
</message>

However, the very first packet landing into HandlePacket is the <message/>. Per XEP-0045, a <message/> with no <body/> [empty not being a good replacement] and containing a mandatory <subject/> [which may be empty; see also https://github.com//issues/167] means that the room join is complete.

Yet, none of the <presence/>s have been seen at this point.

Inability to distinguish between empty and not-present body and subject #167 and delivery of <message/> and <presence/> out of order means it's not possible to know which users were already present in the room and which entered later, despite XEP-0045 allowing for this scenario.

This is on ac5b066 from May 7 2020, currently the latest commit.