XMPP Council - 2023-02-23


  1. MattJ

    But... do we need <good-id/>? What does it help, really?

  2. MattJ

    I don't know if the additional semi-useless payload on every message stanza is worth it

  3. Ge0rG

    exactly my question.

  4. Ge0rG

    And I don't see how disabling features on messages that lack it is going to benefit the ecosystem

  5. MattJ

    XMPP has a history of (rightly or wrongly) being called bloated, but mandating duplication seems a step in the wrong direction

  6. jonas’

    <good-id/> would not carry an actual ID value, AIUI

  7. jonas’

    and servers could translate <message id="$x"><origin-id id="$x"/></message> to <message id="$x"><good-id/></message> easily, fwiw

  8. MattJ

    The current proposal AIUI is not to spec good-id but mandate origin-id == @id

  9. MattJ

    Which I think is logically sound, only on the premise that we MUST have good-id at all

  10. MattJ

    Which I dispute

  11. jonas’

    I'm confused by the statement

  12. MattJ

    Which one?

  13. jonas’

    > Which I think is logically sound, only on the premise that we MUST have good-id at all

  14. jonas’

    are you saying you don't see a need for the concept behind origin-id at all?

  15. MattJ

    I am

  16. jonas’

    why not?

  17. Ge0rG

    I'd rephrase that as "the benefits of origin-id don't outweigh the drawbacks"

  18. MattJ

    It was added as a workaround for one buggy MUC implementation that isn't even common on the network (and I think has been fixed now

  19. MattJ

    It was added as a workaround for one buggy MUC implementation that isn't even common on the network (and I think has been fixed now)

  20. MattJ

    Ge0rG [09:32]: > I'd rephrase that as "the benefits of origin-id don't outweigh the drawbacks" Sure, I can go with that

  21. Ge0rG

    the rationale presented yesterday was that it's a marker to enable advanced functionality on the receiving side, like editing and referencing messages.

  22. MattJ

    I see why people might want it, but not why we need it at this price

  23. MattJ

    I think we can live with broken clients being broken

  24. jonas’

    alright, fair

  25. Ge0rG

    and the larger problem I see with that is that it will cut off many clients with good-enough @id's from advanced functionality

  26. jonas’

    MattJ, thanks for clarifying

  27. MattJ

    We have a slot for this already, we just need people to use it properly, which practically every modern implementation already does

  28. MattJ

    But this is effectively giving up on it, adding a new duplicate slot to every message to fix a very minor uncommon issue

  29. MattJ

    And we have to spend the next decades explaining to people why we did this

  30. daniel

    To be clear. I'm fine with killing it. What I said yesterday was meant as 'if we want to keep orgin id we should mandate message id==origin id'

  31. MattJ

    Yes, I totally agree that it's the sensible way to do it, if we do it

  32. MattJ

    I just really would rather we didn't

  33. MattJ

    If it fixed a security issue, I could get behind it (or another solution)

  34. Ge0rG

    so we do a Last Call, reject the XEP, remind the author to completely remove <origin-id>, and start from scratch?

  35. Ge0rG

    No wait, we do an LC and MattJ writes those very eloquent words of rationale to the ML.

  36. MattJ

    Happy to

  37. Ge0rG

    MattJ: I hope you've copied that wall of text into a draft email already :D

  38. MattJ

    I can do it when I'm at my laptop 🙂