XSF Discussion - 2021-09-07

MattJ, what's your opinion on SHOULD NOT vs. MUST NOT for type="groupchat" in User Archives (*not* MUC archives!) in '313?

Definitely not MUST NOT.

:)

I still think they SHOULD be included in the user archives.

cc @ Ge0rG ^

I also saw Ge0rG claiming on list that no-one is storing MUC messages in archives, which is demonstrably false.

Whichever wording allows MIX to conditionally override it.

Kev, I suggest to outline all of that as a reply to the list then.

I’m quite convinced I’ve said much the same multiple times in the past.

I have no idea ✏

it's been too long

Ge0rG, it seems that consensus for MUST NOT for type="groupchat" may be hard to achieve

But I have replied to list, anyway.

"if you do store type=groupchat, you most likely want to dedup somehow, glhf"

Kev: I'm very much missing a rationale for storing those messages, and useful measures for preventing their delivery to clients that are not joined to the archived rooms, and for doing the deduplication ✏

I vaguely remember "server side message search"

But given that some rooms are very very very noisy and some clients will ask for "all archived messages since timestamp x", this is waiting for disaster

And if there are implementations doing it both ways, we need to have a feature var or something comparable for this anyway.

Or, in other words, we can't advance 313 as is

XMPP. We MAY do something, we MAY do the opposite, you never know ...

Apart from the actual question whether or not storing MUC messages in user archives seems desirable: If the idea is to move to MIX some day, it might then seem somewhat weird to have MUC stuff specified in '313?

... whereas for MIX, the idea seems to be: > The client's local server MAY archive messages and advertise this capability as specified in Mediated Information eXchange (MIX): Participant Server Requirements (XEP-0405) [ https://xmpp.org/extensions/xep-0369.html#use-mam-retrieve ]

Holger: I'm probably sounding like a broken record, but the "synchronize central and user server archives after a network outage" is still not solved

Apparently most protocol designers are considering s2s issues as non existent

I agree. Nevertheless I just tried to limit my comment to MUC-vs.-MIX consistency in '313 :-)

I've mentioned that on every incarnation of the MIX XEP, and the answer boils down to magic handwaving

Given that some modern xmpp clients still will lose a connection to a MUC, silently leaving the user offline for days or weeks, due to this effect, I should probably conclude that reliable message delivery is just not worth solving in xmpp

I'm very sceptical about just blindly throwing groupchat messages into user archives (and the MIX XEP does strongly suggest doing so). There's the sync issue, yes. Also it sounds to me like a receipt for getting the worst of the XMPP and Matrix worlds. So if you ask me, it would be good to at least make this behavior optional. In which case a feature announcement makes sense. And it might make sense in just the same way for MUC MAM.

Holger: I see your feature announcement and raise a query flag

(The worst of both worlds, because we're spreading copies of messages all over the place without having an obvious way to at least dedup the history on a given server. And yes, the sync issue, which is related: Our history is not linked into a DAG or whatever.)

Maybe we should just reflect the reality in 313: for type=groupchat, a server SHOULD store a subset of the messages received from rooms, without information about where the archive might have message holes caused by intermittent network issues.

Isn't the reality that only M-Link does these things?

Prosody doesn't. I take it ejabberd doesn't? Not aware of anyone else doing it either.

Right.

I don’t know of anyone else doing it. But I’m also aware that many XMPP implementations aren’t generally known about.

Yes, just saying that "SHOULD store a subset" would only reflect part of the reality.

Kev: should I rather ask all my questions from above on list?

https://xmpp.org/extensions/xep-0050.html#impl-commands says there should be a <note type='error'/>, but #example-23 places type='error' on <iq> not <note>, which is true in practice?

was there ever any follow-up on https://mail.jabber.org/pipermail/standards/2019-April/036073.html ?

southerntofu, the message right next in that thread: https://mail.jabber.org/pipermail/standards/2019-April/036076.html

> But I’m also aware that many XMPP implementations aren’t generally known about.

who cares about these implementations though

do we also ask google and apple about their xmpp implementations when considering a spec change or