XMPP Council - 2019-09-04

  1. Lance has joined

  2. Lance has left

  3. Lance has joined

  4. Lance has left

  5. Lance has joined

  6. lnj has joined

  7. Tobias has joined

  8. linkmauve has joined

  9. Remko has joined

  10. ralphm

    It is not a Dutch expression either, but we've been quite present on the edges of the anglosphere.

  11. daniel has left

  12. daniel has joined

  13. Reventlov has left

  14. Reventlov has joined

  15. Ge0rG

    So it's similar to the jokes that were made around XEP-0420

  16. Zash has joined

  17. Zash has left

  18. daniel has left

  19. daniel has joined

  20. daniel has left

  21. daniel has joined

  22. Tobias has left

  23. Tobias has joined

  24. Guus has left

  25. Guus has joined

  26. linkmauve has left

  27. Ge0rG

    It's time, isn't it?

  28. dwd

    Yes, indeed.

  29. dwd

    1) Roll Call

  30. Kev

    It is, but I've not noticed an agenda.

  31. dwd

    Yes, sorry - I'm on the road so I've struggled with that this week.

  32. dwd

    jonas’ ?

  33. Ge0rG

    jonas’ was here just two minutes ago

  34. Ge0rG

    the jabberfr linkmauve dropped out just five minus before the meeting.

  35. jonas’

    I’m here

  36. dwd


  37. jonas’

    we have a ProtoXEP

  38. dwd

    2) Agenda Bashing

  39. Kev

    I find no fault in the published agenda.

  40. dwd

    So we have CS-2020 as a ProtoXEP. I don't know of any other requests for the agenda.

  41. jonas’

    there’s one [needs council] we haven’t voted on I think

  42. jonas’

    this one: https://github.com/xsf/xeps/pull/812

  43. dwd

    Ah, yes.

  44. dwd


  45. dwd

    3) Items for a Vote:

  46. dwd

    a) Adopt https://xmpp.org/extensions/inbox/cs-2020.html (XMPP Compliance Suites 2020)

  47. Ge0rG

    +1 obviously. Also I'd like to AOB that a bit

  48. Kev


  49. jonas’

    +1, I think we can discuss all content details in Experimental stage for this one.

  50. dwd

    I'm afraid I need some time to look at this, so on-list.

  51. dwd

    (I can't imagine why I'd do anything but +1)

  52. dwd

    AOB noted.

  53. dwd

    b) https://github.com/xsf/xeps/pull/812 (Bump bytes datatype from unsignedShort to unsignedInteger)

  54. Ge0rG


  55. dwd

    I'm +1 on this. It's just rectifying an error in the XML schema.

  56. dwd

    Note that vanitasvitae posted about this on the list as well.

  57. Kev

    Default to +1 unless I think of a reason it's daft later.

  58. jonas’

    yeah, +1

  59. Lance has left

  60. dwd


  61. pep.

    I poked lm

  62. pep.

    (via sms)

  63. dwd

    4) Outstanding Votes

  64. pep.

    But apparently it's over already.

  65. jonas’

    not quite yet

  66. dwd

    IIRC, Ge0rG has some outstanding, as does Link. I think the rest of us have voted lodged.

  67. Ge0rG

    I mailed in my votes yesternight

  68. dwd

    Ge0rG, Oh, sorry.

  69. Ge0rG

    At least I think now that I'm synced.

  70. dwd

    In that case, I think XEP-0353's vote is done, so we're just pending on XEP-0300.

  71. jonas’

    I change my vote on XEP-0353 advancement to -1

  72. jonas’

    I think the Last Call has provided valuable feedback and that needs to be considered before moving to Draft.

  73. dwd

    jonas’, Noted, thanks.

  74. dwd

    5) Next Meeting

  75. dwd


  76. jonas’


  77. dwd

    6) AOB

  78. Ge0rG

    +1W WFM

  79. dwd

    Ge0rG, hit it.

  80. Ge0rG

    I have two AOBs regarding CS-2020, one regarding Message Errors and one regarding Attach-To-Reactions.

  81. dwd


  82. Ge0rG

    I'll start with CS-2020a: introductory text. The text in XEP-0412 is awful at informing developers that this is *THE* XEP to use as a guidance on what to implement first

  83. Ge0rG

    I'd like to change the intro in CS-2020 and to make "compliance" a remote second in it.

  84. jonas’


  85. pep.

    (https://github.com/siacs/Conversations/issues/3530 as an exemple of how it's not being advertized correctly)

  86. dwd

    Isn't this a third AOB item? But anyway, I'm fine with whatever you like.

  87. jonas’

    dwd, I was confused for a second, too, but I think there are four AOBs in total, two for CS, one for Message Errors and one for Attach-to-Message

  88. Ge0rG

    what jonas’ said

  89. dwd

    Ah. Ge0rG, master of the AOB.

  90. Ge0rG

    We still have 8mins left

  91. Ge0rG

    No wait, my clock is off.

  92. dwd

    But yes, I'm absolutely fine with some different introductory text.

  93. Ge0rG


  94. Ge0rG

    AOB CS-2020b: https://xmpp.org/extensions/inbox/cs-2020.html#future - I've added that section because we need something like it, but the content I've put there is very very rough.

  95. Ge0rG

    Please throw XEP numbers at me

  96. dwd

    Ideally, that text would have broad agreement from the community, mind.

  97. Ge0rG

    dwd: I'm sure we can gain that via a Last Call.

  98. Kev

    In an ideal world the community would agree with us.

  99. jonas’

    Ge0rG, XEP-0500

  100. dwd

    Ge0rG, But what if Royal Assent is withheld?

  101. Kev

    Equally, technical direction is one of the few things Council has purview over.

  102. dwd

    Sorry, wrong politics.

  103. Kev

    So by our process the most important thing is that Council agrees to a statement of technical direction.

  104. dwd

    Kev, That's true enough. Also, "Ideally".

  105. dwd

    Ge0rG, WRT "Future Development", I suspect that could cause a lot of discussion, and potentially few conclusions.

  106. jonas’

    dwd, Ge0rG, I tend to agree

  107. jonas’

    I think "future development" is more like a wiki page

  108. Ge0rG

    dwd: Maybe that. Or it will get ignored, like most other topics.

  109. dwd

    Ge0rG, I mean, your call. But I think it might be the cause of much stress for little benefit.

  110. Kev

    I think a little tweaking would make it fine.

  111. Ge0rG

    I'm not going to die on that hill. If there are issues, I can axe that section

  112. Kev

    If it simply said "These are the areas that Council believe ..."

  113. Kev

    Then if we agree between ourselves, it's non-contentious.

  114. dwd

    Or if it suggested these were areas under development rather than a forecast of the future.

  115. Kev

    I very very much think we should have that section, because we need to stop using the compliance suites as a form of wishful thinking, which we often seem to.

  116. dwd

    Kev, Yes, I can accept that.

  117. jonas’


  118. jonas’

    I tend to agree with the sentiment, Kev, but I don’t think the CS are the right place for that. Maybe they are, though, because it makes it very clear immediately what they are for (by having a dedicated Future section)

  119. Ge0rG

    Kev: so you say we need to move the wishful thoughts into that section?

  120. jonas’

    so, no strong opinion either way from my side

  121. Kev

    Ge0rG: Yeah.

  122. dwd

    Ge0rG, If you're up for the pain, keep the section and we'll see what we can do with it. But I won't blame you if you find it more painful than you can be bothered with.

  123. Kev

    The world that we wish it to be, rather than what it currently is, can sit in that section.

  124. Ge0rG

    I think there is value in having a section that contains XEPs that a (client) implementor should closely watch, or even implement under the premise that they will change.

  125. jonas’

    Ge0rG, +1 to that sentiment, too

  126. dwd

    Ge0rG, There's both aspirational stuff and development stuff that could be there.

  127. Kev

    +1 to the sentiment

  128. dwd

    But you're running out of time for Errors and Reactions.

  129. Ge0rG

    dwd: so we need sub-sections

  130. Kev

    Ge0rG: Or maybe a summary of why it's there.

  131. Ge0rG


  132. Kev

    Anything along those lines would work for me.

  133. Ge0rG

    Well, well.

  134. Ge0rG

    The other AOBs won't fit into the remaining 3 minutes.

  135. Ge0rG

    They rather deserve a Council Meeting of their own. Each of them.

  136. Ge0rG

    Please comment on the "Persisting Message Errors (XEP-0280, XEP-0313, XEP-0160)" thread on standards@!

  137. Kev

    We need to rethink archives so drastically it's painful.

  138. Ge0rG

    What about starting to rethink message delivery, and then fixing archives on the way?

  139. Kev

    That works.

  140. Ge0rG

    Oh wait, we started that two years ago.

  141. dwd

    Well, errors I basically agree with. I should say so on the mailing list.

  142. dwd

    If I haven't.

  143. Ge0rG

    dwd: you haven't

  144. Lance has joined

  145. dwd

    Reactions-and-attaching-and-stuff, I'm a little concerned that unless someone comes up with a proposal there, we risk rejecting every XEP in the space out of hand, which seems less than useful.

  146. dwd

    Assuming that was the other AOB.

  147. Ge0rG

    dwd: it was indeed.

  148. jonas’


  149. Kev

    Ralph and I were working on stuff that I hope leads to a proposal.

  150. Ge0rG

    dwd: we had a very productive discussion the other day on xsf@, and I've tried to summarize it in a gist.

  151. jonas’

    I tried to get hold of the authors of Reactions and didn’t get a reply

  152. Ge0rG

    I should just dump it onto standards, I suppose.

  153. dwd

    jonas’, I believe that one of them joined the XSF, which is positive.

  154. Kev

    Ge0rG was in the discussion too, actually. I wrote up some gists, Ralph is writing those up in a more consumable form.

  155. dwd

    Ge0rG, Please.

  156. Ge0rG

    Three kinds of "References" in XMPP: * Thread (in-reply-to); largely off-scope for our discussion * References of things mentioned in the payload/body of a message (0372) - nicknames, URLs, old messages by means of xmpp: URI, etc. - multiple Reference elements are allowed - Can be used inside Attach-To to add References to a previous message - Can be sent by anyone - is irrelevant to MAM 2.0 * Attach-To for content that only makes sense in the context of another message - Usable for Reactions, Edits (former LMC), Retraction, Image / website previews, Receipts(?), Read Markers(?) - A message can be attached at-most to one other message (nobody could think of a case where it would be needed, Ge0rG still objects) - allows grouping / special handling by MAM 2.0, e.g. for thin clients - generally, the attached payload SHOULD be inside of the <attach-to> element (e.g. reactions) - for E2EE and legacy Last Message Correction, an <attach-to> without a payload implies that the sibling elements need to be reviewed - Some kinds of Attach-To can only be sent by the original author or a privileged entity (bot/admin in MUCs) - Attach-To messages SHOULD NOT be nested, i.e. attach-to another Attach-To message

  157. Ge0rG

    Kev: what form is ralphm writing them in?

  158. Kev

    He's got a draft blog post about it.

  159. jonas’

    Kev, can’t you make that proposal right away and get early feedback from the community?

  160. jonas’

    ah; I’d prefer a ProtoXEP tbh

  161. dwd

    I am somewhat concerned with rejecting a XEP for not using another XEP that doesn't exist.

  162. Kev

    I think a description of the concept is more useful than a protoXEP at this point.

  163. jonas’

    dwd, yes

  164. jonas’

    Kev, a ProtoXEP could be a description of the concept

  165. jonas’

    it doesn’t have to be standards track, mind

  166. jonas’

    (even though I’d prefer that)

  167. dwd

    It seems that it is not the fault of the authors, and nothing they can possibly do can remedy it.

  168. Kev

    Ok. I got ahead of my schedule today.

  169. Kev

    So I can write something tomorrow, interruptions allowing.

  170. jonas’

    dwd, well, they *could* come up with a solution ;)

  171. jonas’

    but meh

  172. Kev

    dwd: Other than have said "Yes Kev, go ahead and make your suggestion"

  173. jonas’

    Kev, I’m saying that because I know what happens to draft blog posts

  174. Kev

    I mean, I did offer to 'fix' it.

  175. Ge0rG

    Kev: it seems that you were the only one who interpreted your response as an actual offer to 'fix' it ;)

  176. Kev

    Am I updating Sam's spec, or writing a new mostly duplicate one for attaching, or rolling it into References?

  177. jonas’

    Ge0rG, no, I also interpreted it that way actually

  178. jonas’

    Kev, we need to do a breaking change to the protocol in any case

  179. jonas’

    so I’d say go with a separate document for now, see what happens. It also prevents issues with getting Sam on board.

  180. Kev

    Yes, but I would like Council to give me guidance here because I don't want a fight about having done the wrong thing.

  181. Ge0rG

    I disagree with jonas’ here. Don't make a copy of Attach-To

  182. jonas’

    I can still git mv inbox/kevs-thing.xml xep-0367.xml

  183. jonas’

    I don’t have a strong opinion towards a separate document.

  184. Ge0rG

    Can somebody summon Sam?

  185. jonas’


  186. jonas’

    but MattJ is a co-author

  187. Kev

    Would I be right in assuming there is no desire to have all this described in a single document (references)?

  188. Ge0rG

    Kev: right.

  189. jonas’

    Kev, references needs fixing first

  190. dwd

    Kev, I honestly don't care.

  191. jonas’

    I made proposals on-list about that a year ago or so

  192. Ge0rG

    Kev: from our last discussion, we figured out three use cases. They should have three documents

  193. Kev

    jonas’: There's two halves - one is references, the other is attaching.

  194. dwd

    The other half is MAM, of course.

  195. Kev

    (Or three halves, if you include threads, which I think we decided to punt for now)

  196. dwd

    We're 10 minutes over, so unless anyone's got anything else pressing, I'm going to call it a day.

  197. Kev

    I would like a concrete agreement on my approach.

  198. Kev

    Update References for the one half, new protoXEP for the other (which can later overwrite attachment if people agree)?

  199. jonas’

    Kev, ok, I don’t have a strong opinion on whether you do a new document or not, but I strongly don’t think that References is the right place for this.

  200. Ge0rG

    TBH, with the ideas around redoing attach-to and to put the payload inside of the attach-to element, maybe forking it into a new document is the better way forward

  201. jonas’

    Kev, ok, I don’t have a strong opinion on whether you do a new document for attaching or not, but I strongly don’t think that References is the right place for this.

  202. Kev

    Just give me a +1 on my approach, please people, and we can go home :)

  203. jonas’

    Kev, pragmatically, I’d say prepare an update to Message Attaching

  204. jonas’

    if we find it should be a separate XEP, that’s a trivial thing to do

  205. Kev

    I would rather not deal with the admin of removing an author if Sam doesn't believe it should be used for this, but if that's the will of Council I'll go that way.

  206. Kev

    Just between the three of you agree something, please.

  207. jonas’

    Kev, in that case we can still fork into a new XEP.

  208. Kev

    My preference is fork for now, as I said.

  209. Kev

    But I will do either.

  210. jonas’

    do whatever you like (except merging into References) from my side

  211. jonas’

    the rest is just editor dutywork which I’m happy to do

  212. dwd

    Kev, Least contentious is write a new XEP.

  213. jonas’

    my main point is, get a proposal out there

  214. dwd

    Kev, Since it's much easier to merge into an existing one later if we choose that.

  215. Kev

    And Ge0rG already said fork, so I think that's agreement. Thanks.

  216. Ge0rG

    Message Attaching 2

  217. Kev

    I will see what I can get done tomorrow.

  218. Ge0rG

    I don't like forking.

  219. jonas’

    "... (This time it’s going to stick around)"

  220. jonas’

    Ge0rG, please.

  221. linkmauve has joined

  222. dwd

    jonas’, He's suggesting a new XEP, not a fork. That's fine.

  223. Ge0rG

    XEP numbers are cheap, right?

  224. linkmauve

    Aaah, sorry! I was moving to the Berlin XMPP Meetup just during council meeting! >_<

  225. jonas’

    they are

  226. dwd

    linkmauve, Well, I think I'm finally going to close this meeting, so perfect timing...

  227. Kev

    Thanks all.

  228. dwd

    X_1) Ite, Meeting Est

  229. jonas’

    thanks dwd for chairing, thanks Kev for taking a stab on the attaching thing, thanks everyone for everything

  230. Ge0rG

    thanks jonas’ for the encouraging words

  231. Tobias has left

  232. Tobias has joined

  233. Lance has left

  234. Kev_ has left

  235. Lance has joined

  236. Wojtek has joined

  237. Wojtek has left

  238. Lance has left

  239. Kev

    https://github.com/Kev/xeps/blob/fasten/inbox/fasten.xml That's ludicrously simple, but I think it works as a first indication of how the marking that a payload applies to an earlier message would look.

  240. Kev

    There are several details of the (primarily) ralphm / Ge0rG / Kev discussion that still need reflecting there, and References also needs work, I realise.

  241. Guus has left

  242. Guus has joined

  243. daniel has left

  244. daniel has joined

  245. jonas’

    Kev, FYI https://mail.jabber.org/pipermail/standards/2018-March/034559.html

  246. ralphm

    Ge0rG: what Kev said. I'm drafting a blog post, with various way of pointing to things (attaching, referencing, etc.), in protocol and visual renderings, along with explanatory prose.

  247. jonas’

    let’s move this to xsf@?

  248. ralphm

    Ge0rG: [moved over to xsf@]

  249. linkmauve has left

  250. Reventlov has left

  251. Reventlov has joined

  252. Remko has left

  253. moparisthebest has left

  254. lnj has left

  255. moparisthebest has joined

  256. moparisthebest has left

  257. moparisthebest has joined

  258. Kev

    jonas’: Thanks. I'll try to incorporate that when I get to references.

  259. linkmauve has joined

  260. Wojtek has joined

  261. Wojtek has left

  262. Tobias has left

  263. linkmauve has left

  264. moparisthebest has left

  265. moparisthebest has joined

  266. moparisthebest has left

  267. moparisthebest has joined