XMPP Council - 2019-10-09

  1. Wojtek has left
  2. debacle has left
  3. daniel has left
  4. daniel has joined
  5. Tobias has joined
  6. lnj has joined
  7. sonny has joined
  8. moparisthebest has left
  9. vanitasvitae has left
  10. pep. dwd: https://github.com/xsf/xeps/pull/840 I think you forgot this
  11. pep. (Mentioned above)
  12. vanitasvitae has joined
  13. debacle has joined
  14. debacle has left
  15. kusoneko has left
  16. kusoneko has joined
  17. debacle has joined
  18. moparisthebest has joined
  19. Zash has joined
  20. Ge0rG Is it Council Meeting Day again?
  21. Ge0rG Time flies fast.
  22. Kev I shall be trying to make it, but AFK a bit.
  23. kusoneko has left
  24. kusoneko has joined
  25. Syndace has left
  26. Link Mauve Hi, I am here.
  27. Ge0rG Hi Link Mauve
  28. jonas’ I am here too
  29. jonas’ I also just sent feedback on CS-2020 to the list
  30. Link Mauve Breakfast is almost ready here.
  31. Ge0rG Damn, I'm hungry.
  32. jonas’ I could eat, too.
  33. jonas’ that’s not fair.
  34. Link Mauve I’m still so sad for the onions I just cut, and I don’t know why.
  35. jonas’ because you murdered those onions
  36. Link Mauve jonas’, uh, I haven’t received your email yet.
  37. Link Mauve Ah, now I have.
  38. dwd Oh, good lord. It's time for a meeting.
  39. jonas’ Link Mauve, yeah, the list server is a bit slow
  40. dwd So.
  41. dwd 1) Roll Call
  42. Link Mauve o/
  43. jonas’
  44. Ge0rG ,o/
  45. dwd Great, that's quorum.
  46. dwd 2) Agenda Bashing
  47. jonas’ as pep mentioned: https://github.com/xsf/xeps/pull/840
  48. dwd Note pep.'s comment above about #840.
  49. jonas’ I don’t know of anything else
  50. dwd 3) Items for a vote
  51. dwd a) ProtoXEP: Message Retraction https://github.com/xsf/xeps/blob/master/inbox/message-retraction.xml
  52. jonas’ why not: https://xmpp.org/extensions/inbox/message-retraction.html ?
  53. dwd Because I'm half asleep?
  54. dwd But yes, much better URL.
  55. Ge0rG on-list
  56. jonas’ on-list
  57. jonas’ shall handle it together with that message moderation protoxep
  58. Link Mauve On-list too.
  59. dwd I'm +1. But willing to be told I'm wrong later. :-)
  60. Ge0rG reaction, retraction, attach-to-fastening
  61. dwd Ge0rG, Retracting reactions is perfectly fine.
  62. Ge0rG dwd: what about correcting retracted reactions?
  63. Ge0rG We could probaby go on with this forever.
  64. jonas’ let’s move on.
  65. Ge0rG Did I mention I still have some more AOBs pending?
  66. dwd OK, we'll move to:
  67. dwd b) https://github.com/xsf/xeps/pull/840
  68. jonas’ I’m not sure if that needs a feature
  69. pep. context: https://mail.jabber.org/pipermail/standards/2019-October/036502.html as it's not mentioned in the PR
  70. dwd Is this suggesting that we has an infinity symbol as a legal value?
  71. jonas’ dwd, I think so
  72. Zash An "max_items=current + 1 plz" option would be handy
  73. Wojtek has joined
  74. pep. dwd, I assume it's just a placeholder, council can of course bikeshed on what to put as a value :P
  75. Ge0rG I'm not sure whether "∞" is supposed to be a verbatim value for that field, or just some elaborate joke.
  76. Ge0rG Oh, what dwd said.
  77. Syndace has joined
  78. Ge0rG Is the value to be transmitted by the server or by the client?
  79. dwd Well, I'll -1 this then. Having "-1" or empty seems sane for unlimited, but not novel unicode glyphs.
  80. Ge0rG I'm with dwd here.
  81. Ge0rG Also I don't understand the implied semantics of that value.
  82. daniel > Is the value to be transmitted by the server or by the client? both; depending on context
  83. Link Mauve -1 would be bad imo.
  84. jonas’ In any case, the text needs to be clearer on what the actual value on the wire for "the server limit" is.
  85. dwd pep., It's really not for Council to do stuff like that.
  86. Kev Here, sorry.
  87. Link Mauve Having it mean arbitrarily-high value wouldn’t be nice.
  88. pep. dwd, you mean it's not for council to provide feedback?
  89. jonas’ Link Mauve, but it does that when you cast it to uint ;-)
  90. jonas’ (* on some platforms)
  91. Link Mauve jonas’, so with an example?
  92. Ge0rG jonas’: don't get me started about the semantics of 0198 stanza counter overflow.
  93. jonas’ Ge0rG, :-)
  94. Ge0rG jonas’: it's NOT funny
  95. dwd pep., Sure, we can provide feedback that a symbol I can't remember how to type isn't going to work.
  96. dwd Anyone else voting?
  97. Kev I'd have thought "" would be better than ∞.
  98. Kev But then so would anything I can type.
  99. jonas’ I meant to say -1
  100. Ge0rG we need a value that is a distinct "explicitly set to unlimited", which "" maybe is not.
  101. Kev -1 for untypable glyphs in particular.
  102. Kev Ge0rG: It's not actually unlimited, is it? It's 'largest server-allowed value'.
  103. Ge0rG it could be just "-"
  104. Kev "", "-", "unlimited", "max", all are better than "∞", I think.
  105. dwd I could go along with "". That probably works on servers now. I doubt they all mandate an integer value here.
  106. Ge0rG Kev: "∞" is better than ""
  107. jonas’ this discussion reminds me of: > APL apparently used +.× [as infix matrix multiplication operator], which by combining a multi-character token, confusing attribute-access-like . syntax, and a unicode character, ranks somewhere below U+2603 SNOWMAN on our candidate list.
  108. jonas’ dwd, servers may easily default to 1 for ""
  109. jonas’ I wouldn’t trust that
  110. Ge0rG also there is ambiguity between "" and unset
  111. jonas’ especially PEP implementaitons.
  112. dwd Perhaps. Either way, the proposal is an infinity symbol, so the point it moot.
  113. Kev "max" sounds good to me, but anything typable beats untypable, I think.
  114. Zash dwd: Wrong. Prosody has some limited support for the dataforms datatypes XEP.
  115. dwd 4) Outstanding Votes
  116. Ge0rG We have two votes expire today
  117. dwd I'll get to those votes after this meeting.
  118. dwd I know I have outstanding.
  119. Link Mauve The value must be something current servers won’t understand imo, otherwise we’re exposing ourselves to implementation details.
  120. dwd I'm sure others do as well.
  121. dwd 5) Next Meeting
  122. pep. Kev, "max" sounds good indeed
  123. daniel could council provide me with some clear direction on how to fix the PR instead of just saying no?
  124. dwd Same time next week?
  125. jonas’ dwd, +1wwfm
  126. Ge0rG +1W WFM
  127. jonas’ daniel, I think we did. Don’t use "∞", use some text value instead. In addition, make it clear what is the magic value.
  128. Ge0rG daniel: replace ∞ with "max"?
  129. Ge0rG daniel: also it would be nice to have an explanation of the semantics of that value when sent by the client vs. by the server
  130. dwd daniel, You'll almost certainly need a feature if you're doing something existing servers don't understand.
  131. dwd 6) AOB a) Georg wishes to thrash out CS-2020, please review https://github.com/xsf/xeps/pull/841
  132. Ge0rG I've modified the XEP with a new intro text, added some more XEPs
  133. Ge0rG more XEPs to be added are asked for
  134. jonas’ oh, I forgot about that PR; luckily, judging from the summary, my feedback is still valid
  135. Ge0rG Also the "future work" section
  136. daniel > daniel: also it would be nice to have an explanation of the semantics of that value when sent by the client vs. by the server where. in the label?
  137. dwd daniel, Not now, please.
  138. Link Mauve Ge0rG, I’ll be on-list for that.
  139. dwd Ge0rG, I think everything you've got in #841 looks good.
  140. Link Mauve I wasn’t aware of this PR until now.
  141. Ge0rG jonas’ was so kind to propose some more XEPs for CS-2020
  142. Ge0rG ...on list
  143. Link Mauve But it looks nice.
  144. Ge0rG please also comment on jonas’ suggested XEPs
  145. dwd jonas’, Ge0rG - do you have an archive link to the email?
  146. Ge0rG oh, yeah: important detail: I want this XEP to get through Council before the Council re-election, so feedback closes on November 5th
  147. Ge0rG dwd: https://mail.jabber.org/pipermail/standards/2019-October/036515.html
  148. jonas’ dwd, one sec
  149. jonas’ dwd, ^
  150. dwd Thanks. That was of course for the record and not because I'd completely forgotten it.
  151. jonas’ dwd, the email I sent 4 minutes before this meeting started? ;)
  152. jonas’ good thing you didn’t forget about it, that would indicate very bad memory ;)
  153. dwd Oh, OK. So I'd just not seen it yet. :-)
  154. Ge0rG Apparently everybody is on-list to this AOB?
  155. dwd Ge0rG, Do you want a formal vote?
  156. Ge0rG dwd: on the PR? No.
  157. jonas’ Ge0rG, I think #841 looks good, but I didn’t review the yes/no changes if any because they’re hard to read in the diff.
  158. Ge0rG I'm the owner of the XEP, so I can do whatever I want.
  159. dwd Ge0rG, Indeed you can.
  160. Ge0rG jonas’: it was just a `s/#10005/no/g` kind of change
  161. jonas’ okay
  162. jonas’ Ge0rG, then only the feedback I already sent to the list standrs
  163. jonas’ Ge0rG, then only the feedback I already sent to the list stands
  164. Ge0rG jonas’: it was very good, thank you
  165. jonas’ you’re welcome :)
  166. Ge0rG I feel slightly inclined to abuse my power to add XEP-0379 to Advanced Mobile.
  167. dwd Ge0rG, I think it all looks good. I'm inclined to agree with Evgeny, too - ditching BOSH sounds like a plan.
  168. Ge0rG dwd: see my response on-list
  169. Kev I would be more inclined to keep BOSH with a note that where possible WSS is better.
  170. Kev (But am not vetoing anything that happens based on either outcome)
  171. jonas’ Ge0rG, something about tokens ;)
  172. jonas’ (would be an excellent response to evgeny)
  173. Ge0rG jonas’: something about rejected and/or abandoned protoXEPs
  174. jonas’ Ge0rG, something about SASL-HT something
  175. dwd Ge0rG, Something about client-key.
  176. jonas’ Ge0rG, something about Instant Stream Resumption (which is Experimental)
  177. jonas’ dwd, that’s what I meant
  178. Ge0rG jonas’: are you sure it's not Deferred?
  179. jonas’ Deferred \subset Experimental in my book
  180. Link Mauve Deprecating BOSH might be a plan, but it sounds like it’s still worth it to have it supported by servers.
  181. dwd Could we deprecate BOSH in clients but not in servers?
  182. Ge0rG Link Mauve: this is exactly what jonas’ suggested in the first mail
  183. jonas’ Ge0rG, not exactly
  184. Ge0rG dwd: we could in CS-2020
  185. jonas’ Ge0rG, I said clients can pick one
  186. jonas’ which isn’t deprecating BOSH
  187. dwd Ge0rG, RIght, what I meant.
  188. jonas’ oh wait, I said something about phasing out
  189. Ge0rG jonas’: but you also suggested to phase out BOSH ;)
  190. jonas’ but that was an "maybe even" because what do I know about web
  191. dwd As we're coming toward close, can I ask people to keep an eye on Georg's work on CS-2020, and suggest we revisit this every meeting until it ships?
  192. jonas’ +1
  193. pep. jonas’, is it 114 you want to remove? I'm curious why. Do you want to push for 225? :p
  194. dwd Anyone want to raise anything else before we close the meeting?
  195. Link Mauve Do we have any data about how usable/blocked WebSocket is in the wild, compared to BOSH?
  196. Ge0rG dwd: yes.
  197. Ge0rG I forgot a tiny little thing.
  198. jonas’ pep., no, and only removing for Core Server. You can host a Component on a standalone piece of software, no need to have support for this in every server.
  199. Ge0rG We need to LC CS-2020 two weeks in advance to the final vote.
  200. Ge0rG That would mean we have to LC it next week
  201. Ge0rG ...latest.
  202. jonas’ Ge0rG, SGTM
  203. jonas’ I’d like to call everyone on council ( Kev, dwd, Link Mauve, Ge0rG and me) to try to make this work for once.
  204. jonas’ I.e. vote on list quickly to let it enter LC
  205. Ge0rG Which is why I'd like to vote for LC now, and use the LC phase to sort out "Future Development"
  206. Link Mauve Same, I will propose changes before next week if I have any.
  207. jonas’ I don’t think we can technically still vote.
  208. Ge0rG can't we vote in AOB?
  209. dwd Ge0rG, Ah, rather renders my suggestion a waste of time.
  210. jonas’ I’m +1 on LC after #841 has been included. My feedback shall be counted as LC feedback then.
  211. Ge0rG dwd: your suggestion of revisiting it each meeting? It's sound.
  212. dwd Ge0rG, No, I suggest we Last Call it next week, and this week we ensure we've helped get it to the right shape.
  213. Ge0rG It's still in urgent and dire need of content for "Future Development", though
  214. Ge0rG dwd: well, let's go on with that, then.
  215. dwd But please, let's make sure we're in a position to vote on this within the meeting - otherwise we will run out of time.
  216. Ge0rG Yes.
  217. dwd Sound good to everyone?
  218. Link Mauve Yes.
  219. jonas’ yes
  220. Ge0rG I have a gut feeling that we will run out of time, so I'll pester everybody delaying the vote with messages.
  221. dwd OK. With that, I think we're done.
  222. Ge0rG If we vote LC now, we still have roughly enough time in the worst case.
  223. Ge0rG Because surely somebody will on-list the LC vote until October 23rd.
  224. dwd 7) Ite, Meeting Est
  225. jonas’ Thanks everyone.
  226. Ge0rG Thanks Dave, thanks everybody else.
  227. Link Mauve Thanks. :)
  228. dwd Ge0rG, I hope not.
  229. Kev On-list.
  230. Ge0rG dwd: ^
  231. Kev Did I do that right?
  232. jonas’ squints at Kev
  233. Ge0rG Don't make me sad, Council comrades.
  234. jonas’
  235. Ge0rG jonas’: do you want me to pile up more changes into #841?
  236. jonas’ Ge0rG, asking me as editor?
  237. Ge0rG jonas’: yes
  238. jonas’ Ge0rG, I have no strong opinion one way or the other.
  239. Ge0rG jonas’: I'd like to have a single revision block for everything between CS-2019 and Final CS-2020.
  240. jonas’ Ge0rG, if you do, remind me at least 24h before the next meeting about merging it
  241. jonas’ Ge0rG, that’s not going to be possible
  242. jonas’ we need to make a release prior to LC
  243. jonas’ and there will be feedback during LC which needs a separate revision block
  244. dwd Ge0rG, I'd rather we merged and published on a release early/often kind of style.
  245. Ge0rG Does that ask for a "Changes since 2019" sub-section?
  246. dwd Ge0rG, Might nudge people to make more comments that way.
  247. Ge0rG dwd: I'm not talking about not releasing, I'm talking about having a history block that's useful in 2020, and not just in November 2019.
  248. dwd Ge0rG, I don't hugely care about changes. People can figure those out by comparing the docs, they're not radically different in layout etc.
  249. jonas’ dwd, I don’t agree
  250. jonas’ strongly disagree even
  251. Ge0rG dwd: using out awesome xep-diff infrastructure?
  252. Ge0rG dwd: using our awesome xep-diff infrastructure?
  253. Ge0rG dwd: as a developer, I want to have all the changes at a glance, so that I can evaluate what needs to be dump to bump my CS level..
  254. pep. figuring out xep changes is a pita indeed
  255. daniel i still would like some clear consultation on how to resolve #840; since this is something that council will have to decide i'm not sure that brute force trying different version only to be told -1 every week is a productive method
  256. jonas’ daniel, I gave you clear advice which I think will be accepted by all members if I read this meeting correctly.
  257. daniel unless council doesn’t feel that this is important in that case i'll just stop
  258. jonas’ daniel, do you even read what I’m writing?
  259. pep. jonas’, there was another question
  260. pep. daniel> > daniel: also it would be nice to have an explanation of the semantics of that value when sent by the client vs. by the server where. in the label?
  261. jonas’ to that my answer is: find a suitable location in the prose of the document and insert it there.
  262. jonas’ maybe around publish-options or the disco#info example
  263. Ge0rG daniel: I don't much care about the where. It should be readable, so "in the label" is probably not the smartest place to put it
  264. jonas’ probably publish-options
  265. jonas’ or that
  266. jonas’ I don’t care too much either way
  267. Ge0rG what jonas’ said
  268. daniel the thing is that none of the other node configs are explained anywhere
  269. jonas’ yeah
  270. daniel feels weird to randomly start explaining max
  271. jonas’ which isn’t great
  272. Ge0rG daniel: PRs welcome.
  273. Kev Personally, I will un--1 it as soon as it's "max" instead of <glyph>, and would accept probably a large number of other typeable strings too
  274. Kev Descriptions desirable but not required in this case, for me.
  275. debacle has left
  276. Ge0rG I would +0 or +1 it without a description, but not without a feature flag
  277. jonas’ Ge0rG, that’s new.
  278. dwd daniel, ASCII character set value, and probably a feature.
  279. daniel max and feature flag have been added fwiw
  280. Ge0rG jonas’: what's new?
  281. jonas’ Ge0rG, your requirement
  282. Kev Ge0rG did mention it earlier.
  283. jonas’ I missed it
  284. Kev Anyway, +1 on the current version (having just seen Daniel's changes).
  285. jonas’ +1, too
  286. daniel also dwd Bookmarks2 should probably explain what to do when node-config-max is not available as a feature
  287. daniel maybe introduce a magic number :-/
  288. pep. Or just require node-config-max?
  289. Ge0rG daniel: the backticks might be less understandable than "" </bikeshed>
  290. daniel we currently decideded on 128 which ~4 implementations use
  291. Kev I thought that and thought it wasn't worth mentioning :)
  292. Kev (backticks)
  293. Ge0rG but +0 now
  294. Ge0rG but 128 is too small for power users!
  295. jonas’ I’m going to detach myself from this bikeshedding now.
  296. daniel what is the current number of channels listed on search.jabber.network
  297. daniel let that be our magic number
  298. dwd +1 on #840 now. And FWIW, I'm totally fine with backticks - Markdown, innit?
  299. jonas’ daniel, 7453
  300. Ge0rG dwd: consistency over markdown.
  301. pep. Ge0rG, I agree. I'd go with a full u8 at least :p
  302. Ge0rG pep.: 256 would force implementations to use at least an int16
  303. pep. I'm missing why
  304. Ge0rG because 256 doesn't fit into an uint8
  305. pep. I didn't say 256 :-°
  306. dwd As for Bookmarks2, I'm not sure this isn't orthogonal. You need the maximum to be set to at least as many bookmarks as you want to store.
  307. Ge0rG pep.: I did
  308. pep. (*trying to escape*)
  309. dwd Ge0rG, What about with compression?
  310. Ge0rG summons waqas
  311. Ge0rG dwd: my gut feeling is that compression will be harder to abuse on mobile, while providing significant benefits
  312. Ge0rG I have only disabled compression in my client because the compressor wasn't thread-safe
  313. Kev I think Dave was suggesting that 256 will fit in a uint8 with compression.
  314. Ge0rG Kev: maybe.
  315. dwd RLE the bits, I reckon. What could go wrong?
  316. Ge0rG it's only one bit.
  317. Ge0rG jonas’: I'd like to group 0245 and 0392 into one category. Is "Message display" too broad / too narrow?
  318. daniel dwd, the 'problem' is that to use Bookmarks2 correctly you really want to put max_items in publish_options; and then you need to put some number in there.
  319. jonas’ Ge0rG, I disagree on that grouping
  320. jonas’ Ge0rG, because '392 also makes sense in the roster
  321. daniel and when mulitple implementations disagree on that number you end up having to reconfigure on every publish
  322. dwd daniel, Not if the number is high enough, surely?
  323. daniel yes. but then you need to agree on one
  324. Zash Prosody defaults to 256 fwiw
  325. Ge0rG jonas’: right. That was also a request for a better name.
  326. dwd daniel, Not really. I mean, I see it's simpler if you can just say "max", but I don't see it matters much if the number is smaller.
  327. jonas’ dwd, publishing with publish-options would reject your publish if your max_items request is different from the one already set on the node.
  328. dwd jonas’, Yes.
  329. jonas’ Ge0rG, "User handle coloring" maybe?
  330. dwd jonas’, But we know if the node exists at the start, so we're not publishing blindly.
  331. Link Mauve “17:48:52 daniel> we currently decideded on 128 which ~4 implementations use”, I’m awfully close to this limit already myself. :/
  332. jonas’ dwd, but then you need extra round trips
  333. dwd jonas’, You do, yes. My point is that if the server supports max, that's great. If it doesn't, the client has to do more work, but it'll still function.
  334. dwd jonas’, So I'd see this as a SHOULD at best.
  335. Ge0rG This discussion clearly shows that we are piling workarounds on top of workarounds. Can we step back a step or two and fix the design?
  336. Ge0rG and by "we" I mean somebody else than me ;)
  337. dwd Ge0rG, If you want to ship a free forklift with every client.
  338. daniel so to summarize if a server doesn’t support max i need to download the node config; see if the value currently set is "high enough" and if so omit my own value from publish_options?
  339. daniel that should probably be documented in the XEP so people who are not in the chat right now know that
  340. dwd daniel, Sure. And yes, we should encourage/recommend/etc that `max` is supported and used.
  341. Kev Or just don't do BM2 unless max.
  342. Kev Actually, in the absence of max, what really is the harm in reconfiguring on every push?
  343. Kev At the point you push you already know what 'big enough' is, and can just set it to enough plus a few, or something.
  344. dwd Could even pipline the configure, right?
  345. Kev That's what I was thinking, yes.
  346. jonas’ also very relevant: https://mail.jabber.org/pipermail/standards/2019-October/036506.html
  347. daniel but pubsub is just a cache
  348. pep. > jonas’> Ge0rG, because '392 also makes sense in the roster And in other places.. OMEMO fingerprint has been mentioned in the past, I'm sure there's lots of other places it could be useful
  349. Wojtek has left
  350. Wojtek has joined
  351. peter has joined
  352. jcbrand has joined
  353. Wojtek has left
  354. jos1264 has joined
  355. jonas’ true treu
  356. jonas’ true true
  357. jos1264 has left
  358. jos1264 has joined
  359. jos1264 has left
  360. jos1264 has joined
  361. jcbrand has left
  362. Wojtek has joined
  363. peter has left
  364. jos1264 has left
  365. jos1264 has joined
  366. peter has joined
  367. peter has left
  368. Tobias has left
  369. jos1264 has left
  370. jos1264 has joined
  371. jos1264 has left
  372. jos1264 has joined
  373. jos1264 has left
  374. kusoneko has left
  375. kusoneko has joined
  376. daniel has left
  377. daniel has joined
  378. daniel has left
  379. daniel has joined
  380. daniel has left
  381. daniel has joined
  382. daniel has left
  383. daniel has joined
  384. daniel has left
  385. daniel has joined
  386. Zash has left
  387. lnj has left
  388. daniel has left
  389. daniel has joined
  390. daniel has left
  391. daniel has joined
  392. kusoneko has left
  393. kusoneko has joined
  394. daniel has left
  395. peter has joined