[OMEMO] Psi XMPP Client does not work correctly with all Openfire XMPP based Servers

[Neustradamus]

Dear @psi-im team, @psi-plus team, @Ri0n, @Vitozz, @tehnick,

There is an historical OMEMO bug with Openfire XMPP based Servers, this one for example: https://igniterealtime.org/.

Example (2 XMPP Accounts on 2 different XMPP Servers: jabber.org and igniterealtime.org):

• user2@igniterealtime.org has OMEMO fingerprints of user1@jabber.org (GOOD)
• user1@jabber.org has not OMEMO fingerprints of user2@igniterealtime.org (NOT GOOD)

Example 2 (2 XMPP Accounts on same XMPP Server: igniterealtime.org):

• user1@igniterealtime.org has not OMEMO fingerprints of user1@igniterealtime.org (NOT GOOD)
• user2@igniterealtime.org has not OMEMO fingerprints of user1@igniterealtime.org (NOT GOOD)

Can you look it?

---

No problem with all other XMPP Servers: ejabberd, Prosody IM and Tigase XMPP Server.

---

IMPORTANT and STRANGE: it has not been tested by me but some people said that OMEMO works without any problems with Openfire and another XMPP Clients.

---

EDIT: I have done all diagnostics about it: Openfire has a problem with PubSub/PEP and not only for OMEMO, but it is linked to all <message to="user@domain.tld/client" from="user@domain.tld" type="headline">:

<items node="http://jabber.org/protocol/activity">

<items node="http://jabber.org/protocol/mood">

<items node="http://jabber.org/protocol/tune">

<items node="http://jabber.org/protocol/geoloc">

<items node="eu.siacs.conversations.axolotl.devicelist">

<items node="urn:xmpp:avatar:metadata">

At the same time, it has been missing:

<feature var="urn:xmpp:bookmarks:1#compat"/>
<feature var="urn:xmpp:bookmarks:1#compat-pep"/>

All details in my following comments.

---

Note: This ticket has not been published several years ago.

cc: @stigger, @stokito (a recent contributor).

[Neustradamus]

Dear @igniterealtime team, @guusdk, @akrherz, @Fishbowler, @Flowdalic, vanitasvitae (untagged), @dwd,

After several log checks, I have found a missing part for OMEMO in Ignite Realtime Openfire XMPP Server (Smack included), there is no:
<message to="user@domain.tld/client" from="user@domain.tld" type="headline">

-> https://xmpp.org/extensions/attic/xep-0384-0.3.0.html#usecases-discovering

It can be like this:
<message to="user@domain.tld/client" id="XXXXXXXXXXX" from="user@domain.tld" xml:lang="en" type="headline">
<message to="user@domain.tld/client" from="user@domain.tld" xml:lang="en" type="headline">

ejabberd, Prosody IM and Tigase XMPP Server have good one.

---

More details, in this OMEMO case, XMPP Servers:

ejabberd:
<message to="ejabberd@server.tld/client" from="ejabberd@server.tld" type="headline">

Prosody IM:
<message to="prosody@server.tld/client" id="XXXXXXXXXXXXXXXXXXXXXX" from="prosody@server.tld" type="headline">

Tigase XMPP Server:
<message to="tigase@server.tld/client" id="XXXXXXXXXXXXXX" from="tigase@server.tld" type="headline">

Openfire:
Nothing

---

For a contact (in roster or contact list):

Openfire is good*:
<message to="openfire@server/client" id="XXXXXXXXXXXX" from="contact@domain.tld" type="headline">
<message to="openfire@server.tld/client" from="contact@domain.tld" type="headline">

Prosody IM:
<message to="prosody@server.tld/client" id="XXXXXXXXXXXXXXXXXXX" from="contact@domain.tld" xml:lang="en" type="headline">
<message to="prosody@server.tld/client" from="contact@domain.tld" xml:lang="en" type="headline">

ejabberd:
<message to="prosody@server.tld/client" id="XXXXXXXXXXXXXXXXXXX" from="contact@domain.tld" type="headline">
<message to="prosody@server.tld/client" from="contact@domain.tld" xml:lang="en" type="headline">
<message to="prosody@server.tld/client" from="contact@domain.tld" type="headline">

At the same time, it will be nice to harmonize in Smack/Openfire about "id" and "xml:lang".

---

Can you look it?

Thanks in advance.

[vanitasvitae]

@Neustradamus please stop pinging me.

I never used Psi-IM and I haven't contributed to Smack in ages, as you can very easily find out. Just stop it!

[Fishbowler]

Whoa, what is this??
This is not how to internet.

[Neustradamus]

@vanitasvitae: No problem, I have only added you here because the problem is not in Psi but in Openfire and Smack, and you have contributed for OMEMO, history here:

• https://github.com/igniterealtime/Smack/commits/master/smack-omemo/src/main/java/org/jivesoftware/smackx/omemo

And of course, thanks for your past contributions :)

[guusdk]

No problem, I have only [...]

This is where you are wrong. It is a problem.

It has been a problem for years and years. Several people, myself included, have tried in various ways to make you aware of the fact that some of your behavior is a big problem.

I am convinced that you mean well, but your methods, specifically the relentless talking to a broad range of people in private, in chat rooms, on issue trackers, all the while maximizing notifications to get attention to something that is important to you, is incredibly de-motivating for other people.

I have tried to make this clear to you at various times in the past, but apparently, I have been unsuccessful. Today, I don't know any other way to try and make you aware that this behavior is undesirable other than to be very, very blunt and take radical measures. From today, for projects that I take some responsibility for, I will try and make sure that the offending bits of your behavior will have the opposite effect of what you want it to have. This means that every time you increase the verbosity of your messaging, whatever topic it is that you try to get attention for will be pushed down on the priority list.

[Neustradamus]

@guusdk: You have requested details, I have taken several hours to check this historical problem.
Debug logs, between all XMPP Servers...

The ticket has been done here because it is not possible to create directly.

It is linked to a bad PubSub and PEP features in Openfire.

It is possible to create the ticket on Jira?
I understand that you will not solve it, it is not for me, I have not invited the bug.

Thanks in advance.

[dwd]

You can't just create a ticket on a different project and tag everyone you can possibly think of. This is not how to support this project, Openfire, or your own agenda. This is a perfect example of why so many projects simply ban you from creating tickets. It has, as Guus notes, the exact opposite effect from the one you (presumably) intend - and it has for years.

If you are actually trying to ensure that these bugs don't get fixed, and these features don't get implemented, then you're doing a perfect job.

[Neustradamus]

@dwd: Thanks for your comment.

Recall, this problem is not new and has never really looked by the Ignite Realtime team.
Several years after, I do the ticket with details, and now, like there is a ticket, it will be not looked.
Really strange but I have done the job: to create a detailled ticket, to easy understand and to find a fix.

Note: If I had not done tags to Ignite Realtime team members in this ticket, the Ignite Realtime team will not received the detailled problem to verify the problem...

It is a vicious circle.

Attention: This OMEMO bug is a security and a privacy problem: Should not be taken lightly.

[Fishbowler]

That's not true. You put the information in the Ignite muc. A majority are telling you this is unacceptable behaviour, and I suspect you'll find we don't all hold outlier opinions in this regard.

[Neustradamus]

Here more details: All examples which do not exist in Openfire:

<message to="user@domain.tld/client" from="user@domain.tld" type="headline">
<event xmlns="http://jabber.org/protocol/pubsub#event">
<items node="http://jabber.org/protocol/activity">
<item id="current">
<activity xmlns="http://jabber.org/protocol/activity"/>
</item>
</items>
</event>
<addresses xmlns="http://jabber.org/protocol/address">
<address jid="user@domain.tld/client" type="replyto"/>
</addresses>
</message>

---

<message to="user@domain.tld/client" from="user@domain.tld" type="headline">
<event xmlns="http://jabber.org/protocol/pubsub#event">
<items node="http://jabber.org/protocol/mood">
<item id="current">
<mood xmlns="http://jabber.org/protocol/mood"/>
</item>
</items>
</event>
<addresses xmlns="http://jabber.org/protocol/address">
<address jid="user@domain.tld/client" type="replyto"/>
</addresses>
</message>

---

<message to="user@domain.tld/client" from="user@domain.tld" type="headline">
<event xmlns="http://jabber.org/protocol/pubsub#event">
<items node="http://jabber.org/protocol/tune">
<item id="XXXXXXXXXXXX">
<tune xmlns="http://jabber.org/protocol/tune"/>
</item>
</items>
</event>
<addresses xmlns="http://jabber.org/protocol/address">
<address jid="user@domain.tld/client" type="replyto"/>
</addresses>
</message>

---

<message to="user@domain.tld/client" from="user@domain.tld" type="headline">
<event xmlns="http://jabber.org/protocol/pubsub#event">
<items node="http://jabber.org/protocol/geoloc">
<item id="current">
<geoloc xmlns="http://jabber.org/protocol/geoloc"/>
</item>
</items>
</event>
<addresses xmlns="http://jabber.org/protocol/address">
<address jid="user@domain.tld/client" type="replyto"/>
</addresses>
</message>

---

<message to="user@domain.tld/client" from="user@domain.tld" type="headline">
<event xmlns="http://jabber.org/protocol/pubsub#event">
<items node="eu.siacs.conversations.axolotl.devicelist">
<item id="current">
<list xmlns="eu.siacs.conversations.axolotl">
<device id="XXXXXXXXXXXX"/>
<device id="XXXXXXXXXXXX"/>
</list>
</item>
</items>
</event>
<addresses xmlns="http://jabber.org/protocol/address">
<address jid="user@domain.tld/client" type="replyto"/>
</addresses>
</message>

---

<message to="user@domain.tld/client" from="user@domain.tld" type="headline">
<event xmlns="http://jabber.org/protocol/pubsub#event">
<items node="urn:xmpp:avatar:metadata">
<item id="XXXXXXXXXXXXXXXX">
<metadata xmlns="urn:xmpp:avatar:metadata"/>
</item>
</items>
</event>
<addresses xmlns="http://jabber.org/protocol/address">
<address jid="user@domain.tld/client" type="replyto"/>
</addresses>
</message>

---

Linked XEPs:

XEP-0384: OMEMO Encryption:

• https://xmpp.org/extensions/xep-0384.html

XEP-0060: Publish-Subscribe:

• https://xmpp.org/extensions/xep-0060.html

XEP-0163: Personal Eventing Protocol:

• https://xmpp.org/extensions/xep-0163.html

XEP-0080: User Location:

• https://xmpp.org/extensions/xep-0080.html

XEP-0107: User Mood:

• https://xmpp.org/extensions/xep-0107.html

XEP-0108: User Activity:

• https://xmpp.org/extensions/xep-0108.html

XEP-0118: User Tune:

• https://xmpp.org/extensions/xep-0118.html

In more, it is missing:

<feature var="urn:xmpp:bookmarks:1#compat"/>
<feature var="urn:xmpp:bookmarks:1#compat-pep"/>

XEP-0402: PEP Native Bookmarks:

• https://xmpp.org/extensions/xep-0402.html

[Fishbowler]

Blocked user and unsubscribed.

Sorry Psi team - this must be rough for you too.

[Ri0n]

@Fishbowler, well sort of. I believe Neustradamus is trying his best but his vision of the engineering world is sort of different. In general engineers have their own plans for near future. But Neustradamus often wants things to be resolved immediately, pushing a lot on this.
Moreover if we talk about opensource free sw, it's often matter of having fun with the code, and some bugs can be postponed forever.

For example I find the real life more interesting and satisfying. and wrt Psi code OMEMO+Openfire compatibility is far to be the first priority. So likely I won't deal with this at least next few months. But it's hard to explain it to Neustradamus, even so he is still trying to do something good.

So instead of being hostile I chose tolerance.

[guusdk]

@Neustradamus, I can see you have put a lot of work into identifying and describing the OMEMO problem on Openfire. Your dedication is admirable.

What is preventing progress right now is your communication style, specifically:

• Sending repeated reminders and follow-ups.
• Tagging many people who are not directly involved.
• Posting the same message in multiple channels.

These actions generate a large number of notifications for many people. This does not speed up the work - it has the opposite effect. When contributors feel overloaded by repeated pings, they tend to disengage from the topic entirely.

To be open with you: this behavior is demotivating not only for others in the community, but also for me personally. It makes me less inclined to work on the issue, even when it is valid and important. Part of my responsibility is to protect both myself and the wider community from interaction patterns that drain motivation. My concern is that if this continues, it will drive people away from contributing at all.

Because of this, I will be stopping any progress on this particular issue. The way it has been communicated has made it harder, not easier, to address, and I do not want to set a precedent that this approach is effective.

For the future, here is the behavior that will lead to better results:

• Tag only the maintainers who are currently active in that specific project, or don't tag at all. New tickets and comments will already generate plenty of notifications for people that are interested in receiving them.
• Do not send repeated reminders unless you have new, relevant technical information to add.
• Keep all discussion about the issue in one single place.
• Allow time for maintainers to review before following up (which, as we mostly depend on volunteers, can sometimes be a very long time)

If these guidelines are followed, your reports will be easier to manage, and you will have a much higher chance of seeing them addressed.

[Neustradamus]

@Fishbowler: Strange attitude. I will explain the situation:
Please specify that to understand the problem, YOU have asked me if I have done all scenarios.
I have confirmed you that it has been verified with ejabberd, Openfire, Prosody IM, Tigase IM.
All tests have been done -> contacts between different XMPP based servers, etc.
The results is: all works except with Openfire.

The problem affects all XMPP clients which respect XMPP and XEPs.

YOU have requested me all details in private, so I have sent you all details before to add here in this good and only one public ticket (normally it must be in Ignite Realtime JIRA).

For you only, here, you have duplicate informations that you have already seen in private but it was not in a public ticket.

Recall, it is very important: this ticket has not previously done several years, it was only specified in the past in MUC Room and directly to dev team. It was not urgent, this important bug has been forgotten (no ticket).

---

@guusdk: Thanks for your comment and to confirm the work done to identify and to describe the problem liked to OMEMO and PEP/PubSub since several years, it was important to me to explain perfectly this historical bug to permit a fix :)

Yes, I do not need to publish on a MUC Room several log informations because on a MUC Room, it is not easy to find an information which has been published several years before.

It is for this, it exists since several years, different bug tracking systems (GitHub "Issues" section included):

• https://en.wikipedia.org/wiki/Bug_tracking_system

Note about it, there is Flyspray which is the initial bug tracker of the Psi project:

• https://www.flyspray.org/