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 OK.
  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 OK:
  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 On-list.
  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 on-list
  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 OK.
  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 +1W?
  76. jonas’ wfm
  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 OK.
  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’ +1
  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 Great.
  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’ mmm
  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 Yes.
  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’ yeah
  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’ hardly
  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