XMPP Council - 2018-11-21


  1. vanitasvitae has left

  2. vanitasvitae has left

  3. vanitasvitae has joined

  4. labdsf has left

  5. labdsf has joined

  6. labdsf has left

  7. labdsf has joined

  8. labdsf has left

  9. labdsf has joined

  10. vanitasvitae has left

  11. vanitasvitae has joined

  12. moparisthebest has left

  13. moparisthebest has joined

  14. moparisthebest has left

  15. moparisthebest has joined

  16. alex-ray has joined

  17. alex-ray has left

  18. lnj has left

  19. lnj has joined

  20. lnj has left

  21. Tobias has joined

  22. labdsf has left

  23. Remko has joined

  24. labdsf has joined

  25. moparisthebest has joined

  26. moparisthebest has joined

  27. Zash has joined

  28. pep. has left

  29. ralphm has left

  30. vanitasvitae has left

  31. vanitasvitae has joined

  32. daniel has left

  33. daniel has joined

  34. daniel has left

  35. daniel has joined

  36. Zash has left

  37. daniel has left

  38. daniel has joined

  39. moparisthebest has joined

  40. moparisthebest has joined

  41. Zash has left

  42. Zash has left

  43. Zash has left

  44. moparisthebest has joined

  45. moparisthebest has joined

  46. daniel has left

  47. daniel has joined

  48. SamWhited has left

  49. SamWhited has joined

  50. Zash has left

  51. labdsf has left

  52. labdsf has joined

  53. Zash has joined

  54. lnj has joined

  55. moparisthebest has left

  56. moparisthebest has joined

  57. Zash has left

  58. moparisthebest has left

  59. moparisthebest has joined

  60. moparisthebest has left

  61. moparisthebest has joined

  62. moparisthebest has left

  63. moparisthebest has joined

  64. Holger has left

  65. ralphm has left

  66. Holger has left

  67. Ge0rG

    Still a bunch of votes pending, deadline tomorrow EOB.

  68. Ge0rG

    or rather EOM?

  69. jonas’

    EOM?

  70. Kev

    We agreed 'end of Council', I believe.

  71. Kev

    End Of Meeting, I would assume.

  72. dwd has joined

  73. Kev

    I'm ready to vote on all of mine in the meeting, FWIW.

  74. daniel has left

  75. Ge0rG

    End Of Meeting, indeed.

  76. Ge0rG

    Kev: đź‘Ť

  77. dwd

    Right.

  78. dwd

    1) Is there anybody out there?

  79. Ge0rG is out there

  80. dwd

    Kev, SamWhited, daniel ?

  81. daniel

    hi

  82. peter has joined

  83. Kev

    I is definitely here.

  84. dwd

    OK.

  85. dwd

    2) Agenda

  86. dwd

    I am working on the assumption that the only items for a vote are anything outstanding from last week.

  87. dwd

    (And that nobody is mad enough to try adding new stuff).

  88. dwd

    So with that in mind:

  89. dwd

    3) Outstanding votes

  90. Kev

    I think it's everything from last week, yes.

  91. Kev

    i.e. just the same agenda again.

  92. Ge0rG

    I shortly considered adding items to vote on, but abstained.

  93. dwd

    I believe I'm up to date, as is Ge0rG.

  94. Ge0rG

    I've done all my on-list votes.

  95. dwd

    And SamWhited is too.

  96. Kev

    Alright. We did agree last week to have discussions on them all this week, rather than just treat them as purely on-list, but w/e.

  97. Ge0rG

    I anticipated objections to my requirement to make stanza @id = origin-id @id

  98. dwd

    We certainly can discuss.

  99. Kev

    3) Advance XEP-0357 (Push Notifications) to DRAFT - https://xmpp.org/extensions/xep-0357.html -1 4) Advance XEP-0359 (Unique and Stable Stanza IDs) to DRAFT - https://xmpp.org/extensions/xep-0359.html -1 5) PR #692 - XEP-0060: correct "entity" to "<subscription/>" - https://github.com/xsf/xeps/pull/692 +1 6) PR #693 - XEP-0060: Remove unused 'node' attribute on pubsub#event item - https://github.com/xsf/xeps/pull/693 +1 7) PR #715 - XEP-0045: Add missing disco#info feature to example 4, 9, 78 and 218 - https://github.com/xsf/xeps/pull/715 +1 8) PR #716 - XEP-0030: Clarify 'disco#info' feature in 'disco#info' responses - https://github.com/xsf/xeps/pull/716 -1

  100. dwd

    Ge0rG, I suspect that's desirable, but also potentially difficult if the library sets the stanza's @id at the point of send.

  101. Ge0rG

    Kev: that lacks rejection rationale

  102. daniel

    > I anticipated objections to my requirement to make stanza @id = origin-id @id i think i suggested that a few times but the author always objected

  103. Ge0rG

    dwd: ideally, the library should be the one adding the origin-id then

  104. Ge0rG

    daniel: yes, I suggested that as well, and got the same reaction.

  105. Ge0rG

    There was no rationale, so I'm using my Council hat now.

  106. Kev

    I can't see a reason not to make stanza id = origin id.

  107. dwd

    Ge0rG, Well, yes. But often, libraries bake in support after various apps have used them first.

  108. jonas’

    dwd, then it’ll take a while for libraries to adapt.

  109. Ge0rG

    dwd: I'm sure this is a problem easier to solve than multiple mismatching ids on a message

  110. dwd

    Ge0rG, That all said, I won't object very strongly whichever way it goes.

  111. daniel

    wasn’t the primary reason that smack can’t do it

  112. Ge0rG

    besides, we need to fix Receipts and LMC with origin-id in place.

  113. dwd

    Ge0rG, Could a server just add in the origin-id, then?

  114. Ge0rG

    daniel: even the old version of smack I run makes it possible to extract and change stanza IDs

  115. Ge0rG

    dwd: that sounds like a reasonable proposal to solve some problem. I'm just not sure which one.

  116. Ge0rG

    dwd: also not sure whether the rules of 0359 allow injection of origin-id

  117. dwd

    Ge0rG, If a client wishing to add in origin-id has to add the same id twice, then a server could add in that as well.

  118. dwd

    Ge0rG, Probably not, as written. My question was whether it made sense to do so.

  119. Ge0rG

    As already stated, I consider origin-id to be a hack to work around bad servers, so I'd rather burn it.

  120. Ge0rG

    I can see some benefit in <stanza-id/> for MAM purposes, because you have an independent entity defining _that_ id.

  121. Ge0rG

    Originally, <origin-id> was a payload you were supposed to stuff into messages you send into a MUC or into transports, in the hope to see the element reflected

  122. Ge0rG

    But then we got MUC changed to discourage that, and transports probably can't retain XML payloads anyway.

  123. Ge0rG

    So in my eyes, <origin-id/> could go away.

  124. dwd

    That I could go along with.

  125. vanitasvitae has left

  126. Ge0rG

    (and if you have a transport that can maintain XML payloads internally, you surely can send a reflected message to the sending client with the same @id attribute)

  127. vanitasvitae has joined

  128. jonas’

    (for example, the transport implementation could inject its own version of the <origin-id/> thing into the "legacy" protocol and convert it back to the @id when the reflection comes back)

  129. dwd

    Ge0rG, Yes, I was just thinking that. So does that mean there's no point to origin-id excepting some old servers?

  130. Ge0rG

    the last reason to have <origin-id/> is that it's an indication that the client is using sufficiently-random @id's, and I think that can be signalled in an easier fashion, if needed at all

  131. Ge0rG

    dwd: that's my understanding, yes.

  132. jonas’

    I am amazed. will we really solve this battle in the last sitting of council? probably not because SW won’t be able to react in time...

  133. dwd

    Ge0rG, I'm not sure that *is* an indication of more than some vague intent.

  134. Ge0rG

    dwd: excepting some old MUC implementations, to be precise

  135. Kev

    I think this is a mailing list or after-Council discussion really. We've reached -1 point, I think.

  136. dwd

    Kev, I think you're right.

  137. Kev

    I think.

  138. jonas’

    aw pity

  139. jonas’

    how about "apply these changes and then +1"?

  140. jonas’

    where "these changes" points to a PR?

  141. Ge0rG

    jonas’: not gonna happen in the next 15 mins

  142. dwd

    Right.

  143. Ge0rG

    how about "take authorship away and do it right"?

  144. Ge0rG

    no, I don't volunteer.

  145. jonas’

    I do.

  146. dwd

    Anything else ... XEP-0357? Kev, you'll owe rejection reasons, but I guess those are in your mail to list?

  147. Kev

    We don't need to take authorship away to do it right, incidentally.

  148. jonas’

    I was about to write "challenge accepted!" and do a PR right away, but then I figured that the security considerations of stripping existing stanza-ids probably really can’t be figured out in 15 mins

  149. Ge0rG

    jonas’: my -1 was already conditioned on "make @id = origin-id", but now it looks like it's just -1

  150. Kev

    I think my mails today about both 357 and 359 are feedback enough on those.

  151. Kev

    Especially as I'm the person that needs to make the 357 changes.

  152. dwd

    True.

  153. dwd

    Congrats on rejecting your own XEP.

  154. Ge0rG

    Speaking of taking ownership away.

  155. dwd

    So, PR #716?

  156. dwd

    I was in favour of dropping the need to signal disco#info over disco#info.

  157. Ge0rG

    dwd: is #715 fully voted on already?

  158. Ge0rG

    dwd: re #716, last Council it was brought up that caps hash calculation would be inconsistent then

  159. dwd

    Ge0rG, Oh, no, daniel hasn't I don't think.

  160. Ge0rG

    also it's a MUST from a Final XEP

  161. Kev

    I think the normative change here is wrong at this stage. I think noting that it'll be elided from many examples is reasonable, and probably even that some implementations may elide it (although what the implications of that are isn't entirely clear. I think it doesn't affect 115, though).

  162. dwd

    Ge0rG, I think a client that includes it in disco#info includes it in XEP-0115, surely?

  163. Ge0rG

    I'm not quite sure what Florian was trying to make on the list responding to my -1.

  164. jonas’

    at the very least, doing it inconsistently will defeat some 115/390 caches

  165. Ge0rG

    dwd: I think that having it being defined implicitly leads to corner cases. Also Final XEP.

  166. Kev

    We /are/ allowed to modify Final XEPs.

  167. dwd

    Ge0rG, I'd be more convinced about the Final XEP argument if this affected interop, or indeed was actually followed.

  168. Kev

    "Every effort" not to, though.

  169. Kev

    dwd: I think the argument is that an implicit feature there might make future 115 bugs.

  170. jonas’

    dwd, I think most implementations do follow it

  171. dwd

    Ge0rG, The fact that many implementations *don't* include disco#info, and everything still works, really does suggest it's wrong.

  172. jonas’

    we do have the luck to have a huge stash of disco#info replies from both servers and (a bit outdated) clients if you want to make a survey

  173. Kev

    My inclination would be to leave the normative language, but note a) that examples don't include it, and b) some implementations elide it.

  174. jonas’

    I can modify the muclumubs ( https://search.jabber.network ) bot to make a stat on that

  175. Ge0rG

    +1 to what Kev suggested.

  176. dwd

    I can see I'm on the losing side here, and can go along with Kev's suggestion.

  177. Kev

    Otherwise I'm not strictly opposed to making it optional if we're very sure that the language we introduce couldn't cause caps weirdness with it being implicitly added.

  178. Ge0rG

    Kev: in my eyes, it's not about the language but about implementations that add it, then do caps, vs. implementations that just do caps.

  179. dwd

    Right - anyone want to discuss anything else?

  180. Kev

    I'd like to thank everyone for their work this term :)

  181. dwd

    Ge0rG, I think if implementations were inconsistent then caps would be failing for them and people would have noticed, FWIW.

  182. Kev

    I think dwd is right.

  183. dwd

    Kev, Yes, I was going to do this:

  184. dwd

    4) Thanks, All.

  185. Kev

    I'm worried that we might inadvertently make matters worse by adding language about optionalness. If we're sure we won't, I'm not strictly opposed.

  186. dwd

    Thanks to everyone for your efforts - not only Council, but jonas’s work on Editor stuff, too.

  187. Kev

    Indeed.

  188. Ge0rG

    Thanks to you too, Dave.

  189. jonas’

    thanks to council :-)

  190. jonas’

    this was a fun ride

  191. Kev

    And to the Chair.

  192. jonas’

    let’s see what the numbers tomorrow bring for next year

  193. dwd

    Also, this year, we've had a number of useful contributions from the floor, so thanks to anyone who's chipped in.

  194. Ge0rG

    I've heard we didn't pass that many XEPs to Draft, which is maybe a bit sad.

  195. jonas’

    exactly one.

  196. jonas’

    and it was the compliance suites

  197. jonas’

    three months late or something :)

  198. jonas’

    but whatever

  199. Ge0rG

    jonas’: I've heard you are already preparing Compliance Suite 2019.

  200. jonas’

    yeah, that cp sure takes a while...

  201. Kev

    It's not Council's job to make XEPs ready for advancement, mind, so I don't feel too bad about that.

  202. jonas’

    Kev, I didn’t mean to make anyone feel bad anyways

  203. jonas’

    just for the record :)

  204. Kev

    đź‘Ť

  205. Ge0rG

    We have five minutes left. Any technical topics?

  206. Kev

    Happy for the 359 discussion to continue now I don't have to pay as much attention :)

  207. Ge0rG

    Kev: I'm not sure what's left to discuss there. I'd rather discuss Push.

  208. jonas’

    what are my chances that someone updates the spreadsheet of doom right now so that I don’t have to go over the emails?

  209. Kev

    359-2 then :)

  210. Ge0rG

    Besides, should we propose a meeting time for the new Council?

  211. jonas’

    new council will have to figure that out tomorrow night I think

  212. Kev

    Well, not tomorrow night, but yes.

  213. jonas’

    although we could agree on a time; in any case, we know the maximum set of people who’ll be on it anyways

  214. SamWhited

    oops, sorry, had guests and wasn't paying attention to the time

  215. Ge0rG

    it's probably overly optimistic to assume that all five candidates will actually receive a majority of votes.

  216. jonas’

    Ge0rG, sarcasm?

  217. Ge0rG

    SamWhited: are you missing any votes?

  218. dwd

    Ge0rG, Thankfully it needs people to vote against to actually lose.

  219. Ge0rG

    jonas’: no, just saing it's rather inappropriate to proclaim "I'll probably get reelected anyway"

  220. jonas’

    in any case, the wednesday 16:00Z slot wfm

  221. Kev

    dwd: Simple needs people to not vote for.

  222. jonas’

    for now.

  223. SamWhited

    No, I emailed mine and should be all caught up now

  224. dwd

    SamWhited, Ooops, soryr - didn't think, it's Turkey Day tomorrow, isn't it.

  225. SamWhited

    dwd: yup, don't worry, I forgot too and I live here…

  226. dwd

    Kev, Well, yes, but if they do not vote at all, that's not counted.

  227. daniel has left

  228. Kev

    I'm not sure that's true.

  229. Kev

    Someone can submit their vote, for no candidates.

  230. Ge0rG

    Let's postpone this until after the election.

  231. Kev

    If a majority of people did that, we'd have no Council.

  232. dwd

    Kev, True. But that counts as voting.

  233. jonas’

    > Third, the individuals elected shall be those receiving the highest percentage of votes cast, up to the limit set by the Members and with the proviso that no individual receiving less than a majority of votes cast shall be elected.

  234. Ge0rG

    Does memberbot allow that?

  235. jonas’

    Ge0rG, yes

  236. dwd

    Ge0rG, Yes.

  237. jonas’

    you can abstain for all five

  238. Kev

    dwd: Yes,t hat's what I said. It just needs people to not vote 'for'.

  239. dwd

    Anyway. I think we may be done.

  240. jonas’

    thanks again y’all

  241. dwd

    Kev, Yeah, I just think it's more likely they won't vote at all.

  242. dwd

    So, for the final time this Council:

  243. Kev

    Our voting rules are actually broken, because all we need is for enough (non-joke) candidates to apply and we can't form a Council.

  244. dwd

    5) Ite, Meeting Est

  245. Kev

    Diolch, pawb.

  246. Zash

    Thanks all

  247. jonas’

    Kev, as long as this doesn’t happen to board (or whoever has power to fix bylaws), we’re good!

  248. Ge0rG

    Kev: so we need to define a second ballot process with at most 10 candidates?

  249. dwd

    Kev, I suspect that it's memberbot breaking. The way the bylaws are written, one could argue that each council candidate is voted for/against individually.

  250. Kev

    jonas’: I think that for Board we're probably already covered.

  251. Kev

    dwd: True.

  252. jonas’

    dwd, I agree

  253. jonas’

    I was a tad surprised to see the memberbot process after reading the bylaws more carefully this time

  254. dwd

    Meeting's tomorrow night at 1900Z, right?

  255. jonas’

    yes

  256. daniel has left

  257. daniel has left

  258. jonas’

    also, I don’t think that we need to have an elected board to fix the bylaws... we could have an all-member-vote about the change :)

  259. Kev

    ISTR (without checking) that in the case that we somehow had no Board elected, Peter could pick his own.

  260. dwd

    jonas’, We did that one time in a meeting when we realised we'd catastrophically f**ked up. Ah, it was fun.

  261. dwd

    jonas’, Strangely, XSF Meetings were very well attended for the next few.

  262. jonas’

    :D

  263. jonas’

    storytime?

  264. SouL is paying attention.

  265. Kev

    There was a thing. Hopefully there isn't a thing again.

  266. daniel has left

  267. daniel has left

  268. daniel has left

  269. vanitasvitae has left

  270. vanitasvitae has joined

  271. peter

    Kev: I can't do any such thing because I'm no longer the executive director.

  272. Kev

    Ah, ok. I thought you still were until they found a new one :)

  273. peter

    Seems to me we're doing fine with just the council. And as noted the members can always call a special meeting to fix things.

  274. peter

    er, board

  275. daniel has left

  276. Kev

    I prefered your first version :)

  277. peter

    heh

  278. lnj has joined

  279. Ge0rG

    Kev: accidentally candidated for the wrong panel?

  280. dwd

    I hope not, otherwise Council's short.

  281. daniel has left

  282. peter

    even if the Council were short, it could presumably nominate another member after the election, no?

  283. Kev

    Yeah.

  284. Kev

    I think we've entered silly territory now.

  285. Kev

    "now".

  286. Ge0rG

    I thought the Council is allowed to be short.

  287. jonas’

    tallism!

  288. jonas’

    heightism!

  289. ralphm has left

  290. peter

    :-)

  291. dwd has left

  292. Zash

    xnyphs for new ED?

  293. Zash

    xnyhps for new ED?

  294. moparisthebest has left

  295. Link Mauve

    Re the discussion about XEP-0359 here, what you actually want is to revive https://github.com/xsf/xeps/pull/689 right?

  296. moparisthebest has joined

  297. Kev

    Without reading and just going on the title, maybe :)

  298. Ge0rG

    Discussion on the editor issue tracker.

  299. jonas’

    nooo

  300. Ge0rG

    > XEP-0359: Replace tabs with spaces. WHY?!

  301. Holger has left

  302. Ge0rG

    I like #689, except the implementation note says "to be set by the emitting client on every message to a MUC" - I don't see <origin-id/> as a MUC-only thing.

  303. Zash has left

  304. Ge0rG

    Link Mauve: you could have confused the Council by bringing up #689 right in time for today's Agenda.

  305. Kev

    Council don't need to be more connfused than usual :p

  306. jonas’

    next week, he might be able to confuse himself with that

  307. moparisthebest has left

  308. moparisthebest has joined

  309. vanitasvitae has left

  310. Syndace has joined

  311. labdsf has left

  312. moparisthebest has joined

  313. moparisthebest has joined

  314. Syndace has joined

  315. lnj has left

  316. labdsf has joined

  317. pep. has left

  318. pep. has left

  319. peter has left

  320. labdsf has left

  321. labdsf has joined

  322. moparisthebest has left

  323. moparisthebest has joined

  324. peter has joined

  325. lnj has left

  326. SamWhited has left

  327. Remko has left

  328. lnj has left

  329. Holger has left

  330. Holger has left

  331. moparisthebest has left

  332. moparisthebest has joined

  333. Tobias has joined

  334. labdsf has left

  335. labdsf has joined

  336. peter has left

  337. vanitasvitae has left

  338. Zash has left