Man, so many weird requests these days There are no such feature and i don’t think Compression is about this. I don’t see how this can be implemented either (how the server should decide when to convert 1m messages to 1) and the server will still receive that 1 million messages, so it still be overloaded.
It seems that the OP is asking if the replies can be sent 1 to 1 rather than 1 to many. When each person replies they are replying to the original sender, plus all of the other people that were in the original message.
I have very limited knowledge on this, but it seems like a fair question.
If someone sends out to 2000 ppl “are you there”
then each person should only be replying to that original message, it sounds like the OP is saying that each reply then goes to each of the 2000 ppl.
Oh, i missed the “muc” part. Then this is even more complicated. In theory everything is possible. You will need to customize the server and the client. First, the server should wait for x seconds before sending the messages and collecting every message sent to muc into a bulk packet for every participant and then send such a collection to every client. So, instead of a million messages of 1 KB, server will send a thousand of messages of 1 MB after x seconds. You can further fine tune the mechanism, maybe it should add all such bulk messages into a queue and do not send them all at once. Anyway, in such case every message in the chat will be delivered with x seconds delay. Maybe this delay can be disabled for separate messages, but i don’t know how to tell server not to aggregate certain messages, because it can’t know in advance how many messages there will be in a row. As LG said, i’m not sure how this will affect the server. Keeping in RAM a thousand MB of bulk messages maybe even worse than sending a million of small messages. Then the client part. It should be customized to understand such bulk messages and “extract” them into normal separate messages in the chat window. Of course, there will be no compatibility with other clients then. Unless server will somehow check what client is in use and in other case will use standard technique.
Actually one can send MUC messages to only one client. With usual clients this s possible but not very comfortable as a new communication window is needed.
I’ve seen chat clients which mix private and public messages in the message window and have at the bottom 2-n input lines. One input line for public messages and the other(s) for private chats. Anyhow this would still require that the users make use of such a feature, some will prefer to answer to everyone so everyone sees that the user is still online / active.