XSF Discussion - 2023-01-04


  1. flow

    that seems to be a valid question

  2. jonas’

    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?

  3. dwd

    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.

  4. Guus

    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.

  5. lovetox

    but we want carbons for pms

  6. lovetox

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

  7. lovetox

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

  8. lovetox

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

  9. dwd

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

  10. lovetox

    i remember now

  11. lovetox

    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).

  12. lovetox

    this was the pain

  13. lovetox

    on client side you got sent the same message twice