XMPP Council - 2021-04-07

  1. daniel


  2. jonas’


  3. jonas’

    1) Roll Call

  4. Zash


  5. jonas’

    staring at graphs

  6. daniel

    I'm here

  7. dwd


  8. jonas’

    pinging Ge0rG

  9. dwd

    I like graphs. Especially boring ones.

  10. jonas’

    this one threatens to become non-boring, hence I was a bit distracted

  11. jonas’

    2) Agenda Bashing

  12. jonas’

    any modifications?

  13. jonas’

    please mention any AOB during the meeting—I know that Ge0rG had some AOB, but it seems that we’re now lacking Ge0rG

  14. jonas’

    3) Editor’s Update

  15. jonas’

    - Last Call on XEP-0313 expired (last week already) - Last Call on XEP-0280 expired yesterday (2021-04-06)

  16. jonas’

    4) Items for voting

  17. jonas’

    4a) Decide on Advancement of XEP-0313: Message Archive Management URL: https://xmpp.org/extensions/xep-0313.html Abstract: This document defines a protocol to query and control an archive of messages stored on a server.

  18. jonas’

    I share Ge0rGs concerns about the security considerations section

  19. jonas’

    his AOB is related

  20. dwd

    Is the AOB about CVE listing in XEPs?

  21. jonas’


  22. Zash

    on-list, haven't read all the LC replies yet

  23. daniel

    On list as well

  24. jonas’

    also on-list

  25. daniel

    I have complicated feelings about both of these xeps...

  26. jonas’

    do you want to share your feelings with the group, daniel? :)

  27. dwd

    I would like to understand the CVE position, and run that past the list ideally, before voting.

  28. Zash

    I'd say they feel like pretty large parts of Modern XMPP

  29. daniel

    Both feel like rather temporary fixes to more fundamental issues in the protocol

  30. jonas’

    daniel, are you hinting at Bind2 + IM-NG?

  31. Zash

    Towards Future XMPP?

  32. Zash

    Future Modern*

  33. daniel

    Maybe. But even IM-NG is going to be complicated

  34. daniel

    More like what Zash said

  35. Kev

    They’re both pretty temporary. If either lasts more than a couple of decades I’d be surprised.

  36. Sam

    Obligatory advertisement for next week's office hours: Towards XMPP 2.0 roundtable discussion

  37. daniel

    But that said that shouldn't necessarily stood us from advancing them

  38. daniel

    It's just an explanation towards why we are never really going to be happy about those two xeps

  39. jonas’

    daniel, that’s certainly true

  40. Kev

    I think if one doesn’t have complicated thoughts about these XEPs (at least carbons, maybe MAM), they probably don’t understand :)

  41. Zash

    Hm, it'd probably be good to go through previous LCs (there has been a couple, right?) and check if everything raised there has been adressed

  42. Zash

    Something something representing a big shift in how XMPP works 🤷️

  43. jonas’

    Zash, do you volunteer? :)

  44. Zash

    I did not say that 🙂

  45. daniel

    IIRC a lot of the previous LCs were it doesn't cover this specific edge case

  46. daniel

    And I don't think it will ever do that

  47. daniel

    We just have to live with that. Probably...

  48. jonas’

    I mean at this stage, the XEPs are certainly a 80%-95% solution to the problem of "how to get all relevant messages on all devices"

  49. Zash

    Until IM-NG et all?

  50. dwd

    Actually, thinking more about this, +1 to advancing. We can add the CVE bits in afterward just fine.

  51. Ge0rG

    I've gone through my LC feedback for 0280 at least

  52. jonas’

    they’re worth moving to Draft based on that.

  53. jonas’

    Ge0rG, \o/

  54. Ge0rG

    I'm on-list for 313 because I really want to see a discussion of the points I brought up

  55. jonas’

    Ge0rG, I skimmed them and my summary is mostly "Bind2"

  56. Ge0rG

    And honestly I'm most interested in properly specified storage rules in 313

  57. jonas’

    Ge0rG, I skimmed them and my summary is mostly "Bind2" (for the long part at the bottom)

  58. Zash

    I'm wondering if those rules aren't going to have to evolve as we go forward, with new XEPs etc.

  59. Zash

    Same with carbons

  60. Ge0rG

    jonas’: well, bind2 won't solve all problems of 313

  61. jonas’

    Ge0rG, see the parenthesis I added

  62. Ge0rG

    Zash: yes, so having them under a separate namespace is a good idea

  63. daniel

    > I'm wondering if those rules aren't going to have to evolve as we go forward, with new XEPs etc. > Same with carbons Yes. We don't really have a good definition of what a message is

  64. daniel

    That's the problem with both of these xeps

  65. Ge0rG

    Not in the context of IM

  66. jonas’


  67. Zash

    Ge0rG, I think I meant like, new XEPs should maybe describe whether the payloads they describe should/should not be stored.

  68. jonas’

    IM-NG has an idea how to address (pun intended) this, I think it deserves more experimentation

  69. Ge0rG

    I hope that my work on the 0280 rules can be applied equally to 313

  70. Zash

    Tho a whole new $XEP Rules XEP could work too

  71. Sam

    FWIW, this is all part of why I think these two need to advance. We probably can't get them perfect, they may need to change in the future, but they're both already extremely widely implemented so we probably can't change them that much. That sounds like draft to me.

  72. Ge0rG

    Zash: like Hints?

  73. Zash

    In my experience you want subtly different rules for MAM, Carbons and CSI, but there's definitely a bunch of overlap.

  74. Zash

    Oh and cloud notify stuff.

  75. Ge0rG

    Zash: I'm very much interested in extracting those subtle differences

  76. Zash

    Could be wrong tho, but I still think they'll probably have to continue evolving in the future.

  77. jonas’

    likely, especially when push services evolve the cloud notify stuff will have to evolve

  78. Kev

    e.g. as long as they’re in <message/>s, you want CSN sent to carbons but not MAM.

  79. jonas’

    either way… I doubt that this’s something we can solve in this meeting, I’d propose we move on through the formalities and the discussion can then be had later on?

  80. Zash


  81. jonas’

    (I don’t seem to be getting typing notifications in this channel anymore, so I hope I don’t cut anyone off)

  82. Ge0rG

    I'm here from yaxim

  83. jonas’

    4a) Decide on Advancement of XEP-0280: Message Carbons URL: https://xmpp.org/extensions/xep-0280.html Abstract: In order to keep all IM clients for a user engaged in a conversation, outbound messages are carbon-copied to all interested resources.

  84. Zash

    I don't think Dino sends typing notifications to this kind of chat

  85. daniel

    On list

  86. Zash

    on list here too

  87. jonas’

    on list

  88. Ge0rG

    I'm also very much interested in more list feedback, especially from server developers

  89. Ge0rG

    The LC feedback wasn't appropriate to the importance of the XEP, but I don't know what that means.

  90. Ge0rG

    Maybe it's just working perfectly for everybody.

  91. jonas’

    probably the community is worn out after the ten dozen LCs this already had

  92. jonas’

    but I haven’t experienced any carbons issue in the past years

  93. Zash

    probably the case

  94. Kev

    I think everyone understands that carbons is a necessary evil at the moment.

  95. Kev

    (Some may disagree on the ‘evil’ part)

  96. Ge0rG

    It's a hack on top of a hack on top of a bad design from the last millennium

  97. moparisthebest

    yes but how are we planning to reduce carbons by 2030

  98. Zash


  99. jonas’

    alright, same procedure as '313 I suppose

  100. jonas’

    5) Pending Votes

  101. jonas’

    - dwd on deprecation of '13

  102. dwd

    Sorry, major incident at work, I need to drop.

  103. jonas’

    ok, good luck!

  104. jonas’

    moving on then

  105. jonas’

    6) Date of Next

  106. jonas’

    +1w wfm

  107. Zash

    +1w? wfm

  108. daniel


  109. Ge0rG


  110. jonas’


  111. jonas’

    7) AOB

  112. jonas’ hands the mic to Ge0rG

  113. Ge0rG

    Yeah, CVEs in XEPs. This is not strictly a protocol thing, as it doesn't affect the protocol itself but only its implementations, but I think that it goes in a similar direction as DOAP, where we map out which implementations support which XEP

  114. Ge0rG

    I'm currently working on a first draft of a `<cve/>` XML element for XEPs that works in a similar way as a `<code>` block

  115. jonas’

    I think that having references to past CVEs in the Security Considerations of affected XEPs is a good thing to show the severity and also the rationale for specific rules.

  116. jonas’


  117. jonas’

    no objections with either of my hats

  118. Zash

    In the XEPs themselves or, like DOAP, merged in during rendering?

  119. jonas’

    in the XEPs themselves

  120. jonas’


  121. Ge0rG

    first rendered example at https://op-co.de/tmp/xep-0280.html#security

  122. jonas’

    having it in the metadata of the document feels wrong because CVEs are about implementations, not about protocols (in most cases anyway… https://xmpp.org/extensions/xep-0223.html#revision-history-v1.1 might be a notable exception) So adding a list of CVEs to a protocol seems incorrect (in general).

  123. Ge0rG

    What jonas’ said

  124. Ge0rG

    And having a custom element hopefully gives us enough rope to extract it later on.

  125. jonas’

    in addition, for the CVEs which are more like implementation notes / security considerations, embedding the metadata-cve-list at the right place in the document becomes a non-trivial XSL task

  126. jonas’

    Ge0rG, that looks great already

  127. Ge0rG

    jonas’: if you have some CSS magic to add a red warning sign to the left and to the right, I'd be very grateful

  128. Ge0rG

    XSL magic works as well.

  129. jonas’

    we’d need artwork for that, unicode is not good enough as I learnt recently

  130. Ge0rG

    don't we have some obscure math symbol we can use?

  131. Ge0rG

    Also what's wrong with ⚠?

  132. jonas’

    depends on how it’s used it’s an accessibility issue

  133. jonas’

    needs to be looked at in detail anyway

  134. Ge0rG

    jonas’: you just volunteered? :)

  135. jonas’

    Ge0rG, I can fix you up with some CSS in your PR, yes

  136. Ge0rG


  137. jonas’

    if and only if it is solvable without :before/:after, because I haven’t found a good solution for those yet

  138. jonas’

    any other notes on this topic?

  139. Ge0rG

    well, I actually wanted to do some more talking about my LC comments on both 313 and 280

  140. Ge0rG

    but we are also over time and I need to get into a business that closes at 1800CEST

  141. jonas’

    yeah, I’m also super hungry

  142. jonas’

    any other AOB?

  143. jonas’

    (I suggest you bring the general '280/'313/cloud-notify? discussions on-list and/or try to schedule an A/V call with interested participants)

  144. jonas’

    assuming no other AOB

  145. jonas’

    8) Ite Meeting est

  146. jonas’

    8) Ite Meeting Est

  147. Ge0rG

    thanks jonas’

  148. jonas’

    thanks everyone!

  149. Zash

    Thanks jonas’, all.

  150. daniel

    Thanks all

  151. Ge0rG

    jonas’: do the LC mails count as "bringing up"?

  152. jonas’

    generally, yes

  153. Ge0rG

    I have a feeling that I should -1 the 0313 as-is, because of lack of business rules. My feeling is that the 0280 rules were a huge step forward, even if they aren't perfect, and that having them in 0313 would be another huge benefit. That and business rules for clients.

  154. Ge0rG

    I can live without the bind2 stuff

  155. Zash

    I'm thinking you probably want to make the CVEs count as references, wrt the XML magic.

  156. Ge0rG

    Zash: my head might explode if I try that.

  157. Ge0rG

    I'm largely copy&pasting stuff from other places in the xsl

  158. jonas’

    Ge0rG, I think you’re not wrong about the rule stuff

  159. Zash

    Hmm, there was that talk about dusting off https://xmpp.org/extensions/xep-0226.html or something similar

  160. Ge0rG

    Zash: I think you volunteered to do that

  161. Zash

    oh no