Chatmarkers are not saved to Archive!
Opened this issue · 5 comments
Messages without body-tag are currently not saved in the archive.
However chatmarkers (XEP-333) should be saved, because if a client requests messages from the archive without or a cleared local history, the user can currently not see whether his messages were delivered / read / ... by the opponent or not..
XEP-0313 allows it:
6.1.1 User Archives
A user archive is anticipated to provide the user with the ability to access their prior conversations. To this end, 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 , 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.
A server MAY include additional non-conversation messages.
A server MAY include messages of type 'headline', but this is not generally suggested.
At a minimum, the server MUST store the elements of a stanza. It is suggested that other elements that are used in a given deployment to supplement conversations (e.g. XHTML-IM payloads) are also stored.
Other elements MAY be stored.
There is a problem here that in a groupchat of (say) 50 people, to show 20 messages in the scrollback means pulling 1000 messages from MAM. This is pretty painful over a high latency link. I intended XEP-0437 to address these concerns.
There is a problem here that in a groupchat of (say) 50 people, to show 20 messages in the scrollback means pulling 1000 messages from MAM. This is pretty painful over a high latency link. I intended XEP-0437 to address these concerns.
Normaly clients wont request all messages at once, they should use paging functionality as best practice...
Maybe we could limit saving chatmarkers to messages with type "chat" only
Well, our clients do not request all messages at once of course, but on high latency links, that just means lots of MAM queries, each costing 1xRTT.
To clarify, I'm not saying "Don't do this", because we do, and it's useful. But it has severe downsides and it might be worth considering making it an option at best.
To clarify, I'm not saying "Don't do this", because we do, and it's useful. But it has severe downsides and it might be worth considering making it an option at best.
Yes an implementation with option to enable/disable this function would be the best