XMPP Council - 2021-09-29


  1. debacle has left

  2. pprrks has left

  3. pprrks has joined

  4. SouL has joined

  5. pprrks has left

  6. Tobias has joined

  7. ChronosX88 has left

  8. ChronosX88 has joined

  9. pprrks has joined

  10. me9 has joined

  11. ChronosX88 has left

  12. ChronosX88 has joined

  13. marc0s has left

  14. marc0s has joined

  15. ChronosX88 has left

  16. ChronosX88 has joined

  17. paul has joined

  18. ChronosX88 has left

  19. ChronosX88 has joined

  20. ChronosX88 has left

  21. ChronosX88 has joined

  22. ChronosX88 has left

  23. ChronosX88 has joined

  24. ChronosX88 has left

  25. ChronosX88 has joined

  26. me9 has left

  27. marc0s has left

  28. marc0s has joined

  29. Kev has left

  30. Kev has joined

  31. Kev has left

  32. Kev has joined

  33. Kev has left

  34. Kev has joined

  35. Kev has left

  36. Kev has joined

  37. Kev has left

  38. Kev has joined

  39. Kev has left

  40. Kev has joined

  41. debacle has joined

  42. Kev has left

  43. Kev has joined

  44. Tobias has left

  45. Tobias has joined

  46. debacle has left

  47. marc0s has left

  48. marc0s has joined

  49. Kev has left

  50. Kev has joined

  51. debacle has joined

  52. ChronosX88 has left

  53. ChronosX88 has joined

  54. ChronosX88 has left

  55. ChronosX88 has joined

  56. sonny has left

  57. sonny has joined

  58. ChronosX88 has left

  59. ChronosX88 has joined

  60. ChronosX88 has left

  61. ChronosX88 has joined

  62. sonny has left

  63. sonny has joined

  64. sonny has left

  65. sonny has joined

  66. ChronosX88 has left

  67. ChronosX88 has joined

  68. Wojtek has joined

  69. ChronosX88 has left

  70. ChronosX88 has joined

  71. marc0s has left

  72. marc0s has joined

  73. alex11 has left

  74. marc0s has left

  75. marc0s has joined

  76. me9 has joined

  77. sonny has left

  78. sonny has joined

  79. sonny has left

  80. sonny has joined

  81. Wojtek has left

  82. sonny has left

  83. sonny has joined

  84. Wojtek has joined

  85. sonny has left

  86. sonny has joined

  87. jonasā€™

    1) Roll Call

  88. Ge0rG /o\

  89. daniel

    hi

  90. Zash

    šŸ™„ļø

  91. jonasā€™

    the look of dread

  92. jonasā€™

    do we get a dwd?

  93. Zash

    well, we?

  94. jonasā€™

    let's se

  95. jonasā€™

    let's see

  96. jonasā€™

    2) Agenda Bashing

  97. jonasā€™

    anything?

  98. jonasā€™

    you may voice your complaints throughout the meeting

  99. jonasā€™

    3) Editor's Update

  100. jonasā€™

    nothing

  101. jonasā€™

    4) Items for Voting (or maybe also just discussion)

  102. jonasā€™

    4a) Can we talk about XEP-0313 again?

  103. Zash

    I guess we can

  104. Ge0rG

    jonasā€™: is that a formal vote?

  105. jonasā€™

    I think there was some discussion last night in xsf@

  106. jonasā€™

    Ge0rG, no.

  107. jonasā€™

    how do we want to move forward?

  108. jonasā€™

    there was some positive feedback to Zashes proposal on list, but Kevs is simpler

  109. jonasā€™

    and both seem to have similar drawbacks in the end (discoverability)

  110. Ge0rG

    I was pressed into suppressing all but the most pressing issues I had about it.

  111. Zash

    I'm not going to block Kevs PR. It does have discovery and seems sane. My approach would need more thinking about discovery and seemed to add more complexity than what I could find time to think about since last week.

  112. Ge0rG

    I still haven't received any answers regarding how a hypothetical client in the kev usecase is supposed to query for, display or process the groupchat logs from MAM.

  113. jonasā€™

    Ge0rG, pipe to /dev/null?

  114. jonasā€™

    jokes aside, it seems that Kev has something specific in mind there and that it seems to work with "some clients".

  115. jonasā€™

    It would be good to have that written down, but I don't see that as a blocking issue.

  116. Zash

    (I can't actually block that, but still)

  117. Ge0rG

    jonasā€™: in that case we can just remove the groupchat requirement from MAM and add a note about some servers delivering type=groupchat junk that shall be ignored

  118. jonasā€™

    Ge0rG, well we can obviously not do that because above

  119. dwd

    Hello, sorry I'm late.

  120. Zash

    Ge0rG, so leave it at "MAY" q

  121. Zash

    Ge0rG, so leave it at "MAY" ?

  122. Ge0rG

    jonasā€™: well, given that the use case is a handwavy "I want to be able to search through all my seen MUC logs" that is full of corner cases, I don't agree with that assessment

  123. daniel

    I don't see a lot of real world problems with groupchat in mam (before we have mix). The xep needs to allow it because it makes sense for some deployments but I don't think you will experience this in the normal public ecosystem

  124. Zash

    I remembered something I think Ge0rG said at some point about having profiles, with corresponding disco features

  125. Ge0rG

    I'd rather break an experimental spec than cement something of the quality of GC1.0 into our spec.

  126. Zash

    Kevs PR does ... almost that

  127. daniel

    I haven't really been following the discussion on how to signal that because I don't really see it needs signaling in practice

  128. daniel

    It's still good to have it in the protocol I guess...

  129. Ge0rG

    daniel: well, you don't see the problems because most server implementations ignored the advice and went on with what you consider as best practice

  130. Ge0rG

    I'm not saying that it's wrong to ever store type=groupchat, I'm saying that it's wrong and harmful to store them by default and to return them to a standard query.

  131. Zash

    Ge0rG, btw, we don't actually store top level attributes of <message> stanzas (I think we said we did), but 'with' and the timestamps are derived values, from the archiving itself.

  132. Zash

    Ge0rG, btw, we don't actually query on* top level attributes of <message> stanzas (I think we said we did), but 'with' and the timestamps are derived values, from the archiving itself.

  133. Zash

    as are the ids extended mam adds

  134. jonasā€™

    to me, the PR by Kev is sufficient

  135. jonasā€™

    let's not make MAM another Message Archiving.

  136. MattJ

    Let's not indeed.

  137. Ge0rG

    well, it's the strictly minimal PR needed to get me away from -1.

  138. jonasā€™

    excellent

  139. Ge0rG

    it's far away from a PR that makes 0313 a good spec.

  140. jonasā€™

    I'll instruct the editor to merge it then, unless anyone voices another complaint to me until the next merge window

  141. Zash

    The thing I suggested could be added later, if real need for it turns up

  142. Zash

    as a separate XEP even, if it makes sense

  143. Zash

    jonasā€™: Explicit lack of complaint. šŸ™‚

  144. jonasā€™

    \o/

  145. jonasā€™

    moving on

  146. jonasā€™

    4b) XEP-0280: Advance now with the fixes applied?

  147. jonasā€™

    I merged and pushed the changes from Ge0rG yesterday.

  148. jonasā€™

    unless there's anything we haven't addressed yet, let's vote on Advancing to Stable

  149. jonasā€™

    unless there's anything we haven't addressed yet && have to address before advancing, let's vote on Advancing to Stable

  150. Zash

    got a link to those changes?

  151. jonasā€™

    https://github.com/xsf/xeps/pull/1105

  152. jonasā€™

    I also extended them with a nice changelog entry

  153. Ge0rG

    can't we have another Last Call, for the sake of it? I'm going to miss the yearly 0280 LC otherwise.

  154. Zash

    Haha

  155. jonasā€™

    Ge0rG, into your corner!

  156. Ge0rG

    +1 to advance XEP-0280.

  157. dwd

    Ge0rG, I can veto it if you like.

  158. Zash

    +1

  159. jonasā€™

    +1 to aXEP-280

  160. daniel

    +1

  161. Ge0rG

    dwd: I'm interested in your rationale

  162. jonasā€™

    +1 to advancing XEP-280, specifically NOT to dwd vetoing.

  163. dwd

    Ge0rG, And would like to suibscribe to my newsletter?

  164. dwd

    Anyway.

  165. Ge0rG

    After all those years of blocking 0280, this is a strange feeling.

  166. dwd

    Drum roll, please!

  167. jonasā€™

    šŸ„

  168. dwd

    +1 to advance!

  169. jonasā€™

    šŸŽ‰

  170. ChronosX88 has left

  171. jonasā€™

    let's quickly move on before someone changes their mind

  172. ChronosX88 has joined

  173. Ge0rG

    šŸ¾

  174. Sam

    šŸ˜‚

  175. jonasā€™

    5) Pending Votes

  176. Zash

    ƄNTLIGEN

  177. jonasā€™

    everyone is pending on CS-2021

  178. Ge0rG

    jonasā€™: CS-2022?

  179. jonasā€™

    yes

  180. jonasā€™

    that

  181. Zash

    CS-Source?

  182. jonasā€™

    Zash, thanks :D

  183. dwd

    It's entirely possible we're pending on CS-2021 as well, mind.

  184. Zash

    Why not both!

  185. jonasā€™

    let's not go there

  186. Ge0rG

    I've had a look at https://xmpp.org/extensions/xep-0459.html#future and I'd love to see XEP-379 and the associated XEPs become part of Advanced IM

  187. jonasā€™

    there was some discussion about words

  188. Zash

    It _would_ have been nice to see more discussion

  189. dwd

    Anyway, I did review CS-2022 carefully, and I noticed some things I find pretty weird.

  190. jonasā€™

    dwd, is this the right venue or should we take it to the list?

  191. dwd

    For one thing, we're saying that you can have a server that's "Core IM", but has no PEP, in 2022. Are there *any* servers that don't do PEP?

  192. dwd

    I don't think this is helped by us not actually defining anywhere what "Core" vs "Advanced" actually mean.

  193. jonasā€™

    aren't those just words to distinguish the two levels?

  194. jonasā€™

    but defining goals would indeed be interesting

  195. Zash

    Remember how there's a Core category too

  196. dwd

    jonasā€™, Sure, but what do the levels even mean?

  197. Ge0rG

    > This document defines XMPP application Categories based on typical use cases (Core, Web, IM, Mobile) and Levels (Core, Advanced) based on functionality in the respective category.

  198. Ge0rG

    Also I don't think that "Core Core" is actually a problem because you can deduplicate those words.

  199. jonasā€™

    I don't think that the "what does advanced even mean" can be solved in a single council session, even though it seems like something council should have a stance on.

  200. dwd

    Ge0rG, Right, exactly. The levels are based on functionality. We decide what functionality belongs in what level based on, I dunno, functionality. Or level. I'm absolutely not blaming you for this, we should have dealt with this when we first came up with the levels.

  201. Ge0rG

    we could rename the levels to "Must", "Should" and "May"

  202. Zash

    šŸ˜€

  203. dwd

    Ge0rG, I did consider that, actually.

  204. dwd

    Anyway, I wrote a screed on this to the mailing list.

  205. jonasā€™

    (what to do with a SHOULD in a spec which is listed in Should?! šŸ˜)

  206. dwd

    But you didn't see it because I looked at the draft and binned it.

  207. dwd

    Mostly because we'll never fix it before the end of the year.

  208. Ge0rG

    dwd: there is always next year's CS.

  209. jonasā€™

    so how do we proceed with the vote here?

  210. jonasā€™

    does anyone want to cast this week?

  211. jonasā€™

    otherwise I'd like to move on

  212. dwd

    So instead, my proposal is that we accept this and publish it, and see if we can assemble a team (a SIG, maybe?) to figure out Compliance Suite policy for the next one.

  213. dwd

    Hence, I'll +1 this.

  214. jonasā€™

    dwd, that sounds like what I had in my head, so I like it ;)

  215. Ge0rG

    +1 with a minor note/question/AOB about promoting XEP-0379, XEP-0401 and XEP-445 into Advanced IM.

  216. Zash

    Observation: The diff is pretty small. https://xmpp.org/extensions/xep-0459.html#changes-2021

  217. jonasā€™

    Ge0rG, I think you should bring that up on-list

  218. dwd

    I wouldn't mind our Executive Director discussing the idea of a Compliance Suite SIG with the Modern XMPP people, if he could get into contact with them.

  219. Zash

    s/no/yes/ on 156

  220. Zash

    dwd, that sounds like a grand idea

  221. Ge0rG

    jonasā€™: what about issuing LCs on the three?

  222. jonasā€™

    Ge0rG, might be worth a shot

  223. daniel

    +1 to advance cs22

  224. jonasā€™

    Ge0rG, do you think you can get ahold of the author of '401 to figure out if they are interested in taking care of the document for the LC, and if they are not, would you shepherd?

  225. jonasā€™

    daniel, thanks

  226. jonasā€™

    Ge0rG, heh, okay

  227. daniel

    Fwiw I'm against adding those xeps to the CS

  228. Ge0rG

    jonasā€™: I'm aware of two clients and one server implementation (not sure about ejabberd), and I'm pretty sure the spec is solid, as far as pre-login IQ hacks go.

  229. Ge0rG

    jonasā€™: I'm interested in shepherding 0401

  230. jonasā€™

    Ge0rG, okay, thanks

  231. Ge0rG

    daniel: could you please explain?

  232. jonasā€™

    daniel, Ge0rG, re inclusion in the CS, please take that to the list

  233. jonasā€™

    it makes more sense to discuss this in the open

  234. jonasā€™

    and in the corresponding thread

  235. jonasā€™

    moving on

  236. jonasā€™

    6) Date of Next

  237. Zash

    +1 to cs2022 and let's make 2023 the best one ever

  238. jonasā€™

    +1w wfm, unless we're in assembling-furniture-frenzy and I completely lose track of the time

  239. daniel

    +1w wfm

  240. jonasā€™

    (I'll hold my vote to give Ge0rG and daniel a chance to discuss the onboarding XEPs on-list)

  241. Ge0rG

    +1W WFM

  242. Zash

    +1w wfm

  243. dwd

    +1WWWWWFM.

  244. Ge0rG

    jonasā€™: thanks very much!

  245. jonasā€™

    7) AOB

  246. jonasā€™

    7a) XEPs format

  247. Zash

    `xmllint` all the things?

  248. jonasā€™

    there has been the occasional feedback that it'd be nice to edit XEPs in markdown. the XML we use is also a really terrible example of how to use XML for documents IMO.

  249. jonasā€™

    I was wondering what your folks opinion on that would be, editor hat on.

  250. Zash

    The XML we have mixes tabs and spaces and have very long lines

  251. jonasā€™

    with "that" being changing the official XEP language to markdown, from our custom XML schema.

  252. Zash

    Properly formatted and indented XML is much nicer to edit

  253. jonasā€™

    Zash, I prefer long lines for editing.

  254. dwd

    I'm not mad keen on Markdown for canonical specification work, especially as it's nice to be able to extract the metadata (even if we tend not to do that right now).

  255. Ge0rG

    any text reflow mechanism will cause horrible PRs.

  256. Sam

    I have a formatter for XEPs somewhere that re-wraps lines to a configurable line length and re-tabs everything if the editors want it. I think it's left over (though it might have been rewritten since then too) from when I was an editor and we wanted to redo a few tools

  257. jonasā€™

    because of exactly what Ge0rG said

  258. dwd

    I *am* keen on allowing people to write XEPs in Markdown and then convert them.

  259. jonasā€™

    dwd, I hear you can have YAML headers on Markdown files

  260. Zash

    I did make those markdownā†ā†’XEP XML tools, which are in the repo since some time.

  261. jonasā€™

    the problem with the tools is that they'll bitrot if not used regularly

  262. Ge0rG

    I have no strong feelings about the tooling people want to use, as long as somebody provides a word-diff tool. We used to have that and it was very useful.

  263. jonasā€™

    I hear that word-diffing markdown is much easier than word-diffing rendered HTML

  264. Ge0rG

    what about word-diffing XML?

  265. jonasā€™

    Ge0rG, noisy, but probably easier than the rendered HTML ;)

  266. Ge0rG

    jonasā€™: also is now a good time to remind you of markdown being a *superset* of HTML?

  267. daniel

    Wouldn't we be loosing entities?

  268. Sam

    I think Dante wrote a whole book about doing that

  269. jonasā€™

    daniel, that's a good point I hadn't thought of

  270. jonasā€™

    okay, we're overrunning anyway

  271. jonasā€™

    any other AOB? (looking at Ge0rG )

  272. Zash

    That's often an argument for reStructuredText or whatsitcalled, having macros or something

  273. Ge0rG

    jonasā€™: I'm taking those to the list I think.

  274. jonasā€™

    (reST would come with a non-terrible-hack-based PDF renderer, too.)

  275. dwd

    Also I do like having named anchors in XEPs for long-term reference.

  276. jonasā€™

    Ge0rG, thanks!

  277. Ge0rG

    At least the XEP-0379 ones.

  278. Ge0rG

    not sure what else I wanted to rant about.

  279. jonasā€™

    excellent

  280. jonasā€™

    let's close then before you remember ;)

  281. jonasā€™

    8) Ite Meeting Est

  282. jonasā€™

    thanks everyone

  283. Ge0rG

    good idea

  284. Ge0rG

    thanks jonasā€™

  285. daniel

    Thanks everyone. Thanks jonasā€™

  286. Zash

    Thanks all

  287. dwd

    Thanks jonasā€™

  288. sonny has left

  289. sonny has joined

  290. paul has left

  291. Kev

    > I'll instruct the editor to merge it then, unless anyone voices another complaint to me until the next merge window So, at the risk of being an arsehole, why does the Editor need an instruction to merge it? We have a process, which is that Authors have free reign to edit XEPs as they wish before Draft-as-was. In principal Council could potentially instruct the removal of an Author (although I'm not *sure* we ever codified that), but the Editor choosing not to merge a change is (almost?) unprecedented.

  292. Kev

    Maybe it was sensible in this case to hold off on the change, and maybe 313 is odd because of the Matt/Kev tag-team, but to be honest as the author submitting the change here the fact that it's being repeatedly suggested that I have to justify why I should be allowed to make edits to the XEP is starting to grate a little.

  293. paul has joined

  294. ChronosX88 has left

  295. ChronosX88 has joined

  296. Kev

    And the minutes saying that the Editor is intending merging Zash's change (which I don't think has been PRd yet) rather than mine is I *think* a typo, but didn't help my mood as I read that before reading the log here.

  297. Ge0rG

    Kev: I think there is this weird limbo after issuing a Last Call and before the actual advancement takes place, where changing the XEP can lead to Council Confusion

  298. Ge0rG

    daniel: I've written my suggestion to include 0379++ to standards@, feel please reply on list :)

  299. Ge0rG

    daniel: I've written my suggestion to include 0379++ to standards@, please reply on list :)

  300. Ge0rG

    Kev: and indeed, I agree with your assumption that it's a typo and that consensus was to merge your change

  301. Ge0rG

    (also given that your change fixed two of the issues I had, and Zash only provided a suggestion for fixing one of them)

  302. jonasā€™

    Kev, uhh, you're of course right.

  303. Kev

    I'm not even that precious about my change, and maybe there's a better one to be made (although I don't think Zash's works very well once you follow it through to conclusion), I'm just feeling frustrated that we're not applying our usual process to the change.

  304. Zash

    I'm not sure what the conclusion is, it seemed to get more complicated the more I was thinking.

  305. jonasā€™

    I (editor hat) treated this specially because '313 is currently undergoing the scrutiny of the last call process. It was a direct consequence of LC feedback from at least one council member, so to me (editor hat) it made sense to postpone applying this to keep the workload for me (editor hat) lower. Otherwise, I was running at risk of applying a change which would be modified just a week later when a council member decides to veto advancement because of disagreement.

  306. jonasā€™

    If you think I could've handled this better, please let me know. I didn't mean to offend you in any way (by "picking" on your change). I'd have treated this the same for any change to a XEP under LC (we did the same for a change to 280, effectively)

  307. jonasā€™

    It might've been handled differently if I wasn't editor and council chair in the same person, mind. It allows me (editor) to really quickly sync a "plan" with me (council) to get things done in the most efficient manner (for me) possible. If we had more editors, it might also have gone differently because as you say, the process is rather clear on that you could've just applied that change without any confirmation (so another editor might've done that). And it wouldn't even have been bad that way, because the load is spread. I'm currently trying to keep the load for the editor low, because it's enough work as it stands.

  308. Kev

    I think if our SOP is that once a LC is issued, Authors can't make changes to the XEP without Council approval, I think we should change our documents to reflect that (and *maybe* that's not a bad change), and also ensure that an LC can't happen without the Authors agreeing (I can't remember what the current state of LC issuing is, TBH).

  309. Ge0rG

    Kev: the author or a shepherd needs to request the LC from editor

  310. Kev

    I'm aware the Editor is spread thin, and I don't want to shit on the people actually doing the volunteer work for the XSF in this or other cases, to whom I'm grateful, nor make this a personal attack. I do think that if a PR that an Author is allowed to make isn't being merged, that unless we change process so they're not automatically allowed to make it, it would be useful for the Editor to explain why they would like to not merge it, and get the Author to agree. TBH, If asked "Can we hold off merging this for review so we don't have to issue two changes back to back?" on the PR, I *imagine* I'd have said 'fine'.

  311. Ge0rG

    Well, https://xmpp.org/extensions/xep-0001.html#proposal states that the "Editor shall formally propose *a specific revision of the XEP*" (emphasis mine), so this is not quite reflecting our current process.

  312. Zash

    I suppose that compounds with the general versioning troubles we've had

  313. Ge0rG

    Ā§6 Discussion Process doesn't explicitly mention but kinda-sorta assumes that the author is responsible during "Experimental" and maybe "Deferred"

  314. Zash

    .. but not while Proposed?

  315. Ge0rG

    Zash: the relevant part is in Ā§8.1: > Ultimate authority for Stable XEPs rests with the XMPP Council

  316. Ge0rG

    so we do not have formal restrictions on the author during Proposed.

  317. marc0s has left

  318. marc0s has joined

  319. marc0s has left

  320. marc0s has joined

  321. jonasā€™

    Kev, feedback noted, I'll communicate that better next time. Thanks!

  322. debacle has left

  323. marc0s has left

  324. marc0s has joined

  325. debacle has joined

  326. larma has left

  327. larma has joined

  328. David has left

  329. David has joined

  330. ChronosX88 has left

  331. ChronosX88 has joined

  332. me9 has left

  333. me9 has joined

  334. marc0s has left

  335. marc0s has joined

  336. marc0s has left

  337. marc0s has joined

  338. sonny has left

  339. sonny has joined

  340. sonny has left

  341. sonny has joined

  342. SouL has left

  343. SouL has joined

  344. Wojtek has left

  345. Tobias has left

  346. me9 has left

  347. marc0s has left

  348. marc0s has joined

  349. marc0s has left

  350. marc0s has joined

  351. larma has left

  352. debacle has left

  353. SouL has left

  354. sonny has left

  355. sonny has joined