XSF Discussion - 2023-01-04

that seems to be a valid question

dwd: > Tobi, the problem is that the user’s server can’t (often/always) tell if they were MUC PMs or ordinary direct messages, at least not without the server going and finding out what type the sending Jid is. So yes, they often end up in MAM - however, there was a move to mark them as MUC PMs, so they can easily be omitted then. wasn't that discussion for MIX groupchat messages, or am I missing something?

jonas’, Or both? Everything blurs into one. And is then repeated. And yes, lovetox, maybe the idea was to avoid Carbons but ensure archiving, or the reverse, or both except on Tuesdays in summer after 4pm where a replacement bus service will be provided.

dwd, jonas’: I do not know the answer, but there is maybe a chance that dwd is blurring in implementation details of Openfire's plugin, in context of which this all feels very familiar.

but we want carbons for pms

the motivation behind <x> has nothing to do with archiving in my experience

the problem is client side, its implementation wise much easier for clients if they can differentiate between PMs and normal chat messages

if i ever have to design a protocol i think i would make everything very explicit

lovetox, I mean, the motivation in the spec is for Carbons. Specifically, supression thereof, as noted in '280, §6.1

i remember now

A private <message/> from a MUC participant (received from a full JID) to a local user SHOULD NOT be carbon-copied (these messages are already replicated by the MUC service to all joined client instances).

this was the pain

on client side you got sent the same message twice