GNOME Bugzilla – Bug 602953
Message from own nick are not echoed in XMPP MUCs
Last modified: 2018-05-22 13:52:29 UTC
Messages send to a MUC are directly copied from the text-entry. If a message is received from the server that with our nick it is not echoed. This has the following consequences: 1. XEP-0045 allows using one nickname from multiple resources. Messages from another resource using the same nickname are not visible/lost. 2. Servers can change the text you send before sending it back. This is sometimes used for bot-like tasks or just nonsense. E.g. xmpp:chef@funchats.babelmonkeys.de?join
One and a half year and nobody even bothered to confirm this. Any chance to get this fixed?
Some discussion about this on #telepathy: <cassidy> Do we guarantee that our messages sent to a muc are echoed back? see https://bugzilla.gnome.org/show_bug.cgi?id=602953 <wjt> they're emitted as delivery reports <wjt> but this is broken <wjt> i noticed another symptom of this the other day <wjt> https://bugs.freedesktop.org/show_bug.cgi?id=39630 <sjoerd> so gabble can't match up what we sent with what we received ? <wjt> exactly <wjt> cridland doesn't think it can rely on message IDs <wjt> actaully the weird one-nickname-from-multiple-resources thing almost convinced him to make M-Link behave like every other server ;) <sjoerd> hehe <wjt> We could fix https://bugzilla.gnome.org/show_bug.cgi?id=602953 by making Gabble track messages it's expecting an echo from, and any other messages from itself could be emitted as received as normal <wjt> server-messed-with-my-message is a weird case <sjoerd> as long as empathy can replace previous message it can deal with it by transforming it, but there will always be artifacts.. not sure if that matters though
FWIW, I actually don't want my (sent) messages to show up before I received them. It gives a false sense of them having been received by the groupchat too. This is AFAIK what about every XMPP-only client does. It only prints out the received messages, done. Is this hard to do for Empathy because it doesn't work this way for other protocols? As to the "weird case" statement. The swedish-chef one is more of an easy way to see it. More normal use-cases include word filters or automated pastebining as Prosody has it. In those cases the sender will probably want to know the changed message.
Another good reason for this behaviour is consistent message order. It's not uncommon in IRC for multiple participants to have different ordering of messages. XMPP's MUC behaviour specifically ensures that each occupant's client can display the same message log. IRC networks are one big race condition :)
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/empathy/issues/148.