XSF Discussion - 2021-09-07

  1. jonas’

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

  2. Kev

    Definitely not MUST NOT.

  3. Kev


  4. Kev

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

  5. jonas’

    cc @ Ge0rG ^

  6. Kev

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

  7. Zash

    Whichever wording allows MIX to conditionally override it.

  8. jonas’

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

  9. Kev

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

  10. jonas’

    I have no idae

  11. jonas’

    I have no idea

  12. jonas’

    it's been too long

  13. jonas’

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

  14. Kev

    But I have replied to list, anyway.

  15. Zash

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

  16. Ge0rG

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

  17. Ge0rG

    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

  18. Ge0rG

    I vaguely remember "server side message search"

  19. Ge0rG

    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

  20. Ge0rG

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

  21. Ge0rG

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

  22. Holger

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

  23. Holger

    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?

  24. Holger

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

  25. Ge0rG

    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

  26. Ge0rG

    Apparently most protocol designers are considering s2s issues as non existent

  27. Holger

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

  28. Ge0rG

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

  29. Ge0rG

    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

  30. Holger

    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.

  31. Ge0rG

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

  32. Holger

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

  33. Ge0rG

    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.

  34. Holger

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

  35. Zash

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

  36. Holger


  37. Kev

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

  38. Holger

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

  39. Ge0rG

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

  40. southerntofu

    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?

  41. southerntofu

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

  42. jonas’

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

  43. moparisthebest

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

  44. moparisthebest

    who cares about these implementations though

  45. moparisthebest

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