Hello. I have noticed that Conversations App is showing some XEP-s, that are unavailable. These XEPs are required to meet XMPP Compliance (e.g. https://compliance.conversations.im/server/conversations.im/).
Could someone tell me how to enable those, or if they are supported at all? Thanks.
XEP-0352: Client State Indicator
XEP-0357: Push
XEP-0368: SRV records for XMPP over TLS
Openfire doesn’t support XEP-0352 (technically, it could support it, but it doesn’t actually reduce any traffic, so we didn’t bother advertising support).
Push Notification support can be added by installing the Push Notification plugin (which is in an experimental state at the time that I’m writing this).
XEP-0368 should be green if you add the corresponding DNS SRV records. https://github.com/igniterealtime/Openfire/pull/1450 adds a change that will cause Openfire to better guide administrators creating the required records.
Work is ongoing (https://issues.igniterealtime.org/browse/OF-1838, https://issues.igniterealtime.org/browse/OF-1839) to get more of the compliance suite checks green in the future.
I noticed that for example Conversations app has Push working fine even without a plugin. Is that normal? Is this plugin helping other clients, that dont have in built notifications, to push notifications or what does it actually do then? Cheers.
Conversations tends to sit in the memory when you exit it. I think there is a setting to turn that off or your device might have a setting to remove it from a white list in memory saving. You can test this by rebooting your device, not opening Conversations and sending a message.
I finally managed to install Let’s Encrypt certificate! So i was able to run the Compliance test, not just look into Conversations App server info.
These are my results:
I know how to fix the “XEP-0368: SRV records for XMPP over TLS” - the DNS hasn’t refreshed yet, so hopefully this one should be fine.
I also can switch the In-Band Registration, which fixes the “XEP-0077: In-Band Registration” fail.
This is a list of XEPs that still don’t work:
XEP-0153: vCard-Based Avatar (MUC) - I have installed the “Avatar Resizer” plugin, clearly this has nothing to do with this XEP, so it did not help;
XEP-0352: Client State Indication - It still would be nice to implement this, for a peace of mind, and full 100% compliance…
XEP-0357: Push Notifications - Now this one is tricky. I have the plugin, Conversations App shows its available, but Compliance test says it’s not. Any idea why?;
XEP-0398: User Avatar to vCard-Based Avatars Conversion;
XEP-0411: Bookmarks Conversion;
XEP-0157: Contact Addresses for XMPP Services (Abuse);
XEP-0156: Discovering Alternative XMPP Connection Methods (HTTP);
XEP-0363: HTTP File Upload (CORS Headers).
Could someone help the developer team to implement all these XEPs into OpenFire, so we could hit 100% and all be very proud of ourselves? 
Avatar Resizer is not needed in the current version of Openfire, its function is already included in the code.
Please note that the compliance checker checks for compliance, primarily with the Conversations client. On top of that, Conversations works pretty well without all boxes ticked.
I’ll not engage in an effort to blindly work until everything is green, for the sake of it being green. CSI, for example, will probably never be green, as, apart from advertising support for the feature, it doesn’t actually do anything
Note that enabling in-band registration opens up your server for abuse by people generating spam accounts. You should limit registration to trusted parties, to be safe.
This is a list of XEPs that still don’t work:
These are currently unsupported in Openfire.
This should work with the PushNotification plugin. I’m unsure why it’s not working for you.
Currently unsupported.
Manasse is working on fixing these. Support was already in Openfire, but was not advertised in the way that the compliance suite tries to detect them.
This can be fixed by hosting the required content on a webserver that’s running on the same domain as Openfire. Not much that Openfire natively can do for this, I think.
This should work after installing the File Upload plugin.
guus: how do you sleep at night when not everything is green?
Just joking Your’e right, I undertand.
interesting thing, the XEP-0368: SRV records for XMPP over TLS did not change, even after DNS has mitigated. Is there a difference between TLS and Not TLS? How do i make those records TLS?
XEP-0357: Push Notifications - I think it does work, but the Compliance doen’t pick up for some reason.
XEP-0363: HTTP File Upload (CORS Headers) - I do have HTTP file Upload plugin installed, I’m not sure what are those “CORS Headers”, maybe it’s also working as it should, but Compliance doesn’t pick up that as well for some reason? If I would know what that is, I could test it.
Thanks
Regular DNS SRV records:
_xmpp-client._tcp.example.net. TTL IN SRV priority weight port target
_xmpp-server._tcp.example.net. TTL IN SRV priority weight port target
DNS SRV records for XMPP over TLS (XEP-0368):
_xmpps-client._tcp.example.net. TTL IN SRV priority weight port target
_xmpps-server._tcp.example.net. TTL IN SRV priority weight port target
You need all four.
It took me a few minutes to spot s in xmpps 
CORS headers showing fine in Compliance after enabling feature in Openfire Admin Panel.
Has anyone experienced message retrieval issues?
I have tested a bit group chats and private messaging. With Gajim and Conversations clients. It seems sometimes, when chatting one user can see its own and other persons messages, but other user, in this case Conversations client user, does not retrieve messages that Gajim user has sent.
This seems to be independant from OMEMO usage. It seems to be a server issue. Or maybe Push problem? Or something to do with Message Archive Management?
To retrieve messages I have to quit and reopen Conversations App, and then after 6-8 seconds all history and unretrieved mesages appear in the dialogue.
Any ideas what could be causing this issue?
Also this issues has to do with HTTP File Upload feature. I noticed that SOMETIMES when I try to send something with this option to other user (doesnt matter from Gajim or from Conversations, the other user does not get the URL, and then after that the user who sent the file can type messages, but receiving user wont see them at all - its kind of stuck after this point. And it only can be fixed by restarting the client (of receiving user), then messages and sent files appear again (although sometimes they are not decrypted…). Weird stuff.
SOMETIMES even for the sender of file (in this case Gajim client) after this issue, the messages written afterwards are not printed on screen, and the only way to fix this is to restart Gajim. After that, logged into chat again i can see something like this:
[23:30:30] gajimtest2: This message was encrypted with OMEMO and could not be decrypted.
[23:30:50] gajimtest2: This message was encrypted with OMEMO and could not be decrypted.
It seems that file sending option in some way messes up the OMEMO, and thats why some messages sent afterwards are not visible to sender or receiver.
It seems that XMPP still has many many issues. I think the cause of this issue could be the same as of the earlier mentioned. Any ideas on this?
On the same note, the “XEP-0313: Message Archive Management (Multi-User Chat)” has dissapeared and doesn’t work anymore for some reason (Compliance says its unavailable).
I feel that all these weird issues are somehow related. What do you think?
Thanks
To add:
In a Compliance page, after the test, if I press on “XEP-0313: Message Archive Management (Multi-User Chat)” I will see this:
Note: These instructions are valid only for this particular server, because of the software running on it.
Monitoring Service plugin is enabled and archiving is on… Why doesn’t this work?
Since no one replied yet, I would like to add that “XEP-0313: Message Archive Management (Multi-User Chat)” shows as enabled after Openfire server installation and setup, but when I create a Group chat room, its compliance are gone.
Any ideas why?