igniterealtime/openfire-monitoring-plugin

Searching archive for one-to-one chats

Opened this issue · 2 comments

When querying the message archive for an individual user, the result set contains both chat and groupchat messages.

As XEP-0313 states, "a server SHOULD include in a user archive all of the messages a user sends or receives of type 'normal' or 'chat' that contain a element. A server SHOULD also include messages of type 'groupchat' that have a " so this behavior is quite understandable.

However, XEP-0313 also mentions "but where such history is accessible through another method (e.g. through an archive on the MUC JID), a server MAY exclude these from the archive."

If the plugin has been configured to both "Archive one-to-one chats" and "Archive group chats", would that exception be valid so that asking for messages of an individual user, only messages of type 'normal' or 'chat' would be returned?

Currently, we are trying to show, say, 25 previous messages between two users in a private chat but it is hard to accomplish as in the worst case scenario, we would have to go through the entire message history of the other user to determine if there even are 25 such messages to begin with. Or can this be accomplished in some other way?

I ran into this myself earlier. It really is a bit of an annoying issue. I'm feeling that you'd typically want to exclude the group chats, but:

  • the current implementation, as you found, is compliant with the specification
  • changing things around will undoubtedly make some users happy, but also break things for others

Still, I'm open to the argument of removing group chat messages from the one-to-one archives - perhaps under some kind of new configuration flag. I'd like more feedback though (also, looking at what other server-implementations do would be good, as to contribute to a level playing field in the larger XMPP ecosystem).

Although not a fix for the more generic issue, searching for a chat with a specific other user might benefit from using the 'with' field. My expectation is that that would sufficiently filter the results.

In general, the specification requires the implementation to support at least filters start, end, and with, optionally also before-id, after-id, and ids. I'd say the best approach to avoid unwanted changes in existing systems would be to introduce a new one to toggle whether this kind of approach should be used or not, especially as the specification also states "Other fields may be used, but are not defined in this document".

At the moment, we're looking into the option of just writing our own Openfire plugin (depending on Monitoring Service) to support some custom stanza we can use to query only the private chat messages from the ofmessagearchive table but that is admittedly not the optimal solution at all.

I also briefly looked at the code of this plugin to see what kind of changes would be required to implement the filter functionality as part of this plugin but I lack too much experience and confidence to actually propose anything tangible for the time being.

Edit: Maybe something like strictWithJid (true|false) which, when with is also used as a filter would exclude any message not shared by the caller and the JID specified with with filter?

Edit x2: Just using with filter on its own is not a viable solution in the long run. If the user has written 10,000 messages in public rooms, we have to go through all of them (twice, for both participants) maybe only to come to a conclusion that no, there hasn't been any private chat messages between them before. Figuring that out puts a massive and needless strain on the plugin, the database, and XMPP on whole.