One-way communication for some but not all users

Openfire
1

This has been plaguing our network for quite a few years, according to notes.

Some users are able to send to everyone, whether their OMEMO or OTR is enabled or not.

Other users are only able to respond when their OMEMO or OTR is disabled.

Yet other users are not able to respond at all.

The only way to solve that is usually by switching them from one client to another. We use several: Gajim and Pidjin on Windows and Linux and Conversations and Yaxim on Android. The most plagued clients are Pidgin and Gajim, in this order.

We also looked into ConverseJS but found that it has many worse issues, so it’s not in production use. I run it mostly but not our users. It is also affected by this one-way issue.

A segment of my users was fixed by upgrading their OS, but this is generally problematic, due to our organization’s budget or rather lack of it: it’s non-commercial and relies on donations, so people volunteer whatever they can procure.

Having said it, is there anything else I can do to enable everyone to send and receive reliably?

2

Hi Tago,

Thanks for sharing the details, that is very helpful. Before digging deeper, could you please clarify what you mean by “not able to send to everyone”?

For example:

  • Does their client not even allow typing or sending a message?
  • Or can they send a message, but it never reaches the recipient?
  • Or does the message arrive, but the recipient cannot decrypt it (for example, they see an unreadable encrypted blob)?

This distinction would help narrow down whether the issue is on the client, transport, or encryption layer.

In the meantime, it would be good to make sure that everyone is using the latest versions of their clients, such as Gajim, Pidgin, Conversations, and Yaxim (if still in use). Several of the problems you described, particularly around OMEMO key handling and message synchronization, have been addressed in more recent releases.

Also, just as a side note, OTR and OMEMO are not compatible encryption mechanisms. Messages encrypted with one cannot be decrypted by the other. So if some users are on OTR and others on OMEMO, that would naturally cause one-way message issues.

Finally, it might be worth testing whether any account-specific server state is contributing to this. You could have affected users create a brand-new account on the same Openfire server and see if the issue persists. If the new accounts can send and receive normally, that would suggest that some old or inconsistent data, such as device lists or PEP nodes, is causing problems on the existing accounts.

Let me know what you find. Those details will help pinpoint the next steps more precisely.

3

I would not bring client UI problems here where they do not belong.

The issue is that the senders are sending, and the client confirms, each in their own way, that the message has been sent, but the recipient never receives the message. Most of the time this is happening all along the other side gets the “Typing…” notification but not the actual instant messages.

The decryption issues are secondary to this, and we should look into that only after the plain-text part of it is figured out because even plain-text messaging absent any encryption is affected.

Example: client A’s messages are never received by client B, all the while B has no problem sending to A, C, or D and A has no problem sending to C or D. Some clients are cursed and cannot send to some others while receiving their messages successfully. I don’t know how else I can put this.

4

Thanks for the detailed description, that’s very helpful.

At this point, it would be good to determine where exactly the messages are getting lost in transit. There are three main possibilities to consider:

  1. The message never actually leaves the sender’s client.
  2. The message reaches Openfire, but isn’t relayed to the recipient.
  3. The message is delivered to the recipient’s client, but isn’t displayed for some reason (for example, a parsing or decryption failure).

To find out which of these applies, you can enable XMPP-level debugging on both the sending and receiving clients. Most clients (like Gajim and Pidgin) allow you to view the raw XML stanzas that are sent and received. Check whether the outgoing message stanza appears in the sender’s log, and whether it shows up as incoming on the recipient’s side.

On the server, you can also use the Monitoring Service plugin to inspect the message archive. If the message appears there, that means Openfire received and relayed it correctly. If it doesn’t show up, then the problem is likely between the sender and the server.

It might also help to reproduce the problem with a new account. Create a brand-new user on the same Openfire server (using a fresh client install) and test communication with one of the affected users. If the new account can send and receive messages normally, then the issue is likely tied to the original account’s state, for example, stale device lists, resource priorities, or roster data.

Similarly, take one of the problematic client setups and try it with a known-good account. If the issue follows the client rather than the account, that points to a local configuration or client-specific problem instead.

These tests should help narrow down where the issue originates, client-side, server-side, or account-specific, and give us a clearer direction for further troubleshooting.

5

The sender’s client sends successfully.

The message ends up being lost somewhere between the server and the recipient’s client.

In the monitoring plugin, I can see them reply, but the recipient never gets their IMs, only sees them typing. If the typing notification passes, then the message has to pass. I see no valid reasons for it not to.

Sorry to be blunt, but if XMPP has this ability to screw up due to the above, then it’s design is wrong. Look at Zoom, Teams, WhatsApp, Telegram, or whatnot. That is unheard of, in their world. This is how it is supposed to work/be: nothing stops the flow of messages. If XMPP thumbs it’s nose away from its users, for trumped up reasons such as stale whatever, then it’s design is horribly wrong. “Messages shall pass” has to be its motto, not “none shall pass”.

6

Thank you for all the detailed testing and observations. It’s clear you’ve invested significant effort into understanding this problem, and I fully appreciate how frustrating it is when messages appear sent but do not reach their recipients. It’s also worth noting that others have reported similar one-way messaging issues. This is an elusive problem: developers have so far been unable to reliably reproduce it, which makes analyzing and resolving it challenging.

That said, I need to address the tone of some of your posts. While your frustration is understandable, language that broadly dismisses XMPP or the people helping here can discourage contributors. Some community members have already stepped back because of this. Let’s keep the discussion constructive so others feel safe to participate.

Now, about the issue itself: I want to clarify that what you’re observing is not evidence that the XMPP protocol is inherently flawed. In fact, XMPP remains one of the most battle-tested and widely deployed messaging technologies in the world. Two of the very products you mentioned as more “reliable alternatives” - WhatsApp and Zoom - both use XMPP internally (albeit with heavy customisation). That alone shows the protocol itself is perfectly capable of supporting dependable, large-scale messaging. The challenges here are more likely due to interoperability quirks, specific client or server implementation bugs, or complex account/state interactions in a diverse open ecosystem.

Unlike the “reliable alternatives” you mentioned, we don’t have the luxury of a dedicated team of developers maintaining a single ecosystem. Our strength lies in the community itself, and only through collective focus, collaboration, and shared expertise can we effectively confront elusive issues like this.

1 Like
7

You are absolutely correct that XMPP protocol does not have an inherent flaw, but the beauty of the real world is that no one is under obligation to care. Users simple do not care, and this is not about to change.

Also, it is great that there is understanding that alternative server implementations are not having this issue. I had no idea that WhatsApp or Zoom use XMPP, for the reason above: they work, and I and a couple more billion users do not care and do not have to. But since you mention this, it simply points at OpenFire as the root cause of this problem.

How about this: you break the silos that all of the collective “you” exist comfortably in, “you” being the developers of XMPP servers and clients? This can be done by your team members registering in the client developers’ resources (Discourse, github, etc.) and raising this issue in each of them, with an invitation to a round table on this issue, so as to collectively share info and ideas and finally come up to a solution that will benefit all of the collective “you” and collective “us”, the latter being users. Because the collective “we” have been raising it for decades but only being stonewalled and shoved off due to this issue being “elusive”.

No one doubts that in the existing zoo where client developers are happy in their own silos and do not talk to the server developers who are also happy in their collective silos and do not talk to client developers, the issue remains elusive.

If status quo remains, your users will continue to silently migrate off to commercial messengers, without you knowing. It is only underpaid and overworked admins like me who bring these issues up, when we are fed up. I am already under tremendous pressure from my user base to ditch Jabber and go Teams. If budget ever permits, I will be told to. I am so tired and fed up that I will happily do so. I would have, long time ago, had I a budget for that. I don’t know why I even bother bringing this up, considering all of the stonewalling by everyone of the collective “you” who, without exception, demonstrate zero interest in ever getting to the bottom of this and 100% interest in having me shut up.

I do not care that “Some community members have already stepped back because of this.” That’s all they are ever willing to do.

8

First, thank you for continuing to engage on this issue and for explaining your experience so clearly. It is entirely fair to say that this kind of message loss is serious and frustrating. It undermines user trust and puts pressure on administrators like yourself, so yes, it absolutely deserves to be investigated further. Openfire may well be part of the problem, and it is right that we keep that possibility open as we look for a cause.

That said, I want to speak to the way the discussion is unfolding, because tone matters here not only for you and the people replying, but for everyone reading this thread.

The repeated framing of “you” versus “we” where “you” are the developers and “we” are the users does not reflect how this community operates. Openfire and the wider XMPP ecosystem are built and maintained by a small number of volunteers. There is not a paid team sitting behind this project, and there is not a company with a budget to assign people full-time to solve issues. The project exists because people care enough to contribute their time freely. That means there is not a “you” to blame and a “we” to suffer, there is only us, trying to improve a shared tool.

The community’s responses to you so far have intended to follow that spirit: help us find the cause so we can fix it together. Developers and other contributors have been engaging in good faith, asking clarifying questions and exploring possible causes. When frustration replaces collaboration, it risks pushing away the very people who are trying to help, and that hurts everyone who depends on the software.

It is worth remembering that while large commercial platforms like Teams or WhatsApp can dedicate entire paid teams to handle issues, that comes with a cost both literally and in terms of control and openness. Openfire and XMPP offer something different: transparency, flexibility, and the ability for anyone to help improve them. But that model only works when discussions stay constructive and mutual respect is maintained.

No one here is dismissing your concern or minimizing the impact you are seeing. The community takes this problem seriously, it is just that solving elusive, multi-component issues requires patient cooperation from everyone involved. When conversations remain focused on data, logs, and reproducible cases, this community is at its best.

Your experience and perspective are valuable, and by engaging with the discussion collaboratively, you help ensure that the volunteers who maintain Openfire can respond effectively. Let us treat this as a shared challenge, where all participants contribute to improving reliability, rather than as a conflict between “you” and “us.”