Messages echoing back / OTR issues / no "message read" marking

[eionrobb]

Messages echoing back / OTR issues / no "message read" marking

[GrandAdmiralThrawn]

Thank you for your work! The DLL won't help me, as I'm on Linux, but I just patched the code and recompiled it. Its behavior is... interesting. Some self-messages get deduped, but others are still duped (When sent from the same, local client).

Just to make sure, I have checked out the entire source code of your plugin from scratch and rebuilt it, but it's the same. It works for a few messages, then I get dupes again. Sometimes after that, some messages work again, some get duped. Sometimes it seemingly keeps duping every message once the issue appears...

[GrandAdmiralThrawn]

@buchty 1) is quite troublesome. A lot of mobile clients do something like this as well (by using proxy servers though). I dislike that very much. But the duplicates are even more troublesome, at least in my opinion.

Anyway, Oscar broke entirely for me two days ago, which is why I have to rely on Pidgin + libicyque now, at least on Linux and BSD UNIX. That's why I'm pressing for a fix. ;)

[EionRobb]

Unfortunately I haven't finished writing the message de-dup code, which will be causing havoc with the OTR plugin (it'll think there's new incoming OTR messages but they're actually outgoing ones)

[hitman72ita]

same problem here, thank you for support

[rzenkov]

one more

yes, same problem. lot of people using the plugin it seems :)

[GrandAdmiralThrawn]

Has development already ceased? This echoing thing is really annoying by now.

I tried to understand the source code myself, but I simply don't get C. I thought it would be easy to just compare the UINs (or nick names) of an incoming message and my own, and then filter accordingly. But I don't even understand how to get a UIN or how to compare it, and with what. ;)

So much for the idea of doing this with a simple 'if'...

So please, could you fix this?

Thank you very much!

[EionRobb]

@GrandAdmiralThrawn I'm a bit time-poor at the moment with a new baby and too many other plugins to try and look after

Pull requests always welcome. I'm happy to guide any would-be devs to help fix things up :)

[EionRobb]

@GrandAdmiralThrawn also, the change wouldn't be to just remove self-messages, but to de-dup messages that you've sent from Pidgin vs sending from another app (or another Pidgin)

[GrandAdmiralThrawn]

I've been fooling around yesterday, but the only thing I managed to do is to filter out ALL messages I got, only one of the mirrored ones was left when sending a message. So I could talk to myself, but that was about it. Not exactly very productive. ;)

I think I'm not cut out for this. I thought the right thing to do was to pass "PurpleBuddy *buddy" to the icq_process_event() function somehow, and then compare the buddy alias and the account alias with each other for each arriving message. But I couldn't make it work, and I don't really know what I'm doing... :( Aah, and I don't know libpurple either.

Near-zero skills here I'm afraid. :(

[EionRobb]

I made an attempt at de-dup in 28d6999 if anyone's willing to try it out (the current dll at https://eion.robbmob.com/libicyque.dll has the same fix in it)

[pf2]

I made an attempt at de-dup in 28d6999 if anyone's willing to try it out (the current dll at https://eion.robbmob.com/libicyque.dll has the same fix in it)

I tested now this patch on linux but without mtr and it seems be working.
I now see only one message on a pidgin conversation.
Thank you RioRobb for a patch 👍

[hitman72ita]

yes, still duplicate messages with this "new" windows dll

[buchty]

On Thu, 28 Mar 2019, GrandAdmiralThrawn wrote: Just to make sure, I have checked out the entire source code of your plugin from scratch and rebuilt it, but it's the same. It works for a few messages, then I get dupes again. Sometimes after that, some messages work again, some get duped. Sometimes it seemingly keeps duping every message once the issue appears...

Same here. Seemingly works at first, but then occasional dupes appear. Not sure, how much ICQ itself also is an issue here: one observation is that with some contacts forwarding between classic (OSCAR) and new (WIM) ICQ works, including showing a correct online list, with others only WIM/WIM communication works, losing any signaling between WIM and OSCAR in those cases (messages, online status). (Personally, I can still log in and use OSCAR-based ICQ; a friend of mine can't -- with him, OSCAR/WIM crossover works, with another contact that crossover doesn't work.) Side note: 1) It seems that the icyque/WIM logins are somewhat "sticky" and create orphaned sessions only deletable from the web interface if not logged-out correctly (e.g. by simply suspending the machine -- with the next resume a new connection is created). 2) At least for me (pidgin 2.13.0/Linux) there's the issue that I cannot properly log out from icyque (Accounts -> disable) -- Pidgin then just crashes. The only way to disable after enabling is manually setting autologin to 0 in accounts.xml; might or might not be related to 1). Rainer

[buchty]

Some more observations and a partial solution:

1. The dupe problem isn't fully fixed as others already pointed out, leading to occasional dupes. Resultingly, OTR sometimes works, sometimes doesn't (mostly doesn't, it seems). I went for pidgin-encryption for the moment, as that seems to work somewhat reliably, once the key is exchanged.

Interestingly, with pidgin-encryption, dupes will appear as a base64-encoded message following the cleartext message, i.e. first the cleartext is printed, then the base64 ciphertext follows. This seemingly continues as long as the encryption isn't active on both ends. Once pidgin-encryption established a stable encryption on both ends, I haven't seen any dupes anymore for as long as the secure connection stays active, i.e. typically until the next timeout. Because ...

2. ... there seems to be a timeout issue: my icyque-using contacts frequently (as in every 60 seconds) vanish from the online buddy list, displaying logoff messages in the chat window, just to typically hop back to online immediately. Same seemed to happen with me, as reported by one of my ICQ contacts.

Checking the debug log on my side reveals "blist: Updating buddy status for (icyque)" followed by "g_log: purple_status_is_online: assertion 'status != NULL' failed" and an immediate URL fetch from bos.icq.net for these falling off/on contacts.

Looking into the JSON response string shows { "fetchTimeout": 60 }. The only timeout I found in the source are a session timeout of 365 days and the heartbeat timeout of 240 seconds. Knowing nothing about the innards of Pidgin, I bluntly set that to 59 seconds and tried it with my own account and two contacts on different machines. The above assertion fail is gone for all three cases, also showing no off/on hopping of those contacts anymore.

If others want to try, too, change in libicyque.c:
purple_http_request_set_timeout(request, 240);
to
purple_http_request_set_timeout(request, 59);

I guess, best practice would be parsing the response and updating the session timeout accordingly to stay in the range [timeToNextFetch:fetchTimeout].

[Darkcleod]

I don't know what the rule is on commenting on issues that are still listed as "Open" but haven't been commented on in over a year, but here goes.

Using Pidgin 2.13.0, and whatever the current (as of a month ago) version of IcyQue (ICQ WIM). But, this is still an ongoing thing, at least for me. About 95% of the messages I send using the ICQ protocol duplicate on my end, but the recipient (and the mobile client) only show it once.
Very rarely, a message won't duplicate, but most of the time, it will.