Bartek, please confirm but as far as I know this is not a bug, this is a feature.

The MUC protocol does not provide a way to solve this problem properly. Avoiding repeating last message on reconnect may cause that in some cases a message might be missed and never delivered. So I think it is better to receive last message multiple times than not receiving it at all.

As you said. XEP-0045 doesn't provide mechanisms to get messages after message we have. We can only get messages with time equals or greater that our last message has.

It did not know that it did not bear it the protocol... Some customers do not repeat the last entrance...I thought that it was a bug. I'm sorry

Yes, we are working on some solution for that. It would be a non-standard as MUC does not offer in protocol anything for that but it will be solved in one of next versions.

There is no way to do that without modification of protocol. We can extend our MUC Component but this protection will not works with others MUC.

Bartosz Malkowski wrote:

There is no way to do that without modification of protocol. We can extend our MUC Component but this protection will not works with others MUC.

As it was stated - other clients (Conversations, I'm looking at you) don't manifest this behaviour so I think this is definitely feasible.

A while back there was a problem with MUC and (I think) osx Messages hence https://projects.tigase.org/projects/tigase-muc/repository/revisions/74ec9be997bbd38d439a7f6be27b21a55371be40 and https://projects.tigase.org/projects/tigase-muc/repository/revisions/70c1eccdbc337d2470b6c2600a41cb2ca2bf148d so one simple solution could be to store last message ID (s?) and while re-connecting and asking for messages equal or newer than the last message date we can filter the message if it matches latest received ID?

Alternatively we could trace what Conversations is doing...

To be hones this was one of the most frustrating things that made me drop Messenger

Sure… But message ID isn't obligatory, so it will works with us MUC and not necessarily with others.

Yes, but given there is no solution in the specification (or we are missing something obvious?) and this should work without modifying further MUC component I think we could use it.

Also - for some reason Psi doesn't receive any repeated history during reconnection but I haven't looked into it further.

What about storing some kind of a hash calculated on the last message stanza? Then it does not matter if it has an ID or not we could detect duplicated message. In any case, it is always worth investigating or asking how others do it.

Then Messenger skips three the same messages sent one by one.

Isn't this resolved in 3.x version?

Yes, it is resolved in 3.0