Ge0rGWill MUC subject changes also be stored in a MUC's offline history and replayed on join?
Andrew Nenakhovhas joined
lovetoxnot to my knowledge Ge0rG
lovetoxthis would be akward
Ge0rGindeed
lovetoxim not sure why though, its just a gut feeling
lovetoxit would be weird in combination with MAM
MarandaNot replayed in history *shrugs*
lovetoxbecause if you join with max=0 history
lovetoxthen you still receive the subject from the MUC
lovetoxand afterwards you request MAM
MarandaIndeed
lovetoxand get a bunch of subject changes
lovetoxbut you have the timestamp so you could sort them correctly
Ge0rG> because if you join with max=0 history [..] and afterwards you request MAM
Are there potential race conditions between sync and live traffic?
lovetoxi dont think so because you have timestamps
lskdjfhas joined
nycohas left
Ge0rG1. join
2. request MAM since $last_timestamp
3. live message comes in
4. MAM comes in, eventually containing that last live message
oliwhy awkward? subject changes could be part and context of a conversation.
MarandaAt most, at least I, record only in http logs the subject changes not the rest
lovetoxoli i meant protocol wise akward
lovetoxnot that it couldnt be useful
Ge0rGoli: because a client might think "the sync is completed"
oliright
lovetoxGe0rG, you case is does not lead to problems with mam:2
lovetoxbecause of stanza-id deduplication
rionhas left
Marandaoli: it's not stated in the protocol to begin with that subject changes should go in the history (or otherwise, but it goes against the intentions me thinks)
Ge0rGI normally don't deduplicate for live messages, only for MAM syncup
lovetoxtrue .. i remember i also dont
lovetoxbut i throw away all messages while a MAM MUC catchup is running
lovetoxor something like that
lovetoxi considererd this case, thats what i remember
Ge0rGWe really need to document all these hairy corner cases
Ge0rGalso notification suppression
Ge0rGJust had a similar discussion with Anu yesterday
Alexhas joined
ZashDid you know: Normal groupchat messages are allowed to have a subject if they have a body too
lovetoxah i remember now Ge0rG this still does work with deduplication
lovetoxbecause live message gets written into the db first
lovetoxthen mam message comes, and you dedup on that
Ge0rGZash: normal != groupchat
lovetoxhe just means groupchat messages
lovetoxyou have to filter on "has subject but not body"
Zash<message type=groupchat><subject>stuff</subject><body>Let's talk about stuff</body></message>
lovetoxto catch a subject, not just "has subject"
ZashThat is *not* a MUC subject change
ZashJust a groupchat message that happens to have a subject
APachhas joined
Zashhas left
andyhas joined
APachhas left
Alexhas left
Link Mauvehas joined
tahas left
Alexhas joined
APachhas joined
rionhas left
Guushas left
Guushas left
rionhas left
Wiktorhas left
ralphmIndeed. “Note: In accordance with the core definition of XML stanzas, any message can contain a <subject/> element; only a message that contains a <subject/> but no <body/> element shall be considered a subject change for MUC purposes.”
chunkhas joined
Ge0rGSome MUC implementation forbid messages having both body and subject.
Ge0rGStill, it doesn't answer my question of whether it's legal to have a subject change in MUC history
Wiktorhas left
ralphmI don't see why it shouldn't be in there.
Ge0rGralphm: because of https://xmpp.org/extensions/xep-0045.html#order
Ge0rGOf course there are also servers that *don't* send the subject at all if it's not set, so...
ralphmGe0rG: I still don't see the issue. If you are sending message history, that's not 'live messages'
lovetoxi think this is not easy to implement for servers
Ge0rGralphm: a client needs to be able to distinguish history from live messages
lovetoxthey only should put the first subject change into the archive
lovetoxafterwards they send the subject to many users, but should not put it into the archive anymore
Ge0rGlovetox: every subject change should be in the archive
ralphmThey already should, no? Message history stanzas have a <delay/> with a from attribute.
lovetoxralphm, from attr is not mandatory
lovetoxand servers dont enforce it
Ge0rGralphm: a <delay/> with a from is not exclusive to history.
lovetoxalso all other messages can also have delay
Ge0rGso it's a good indicator, at best.
lovetoxalso the room subject itself can have a delay
ralphmHmm. It says here in 7.2.14: Note well that this means the room subject (and changes to the room subject prior to the current subject) are not part of the discussion history.
ralphmWell, that sucks
Ge0rGralphm: ah, thanks. Didn't see that.
lovetoxwhy are you interested in this Ge0rG? are you writing code regarding to subject changes?
ralphmGood thing that's resolved with MIX.
ralphmI.e. there's no subject there, at all.
Ge0rGlovetox: I have some legacy code about subject changes. Also a race condition between receiving the subject and receiving the room's disco#info on join
ralphmFortunately, if you want to add such functionality, you'd just have another node for just the room subject.
lovetoxyeah separation is good for that
lovetoxGe0rG, dont you want to disco the muc before you join?
lovetoxthats recommended if you want to use mam when i remember correctly
Wiktorhas left
Ge0rGlovetox: I'll have to change that then
lovetoxthe problem with mam is, that if you join a muc without knowing if it is mam capable
lovetoxyou have to use history in the join, because you dont know about mam
lovetoxbecause you can do a join with max=0
lovetoxand then get the history later
sezuanhas left
lovetoxcant*
lovetoxyou have to specifiy on join if you want history or not, so you already need to know about mam
lovetoxand to make that process faster on rejoins, i would also cache that disco information
XSF Discussion - 2018-12-18