lovetoxAs explained under , when a new occupant joins the room the room SHOULD include the last subject change after the discussion history.
lovetox> As explained under , when a new occupant joins the room the room SHOULD include the last subject change after the discussion history.
lovetoxSHOULD is wrong here in my opinion
lovetoxthere is https://xmpp.org/extensions/xep-0045.html#order
lovetoxand its a MUST
Ge0rGlovetox: MAM doesn't solve the problem of seamlessly switching between history and live messages.
Ge0rGI never understood why I'm the only one bothered by that
lovetoxwith deduplicating this works fine
Ge0rGIt's an ugly hack.
Ge0rGAnd you need MUC history for the dedup
lovetoxGe0rG, i think its a very low priority problem
lovetoxliterally never seen a issue regarding that
Ge0rGOr you need to fill the gap after receiving the first message after you joined.
Ge0rGlovetox: you don't see the issue because it's a race condition that's not happening often, and users are used to xmpp losing messages
lovetoxim not sure i see the problem, i join i request 0 history
lovetoxi receive a live message
Ge0rGWhen do you fetch MAM?
lovetoxi request MAM, and sort all messages into my chat view according to the timestamp and order i receive from MAM
Ge0rGBut when do you request it?
lovetoxafter successful join
lovetoxafter the subject
Ge0rGAnd you request everything after the last message you had in MAM before starting the join?
lovetoxjoin -> receive subject -> request MAM
Ge0rGRequest MAM with which parameters?
lovetoxthe last stanza id i received, of course between receive subject and MAM request finished, i dont record ids
lovetoxand the last mam page gives me all the live messages received while i fetched mam
lovetoxso its fine at the end
Ge0rGThat sounds a bit racy
lovetoxthis would need to be answered by a server dev
HolgerIt's definitely racy 🙂
lovetoxi dont see it
HolgerMaking this non-racy would require some cluster-wide locks server-side.
lovetoxi receive the last mam page with the last message then i record that stanza id
lovetoxat that moment im definitly fine
HolgerWell maybe I misunderstood. What I understood was: You issue a MAM-request, wait for the response, and effectively throw away any live messages received while you're waiting for the MAM response to be completed, right?
lovetoxno message is dropped
Ge0rGThat's also what I understood
lovetoxno i don’t record ids
HolgerThem I misunderstood "of course between receive subject and MAM request finished, i dont record ids".
lovetoxnormally when a live message comes in
lovetoxyou have to record the id
lovetoxthis is now your last stanza -id
Ge0rGWhat does it mean?
lovetoxfor your next mam request in the future
HolgerSo while MAM is in action, you process both the MAM response and the live messages, and you de-dup.
lovetoxthe not recording ids of live messages while a mam fetch is in progress is for stuff like
Ge0rGSo worst case is that you'll request more messages from MAM if the join was aborted
lovetoxwhen the mam requests aborts in the middle or something like that
Ge0rGBut you do record the stanza IDs of the MAM results?
lovetoxpoint is, as long as im not receiving a complete=true with stanza id
lovetoxi display all live messages, but i dont record stanza-ids
lovetoxwhen im in sync (complete=true) every muc messges moves the last-stanza-id
Ge0rGSomebody should write down all these dirty tricks
emus! I told you guys we need a "Did you know?" section in the XMPP Newsletter
Ge0rGLike using MAM to apply stanza IDs to your previously sent messages, or when to advance the last ID