XMPP Council - 2019-11-06


  1. Kev Ge0rG: Given your mail earlier, is it no longer your intention to try to get CS2020 through this Council?
  2. Ge0rG Kev: answering that question with either yes or no would end up ambiguous.
  3. Ge0rG Kev: I don't have my mail in front of me, but my intention was to vote on Draft today, and have Social added during Draft
  4. Kev Ah, I see.
  5. Ge0rG Not sure what kind of wording mishap happened to make you think I changed my plan
  6. Kev Your words were right, I just didn't understand them (because the thought of pushing it to Draft while there were pending changes didn't process)
  7. Ge0rG Sorry for stalling your pipeline
  8. jonas’ .
  9. Ge0rG Is it one of those days?
  10. Kev Always.
  11. Ge0rG no, only with a probability of roughly 14%
  12. Ge0rG Do we have a Dave?
  13. Link Mauve It is one of those days.
  14. dwd We have a Dave.
  15. Kev I think Dave's too busy in xsf@ trying to find Boris-inspired ways to avoid democracy :)
  16. Kev Ah, there we go.
  17. dwd 1) Roll Call
  18. Kev Present.
  19. jonas’ me too
  20. Ge0rG ,o/
  21. dwd Assuming Ge0rG and Link Mauve are still here, full house.
  22. Link Mauve Yes.
  23. dwd 2) Agenda Bashing
  24. dwd XEP-0243 to Draft, and that's it, right?
  25. Ge0rG I have two points for the Agenda, related to CS-2020
  26. dwd AOB or voting things?
  27. Ge0rG a) shall XEP-0392 Consistent Color Generation be demoted from "Advanced IM Client" into "Future Development"? b) Can we advance XEP-0423 to Draft, given the changes that I promise to have pushed some time tomorrow.
  28. dwd OK, given these, let's discuss these first and *then* vote if we're to do so.
  29. dwd 3) Georg's Things.
  30. Kev 3a) Yes.
  31. jonas’ I have no strong opinion on (a)
  32. dwd a) shall XEP-0392 Consistent Color Generation be demoted from "Advanced IM Client" into "Future Development"?
  33. jonas’ do whatever works
  34. Ge0rG Yes please.
  35. Ge0rG I was heavily criticized for adding it to the mandatory list of the Compliance Suite, because Council is not competent at guiding UX, and because it's not ready yet and for other reasons.
  36. jonas’ so just remove it since that seems to be what the (loud part of the) community wants?
  37. dwd I don't think I have an opinion here. But given the Wailing and Gnashing Of Teeth, I'm thinking punting it out of the compliance per-se would be the path of least contention.
  38. Link Mauve I’d say remove it, it can always get integrated back later once it’s clear it works properly for everyone.
  39. Ge0rG indeed, but I have no fear of contention.
  40. Kev My opinion isn't /that/ strong, but I don't think it belongs there, at the moment.
  41. Ge0rG XEP-245 is also clearly guiding the UI design, and nobody objected _that_ (except for its ugly wire format)
  42. dwd Personally I think there are UX issues in much if not all of what we do, but I would rather than CS matched some kind of community concensus anyway.
  43. Kev I think that's vague agreement on 3a, then?
  44. jonas’ (ftr, I need to leave at 16:30Z sharp)
  45. dwd jonas’, Ack.
  46. dwd I think we have rough consensus on 3a), yes.
  47. Ge0rG well, then. https://github.com/xsf/xeps/pull/851/commits/8182e2e38b25bda0a1febe7dc1019c9b0bf2a630
  48. dwd b) Can we advance XEP-0423 to Draft, given the changes that I promise to have pushed some time tomorrow.
  49. Kev I'd be happy to advance to Draft once my feedback's addressed.
  50. Ge0rG The promised changes are in #851, except for an update to the "Changes since 2019", which I'll fix after consensus is reached
  51. dwd This one is more problematc for me. My gut feeling is "no", modulo some very persuasive arguments I've not thought of.
  52. Kev I've not had a chance to check the rendered copy for differences from what I reviewed yet.
  53. Ge0rG Kev: your feedback was adressed on-list as well as in #851
  54. pep. > Ge0rG> XEP-245 is also clearly guiding the UI design, and nobody objected _that_ (except for its ugly wire format) I wanted to.. :-°
  55. Ge0rG dwd: if we make it a formal vote starting today, we can manage to make a decision right before Council falls apart
  56. pep. But it's so much used everywhere..
  57. Ge0rG can imagine
  58. dwd When does Council cease to exist?
  59. jonas’ I have a bad gut feeling about the pre-vote process-wise too
  60. jonas’ dwd, the election meeting is on nov 21st
  61. jonas’ so the last council meeting will be on nov 20th
  62. Kev #851 also adds 156 (probably ok), 520 in future (probably ok), and adds 77, which I don't think is ok, as well as the Push thing being weird (because at least Android nor iPhone guarantee long-lasting background connections, AFAIU).
  63. jonas’ i.e. 2 weeks from now
  64. dwd Ge0rG, Can you get everything merged by tomorrow?
  65. Ge0rG dwd: please ask Editor.
  66. jonas’ can we have an irregular council meeting tomorrow?
  67. jonas’ Ge0rG, if it’s finished by tonight, I can arrange that
  68. jonas’ (tonight ~= 18:00Z)
  69. Ge0rG dwd: I'll take all Council feedback that I can get and update the PR
  70. Ge0rG jonas’: ack
  71. dwd jonas’, That's what i was thinking. Nothig says our meetings have to be every week (indeed, they weren't until recently).
  72. Ge0rG Kev: does "I don't think is ok" translate into a -1?
  73. Kev Where 'recently' is probably longer than they weren't ;)
  74. jonas’ I can join any time tomorrow except 10:45Z -- 11:45Z (lunch \o/) if I know when
  75. dwd Kev, More than likely, these days.
  76. Kev Ge0rG: Including 77 feels wrong to me.
  77. Link Mauve I can join any time tomorrow.
  78. Ge0rG Kev: why?
  79. dwd AGM is at 1900Z?
  80. jonas’ I think IBR is very right to include
  81. Link Mauve Kev, 77 feels right to me, maybe excluding account registration.
  82. jonas’ dwd, yes
  83. Link Mauve But allowing users to change their password is a must imo.
  84. Kev Because it pretty much presupposes that these things are Internet.
  85. pep. Ge0rG> dwd: please ask Editor. I can also help
  86. Link Mauve And supporting account registration (in a software) also seems like a must.
  87. Ge0rG Kev: this is about implementation support, not about having it enabled by default
  88. Kev Link Mauve: I think for just about all non-Internet (and a good chunk of Internet) cases this isn't true.
  89. Zash Mandating support for registration does not mean it has to be enabled on every deployment
  90. jonas’ Kev, note that software and deployment are separate things and disabling either registration and/or password change due to restrictions is valid
  91. jonas’ Kev, supporting account registration on the client side is very reasonable IMO, especially since there have been efforts of building onto the data forms flow of '77 for invitations and such
  92. dwd Guys, stop a sec - if we hold a meeting tomorrow at, say 1600Z, can we all make it and do we think we can have CS-2020 ready for a vote by then?
  93. Kev I understand the distinction between deployment and implementation, but I think requiring stuff that's only interesting for (some) Internet deployments isn't right here.
  94. jonas’ ("invitations" = links with tokens which allow registration to a deployment)
  95. Ge0rG Kev: do you actually have a server or client software that can't be configured to do IBR?
  96. Kev Ge0rG: Several :)
  97. Ge0rG Kev: do those care about being "Core IM"?
  98. Link Mauve dwd, I can be there at 17:00 CET tomorrow.
  99. jonas’ can we agree on having this only "Advanced"?
  100. Kev "Care" isn't the right word, probably, but I think the other stuff in the compliance suite that they don't do they reasonably could, wherease IBR just isn't appropriate.
  101. dwd Kev, Ge0rG, jonas’, Link Mauve - Can we agree a meeting tomorrow at 1600Z, and if so, can we have CS-2020 merged and published ready for a vote by then?
  102. Ge0rG jonas’: it doesn't make much sense to me, but yes
  103. jonas’ dwd, yes, works for me
  104. Ge0rG dwd: +1
  105. Link Mauve +1.
  106. Kev I *think* I can do 1600 tomorrow.
  107. jonas’ (dwd, sorry, I wasn’t ignoring you, I was polling my calendar)
  108. Kev But I think thrashing this out now is worthwhile.
  109. Kev Else we'll get to the meeting tomorrow and vote on something not ready to pass.
  110. dwd OK, in that case I move to adjourn the formal Council meeting until tomorrow. But feel free to use the remaining time now to thrash things out.
  111. Ge0rG yes, having it done by tomorrow's meeting implies that we make all the decisions now
  112. Kev That is, I think we should go into tomorrow with the approval being a formality.
  113. jonas’ dwd, I think that’s a very good move
  114. dwd Ge0rG, It does, and I agree with kev.
  115. Kev dwd: On the IBR point, or on the point that we should agree it now?
  116. Kev s/now/before the time of the meeting so it's a formality/
  117. dwd So, my view on '77 is that it's useful for password changing and IBR in various cases, but in a number of deployments it's undesirable if not impossible.
  118. jonas’ and deployments are free to disable features of the software
  119. dwd Kev, That we discuss things now so tomorrow is, as much as possible, a formality.
  120. jonas’ CS is for software, not deployments AFAIU
  121. Ge0rG What jonas’ said. But I've been thinking about a "deployment" category-thing somewhere in it.
  122. dwd jonas’, It's also for expectations. Could a client find itself reliant on '77 and unable to function without?
  123. Link Mauve Kev, which kind of software can’t change passwords (at all, not depending on e.g. having connected with specific SASL mechanisms), btw?
  124. Kev Link Mauve: Anything running against a corporate directory, probably.
  125. Ge0rG dwd: I don't see such a dependency in 0077
  126. jonas’ Link Mauve, my prosody can’t change passwords because it doesn’t have th enecessary permissions on the ldap database
  127. Ge0rG I also can't imagine a client that will only work if you use it to register a new account.
  128. jonas’ 16:18:27 dwd> OK, in that case I move to adjourn the formal Council meeting until tomorrow. But feel free to use the remaining time now to thrash things out.
  129. Link Mauve Right, but Prosody the software can, if it is configured against another type of database.
  130. jonas’ can we do this please?
  131. Ge0rG you are drifting into deployments again
  132. jonas’ if I can catch a bus earlier that would be very useful
  133. Kev dwd: Close the meeting, sure.
  134. Link Mauve jonas’, I thought it was already adjourned.
  135. jonas’ and I don’t think this discussion is helpful for me or vice versa
  136. dwd 99) Ite, Meeting Est
  137. Link Mauve And we were just continuing the discussion.
  138. jonas’ dwd, thanks :)
  139. dwd (But don't Ite)
  140. jonas’ date of next: 2019-11-07T16:00:00Z
  141. Link Mauve jonas’, see you tomorrow. \o_
  142. Ge0rG bye jonas’, I'll ping you and pep. with the finished PR
  143. jonas’ Ge0rG, thanks
  144. Ge0rG Kev, dwd: jonas’ suggested demoting IBR into "Advanced IM", to which I can agree.
  145. Ge0rG Now the question is: can you, too?
  146. Kev I think it's wrong there, too.
  147. dwd I think it's Basic with a note that says "Implem,entations cannot rely on XEP-0077 being deployed for either IBR or password changes as these may be undesirable or unavailable in a given deployment"
  148. Kev Because it's meaning "IM" is "public open registration chat service", basically, and I think you can legitimately have an "Advanced IM client/server" for all the other uses cases that aren't the "public open registration chat service"
  149. Link Mauve I guess the goal of CS is relevant here, do we want to have a document to point newcomers who want to write XMPP software to, or do we want to have a document for certifying our existing software, or something else?
  150. Kev BRB.
  151. Kev And back.
  152. dwd Kev, WHat do you think of my note suggestion?
  153. Kev I could do both Basic and Advanced with a note saying "Only when intended for public open registration chat services" or something, similar to the weasel words for Push (with which I don't agree, but can live).
  154. Kev dwd: I don't like it being required for implementations.
  155. Kev I think there's wiggle room here if people really want it in - but wiggling is needed.
  156. Kev Or something like "If in-band password change is provided, it must be provided with 77, if not an alternative out of band mechanism for password change must be possible". I think the registration part shouldn't be there for either, though.
  157. Ge0rG What would be the alternative place to put it in?
  158. daniel if the CS is mostly about discoveribility or steering people to the right xeps for problems that have multiple xep solutions; i don’t think that ibr is hard to discover
  159. daniel for those who need it
  160. Ge0rG Do we need a new category "Public IM" just for IBR and 0157?
  161. Kev Ge0rG: We could also just have a section ...
  162. Kev I was thinking "Account Management" just for 77.
  163. Ge0rG Kev: what's a section in CS terms?
  164. dwd Or a section of "Other specifications of note", like the Future Dev one?
  165. Kev dwd: Perfect.
  166. Link Mauve Account Management should include a lot more than just 77, but that’s all we have atm.
  167. Link Mauve Things like MAM messages lifetime configuration, cleaning uploaded files up, etc.
  168. Ge0rG Link Mauve: write the XEPs, and get them into CS-2021
  169. Zash Ad-hoc?
  170. Link Mauve Ge0rG, yes.
  171. Link Mauve Zash, yes.
  172. Link Mauve Ge0rG, current MAM already includes that, future MAM won’t anymore.
  173. Kev I would suggest either "Other specs of note" as Dave said, or a new suite just for 77.
  174. Ge0rG dwd: can we have a more formal name for it? "Further relevant specifications"?
  175. Zash Suggested Reading, eg for the Mobile power consumption one?
  176. Ge0rG I see a certain value in a new category "Public IM"
  177. Kev There are other things that might belong there, like spam handling.
  178. dwd Ge0rG, "If You Like These Suites, You'll Love:"
  179. Kev (Not this year)
  180. Link Mauve Another future category, but that’ll be 2021 at least, would be audio/video.
  181. Link Mauve “Jingle Category”
  182. Ge0rG dwd: I'm not sure I'll get _that_ through tomorrow's council
  183. Ge0rG I'd prefer a "Public IM" category over a section, because it's better structured that way. Also would include 0191
  184. dwd Ge0rG, "Further Specifications" section in each Suite. Good place to put '77, '286, and so on.
  185. Kev I note that you can do 'Public IM' fine without 77 too, but I'm much less militant about that.
  186. dwd Ge0rG, Would work for '392, as well. Stuff we can't or shouldn't mandate, but might be useful.
  187. Ge0rG dwd: I have a bit of a fear that it will end up in a huge list of meaningless and unweighted bullet points
  188. Kev I like the "Further Specifications" (or "Further Specifications Of Note") idea per suite best, but can go along with the new suite.
  189. Ge0rG In that case I need to weigh on which XEPs belong into "Further" and which ones belong into "Future"
  190. Ge0rG Okay, I will create new "Further Specifications of Note" bullet lists in the relevant Compliance Categories. Next?
  191. dwd I don't see anything else raised by Council folks.
  192. Kev 66 goes in there, I think, and that addresses my other bit of feedback.
  193. dwd Oh, there we go.
  194. Ge0rG 66 together with SIMS?
  195. Ge0rG 0333 as well, I suppose.
  196. Link Mauve SIMS is very much future atm.
  197. Kev I would avoid adding anything more than we've already been through.
  198. Kev It feels like we've got something we can live with. Further tweaking is inviting calamity.
  199. Link Mauve So it’s safe to ignore it for this year.
  200. Kev IMNRHO
  201. Ge0rG Kev: do you consider the current state of #851 as "we've been through it"?
  202. Ge0rG and I'll move IBR, 66, SIMS, 0392 into the "Further Specifications Of Note" sub-section and be done with it?
  203. Kev I mean, if the new stuff gets moved into the new 'Futher Specs' bit, it looks ok to me, I think.
  204. Kev Oh, yes, 392 in Further Specs is better than Future, good call.
  205. Kev I think there was one extra thing added with 77? Let me check.
  206. Kev Oh, 157. I think that's better in Futher Specs, but don't feel as strongly as 77.
  207. Ge0rG Kev: 157 hangs on 777
  208. Ge0rG Kev: 157 hangs on 77
  209. Link Mauve Does it?
  210. Kev Ah, it's in there only as 'recommended for public servers' anyway.
  211. Zash Is CS meant to be a deployment thing now, not just an implementation thing?
  212. pep. Kev, As a private entity it might still be good to know which part of another private entity I should reach directly, if the information is available
  213. Ge0rG Kev: https://op-co.de/tmp/xep-0423.html#im
  214. Ge0rG Zash: shush!
  215. pep. Zash, apparently..
  216. Kev Implementations are always intended for deployment. If your implementation isn't for deployment in a public server (in the sense here) the implementation doesn't need to support it.
  217. pep. What about what I just said?
  218. pep. It would still be a private deployment
  219. pep. federating
  220. Kev Ge0rG: I've just read the "Further Specifications of Note" thing under #im, and that looks good.
  221. Kev Thanks for sticking with this.
  222. Ge0rG Kev: I've renamed it to "Further specifications of note, which are not required for compliance:" for maximum explicity
  223. Kev pep.: I didn't say 157 needed to be public only, I just said that in the diff it was public only, which is at least as restrictive as I felt was needed.
  224. Kev Ge0rG: Thanks.
  225. pep. I'm still not sure why you'd want to get Core/Advanced IM compliance for a private deployment anyway, but oh well
  226. Kev FWIW, annoying as this probably is, I think having these sections makes the CS much better than trying to shoe-horn things into compliance, or be ignored completely, so it's a net win, even if at an unfortunate time.
  227. Kev pep.: People still have to write the implementations that people then select for private deployments.
  228. pep. Well they you define your specset and be done with it?
  229. pep. And you call it PrivateCompliance(tm)
  230. Kev If you can always just define the features you want, and check if implementations support them, and don't need guidance from the XSF, the Compliance Suites have no value.
  231. Ge0rG could you please stop that meta discussion? It's making my head spin
  232. Ge0rG Kev: also just moved 0286 into a similar space under https://op-co.de/tmp/xep-0423.html#mobile
  233. Kev Ge0rG: Unless I've missed something, we're good now, and we should stop this.
  234. Kev Ge0rG: I think that's an improvement too, thanks.
  235. Ge0rG Kev: thanks very much for the heated debate, I also consider this as an improvement over before, even for 77
  236. Kev pep.: I think that "The Internet is the only network we have to think about, or 'all services are public services'" are mindsets the XSF falls into quite often, and it's very harmful.
  237. Kev pep.: I think that "'The Internet is the only network we have to think about', or 'all services are public services'" are mindsets the XSF falls into quite often, and it's very harmful.
  238. pep. I think the question is pretty clear, who is the target of CSs, and why would a private company want to comply to it. If they deem they don't need avatars they just don't do avatars
  239. Kev It sounds like you're assuming that anyone with a private deployment wrote it themselves, or had it custom-produced for them.
  240. Ge0rG Kev: that sounds like a strong parallel to the CA/BF and other entities equalling "Internet" with "Web", and causing much more collateral damage than we ever could
  241. pep. Kev, sure. I'm not promoting free software dev slavery for profit-driven companies
  242. pep. And I think I'm done with this discussion.
  243. Kev Who said anything about free software, or profit-driven companies?
  244. Ge0rG but I still think that supporting IBR in an implementation is a net win for that implementation, even if it's targeted at Enterprisey Enterpises.
  245. daniel I think having a map for the jungle of xeps is very valuable to all kind of implementations. The map should just properly mark paths as such if they are only valuable for some demographics
  246. Kev daniel: I agree (and I think Ge0rG's changes just now make this much better).
  247. daniel It not just about getting the 'compliancy stamp'
  248. Kev Yes. I see the compliance suites as more useful for advice to implementors about what people choosing software might need, than about a sticker.
  249. Kev It's why, in a future year, I'd like to see them not called Compliance Suites, but something that better reflects they're Implementation Advice.
  250. pep. Then I don't understand why you fight so hard against IBR. These two last messages make me wonder
  251. pep. If you don't want the stamp anyway
  252. Kev Because I think it's bad advice to say it's needed in the general case (plus, as long as the compliance suites advertise themselves as compliance suites, they'll be treated as such).
  253. daniel > It's why, in a future year, I'd like to see them not called Compliance Suites, but something that better reflects they're Implementation Advice. I think I agree with that. The compliance suites have certainly evolved into what can be understood as implementation advice.
  254. pep. wherever there are green checks people will see green checks. Call it however you want ("Compliance Suites" or "Implementation Advice")
  255. daniel That being said. Stickers are also nice
  256. daniel Blindly chasing green check marks is probably not something we want to encourage
  257. daniel Says the person who developed the compliance tester
  258. Link Mauve Kev, I’m thinking about drafting a blog post emphasising “XMPP 2020”, with the compliance suite being its technical specification, but also to encourage implementations to get the stamp.
  259. Ge0rG My feeling with much of the 0392 backlash was that it came from people blindly following green checkmars.
  260. Link Mauve I don’t know if that aligns with your views.
  261. pep. Ge0rG, did it?
  262. Ge0rG I disagree with Kev regarding the value of a CS-2020 stamp, so feel free to put my name on that blog post ;)
  263. Ge0rG Link Mauve: ^
  264. Link Mauve :D
  265. Link Mauve A little bit of marketing won’t hurt us. ^^
  266. Link Mauve I’ll let you all review it of course.
  267. Ge0rG pep.: along the lines of "we can't implement 0392 while following the Whatever Usability Guides so now you make us lose Advanced IM!"
  268. Ge0rG pep., jonas’: https://github.com/xsf/xeps/pull/851 is ready to merge now
  269. pep. k
  270. Ge0rG pep.: good luck doing the version block!
  271. Ge0rG 🙈🙉🙊
  272. Ge0rG But I suppose you can derive it from https://github.com/xsf/xeps/pull/851/commits/b378edaa069b2d4df2fa5c0b88bf0c927dd585ff
  273. daniel But yeah I think we were successful in creating a compliance suite that nobody implements
  274. pep. Ge0rG, you know generally we just add the "Needs version block" label and let people do?
  275. pep. I'd prefer if you did it, you know best what goes in there :x
  276. pep. ok if it's "just" that I can have a look
  277. Ge0rG daniel: in light of that statement, I now see why you didn't follow up to our recent discussion re Compliance Checker vs Compliance Suite, and how the latter can learn from the former
  278. Ge0rG pep.: I always struggle with what version to put in there, and fear that Editor Tooling will mess around with it. Sorry
  279. pep. Update the minor, it's not an editorial change
  280. pep. editorial is patch, and major is process
  281. pep. (I mean.. experimental, draft, final)
  282. pep. I'm also very much new to that anyway :P
  283. Ge0rG pep.: see, you can train your editor skills now! ;)
  284. pep. How lucky am I!
  285. Ge0rG I'll try to do it next time, but I still haven't fully recovered and already spent more on 0423 today than my time budget permitted.
  286. pep. k, I started already
  287. pep. Ge0rG, you forgot to add 333 and 420 in the changelog since 2019
  288. Ge0rG pep.: you just made me shiver a little bit, but I intentionally left out "Future Development" from "Changes since 2019"
  289. pep. I see. I'm wondering if I should add that in the changelog. But I see now I've copied your block last time and it wasn't in it..
  290. pep. Ge0rG, pushed. Let's wait for CI now..
  291. jonas’ pep., just build locally with docker
  292. pep. I don't have a good enough uplink
  293. pep. it takes ages
  294. jonas’ building?
  295. jonas’ or pushing?
  296. Zash worry about your downlink
  297. pep. pushing
  298. jonas’ right
  299. jonas’ is it on master already?
  300. pep. yeah it's master
  301. jonas’ I’m building it
  302. pep. thanks
  303. jonas’ this 1 MiB/s uplink must be good for something.
  304. Ge0rG > Microsoft is at capacity with at least some of its Azure VMs in the East US2 region, users are reporting. Microsoft acknowledges it is placing restrictions on additional quota on some customers there: https://t.co/8cCaKvJJh1 Stop using the cloud already! It's overloaded! https://twitter.com/maryjofoley/status/1190015959140057089
  305. Zash The cloud isn't a big truck!
  306. Ge0rG Yes it is!
  307. Ge0rG https://upload.yax.im/upload/lfkVjwUG0FDz6k4b/awssnowmobile.0.jpeg
  308. Zash Oh snap
  309. jonas’ pep., push’d
  310. pep. Thanks, I sent the email