XMPP Council - 2019-09-11


  1. 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

  2. jonas’

    also, ProtoXEPs

  3. 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

  4. dwd

    You should have written it. I only just noticed it's Wednesday.

  5. jonas’

    time is tricky

  6. Ge0rG

    dwd: it would've been biased.

  7. Ge0rG

    dwd: the time. It is.

  8. Kev

    Here, we are.

  9. jonas’

    .

  10. dwd

    Yes indeed.

  11. dwd

    1) Roll Call.

  12. jonas’ is here

  13. Link Mauve

    Hi, I’m here!

  14. dwd

    Presumably that's a full house then.

  15. Link Mauve

    Just on time I see. ^^'

  16. dwd

    2) Agenda Bashing

  17. dwd

    Given I didn't notice it was Wednesday, I've not managed one at all, sorry.

  18. Kev

    We've certainly got fastening on it.

  19. dwd

    I see one announced ProtoXEP, and one merged but not yet announced, is that right?

  20. dwd

    Plus the two github PRs above.

  21. jonas’

    seems realistic

  22. jonas’

    the merged one isn’t built yet, thus not announced

  23. dwd

    OK, sounds good. So three things.

  24. dwd

    3) Items for a vote.

  25. dwd

    a) Proposed XMPP Extension: Message Fastening

  26. dwd

    https://xmpp.org/extensions/inbox/fasten.html

  27. Ge0rG

    This is clearly duplication of existing work.

  28. Ge0rG

    The author should collaborate with the authors of Attaching.

  29. 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

  30. 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?

  31. dwd

    What is the actual distinction between this and XEP-0367?

  32. Kev

    dwd: Council decided last week that they'd rather a new protoXEP was submitted/accepted than 367 updated. As you'll remember.

  33. jonas’

    something about the <external/> stuff doesn’t sit right with me either, and I’d like to see a practical motivation for it

  34. Kev

    During our discussion of whether it should be a new XEP, or an update to 367

  35. jonas’

    (FWIW, I’m not strictly arguing for rejecting this because of dup)

  36. dwd

    Kev, Sure. But what is the difference between this as '376 beyond "it's in a different document"?

  37. dwd

    Kev, Sure. But what is the difference between this as '367 beyond "it's in a different document"?

  38. jonas’

    the lack of fastenings to fastenings seems like an unnecessary restriction to me

  39. Kev

    dwd: Mostly the external stuff, the replacing, and the removing that I need to push once it's accepted.

  40. 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.

  41. Kev

    As I've said before, it would fit well into 367 as long as we're happy to update 367 with it.

  42. Link Mauve

    Such as for instance a fictional external approval for an edit.

  43. 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.

  44. Ge0rG

    so maybe the question for Council should be: 1) bury 0367, accept Fastening 2) Merge Fastening into 0367 3) Have both in parallel

  45. 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.

  46. 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.

  47. Link Mauve

    But fair enough.

  48. Kev

    dwd: This started because we were told that Sam (as author) did not want 367 used for reactions.

  49. Ge0rG

    dwd: 0367 is well suitable for reactions, give or take some minor business ruls

  50. jonas’

    dwd, the only thing which made '367 "unsuitable" was that folks had the strong opinion that reactions are not attachments

  51. Kev

    The initial plan was to just update 367

  52. 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.

  53. 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.

  54. jonas’

    Kev, I think there was an expectation that your proposal would go further beyond what '367 has

  55. jonas’

    but I may be wrong

  56. Ge0rG

    I'd be fully okay with burying 0367 and removing Fastening to New Attaching with a new number

  57. dwd

    Well, I'm for publishing it, but clearly both '367 and this cannot go on to Draft.

  58. dwd

    I was just expecting something significantly different from Attaching, I suppose.

  59. 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.

  60. dwd

    Kev, I think that's somewhat unfair, given that you did insist on having orders to follow.

  61. dwd

    But let's vote on this:

  62. dwd

    Anyone want to vote?

  63. Kev

    Someone, anyone?

  64. jonas’

    uh, I was expecting you’d spell something out ;)

  65. jonas’

    I’m +1 on this

  66. jonas’

    we can develop this further in Experimental

  67. Ge0rG

    dwd: in case we do want to merge Fastening into 0367, wouldn't assigning a new number block us from that?

  68. Ge0rG

    But yeah, let's make some progress. +1

  69. Kev

    Ge0rG: I believe if we wanted to C-A, C-C, ->367, C-V, we could.

  70. jonas’

    Ge0rG, we can (have Kev) retract Fastening at any time

  71. Kev

    Although if that's our intention, we could probably just -1 this now and do it immediately.

  72. Ge0rG

    jonas’: with Kev following orders, I agree

  73. Link Mauve

    Kev, if we want to have only one, and the three 0367 authors are fine with that, it would better be.

  74. Ge0rG

    for the protocol, I don't have a strong opinion on that, so we shoud do whatever is good to stabilize fastachments.

  75. dwd

    I'm +1, just to get progress.

  76. Kev

    Link Mauve: Technically, the 367 authors don't need to be, but yeah.

  77. Link Mauve

    Kev, for an experimental one?

  78. Kev

    Indeed. It's the XSF's, Council get to do what they want, pretty much.

  79. Kev

    It doesn't belong to the Authors.

  80. jonas’

    Link Mauve, we can always remove them as authors :)

  81. 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.

  82. Link Mauve

    Right.

  83. Kev

    I'm +0 :)

  84. dwd

    Indeed, XEPs belong to the XSF, but only once adopted and given a number.

  85. Ge0rG

    so everybody voted now?

  86. dwd

    I believe so - 4*(+1) +0

  87. Kev

    Yes, 4*+1, 1*+0

  88. jonas’

    \o/

  89. dwd

    OK, moving on.

  90. Ge0rG

    congratulations Kev

  91. dwd

    b) https://github.com/xsf/xeps/pull/822

  92. dwd

    That's just adding an example of something that should be rejected.

  93. Ge0rG

    +1

  94. Kev

    +1

  95. dwd

    Which looks good to me. +1

  96. jonas’

    +1

  97. Ge0rG

    I wasn't sure about the Shakesperean English.

  98. Link Mauve

    +1 too.

  99. Ge0rG

    Maybe one of the Brexiters can spellcheck that.

  100. dwd

    Unanimous +1's.

  101. jonas’

    \o/

  102. jonas’

    > Merge made by the 'recursive' strategy.

  103. jonas’

    > [master 0fbb008] Accept inbox/fasten.xml as XEP-0422

  104. 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?

  105. jonas’

    Link Mauve, https://github.com/xsf/xeps/issues/821

  106. dwd

    c) https://github.com/xsf/xeps/pull/820/commits/8024555dd59926f092ee9ddb713e4d537888771c

  107. Link Mauve

    jonas’, perfect.

  108. jonas’

    Link Mauve, AIUI, this needs amendments to XEP-0001, so a bit of overhead there

  109. dwd

    That's adding XEP-0333 to carbonization and removing the error note.

  110. dwd

    Why remove the error note?

  111. Link Mauve

    dwd, because errors are important to receive on multiple clients.

  112. dwd

    Also, why are we voting on this? It's Experimental.

  113. 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

  114. Ge0rG

    dwd: I'm not the author

  115. dwd

    Should we make Ge0rG the author?

  116. dwd

    s/the/an/?

  117. 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.

  118. jonas’

    why did we vote on the previous PR? ;)

  119. Ge0rG

    dwd: I wouldn't veto such a motion

  120. dwd

    jonas’, Because I didn't think of this then.

  121. Kev

    jonas’: Because it's easier than working out the process and potentially arguing.

  122. jonas’

    Ge0rG, congrats, you successfully social engineered council and the ediotr ;)

  123. jonas’

    Ge0rG, congrats, you successfully social engineered council and the editor ;)

  124. Kev

    Council voting on changes avoids needing to think about whether a PR without an author's agreement should be merged.

  125. Ge0rG

    jonas’: only to skip asking the vanished authors

  126. jonas’

    I’m not opposed to making Ge0rG an author of '280 FTR

  127. 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.

  128. 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

  129. Kev

    But it *does* need a namespace bump for adding 333

  130. Kev

    (Not for carbons itself, for the I Support These Rules feature)

  131. Ge0rG

    Kev: do you honestly believe that?

  132. Link Mauve

    Instead of a namespace bump, couldn’t we add a feature to implementations which support that?

  133. Ge0rG

    I'm not aware of any implementation that advertises that

  134. Kev

    Ge0rG: M-Link trunk certainly does.

  135. Link Mauve

    Bumping Carbons would be the worst atm.

  136. Ge0rG

    Kev: I can imagine changing the text into "it contains payload elements typically used in IM (e.g. &xep0184;, &xep0085;, &xep0333;)"

  137. Kev

    Since we re-implemented carbons with those rules (without the message tracking) :)

  138. 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.

  139. Ge0rG

    Kev: I can't imagine how anybody would assume that 0184 and 0085 are an exclusive list of all IM-related payloads.

  140. 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".

  141. jonas’

    I tend to agree with Kev

  142. jonas’

    while we’re bumping, how about CC-ing all error messages instead of just removing that node?

  143. jonas’

    while we’re bumping, how about CC-ing all error messages instead of just removing that note?

  144. Ge0rG

    Okay, in that case I retract the PR until somebody comes up with a conclusive list of all IM-related payloads.

  145. Kev

    jonas’: I think that *would* be feasible server-side. I wonder what the effect on clients would be.

  146. Ge0rG

    jonas’: CC-ing MUC(PM) errors will wreak havoc.

  147. Kev

    Ge0rG: Only if clients weren't prepared for it, though.

  148. Ge0rG

    again, there is no conlcusive list of possible causes of errors.

  149. jonas’

    errors can happen

  150. Kev

    What if we had <include-errors/> and then a client needs to cope with errors that it didn't trigger?

  151. jonas’

    Ge0rG, if your client breaks because it receives a random type=error stanza, you need to reconsider your design decisions anyways

  152. Kev

    Error correlation is going to be easier client-side than server-side, I suspect.

  153. Kev

    jonas’: Define 'break'. Swift will tell the user that something has gone wrong.

  154. dwd

    OK - we seem to have moved into developing a new design, please take that elsewhere.

  155. jonas’

    Kev, if your client interrupts the users flow for unsolicited type=error stanzas, you may also need to re-evaluate design decisions

  156. jonas’

    dwd, right, ack

  157. dwd

    4) Outstanding Votes.

  158. 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.)

  159. Ge0rG

    Kev: it _might_ receive error carbons.

  160. dwd

    Link Mauve, You have two outstanding, could you vote please?

  161. dwd

    5) Next Meeting

  162. Link Mauve

    I don’t have access to my emails (my server is down…), could you remind me which ones please? :x

  163. 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

  164. Link Mauve

    Thanks.

  165. dwd

    Same time next week?

  166. Link Mauve

    I’ll shortly do so from my other email account.

  167. dwd

    I will endeavour to get an Agenda sorted this time.

  168. jonas’

    dwd, +1w wfm

  169. Link Mauve

    Same.

  170. dwd

    6) AOB

  171. Kev

    I won't be here next week, FWIW.

  172. dwd

    Given we're 7 minutes over, I'm really hoping nobody has AOB.

  173. Ge0rG

    I still have the same AOBs as the last three times.

  174. Ge0rG

    Sorry, dwd

  175. dwd

    Ge0rG, Yeah. I know.

  176. Ge0rG

    Kev, dwd: did you vote on https://xmpp.org/extensions/inbox/cs-2020.html yet?

  177. dwd

    I'll try to ensure that with an Agenda and a bit of planning, we allocate more time for these next week.

  178. dwd

    Oh, I thought I had but I had not. There's also others expiring today.

  179. Kev

    I don't think I have anything expiring today. I do have stuff expiring next week.

  180. dwd

    Yes, they expire next week, sorry. I'm a mess today.

  181. 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]

  182. dwd

    I'll vote +1 on cs-2020. Nothing we can't fix in Experimental, let's get the ball rolling on it.

  183. dwd

    Anyway, let's call it a day now. See most of you next week.

  184. Link Mauve

    I’m also +1 on both.

  185. 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.

  186. dwd

    7) Ite, Meeting Est.

  187. Link Mauve

    Kev, did you have the meeting about it yet?

  188. Kev

    No.

  189. Link Mauve

    Ok. :(

  190. Ge0rG

    There is a Council re-election soon, and I'm very sure it will mess up our ability to Last-Call a XEP.

  191. Ge0rG

    And I want 2020 to be finished before 2019 ends.

  192. Link Mauve

    I also want to make it a lot more marketing-oriented.

  193. Link Mauve

    sonny, ↑

  194. Ge0rG

    Link Mauve: feel free to PR'ovide better text

  195. 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.

  196. daniel

    Link Mauve, does that include tweeting about it every 5 minutes?

  197. Ge0rG

    Link Mauve: all those goals are worthy.

  198. jonas’

    Ge0rG, any chance you can drop a vote on #812 right now?

  199. jonas’

    I’m working on a bunch of merges and yours is the last missing

  200. Link Mauve

    daniel, I hope not.

  201. daniel

    i think the name doesn’t really matter. but making it more widely know is certainly a good thing

  202. daniel

    not just for marketing but also simply to give developers a helping hand

  203. Link Mauve

    Yes.

  204. daniel

    but we've also done an ok job with that before

  205. daniel

    i can still be improved obviously. but it's not that we were totally terrible about that

  206. 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

  207. daniel

    and that was someone from outside the xmpp community

  208. Link Mauve

    Was it Stéphane Bortzmeyer?

  209. 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

  210. Link Mauve

    He’s a very well-known protocols guy.

  211. Ge0rG

    jonas’ [17:47]: > Ge0rG, any chance you can drop a vote on #812 right now? +1

  212. daniel

    don't recal. no it was an activity pub person i think

  213. Link Mauve

    Ok.

  214. daniel

    just saying all that because sometimes with all the internal criticism we fail to see what we actually did right

  215. Link Mauve

    Indeed. :)

  216. sonny

    for clarity I really like the work around complicance suites, just thinking about an evolution

  217. Link Mauve

    sonny, as Ge0rG said, PR’oviding better text or doing things around it would be super cool. :)

  218. sonny

    👍

  219. undefined

    http://0x0.st/zJkT.txt