XMPP Council - 2023-02-23


  1. emus has left

  2. Tobias has joined

  3. Tobias has left

  4. gooya has left

  5. neox has left

  6. Tobias has joined

  7. pprrks has left

  8. Tobias has left

  9. pprrks has joined

  10. pprrks has left

  11. pprrks has joined

  12. Tobias has joined

  13. MSavoritias (fae,ve) has joined

  14. emus has joined

  15. mdosch has left

  16. mdosch has joined

  17. marc0s has left

  18. marc0s has joined

  19. marc0s has left

  20. marc0s has joined

  21. marc0s has left

  22. marc0s has joined

  23. marc0s has left

  24. marc0s has joined

  25. pprrks has left

  26. neox has joined

  27. pprrks has joined

  28. marc0s has left

  29. marc0s has joined

  30. vaulor has left

  31. vaulor has joined

  32. marc0s has left

  33. marc0s has joined

  34. marc0s has left

  35. marc0s has joined

  36. emus has left

  37. Kev has joined

  38. emus has joined

  39. MattJ

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

  40. pprrks has left

  41. MattJ

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

  42. Ge0rG

    exactly my question.

  43. Ge0rG

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

  44. pprrks has joined

  45. pprrks has left

  46. MattJ

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

  47. jonas’

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

  48. jonas’

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

  49. pprrks has joined

  50. MattJ

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

  51. MattJ

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

  52. MattJ

    Which I dispute

  53. jonas’

    I'm confused by the statement

  54. MattJ

    Which one?

  55. jonas’

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

  56. jonas’

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

  57. MattJ

    I am

  58. jonas’

    why not?

  59. Ge0rG

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

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

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

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

  63. Ge0rG

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

  64. MattJ

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

  65. MattJ

    I think we can live with broken clients being broken

  66. jonas’

    alright, fair

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

  68. jonas’

    MattJ, thanks for clarifying

  69. MattJ

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

  70. MattJ

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

  71. MattJ

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

  72. 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'

  73. MattJ

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

  74. MattJ

    I just really would rather we didn't

  75. MattJ

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

  76. Ge0rG

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

  77. Ge0rG

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

  78. MattJ

    Happy to

  79. Ge0rG

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

  80. MattJ

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

  81. sonny has left

  82. sonny has joined

  83. gooya has joined

  84. emus has left

  85. Kev has left

  86. Kev has joined

  87. emus has joined

  88. flow has left

  89. flow has joined

  90. pprrks has left

  91. pprrks has joined

  92. vaulor has left

  93. vaulor has joined

  94. pprrks has left

  95. pprrks has joined

  96. pprrks has left

  97. pprrks has joined

  98. vaulor has left

  99. vaulor has joined

  100. moparisthebest has left

  101. moparisthebest has joined

  102. Kev has left

  103. Tobias has left

  104. Tobias has joined

  105. pprrks has left

  106. pprrks has joined

  107. MSavoritias (fae,ve) has left

  108. Tobias has left

  109. Tobias has joined

  110. Tobias has left

  111. Tobias has joined

  112. Tobias has left

  113. Kev has joined

  114. sonny has left

  115. sonny has joined

  116. Kev has left

  117. emus has left

  118. stpeter has joined

  119. moparisthebest has left

  120. neox has left

  121. moparisthebest has joined

  122. moparisthebest has left