Private messages cease to function if a clients connection is killed by the server, but they do not get booted back to the login screen. The user attempting to message the flickering nickname will be referenced as User A. User A attempting to private message the flickering user, referenced as User B, will be able to send messages, but they will not be received by User B.
User A will see User B disconnect, and then immediately reconnect. User B will not see any disturbances on their client. Any private message history will be lost to User A, as the flicker creates a new buddy under the same nickname. User B will retain their chat history. Neither User A or User B will be able to continue exchanging messages until one of them exits the client and then re-enters.
Reproducing:
Create a room with two users. Have User A running version 2.5.7 of Cryptodog. Have User B run any version 2.5.6 and below. Have either user send a private message to the other. Wait until the server closes User B's connection. You will know this has occurred when User A sees User B disconnect and then instantly reconnect on User A's client. Attempt to send a private message on either client.
Ramifications:
Users with unstable internet may find themselves unable to receive private messages, with no indication that this issue has occurred. This bug is not limited exclusively to outdated Cryptodog clients, but will occur if a users connection is interrupted, but their client remains logged in.
Potential causes:
OTR key exchange re-occurs on User A's side, but User B's client believes it has already occurred, and does not re-exchange keys.
Potential fix:
Simple: boot User B client-side on disconnect
Complex: alter OTR exchange to re-occur if a client indicates that the other has disconnected
Problem:
Private messages cease to function if a clients connection is killed by the server, but they do not get booted back to the login screen. The user attempting to message the flickering nickname will be referenced as User A. User A attempting to private message the flickering user, referenced as User B, will be able to send messages, but they will not be received by User B.
User A will see User B disconnect, and then immediately reconnect. User B will not see any disturbances on their client. Any private message history will be lost to User A, as the flicker creates a new buddy under the same nickname. User B will retain their chat history. Neither User A or User B will be able to continue exchanging messages until one of them exits the client and then re-enters.
Reproducing:
Create a room with two users. Have User A running version 2.5.7 of Cryptodog. Have User B run any version 2.5.6 and below. Have either user send a private message to the other. Wait until the server closes User B's connection. You will know this has occurred when User A sees User B disconnect and then instantly reconnect on User A's client. Attempt to send a private message on either client.
Ramifications:
Users with unstable internet may find themselves unable to receive private messages, with no indication that this issue has occurred. This bug is not limited exclusively to outdated Cryptodog clients, but will occur if a users connection is interrupted, but their client remains logged in.
Potential causes:
OTR key exchange re-occurs on User A's side, but User B's client believes it has already occurred, and does not re-exchange keys.
Potential fix:
Simple: boot User B client-side on disconnect Complex: alter OTR exchange to re-occur if a client indicates that the other has disconnected