We don’t care about the sender knowing that a message was received (not yet anyway!).
We need a way for a user who does not have the chat visible to see a status telling them they have unread messages…so they can go open the chat page (a dedicated client route, not a popup that is always visible).
The suggestion on Reddit was to use MAM, but they still talk about using Chat Markers, and AFAIK that XEP never got ratified and so is not available in Openfire.
We tested converse.js (which claims partial support for XEP-0333) and it has the same problem. It only sometimes works (like if the user has chat actually open, they see a counter of unread messages).
So how can we use MAM without Chat Markers to let the user know they have unread messages in these 2 cases:
they are in another part of the app, and chat window is not open
they go offline, come online BUT not into chat. Say they are on home page. How can we know that they have unread messages and tell them that?
Any code that people can point me to (javascript/typescript preferably) would be of great help. Thanks.
As an aside: a XEP not having reached a certain certification state won’t necessarily prevent us from adding support to Openfire. XEP-0333 Chat Markers currently having the state of ‘deferred’ does not mean that it cannot be implemented in Openfire.
I have to brush up on my understanding of that XEP, but does it actually need server-sided support? I guess the markers need to be archived (using MAM). I have not tested this, but won’t the Monitoring Service plugin do this by default?
Somewhat shooting from the hip here, but are you sure that XEP-0333 is the optimal answer to your problem? That XEP allows you to signal that a message (or a set of messages up to the one that you’re marking) has been processed. That’s related to detecting if there are messages that you’ve not seen yet, but that needs inferring. I wonder if you’re better served with something like XEP-0430: Inbox. To prevent you from getting your hopes up to quickly: That does require server-sided support, still depends on XEP-0333 and hasn’t been implemented for Openfire yet either.
Both of your described cases describe scenarios where the ‘chat is not open’. I’m not sure what exactly you mean by that: if it means “there is no XMPP connection”, then some kind of out-of-band solution needs to be deviced. For all other scenarios, the client can query for the data, in whatever protocol that we think of.
Luckily, Openfire is quite extensible, and allows for features to be added easily through its plugin infrastructure. You could even use that to go with a proprietary approach, instead of using the defined protocol extensions (although I do not recommend going down that path, as it often drags into lots of reinventing of wheels). If you’re not up to doing the development yourself, then there’s a list of professional partners on our website, that are likely willing to take a job like this on (for full disclosure: I’m on that list myself).
The long way around, but a more direct answer to your question: the client could record the last message in a particular chat, then retrieve messages from MAM, and compare that with the last message that was recorded locally. That will get you an unread count.
Thanks for that incredibly fast reply and all the details. I’m brand new to the XMPP world (last week!) so apologies for my poor explanation.
It does not help that I’m looking at code built by junior devs (who are also new to XMPP).
FWIW, my brief analysis of XEP-430: Inbox tells me you’re right — it seems that would solve the problem for us. My devs who wrote the code also said as much.
But I do believe you’ve actually nailed the issue — I think the XMPP connection is indeed not open when the user is online (but not actively chatting) and it should be. I think it’s only opening the connection if the user visits the actual route that the chat interface appears on.
If so, then fixing that and using MAM should be sufficient. I will check and respond in the next few days.
We have quite a backlog of chat-things to build, so I appreciate the link to the partners. I wasn’t aware that existed. Who knows what else we might need help with?
Hey @guus I just realised the other day that Dave Cripland was talking to you about me and my problem. Can we get on a quick call and see if we can work something out? You can book me on the link below. Cheers!
what else we might need help with?
