Will MUC subject changes also be stored in a MUC's offline history and replayed on join?
Andrew Nenakhovhas joined
lovetox
not to my knowledge Ge0rG
lovetox
this would be akward
Ge0rG
indeed
lovetox
im not sure why though, its just a gut feeling
lovetox
it would be weird in combination with MAM
Maranda
Not replayed in history *shrugs*
lovetox
because if you join with max=0 history
lovetox
then you still receive the subject from the MUC
lovetox
and afterwards you request MAM
Maranda
Indeed
lovetox
and get a bunch of subject changes
lovetox
but 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?
lovetox
i dont think so because you have timestamps
lskdjfhas joined
nycohas left
Ge0rG
1. join
2. request MAM since $last_timestamp
3. live message comes in
4. MAM comes in, eventually containing that last live message
oli
why awkward? subject changes could be part and context of a conversation.
Maranda
At most, at least I, record only in http logs the subject changes not the rest
lovetox
oli i meant protocol wise akward
lovetox
not that it couldnt be useful
Ge0rG
oli: because a client might think "the sync is completed"
oli
right
lovetox
Ge0rG, you case is does not lead to problems with mam:2
lovetox
because of stanza-id deduplication
rionhas left
Maranda
oli: 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)
Ge0rG
I normally don't deduplicate for live messages, only for MAM syncup
lovetox
true .. i remember i also dont
lovetox
but i throw away all messages while a MAM MUC catchup is running
lovetox
or something like that
lovetox
i considererd this case, thats what i remember
Ge0rG
We really need to document all these hairy corner cases
Ge0rG
also notification suppression
Ge0rG
Just had a similar discussion with Anu yesterday
Alexhas joined
Zash
Did you know: Normal groupchat messages are allowed to have a subject if they have a body too
lovetox
ah i remember now Ge0rG this still does work with deduplication
lovetox
because live message gets written into the db first
lovetox
then mam message comes, and you dedup on that
Ge0rG
Zash: normal != groupchat
lovetox
he just means groupchat messages
lovetox
you have to filter on "has subject but not body"
Zash
<message type=groupchat><subject>stuff</subject><body>Let's talk about stuff</body></message>
lovetox
to catch a subject, not just "has subject"
Zash
That is *not* a MUC subject change
Zash
Just 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
ralphm
Indeed. “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
Ge0rG
Some MUC implementation forbid messages having both body and subject.
Ge0rG
Still, it doesn't answer my question of whether it's legal to have a subject change in MUC history
Wiktorhas left
ralphm
I don't see why it shouldn't be in there.
Ge0rG
ralphm: because of https://xmpp.org/extensions/xep-0045.html#order
Ge0rG
Of course there are also servers that *don't* send the subject at all if it's not set, so...
ralphm
Ge0rG: I still don't see the issue. If you are sending message history, that's not 'live messages'
lovetox
i think this is not easy to implement for servers
Ge0rG
ralphm: a client needs to be able to distinguish history from live messages
lovetox
they only should put the first subject change into the archive
lovetox
afterwards they send the subject to many users, but should not put it into the archive anymore
Ge0rG
lovetox: every subject change should be in the archive
ralphm
They already should, no? Message history stanzas have a <delay/> with a from attribute.
lovetox
ralphm, from attr is not mandatory
lovetox
and servers dont enforce it
Ge0rG
ralphm: a <delay/> with a from is not exclusive to history.
lovetox
also all other messages can also have delay
Ge0rG
so it's a good indicator, at best.
lovetox
also the room subject itself can have a delay
ralphm
Hmm. 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.
ralphm
Well, that sucks
Ge0rG
ralphm: ah, thanks. Didn't see that.
lovetox
why are you interested in this Ge0rG? are you writing code regarding to subject changes?
ralphm
Good thing that's resolved with MIX.
ralphm
I.e. there's no subject there, at all.
Ge0rG
lovetox: 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
ralphm
Fortunately, if you want to add such functionality, you'd just have another node for just the room subject.
lovetox
yeah separation is good for that
lovetox
Ge0rG, dont you want to disco the muc before you join?
lovetox
thats recommended if you want to use mam when i remember correctly
Wiktorhas left
Ge0rG
lovetox: I'll have to change that then
lovetox
the problem with mam is, that if you join a muc without knowing if it is mam capable
lovetox
you have to use history in the join, because you dont know about mam
lovetox
because you can do a join with max=0
lovetox
and then get the history later
sezuanhas left
lovetox
cant*
lovetox
you have to specifiy on join if you want history or not, so you already need to know about mam
lovetox
and to make that process faster on rejoins, i would also cache that disco information