This is not a bug. This is implemented like this intentionally to avoid offline storage overfill with unpredictable traffic with no real content in it. I understand that there are some use-cases where strong messages without body might be useful but this should be considered on case-by-case basis not as a general rule.

Bartosz, what do you think about it?

The problem is that real content doesn't have to contain a body as xmpp is extensible and message stanzas are the way to pass any kind of message.

In the current state of Tigase the only way to ensure that a message is passed is to add a dummy body element which is not really a solution.

I think we may add that feature, but we also have to add list of filters, to cut off for example chat states. If, after filtering, stanza has any child elements, then we can store it in database.

But let Andrzej (as author of Offline Storage Module) says what he thinks about it.

Right now out implementation stores only messages with body and this filtering came from consideration of messages as messages between users which needs to have body with some content to be of any value for end user. This is how messages were considered some time ago, but later other usages of messages appeared ie. as pubsub notifications, etc., which created situation in which event a message stanza without body might be of value (in pubsub notification event might be sent event to offline user) and this make it for some cases worth of storage.

But other "type" of messages (mentioned chat states or message carbons) should not be stored, which makes decision of whether to store a particular message stanza very complex. As for now it would be very difficult (but possible) to change current behavior and handle all border cases and exceptions of general rules of processing message stanza (and smart defaults for this logic would be a good idea), but we need to consider also XEP-0160: Best Practices for Handling Offline Messages which states what we should do for particular type of message but as an example it shows only a message with body which suggests that only messages with body element should be stored.

I should also mention that Tigase XMPP Server contains a limit for maximum numer of offline messages stored for single user (which by default is set to 100) and storage of other type of message would also increase load for each part of server and database as well and will easily exceed limit of offline messages which are allowed to be stored.

I also tackled this problem a while ago.

I wanted to implement custom messages in my client, with no body element. Then I found out that Tigase doesn't store those messages, so I just patched my client to add a dummy body element (DUMMY).

It would have been better if I could ask Tigase to store those messages somehow, or if Tigase was to store them unless they are blacklisted (Chat State for example).

Indeed, I think it would be good if we could specify in config file a list of namespaces for payload for which messages should be stored, or better yet, I think ideal solution would be if we had a special payload with namespace like: xmlns="offline:store" val="yes" or something like this. Then, we could control server behavior on the client side.

Is there any extension or spec which defines something like this?

If not, maybe we can create a custom extension?

I'm rather against adding custom namespaces to stanzas on client side to control behavior of offline message store, as it might be useful for people having custom xmpp clients but will not solve situations in which someone might want to change behavior of server but using standard client.

I think that we should rather add list of path+xmlns which if are matching then message would go to offline store (and maybe message archive as well), ie. something like this:

--store-messages=/message/body,/message/storeMe[custom_xmlns],-/message/event[http://jabber.org/protocol/pubsub]

which would allow storage of messages with:

• body element

• storeMe element with custom_xmlns as xmlns

and deny storage of messages with

• event element with xmlns http://jabber.org/protocol/pubsub

This is just an example, but then what we should do if both entries would match (one for deny and one for allow). How should we proceed in this case?

I think that if from example above we would only keep list of allowed path and xmlns then it would make sens.

We need to have path and xmlns as we need to distinguish messages from ie. messages being forwarded by message carbons. Also having path with xmlns would speed up check if particular message matches each rule.

There is a XEP for this already: XEP-0334: Message Processing Hints

However, it defines "no-store" and "no-copy" hints only, right now. But I think this is a good direction. We could add more hints: "offline-store" and possibly some others...

Your suggestions is good as well, and I think ideally we could have both solutions.

I added support for setting list of paths and xmlns which should trigger storage of packets to offline store.

It can be set as:

sess-man/plugins-conf/amp/msg-store-offline-paths[s]=/message/received[urn:xmpp:receipts],/message/store-offline

which will result in storage of:

• message with received subelement with xmlns set to urn:xmpp:receipts

• message with store-offline subelement without checking for xmlns

Support for Message Processing Hints still needs to be added.

Added support for XEP-0334 Message Processing Hints