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