XMPP Council - 2021-09-08

  1. Ge0rG

    Oh, it's almost time, and I'm so excited to be the standin-chair today!

  2. Ge0rG

    It's Meeting Time!

  3. Ge0rG

    1) Roll Call

  4. daniel


  5. Zash


  6. Ge0rG

    Jonas is excused.

  7. Ge0rG

    Do we have a dwd?

  8. dwd

    Sorry, yes!

  9. Ge0rG


  10. Ge0rG

    2) Agenda Bashing

  11. Ge0rG

    It's not my fault, so feel free to fire at will!

  12. Zash

    Surprise MAM vote!

  13. Ge0rG

    It's on the agenda, so not so much of a surprise.

  14. Ge0rG

    Maybe surprise MAM PR?

  15. Ge0rG

    I suggest we can discuss the PR ahead of voting.

  16. Ge0rG

    3) Editor’s Update - Last Call for XEP-0459, Compliance Suites 2022

  17. Ge0rG

    I'm not sure if the author of CS'22 actually asked for the LC or if it was warranted by the remaining time for Old Council.

  18. Ge0rG

    But thank you very much to jonas’ the Editor.

  19. Ge0rG

    4) Items for voting

  20. Ge0rG

    4a) PR#1064: XEP-0227: New revision 1.1 URL: https://github.com/xsf/xeps/pull/1064

  21. Zash


  22. daniel


  23. dwd


  24. Ge0rG


  25. Ge0rG

    I'm sure that jonas’ will on-list.

  26. Ge0rG

    4b) Advance XEP-0313 to Stable as-is

  27. Ge0rG

    There was a surprise PR update to this in https://github.com/xsf/xeps/pull/1104

  28. Ge0rG

    So I suggest to instead vote on: - accept PR#1104 - include CVE-2019-16235 and CVE-2020-26547 blocks from 0280 - accept the resulting XEP as Stable

  29. dwd

    Yeah, so wait for that PR to go in, and the security considerations you wanted?

  30. dwd

    Well, we can't really vote on anything given that.

  31. Ge0rG

    dwd: that PR is an author update based on LC feedback.

  32. Ge0rG

    and the CVE inclusion is viewed as Editorial.

  33. dwd

    Oh, is it? Either way, I'd like to vote once we have those merged.

  34. daniel

    > Oh, is it? Either way, I'd like to vote once we have those merged. +1

  35. dwd

    I'm not sure that writing a load of security considerations really can be Editorial.

  36. Ge0rG

    Okay, so we wait for jonas’-the-Editor to push the merge button and to perform the respective boilerplate tasks.

  37. Ge0rG

    dwd: the security considerations are LC feeback ;)

  38. dwd

    Yes... But that doesn't make them editorial.

  39. Ge0rG

    dwd: no

  40. Ge0rG

    the question is: do we need another LC for feedback integrated from a previous LC?

  41. Zash

    I think not

  42. Ge0rG

    If not, then the next step would be to apply the PR and to vote for advancement into Stable.

  43. dwd

    Yes, sounds right to me.

  44. Ge0rG

    Or to vote for advancement based on the pre-condition of the PR being applied.

  45. dwd

    As in, no need for another LC.

  46. dwd

    But we can't vote on a XEP not in front of us.

  47. Ge0rG

    That's a tough point indeed.

  48. daniel

    Technically we have in the past I think

  49. daniel

    But there is absolutely no rush

  50. Ge0rG

    So let's have the Editor merge the PR and then we will re-elect.

  51. Ge0rG

    daniel: I'm actually not sure why there is sudden activity on this XEP after half a year of silence, but I'm very glad that it *is* happening.

  52. Ge0rG

    That said, I still have a long list of issues that weren't addressed in this PR, given that they were not blocking the advancement.

  53. Ge0rG

    5) Pending Votes None.

  54. Ge0rG

    Good job, everyone :)

  55. Ge0rG

    6) Date of Next

  56. Ge0rG

    +1W WFM

  57. daniel

    +1w wfm

  58. dwd


  59. Ge0rG


  60. Zash

    +1w wfm

  61. Ge0rG

    Awesome. Let's hope that jonas’ comes back well after the party.

  62. Ge0rG

    7) AOB

  63. daniel

    Non here

  64. dwd

    daniel, Bit French, that.

  65. Ge0rG

    dwd: even if PR#1104 fixes the blockers for me, I'd still love to see some more discussion of the usefulness and treatment of type=groupchat in user's MAM. It would be great if you could follow-up on list.

  66. dwd

    Yes. And I will.

  67. daniel

    Tldr It makes no sense with plain xep45 but can be very useful with muc light, muc/sub and stuff?

  68. Ge0rG


  69. Ge0rG

    daniel: looks like that.

  70. daniel

    And maybe or maybe not with MIX

  71. Ge0rG

    But in that case I'd say that 0313 should say "don't do that" and the other specs define how and when to store

  72. Ge0rG

    the only reason we get the include-groupchat query var is not breaking legacy systems.

  73. Ge0rG

    Well, that's my fringe opinion at least.

  74. Ge0rG


  75. Ge0rG

    Alright, then.

  76. Ge0rG

    8) EOM

  77. Ge0rG

    Thanks, everyone.

  78. Zash

    Thanks Ge0rG

  79. dwd

    Thanks Ge0rG

  80. Kev

    I don’t agree it makes no sense with 45, FWIW.

  81. Kev

    If you want the user to be able to search their archive for messages they’ve seen, it’s the only choice you’ve got.

  82. Zash

    Not as straight-forward at least

  83. Ge0rG

    Kev: I'd love to see a response from you on-list :)

  84. Kev

    There are assorted problems with it, and I’m ok (obviously) with the patch that makes it optional, but we simply don’t have another mechanism for it.

  85. dwd

    I mean, it's a bit crappy with XEP-0045, but then, everything is if what you really wanted was persistent groupchats.

  86. Kev

    And FWIW, I think requiring people to restate their arguments over and over and treat them eventually getting bored of repeating themselves as a sign that their arguments don’t need to be considered to be distinctly suboptimal.

  87. Ge0rG

    Kev: I'm sorry for leaving such an impression. I'm guilty of deriving "this doesn't make sense" from "this doesn't make sense for me"

  88. Kev

    I get that lots of people don’t care about being able to have complete archives of chats they’ve been in, and that’s fine, and making this optional means whole deployments can not have to care about it, but some people do care about that, and we shouldn’t be pointlessly changing protocol to prohibit servers from addressing that use case.

  89. Ge0rG

    Kev: it's a very valid use case, and I'm using a dedicated client with a local on-disk archive to solve that problem in a different way.

  90. Kev

    Storing MUC history in MAM sucks royally. But if you want to have access to chat history for all chats you’ve been in, it’s the only thing we’ve got, and it sucking is better (for some people) than not having it.

  91. Ge0rG

    Kev: what I'm saying is that as written, 0313 is not well suited to solve this problem, but opens a large number of 0045ities instead.

  92. Ge0rG

    Normally, Experimental is the phase in which we convert an ugly hack into a sort of viable long-term solution.

  93. Ge0rG

    0045 logs in user MAM still fall into the "ugly hack" category for me, so please convince me it's not.

  94. Kev

    Protocol-wise, I think 313 as-written (at least after the patch that makes it optional) is fine. It defines what’s needed for interop. But the onus is definitely on the server to somehow make the presented archive not suck. I can add some additional words explaining some of the ways that gc in user archives sucks, if that helps.

  95. dwd

    Ge0rG, How would you address the user requirements without a local on-disk archive?

  96. Kev

    Or even with an on-disk archive, if you have multiple clients.

  97. dwd

    Kev, That's easy, you just make MAM queries to the client you keep continuously online...

  98. Ge0rG

    Again, I'm not saying that your problem is invalid, I'm questioning the non-solution that is "stuff all groupchat into user MAM"

  99. Ge0rG

    full-text-search is not even part of MAM.

  100. dwd

    Ge0rG, Yes, but my assertion would be that it's not MAM that's the issue, but MUC.

  101. dwd

    Ge0rG, Also, not in the core, but it is an enabler for it.

  102. Kev

    That somewhat depends what you mean by ‘part of MAM’ - 313 as-written allows arbitrary form fields, and those can be used for search.

  103. Ge0rG

    dwd: yes, but having "stuff all groupchat into MAM" makes it a MAM issue, too.

  104. Ge0rG

    Kev: yes, and I'd love to see a dedicated FTS XEP on top of MAM, and that one could cover "store all groupchat messages in the user's archive, and search them for FTS queries"

  105. Ge0rG

    But as written now, as a client developer I must expect random subsets of past MUC histories from unrelated clients to fall upon me during initial startup sync.

  106. dwd

    Ge0rG, Which is quite useful with MUCSUB, Muclight, or MIX. :-)

  107. Kev

    You will always have to expect that as a client.

  108. Ge0rG

    dwd: none of which are MUC

  109. dwd

    Ge0rG, Well, MUCSUB is, kinda-sorta.

  110. Kev

    MAM is out there with gc results in it, you can’t change that. So the option is to disallow that with a namespace bump, or make it optional as in Dave’s proposal and my text (or to fix any non-compliant implementation currently out there that *doesn’t* do that).

  111. dwd

    Ge0rG, Also I think the Tigase people have something around groupchat to offline members.

  112. Kev

    There’s no way out of this that doesn’t involve clients written against this namespace of MAM having to accept gc messages if presented them.

  113. Ge0rG

    Kev: yes, you convinced me of that much. But I still don't see why or how it could make sense.

  114. Ge0rG

    And if namespace bumps weren't that expensive, I'd rather have suggested to remove gc and to bump.

  115. Kev

    Ignoring MAM search, what if you’re a full-sync client that wants to be able to search local archives? The only way to do that full sync is MAM, and that would also rely on gc messages in a full-sync query in order to build the local archive.

  116. Ge0rG

    Kev: you can't rely on a full gc history in the user archive, so you must ask the MUC for gc history anyway.

  117. Kev

    If your server includes gc in the archive you can rely on it returning the full history of what you’ve seen.

  118. Ge0rG

    Kev: so a full sync is to ask the user archive for non-gc and then each relevant MUC for its respective gc history.

  119. Kev

    Searching a full MUC history is different to searching your chats you’ve been in.

  120. Ge0rG

    the full history of what I've seen is not the full history.

  121. Kev

    And your client has no way of knowing what MUCs you’ve been in in the past.

  122. Ge0rG


  123. Kev

    (Unless it queries MAM for it)

  124. Wojtek

    > Ge0rG, Also I think the Tigase people have something around groupchat to offline members. this is just based on "registration" to the room and then sending messages irregardless if someone is in the room or not (with presence); though - this doens't necesarily invovled MAM and can be handled with regular "offline messages" spool

  125. Kev

    None of this is nice, but it is where we are.

  126. Ge0rG

    Kev: But now you've promoted a technical service interruption to a permanent message loss.

  127. Kev

    If we were writing XMPP from scratch there are many things we wouldn’t do this way.

  128. dwd

    It's nice that everyone has a non-interoperable solution to avoiding using MIX. :-)

  129. Ge0rG

    Kev: we have written MAM from scratch

  130. dwd

    (Though I think Tigase's is perhaps the neatest)

  131. Kev

    Indeed, and MAM isn’t the problem, MUC is.

  132. Ge0rG

    Kev: and once again, storing MUC messages in MAM makes it a MAM problem.

  133. Kev

    MAM storing group chat messages is absolutely fine in the face of MIX or whatever that doesn’t do fan-out.

  134. Ge0rG

    Kev: yes, and that's preconditioned on the MIX feature, and clients will use a MIX signal to obtain that history

  135. dwd

    (And good luck if you want servers to figure out what sort of GC it is)

  136. Ge0rG

    Even though MIX also didn't solve the s2s interruption message loss problem.

  137. Ge0rG

    dwd: do it based on the <x> element.

  138. Zash

    Isn't that something XEP-0198 is supposed to solve?

  139. Kev

    Although I don’t think anyone’s written it yet, I haven’t yet heard (that I can remember) why the MIX-sync stuff from the last summit wouldn’t work.

  140. Ge0rG

    Zash: s2s 0198 when?

  141. Zash

    We already have it

  142. Ge0rG

    Kev: I wasn't there and I didn't hear it, so I need to read it to say if it works.

  143. dwd

    I'm not entirely sure that it's possible to fix entirely. But '198 on S2S should mitigate at least. If you want to detect loss, you'll need a Merkel tree.

  144. Zash

    s2s-198 might be a touch underspecified tho, but it seems to at least not horribly break stuff

  145. Ge0rG

    I'd *love* to see answers to all that questions, and it might even be possible to learn from them to improve MUC.

  146. Zash

    dwd, did you say Blockchain?

  147. dwd

    Zash, No, I didn't. I said Merkel tree.

  148. Ge0rG

    s2s-0198 won't easily work over server restarts.

  149. Ge0rG

    please get Merkel out of my head.

  150. dwd

    Ge0rG, As I said, you can't prevent message loss.

  151. dwd

    Ge0rG, And she'll be gone soon enough.

  152. Ge0rG

    dwd: thanks for reminding me that the alternatives are all worse.

  153. Kev

    Youdon’t need a merkel tree to detect loss, it’s sufficient to be sequenced.

  154. dwd

    Kev, If you assume a sequencing point, yes.

  155. Zash

    Pointer to previous message?

  156. Zash

    Linked list?

  157. Ge0rG

    dwd: you can prevent message loss with a client that directly queries the MUC MAM archive.

  158. Kev

    Zash: That was the unit proposl, yes.

  159. Kev

    Zash: That was the summit proposal

  160. Kev

    Zash: That was the summit proposal, yes

  161. dwd

    Ge0rG, You can if the remote server's down.

  162. Ge0rG

    dwd: the remote server is not going to remain down forever, right?

  163. dwd

    Ge0rG, Whyever not?

  164. Ge0rG

    (well, if it is, at least we know that it is down and that we are somewhere near the end of the room history)

  165. Ge0rG

    I think the probabilities of "server gets disconnected" and "server goes down forever" are multiple orders of magnitude apart.

  166. Ge0rG

    It might make sense to optimize for the frequent event.

  167. dwd

    Ge0rG, Sure.

  168. dwd

    Ge0rG, I'm just saying you can't eliminate the problem, just mitigate.

  169. Ge0rG

    And the flaky network infrastructure that I live on causes more than one MUC disconnect per day, on average.

  170. Ge0rG

    dwd: but you can't paper over the problem by pretending that "all the user has seen" = "all there is"

  171. dwd

    Ge0rG, No, you can't. But if you wan tto search for a message you've seen, that's enough.

  172. Ge0rG

    and now we have completed the circle :)

  173. Ge0rG

    I wonder if it would be feasible to add all discussed XEP numbers into the title of council meeting minutes, for easier mailbox search.

  174. Ge0rG

    So I've finally worked through the LC feedback on XEP-0280, and created three patches at https://gitlab.com/xsf/xeps/-/merge_requests/42

  175. Ge0rG

    Rendered version at https://ge0rg.gitlab.io/-/xeps/-/jobs/1573759155/artifacts/rendered-changes/xep-0280.html

  176. Ge0rG

    I'd like to discuss https://gitlab.com/xsf/xeps/-/merge_requests/42/diffs?commit_id=64f87e1d2ac8c60edd1355bc96ecfda25a603fc8 in next week's meeting, as it looks to me like it would require Council approval.