Chat room connection with multiple connections does not work

[thedjnK]

Describe the bug
In a server setup which supports multiple conconnect connections from different devices (openfire) it seems that the application is unable to handle joining a chat room when another client elsewhere using the same account is already in there, the app shows "joining" status forever in this state, however it can receive messages from it (via push message notifications that is), and the server shows that the app has joined the room. If it is done in the inverse order - the phone app starts and joins first then the other client (pidgin in this case) joins then the app is able to join successfully.

To Reproduce
Steps to reproduce the behavior:

1. Join server with existing client in existing chat room
2. Watch as it stays on joining forever

Expected behavior
Joining to work

Screenshots
App upon opening:

Chat room:

Openfire showing app is in room:

Details (please complete the following information):

• Siskin Version: 7.3.3
• iOS version: 13.4
• iPhone model: iPhone SE 2020

Additional context
Add any other context about the problem here.

[hantu85]

Siskin IM is based on Martin library. This library closely follows XEP-0045 and changes status of the user in the room from joining to joined when it receives presence to self with status code 110 as in the XEP:

the "self-presence" sent by the room to the new user MUST include a status code of 110 so that the user knows this presence refers to itself as an occupant

I'm assuming that you are trying to join the room from the 2 clients using the same account and the same nick (Multi-Session Nicks). If the Siskin joins first then nick is not "shared" yet in the room and server hosting MUC room sends presence with 110 code. However, when other client already joined then Siskin "hangs" on joining as it is not receiving presence with 110 - most likely server is not sending it to the client as it "assumes" that client was joined (well account was joined, but this client wasn't).

[thedjnK]

Siskin IM is based on Martin library. This library closely follows XEP-0045 and changes status of the user in the room from joining to joined when it receives presence to self with status code 110 as in the XEP:

the "self-presence" sent by the room to the new user MUST include a status code of 110 so that the user knows this presence refers to itself as an occupant

I'm assuming that you are trying to join the room from the 2 clients using the same account and the same nick (Multi-Session Nicks). If the Siskin joins first then nick is not "shared" yet in the room and server hosting MUC room sends presence with 110 code. However, when other client already joined then Siskin "hangs" on joining as it is not receiving presence with 110 - most likely server is not sending it to the client as it "assumes" that client was joined (well account was joined, but this client wasn't).

Not that I have any knowledge of the XMPP protocol but from what I see above that:

When a MUC service receives an tagged join stanza from an already-joined client (as identified by the client's full JID), the service should assume that the client lost its synchronization, and therefore it SHOULD send exactly the same stanzas to the client as if it actually just joined the MUC. The server MAY also send a presence update to the other participants according to the received join presence.

Doesn't the may part indicate that in this case it should not receive the 110 status?

[thedjnK]

I enabled the XMPP console from pidgin, disconnected it, then connected from siskin first, then enabled account on pidgin and searched the logs and saw this:

<presence to='*@*/*' from='*@conference.*/*'>
	<priority>1</priority>
	<c xmlns='http://jabber.org/protocol/caps' node='http://pidgin.im/' hash='sha-1' ver='I22W7CegORwdbnu0ZiQwGpxr0Go='/>
	<occupant-id xmlns='urn:xmpp:occupant-id:0' id='*'/>
	<x xmlns='http://jabber.org/protocol/muc#user'>
		<item jid='*@*.*/*' affiliation='owner' role='moderator'/>
		<status code='110'/>
		<status code='100'/>
		<status code='170'/>
	</x>
</presence>

Not sure about logging on siskin for the reverse but the above seems to look like status code 110 is actually sent for the second client

[thedjnK]

Interestingly, there appears to be another iOS app based on this code https://github.com/snikket-im/snikket-ios which does not have the same issue, if snikket is opened first and sisken after then sisken is stuck on "joining", if it's done in the reverse order snikket is able to join fine, seems they fixed the bug but did not upstream the fix?

[hantu85]

Snikket still uses version 2.1.3 of Martin library (was named TigaseSwift back then), and Siskin uses version 3.2.4. I would expect possible issue with newer version of the library

[hantu85]

Thank you for testing and helping with debugging of the issue. It allowed me to find possible cause of the issue in Martin and hopefully I'll be able to publish a new version with a fix.

[hantu85]

I've pushed a new test flight build 7.4.0-b6 that should resolve this issue.

[thedjnK]

I've pushed a new test flight build 7.4.0-b6 that should resolve this issue.

Seems to require iOS 26, no support for older iOS versions going forward?

[hantu85]

That is not true. Minimal required iOS version is 14. Where do you see a requirement for iOS 26?

[thedjnK]

That is not true. Minimal required iOS version is 14. Where do you see a requirement for iOS 26?

Ah maybe it's just the description on testflight:

7.4.0 (6)
Updates for iOS 26 and minor fixes
Expires in 90 days
Requires latest OS

I took it to mean iOS 26 was required, anyhow still requires too new a version for me