XMPP Council - 2021-04-28

  1. Zash

    jonas’, agenda?

  2. jonas’

    chaos yesterday, dropped off my todo somehow

  3. jonas’

    I initially thought I had a time window for that and then the pandemic cancelled that time window and my head did not schedule a replacement and here we are

  4. jonas’

    but I think we don’t have anything anyway

  5. Ge0rG

    something something CVE, something something must update 0280

  6. jonas’

    sent a pro forma one

  7. jonas’

    yep, we’ll have lots of time for AOB

  8. Ge0rG


  9. jonas’

    1) Roll Call

  10. Zash


  11. daniel


  12. Zash


  13. jonas’

    anticipating a Ge0rG and a possible dwd

  14. dwd


  15. Ge0rG

    Oh, it's that late already?

  16. jonas’

    it is :)

  17. jonas’

    2) Agenda Bashing

  18. Ge0rG

    Good morning, everyone!

  19. jonas’

    bad agenda! late agenda!

  20. jonas’

    also, empty agenda

  21. jonas’

    3) Editor’s Update

  22. jonas’

    Nothing, but editor didn’t do anything. Bad editor!

  23. jonas’

    4) Items for Voting

  24. jonas’


  25. Zash


  26. jonas’

    5) Pending Votes

  27. jonas’

    all clear

  28. Zash


  29. jonas’

    6) Date of Next

  30. Ge0rG

    +3W WFM

  31. jonas’

    +1w wfm

  32. jonas’

    Ge0rG, have a nice vacation!

  33. Zash

    +1w wfm

  34. daniel

    +1w wfm

  35. Ge0rG

    jonas’: I'll try my best

  36. dwd

    The same time next week works for me.

  37. jonas’


  38. jonas’

    7) AOB

  39. jonas’

    Ge0rG had some I think

  40. Ge0rG

    Oh, I'm kinda unprepared.

  41. Ge0rG

    I think you mentioned something about bringing uo the CVE thing on standards.

  42. Ge0rG

    I think you mentioned something about bringing up the CVE thing on standards. Which I didn't do yet.

  43. Ge0rG

    And I have a hard time remembering last week's conclusion of what to do with <private/> and no-copy.

  44. dwd

    My AOB is that I'm getting a COVID vaccine shortly, which seems a bit pointless as I don't even have a 5G phone.

  45. jonas’

    dwd, congrats!

  46. jonas’ scrolls up to answer Ge0rGs implicit question

  47. Zash

    Something about not removing <private> IIRC

  48. jonas’

    Ge0rG, the summary was, I think, that if you want to remove that strange <private/> behaviour, add a feature to indicate that the server in fact executes the new behaviour

  49. jonas’

    otherwise it will do nothing good except chaos

  50. Ge0rG

    Why didn't we add a feature the last time we changed <private/> stripping rules?

  51. jonas’


  52. jonas’

    past wrongs don’t give permission for new wrongs

  53. Ge0rG

    I had a slight hope that the past wrong would be cancelled out by the upcoming wrong

  54. Kev

    I’m not even convinced that the last change wasn’t a mistake.

  55. jonas’

    no, because there are a few years of practical deployment inbetween

  56. Kev

    But I don’t think that means fixing it can skip the needful.

  57. Ge0rG

    jonas’: given the amount of server developer feedback, I'm not sure this is true at all ;)

  58. jonas’

    Ge0rG, yes, the lack of feedback does not allow us to come to any conclusion.

  59. jonas’

    hence, we have to play it safe

  60. Kev

    “Lack of feedback” doesn’t actually mean lack of feedback, does it?

  61. jonas’

    even if the only diff on the server side would be adding a thing to disco#info

  62. Kev

    There’s been lots of feedback, IIRC, in response to some of the previous 2039871032730987 last calls.

  63. jonas’

    Kev, I think Ge0rG meant to reference lack of feedback on that specific issue

  64. Ge0rG

    Okay, so I'll move forward by removing the stripping and adding a no-stripping feature.

  65. dwd

    Kev, Maybe we should keeping having more and more last calls until eventually we get no feedback at all and we can reject it on that basis instead.

  66. Ge0rG

    Now what about no-copy hints?

  67. Ge0rG

    dwd: That's an excellent idea

  68. Zash

    LC of Zeno?

  69. jonas’


  70. jonas’


  71. jonas’

    Ge0rG, I have no opinion on no-copy hints

  72. Ge0rG

    Well, my (serious) question still stands.

  73. jonas’

    nor do I have a clear picture about the implications

  74. jonas’

    Ge0rG, could you summarize your thoughts on no-copy?

  75. jonas’

    i.e. what is the current situation, what is bad about it and what would you like to change?

  76. Ge0rG

    jonas’: no-copy was added as an AND requirement for clients after <private/> was there

  77. Ge0rG

    the requirements for servers are vague, at best

  78. Ge0rG

    IMO, removing no-copy will not do any harm to specification-abiding implementations

  79. Ge0rG

    The only corner case I see is when a receiving client would rely on no-copy being there while <private/> being stripped by a stripping server.

  80. Ge0rG

    Sorry, somebody decided that *now* would be a good time to send thousands of vaccination notifications.

  81. daniel

    (I just checked the only time I use no-copy in Conversations is when I send a direct-invite to my own connected resources to inform them that I've just joined a new muc. Which has arguably been made obsolete now that we have bookmarks in PEP)

  82. jonas’

    daniel, lovely hack though :)

  83. jonas’

    love the attention to detail in there

  84. Ge0rG

    daniel: why not sending one invite to your bare JID?

  85. daniel

    to avoid receiving it on my own client i guess

  86. jonas’

    Ge0rG, OK, I don’t have strong opinions on that

  87. jonas’

    as I assume that many implementations would handle <private/> even if <no-copy/> was absent if the XEP is worded vaguely

  88. Ge0rG

    jonas’: that's my conclusion as well

  89. Ge0rG

    Okay, thanks everybody for the fruitful discussion. I think I'm out of AOBs for now.

  90. jonas’

    I sense sarcasm

  91. jonas’


  92. jonas’

    dwd, do you want to elaborate on your AOB? :)

  93. Ge0rG

    I'd never dare to

  94. daniel

    what are we achieving by stripping or not stripping that element?

  95. Ge0rG

    daniel: we get rid of legacy

  96. daniel

    by stripping it?

  97. Ge0rG


  98. daniel

    so you want to reintroduce legacy by telling servers to not strip it?

  99. Zash

    I seem to have lost track of what exactly the question was

  100. daniel

    yes. me too

  101. daniel

    that's why i'm asking

  102. Ge0rG

    daniel: I don't follow

  103. Ge0rG

    daniel: did you ask about no-copy or about private?

  104. Ge0rG

    "that element" appears ambiguous in retrospect

  105. Zash

    no-copy → strip from the XEP private → don't strip from stanzas ?

  106. Ge0rG

    what Zash said!

  107. dwd

    It seems to me that we've spent nearly half an hour doing protocol design in a Council meeting. Can we not write a proposal to the list, see if there's concensus to do anything (or nothing), and go from there?

  108. Ge0rG

    dwd: sure

  109. Ge0rG puts it on his agenda

  110. jonas’

    dwd is a smart person

  111. jonas’

    let’s do what dwd s ays

  112. Zash


  113. jonas’

    any other AOB?

  114. Zash

    none here

  115. dwd

    None from me.

  116. daniel

    none here either

  117. jonas’

    then I wish you all a pleasant rest of the day

  118. jonas’

    8) Ite Meeting Est

  119. jonas’

    thanks all

  120. Zash

    Thanks jonas’

  121. Zash

    Thanks tedd

  122. Zash

    and thanks all

  123. Ge0rG


  124. daniel

    Message Carbons is weird legacy anyway. I don’t thing we gain anything from messing with no-copy and private

  125. daniel

    yes it was a mistake to introduce no-copy

  126. daniel

    but those extra bytes don’t matter

  127. Ge0rG

    No need to cement that mistake into eternity

  128. daniel

    considering the overhead that carbons has anyway

  129. daniel

    i really hope that Carbons don’t hang around for an eternity

  130. dwd

    I'd be curious as to whether it matters if it *is* baked into eternity.

  131. dwd

    I mean, if it's there already in implementations, does it matter?

  132. daniel

    plus looking at the history of the XEP it seems that stripping <private/> was a requirement before no-copy was even introduced

  133. daniel

    so the stripping of private is not to remove redundant information after the introducting of no-copy

  134. daniel

    it was there before

  135. daniel

    i don’t know why

  136. daniel

    so even if you were to remove no-copy you don’t need to mess with the stripping or not stripping of private

  137. Kev

    I think it was a mistake.

  138. daniel


  139. Kev

    Looking at the changelog, the changelog seems to suggest it was trying to do the opposite of what it does.

  140. Kev

    No, adding the stripping of private.

  141. Zash

    Everything! Climbing down from the trees especially

  142. daniel

    considering that there are very few use cases for private/no-copy I suggest that we accept the fact that Carbons is not pretty but de facto draft and just leave everything as is and declare it as such

  143. Zash


  144. jonas’

    weren’t we there already last week?

  145. Zash

    and try for a reasonable upgrade path to IM-NG?

  146. jonas’

    however, the stripping of private might be considered actively harmful

  147. Kev

    I consider it is, yes.

  148. jonas’

    so fixing that before moving to draft may be worthwhile

  149. daniel

    so remove no-copy don’t strip private?

  150. Ge0rG

    remove stripping of private, remove no-copy from XEP

  151. daniel


  152. Ge0rG


  153. daniel

    Can anyone think of a scenario of a receiving client that relies on the stripping?

  154. Kev


  155. daniel

    Because that's the breaking change here, right?

  156. Zash

    Anyone remember why it's even stripped?

  157. Kev

    Depending on one’s definition of breaking, yes.

  158. Zash

    ISTR some privacy issue or something

  159. Kev

    Zash: As I say above, I think it was a mistake. The changelog says that it was removed, but instead it was added.

  160. Ge0rG

    I think there was a version of Carbons that required the *sending* server to strip, but then somebody realized that the receiving server needs that info as well

  161. Zash

    Makes sense, I think Prosody still follows that 😕

  162. Ge0rG

    Zash: prosody will strip on the sending server?

  163. Zash


  164. daniel


  165. Zash

    Unless I'm mistaken

  166. daniel

    OK. I've changed my mind. You have my blessing to remove the no-copy hint from the xep and remove the requirement to strip private

  167. daniel

    (not that you need that since you are the author and the xep is experimental)

  168. dwd


  169. Ge0rG

    if that's true, the fact that nobody noticed it yet speaks tomes.

  170. Zash

    Hm, nm, seems to strip it on the receiving end only

  171. Ge0rG

    so I've replaced the SDK shipped with AS by OpenJDK 12.

  172. Zash

    Wrong room?

  173. Ge0rG

    Ooops, that was the wrong place.

  174. Ge0rG

    is it me or are we missing Council minutes for April? I tried to find the "mention CVE PR on-list" statement in either my local logs or the Minutes and failed :(

  175. jonas’


  176. jonas’


  177. jonas’

    I hope Tedd is alright

  178. Ge0rG

    Yeah, that was also my first thought.

  179. Ge0rG

    And my second thought was, that this kind of thought is very frightening, if the only regular interaction with somebody is them writing a summary email to a list.

  180. Ge0rG

    ah, found it. 20210421T15:42:30Z

  181. Ge0rG

    jonas’: https://mail.jabber.org/pipermail/standards/2021-April/038301.html

  182. theTedd

    jonas’, Tedd is alright ;)

  183. theTedd

    just been otherwise distracted

  184. theTedd

    minutes will magically appear, probably