XMPP Council - 2019-09-11

  1. debacle has left
  2. Remko has joined
  3. peter has joined
  4. Remko has left
  5. peter has left
  6. Remko has joined
  7. Remko has left
  8. Tobias has joined
  9. daniel has left
  10. daniel has joined
  11. lnj has joined
  12. Remko has joined
  13. Remko has left
  14. Remko has joined
  15. Ge0rG There is no agenda yet, so I'd like to bring up for vote: - https://github.com/xsf/xeps/pull/820 - https://github.com/xsf/xeps/pull/822
  16. Neustradamus has left
  17. Neustradamus has joined
  18. Neustradamus has left
  19. Neustradamus has joined
  20. Link Mauve has left
  21. jonas’ also, ProtoXEPs
  22. Ge0rG I even started typing an agenda mail, but then I wasn't able to resist the urge to call it "Twin Towers Edition" and thus I quickly deleted the draft
  23. debacle has joined
  24. Remko has left
  25. Remko has joined
  26. peter has joined
  27. peter has left
  28. peter has joined
  29. peter has left
  30. dwd has joined
  31. undefined has left
  32. dwd You should have written it. I only just noticed it's Wednesday.
  33. jonas’ time is tricky
  34. Ge0rG dwd: it would've been biased.
  35. undefined has joined
  36. peter has joined
  37. Ge0rG dwd: the time. It is.
  38. Kev Here, we are.
  39. jonas’ .
  40. undefined has left
  41. dwd Yes indeed.
  42. dwd 1) Roll Call.
  43. jonas’ is here
  44. Link Mauve has joined
  45. Link Mauve Hi, I’m here!
  46. undefined has joined
  47. dwd Presumably that's a full house then.
  48. Link Mauve Just on time I see. ^^'
  49. dwd 2) Agenda Bashing
  50. dwd Given I didn't notice it was Wednesday, I've not managed one at all, sorry.
  51. Kev We've certainly got fastening on it.
  52. dwd I see one announced ProtoXEP, and one merged but not yet announced, is that right?
  53. dwd Plus the two github PRs above.
  54. jonas’ seems realistic
  55. jonas’ the merged one isn’t built yet, thus not announced
  56. dwd OK, sounds good. So three things.
  57. dwd 3) Items for a vote.
  58. dwd a) Proposed XMPP Extension: Message Fastening
  59. dwd https://xmpp.org/extensions/inbox/fasten.html
  60. Ge0rG This is clearly duplication of existing work.
  61. Ge0rG The author should collaborate with the authors of Attaching.
  62. jonas’ it *is* duplicating existing work, and I find the remarks on the mailing list on lack of examples on how this helps with magic MAM relevant
  63. sonny has joined
  64. undefined has left
  65. Ge0rG There *is* merit in requiring to re-think magic MAM in this context, but maybe Council will be confident enough in this wire format to bear whatever magic MAM will require?
  66. undefined has joined
  67. dwd What is the actual distinction between this and XEP-0367?
  68. Kev dwd: Council decided last week that they'd rather a new protoXEP was submitted/accepted than 367 updated. As you'll remember.
  69. jonas’ something about the <external/> stuff doesn’t sit right with me either, and I’d like to see a practical motivation for it
  70. Kev During our discussion of whether it should be a new XEP, or an update to 367
  71. jonas’ (FWIW, I’m not strictly arguing for rejecting this because of dup)
  72. dwd Kev, Sure. But what is the difference between this as '376 beyond "it's in a different document"?
  73. dwd Kev, Sure. But what is the difference between this as '367 beyond "it's in a different document"?
  74. jonas’ the lack of fastenings to fastenings seems like an unnecessary restriction to me
  75. Kev dwd: Mostly the external stuff, the replacing, and the removing that I need to push once it's accepted.
  76. Link Mauve I haven’t had the time to read this protoxep entirely yet, I just skimmed through it, but indeed that sounds like it would restrict future usecases we don’t know about yet.
  77. Kev As I've said before, it would fit well into 367 as long as we're happy to update 367 with it.
  78. Link Mauve Such as for instance a fictional external approval for an edit.
  79. Kev Link Mauve: Yes, deliberately. Better, in this case, to restrict now and loosen later, than to end up with confusion where we didn't specify the use cases that we didn't anticipate properly.
  80. Ge0rG so maybe the question for Council should be: 1) bury 0367, accept Fastening 2) Merge Fastening into 0367 3) Have both in parallel
  81. Link Mauve Kev, we’ve had that in the past with 0308, where devs mostly ignored the “last” message restriction, and instead allowed to correct any without further negociation.
  82. dwd I mean, I'm basically fine with the document in isolation. But my impression was that XEP-0367 was unsuited to, for example, reactions. But fastening seems essentially similar to '367, so I'm wondering what fastening gains us that '367 does not.
  83. Link Mauve But fair enough.
  84. Kev dwd: This started because we were told that Sam (as author) did not want 367 used for reactions.
  85. Ge0rG dwd: 0367 is well suitable for reactions, give or take some minor business ruls
  86. jonas’ dwd, the only thing which made '367 "unsuitable" was that folks had the strong opinion that reactions are not attachments
  87. Kev The initial plan was to just update 367
  88. Kev Then last week I asked for a clear direction from Council as to whether to update 367 or publish something new because I did not want discussions about what the right thing to do was *after* I did the work. We concluded 'publish a new XEP'. Here we are.
  89. Kev We can, of course, go with Sam's offer of adding me as an author of 367 and having at it that way. I'll just be really annoyed by Council's policy flip.
  90. Remko has left
  91. jonas’ Kev, I think there was an expectation that your proposal would go further beyond what '367 has
  92. jonas’ but I may be wrong
  93. Ge0rG I'd be fully okay with burying 0367 and removing Fastening to New Attaching with a new number
  94. dwd Well, I'm for publishing it, but clearly both '367 and this cannot go on to Draft.
  95. dwd I was just expecting something significantly different from Attaching, I suppose.
  96. Kev FTR, I do *not* think 367 is fundamentally unsuited for this, or that fastening is revolutionarily different to 367. I was Just Following Orders.
  97. dwd Kev, I think that's somewhat unfair, given that you did insist on having orders to follow.
  98. dwd But let's vote on this:
  99. dwd Anyone want to vote?
  100. Kev Someone, anyone?
  101. jonas’ uh, I was expecting you’d spell something out ;)
  102. jonas’ I’m +1 on this
  103. jonas’ we can develop this further in Experimental
  104. Ge0rG dwd: in case we do want to merge Fastening into 0367, wouldn't assigning a new number block us from that?
  105. Ge0rG But yeah, let's make some progress. +1
  106. Kev Ge0rG: I believe if we wanted to C-A, C-C, ->367, C-V, we could.
  107. jonas’ Ge0rG, we can (have Kev) retract Fastening at any time
  108. Kev Although if that's our intention, we could probably just -1 this now and do it immediately.
  109. Ge0rG jonas’: with Kev following orders, I agree
  110. Link Mauve Kev, if we want to have only one, and the three 0367 authors are fine with that, it would better be.
  111. Ge0rG for the protocol, I don't have a strong opinion on that, so we shoud do whatever is good to stabilize fastachments.
  112. dwd I'm +1, just to get progress.
  113. Kev Link Mauve: Technically, the 367 authors don't need to be, but yeah.
  114. Link Mauve Kev, for an experimental one?
  115. Kev Indeed. It's the XSF's, Council get to do what they want, pretty much.
  116. Kev It doesn't belong to the Authors.
  117. jonas’ Link Mauve, we can always remove them as authors :)
  118. Link Mauve I don’t mind having a new number and retracting the 0367 afterwards, or merging it into 0367, so I’m +1 on this too; numbers are cheap.
  119. Link Mauve Right.
  120. Kev I'm +0 :)
  121. dwd Indeed, XEPs belong to the XSF, but only once adopted and given a number.
  122. Ge0rG so everybody voted now?
  123. dwd I believe so - 4*(+1) +0
  124. Kev Yes, 4*+1, 1*+0
  125. jonas’ \o/
  126. dwd OK, moving on.
  127. Ge0rG congratulations Kev
  128. dwd b) https://github.com/xsf/xeps/pull/822
  129. dwd That's just adding an example of something that should be rejected.
  130. Ge0rG +1
  131. Kev +1
  132. dwd Which looks good to me. +1
  133. jonas’ +1
  134. Ge0rG I wasn't sure about the Shakesperean English.
  135. Link Mauve +1 too.
  136. Ge0rG Maybe one of the Brexiters can spellcheck that.
  137. dwd Unanimous +1's.
  138. jonas’ \o/
  139. jonas’ > Merge made by the 'recursive' strategy.
  140. jonas’ > [master 0fbb008] Accept inbox/fasten.xml as XEP-0422
  141. Link Mauve Should we have a new CSS class for examples with a red background, to be certain no one will blindly copy this example?
  142. jonas’ Link Mauve, https://github.com/xsf/xeps/issues/821
  143. dwd c) https://github.com/xsf/xeps/pull/820/commits/8024555dd59926f092ee9ddb713e4d537888771c
  144. Link Mauve jonas’, perfect.
  145. jonas’ Link Mauve, AIUI, this needs amendments to XEP-0001, so a bit of overhead there
  146. dwd That's adding XEP-0333 to carbonization and removing the error note.
  147. dwd Why remove the error note?
  148. Zash has joined
  149. Link Mauve dwd, because errors are important to receive on multiple clients.
  150. dwd Also, why are we voting on this? It's Experimental.
  151. Ge0rG dwd: also because it was only a note, and I don't want server authors to use that note as an excuse not to implement it
  152. Ge0rG dwd: I'm not the author
  153. dwd Should we make Ge0rG the author?
  154. dwd s/the/an/?
  155. Kev I believe that it's impractical to implement for non-trivially-sized deployments, which is why the note is there, and this would need a namespace bump.
  156. jonas’ why did we vote on the previous PR? ;)
  157. Ge0rG dwd: I wouldn't veto such a motion
  158. dwd jonas’, Because I didn't think of this then.
  159. Kev jonas’: Because it's easier than working out the process and potentially arguing.
  160. jonas’ Ge0rG, congrats, you successfully social engineered council and the ediotr ;)
  161. jonas’ Ge0rG, congrats, you successfully social engineered council and the editor ;)
  162. Kev Council voting on changes avoids needing to think about whether a PR without an author's agreement should be merged.
  163. Ge0rG jonas’: only to skip asking the vanished authors
  164. jonas’ I’m not opposed to making Ge0rG an author of '280 FTR
  165. dwd Anyway, I'm fine with moving the note, but as Kev says, this is tricky to implement so I'm not overwhelmingly in favour of removing the note entirely.
  166. Ge0rG Kev: I don't believe it's actually impractical to implement, especially not in the context of persisting message errors, which I still am waiting for feedback on
  167. Kev But it *does* need a namespace bump for adding 333
  168. Kev (Not for carbons itself, for the I Support These Rules feature)
  169. Ge0rG Kev: do you honestly believe that?
  170. Link Mauve Instead of a namespace bump, couldn’t we add a feature to implementations which support that?
  171. Ge0rG I'm not aware of any implementation that advertises that
  172. Kev Ge0rG: M-Link trunk certainly does.
  173. Link Mauve Bumping Carbons would be the worst atm.
  174. Ge0rG Kev: I can imagine changing the text into "it contains payload elements typically used in IM (e.g. &xep0184;, &xep0085;, &xep0333;)"
  175. Kev Since we re-implemented carbons with those rules (without the message tracking) :)
  176. dwd Yes, needs a namespace bump. And if your argument is that it doesn't because nothing [released] advertises the feature, that means a namespace bump is irrelevant.
  177. Ge0rG Kev: I can't imagine how anybody would assume that 0184 and 0085 are an exclusive list of all IM-related payloads.
  178. Kev But in that case, we can't have a feature that says exactly what rules are implemented, and we're back to "Here's the intent, interpret it in your own way".
  179. jonas’ I tend to agree with Kev
  180. jonas’ while we’re bumping, how about CC-ing all error messages instead of just removing that node?
  181. jonas’ while we’re bumping, how about CC-ing all error messages instead of just removing that note?
  182. Ge0rG Okay, in that case I retract the PR until somebody comes up with a conclusive list of all IM-related payloads.
  183. Kev jonas’: I think that *would* be feasible server-side. I wonder what the effect on clients would be.
  184. Ge0rG jonas’: CC-ing MUC(PM) errors will wreak havoc.
  185. Kev Ge0rG: Only if clients weren't prepared for it, though.
  186. Ge0rG again, there is no conlcusive list of possible causes of errors.
  187. jonas’ errors can happen
  188. Kev What if we had <include-errors/> and then a client needs to cope with errors that it didn't trigger?
  189. jonas’ Ge0rG, if your client breaks because it receives a random type=error stanza, you need to reconsider your design decisions anyways
  190. Kev Error correlation is going to be easier client-side than server-side, I suspect.
  191. Kev jonas’: Define 'break'. Swift will tell the user that something has gone wrong.
  192. dwd OK - we seem to have moved into developing a new design, please take that elsewhere.
  193. jonas’ Kev, if your client interrupts the users flow for unsolicited type=error stanzas, you may also need to re-evaluate design decisions
  194. jonas’ dwd, right, ack
  195. dwd 4) Outstanding Votes.
  196. Kev (jonas’: They're not unsolicited - with current routing rules, if the client (with a random resource) receives an error, it's one it triggered.)
  197. Ge0rG Kev: it _might_ receive error carbons.
  198. dwd Link Mauve, You have two outstanding, could you vote please?
  199. dwd 5) Next Meeting
  200. Link Mauve I don’t have access to my emails (my server is down…), could you remind me which ones please? :x
  201. dwd Link Mauve, Advance to Draft: XEP-0300 (Use of Cryptographic Hash Functions in XMPP) - https://xmpp.org/extensions/xep-0300.html Advance to Draft: XEP-0353 (Jingle Message Initiation) - https://xmpp.org/extensions/xep-0353.html
  202. Link Mauve Thanks.
  203. dwd Same time next week?
  204. Link Mauve I’ll shortly do so from my other email account.
  205. dwd I will endeavour to get an Agenda sorted this time.
  206. jonas’ dwd, +1w wfm
  207. Link Mauve Same.
  208. dwd 6) AOB
  209. Kev I won't be here next week, FWIW.
  210. dwd Given we're 7 minutes over, I'm really hoping nobody has AOB.
  211. Ge0rG I still have the same AOBs as the last three times.
  212. Ge0rG Sorry, dwd
  213. dwd Ge0rG, Yeah. I know.
  214. Ge0rG Kev, dwd: did you vote on https://xmpp.org/extensions/inbox/cs-2020.html yet?
  215. dwd I'll try to ensure that with an Agenda and a bit of planning, we allocate more time for these next week.
  216. dwd Oh, I thought I had but I had not. There's also others expiring today.
  217. Kev I don't think I have anything expiring today. I do have stuff expiring next week.
  218. dwd Yes, they expire next week, sorry. I'm a mess today.
  219. dwd Proposed XMPP Extension: XMPP Compliance Suites 2020 - https://xmpp.org/extensions/inbox/cs-2020.html Dave: [on-list] (need time to look at this) Georg: +1 (obviously) Jonas: +1 (we can discuss details in Experimental) Kev: [on-list] Link: [pending] PR #812 - XEP-0084: Bump bytes datatype from unsignedShort to unsignedInteger - https://github.com/xsf/xeps/pull/812 Dave: +1 (just rectifies an error in the XML schema) Georg: [on-list] Jonas: +1 Kev: [on-list] (default to +1, unless I think of a reason later) Link: [pending]
  220. dwd I'll vote +1 on cs-2020. Nothing we can't fix in Experimental, let's get the ball rolling on it.
  221. dwd Anyway, let's call it a day now. See most of you next week.
  222. Link Mauve I’m also +1 on both.
  223. Kev I'm +0. I don't see anything particularly wrong with it, other than that I want to break the cycle of yearly compliance suites.
  224. dwd 7) Ite, Meeting Est.
  225. Link Mauve Kev, did you have the meeting about it yet?
  226. Kev No.
  227. Link Mauve Ok. :(
  228. Ge0rG There is a Council re-election soon, and I'm very sure it will mess up our ability to Last-Call a XEP.
  229. Ge0rG And I want 2020 to be finished before 2019 ends.
  230. Link Mauve I also want to make it a lot more marketing-oriented.
  231. Link Mauve sonny, ↑
  232. Ge0rG Link Mauve: feel free to PR'ovide better text
  233. Link Mauve Ge0rG, it’s not necessarily better text, but more like make noise around it, or rename it from Compliance Suite 2020 to something like XMPP 2020 with logos and a testsuite and other not-really-realistic things for the end of 2019 yet.
  234. daniel Link Mauve, does that include tweeting about it every 5 minutes?
  235. Ge0rG Link Mauve: all those goals are worthy.
  236. jonas’ Ge0rG, any chance you can drop a vote on #812 right now?
  237. jonas’ I’m working on a bunch of merges and yours is the last missing
  238. Link Mauve daniel, I hope not.
  239. daniel i think the name doesn’t really matter. but making it more widely know is certainly a good thing
  240. daniel not just for marketing but also simply to give developers a helping hand
  241. Link Mauve Yes.
  242. daniel but we've also done an ok job with that before
  243. daniel i can still be improved obviously. but it's not that we were totally terrible about that
  244. daniel reminder about the blog post where someone ranted about activitypub and how bad it is and said that activity pub needed something like the compliance suite that xmpp has
  245. daniel and that was someone from outside the xmpp community
  246. Link Mauve Was it Stéphane Bortzmeyer?
  247. sonny Link Mauve and I talked about it today, something like turning complicance suite as an annual XMPP version release, much like the ECMAScript standard
  248. Link Mauve He’s a very well-known protocols guy.
  249. Ge0rG jonas’ [17:47]: > Ge0rG, any chance you can drop a vote on #812 right now? +1
  250. daniel don't recal. no it was an activity pub person i think
  251. Link Mauve Ok.
  252. daniel just saying all that because sometimes with all the internal criticism we fail to see what we actually did right
  253. Link Mauve Indeed. :)
  254. sonny for clarity I really like the work around complicance suites, just thinking about an evolution
  255. Link Mauve sonny, as Ge0rG said, PR’oviding better text or doing things around it would be super cool. :)
  256. sonny 👍
  257. Wojtek has joined
  258. Link Mauve has left
  259. sonny has left
  260. sonny has joined
  261. Wojtek has left
  262. sonny has left
  263. sonny has joined
  264. peter has left
  265. Zash has left
  266. sonny has left
  267. Link Mauve has joined
  268. Link Mauve has left
  269. Link Mauve has joined
  270. undefined http://0x0.st/zJkT.txt
  271. Reventlov has left
  272. Link Mauve has left
  273. Link Mauve has joined
  274. sonny has joined
  275. lnj has left
  276. lnj has joined
  277. debacle has left
  278. debacle has joined
  279. undefined has left
  280. undefined has joined
  281. undefined has left
  282. undefined has joined
  283. undefined has left
  284. undefined has joined
  285. undefined has left
  286. undefined has joined
  287. undefined has left
  288. undefined has joined
  289. undefined has left
  290. undefined has joined
  291. undefined has left
  292. undefined has joined
  293. undefined has left
  294. undefined has joined
  295. Link Mauve has left
  296. undefined has left
  297. undefined has joined
  298. lnj has left
  299. Tobias has left
  300. Tobias has joined
  301. peter has joined
  302. undefined has left
  303. undefined has joined
  304. undefined has left
  305. undefined has joined
  306. undefined has left
  307. undefined has joined
  308. undefined has left
  309. undefined has joined
  310. undefined has left
  311. undefined has joined
  312. undefined has left
  313. undefined has joined
  314. peter has left
  315. sonny has left
  316. sonny has joined
  317. peter has joined
  318. vanitasvitae has left
  319. vanitasvitae has joined
  320. peter has left
  321. debacle has left