Duplicated messages displayed on Pidgin 2.14.5
LurkerHub opened this issue · comments
Please see log and transcript on https://paste.ee/p/jkhOd
hi @LurkerHub, thanks for the report. i had a look and it seems to be a weird interaction between different XEPs.
a copy of the sent message is indeed returned to you, however that would be a server bug:
When a client sends a eligible for carbons delivery, its sending server delivers the according to RFC 6120 and RFC 6121, and delivers a forwarded copy to each Carbons-enabled resource for the matching bare JID sender, excluding the sending client.
(see https://xmpp.org/extensions/xep-0280.html#outbound)
one thing that stands out to me is an added element in the received copy of the sent message:
<archived by='lurker@myserver.example' id='1623108659343108' xmlns='urn:xmpp:mam:tmp'/>are you using a plugin for MAM?
It's even weirder than it looks.
- It only happens with 2.14.5, not with 2.14.4 (and I never experienced it with any earlier version)
- I could not reproduce it when I disabled all the accounts on other protocols. Once I re-enabled them the issue came back.
To answer your questions:
No, I do not have a MAM plugin (that I know of).
The list of plugins that I have is here: https://paste.ee/p/EjjGQ (sorted)
If it was a server bug, why would it only manifest with the latest Pidgin version?
one thing that stands out to me is an added element in the received copy of the sent message:
<archived by='lurker@myserver.example' id='1623108659343108' xmlns='urn:xmpp:mam:tmp'/>
That should be normal. The server I use keeps a copy of the messages for x days.
If it was a server bug, why would it only manifest with the latest Pidgin version?
That is a good question. Did you downgrade and it never happened any more, but it still happens consistently with the newest Pidgin?
All I can say is that according to the specification, a message is not to be carbon-copied to the sending client by the server (the part that I quoted, especially the last sentence). You can see that this is the case in the log you linked because the message came back wrapped in a <sent xmlns='urn:xmpp:carbons:2'> element.
The only way I can think of to prevent this is to add state to the client, maybe remembering sent message IDs and ignoring them if they come back. In your case, this would help, because both messaged have the ID purpled0c8ce3f. However, I am not sure adding this complexity to work around something that should not happen is something I'd like to do at this point. Do you maybe have another suggestion on how to work around this?
It sorted itself out.