hoehermann
commented
9 months ago Thank you for the report. As far as I can tell, it is not a race-condition in this plug-in, but rather a side effect of how the Signal protocol works.
For single-contact chats, I recommend adding the contact's UUID to your buddy list. Then the local alias will be available right away, providing a workaround. I am aware that the "contact is now known as name" message sometimes pops up – even if a local alias exists. It annoys me, but not so much I want to investigate it further.
For group chats, I noticed something quite similar: Sometimes, the messages are received out-of-order. More precisely "ordered by participant" rather than "ordered by date". I suspect messages are cached in signald, then something is going on with cryptographic key exchange in the background. As soon as the messages of one participant can be decrypted, they are forwarded to purple. The official client just re-orders the messages. Unfortunately, Pidgin offers no option to re-order messages which have already been shown. I am not sure if it is the same issue as you describe, though.
In both cases: I do not want to withhold messages from being displayed until they can be displayed correctly. I fear the UUID will never be resolved or the cryptographic key exchange will never be completed before the front-end is terminated. Messages would be regarded as "done" in signald, while not having been shown to the user, opening up a way for messages to be "lost". I rather display messages out of order and with incomplete information.
mooomooo
If there are messages that have come in while the account is offline, they show up immediately on connecting. But that then means they show up as coming from the sender's UUID (i.e. not using the nick_format) which then registers as a different chat from once the nick_format takes hold. I assume there's some race condition on the first connection where the queued messages get handled before the buddy list does?