XMPP Council - 2021-04-21

  1. Zash has joined
  2. Kev has left
  3. Kev has joined
  4. stpeter has left
  5. SouL has left
  6. stpeter has joined
  7. Kev has left
  8. Kev has joined
  9. stpeter has left
  10. Kev has left
  11. Kev has joined
  12. Kev has left
  13. Kev has joined
  14. Kev has left
  15. Kev has joined
  16. Kev has left
  17. SouL has joined
  18. stpeter has joined
  19. Tobias has joined
  20. stpeter has left
  21. paul has joined
  22. Zash has left
  23. Zash has joined
  24. Kev has joined
  25. Kev has left
  26. Kev has joined
  27. debacle has joined
  28. mdosch has left
  29. mdosch has joined
  30. sonny has left
  31. sonny has joined
  32. sonny has left
  33. sonny has joined
  34. moparisthebest has left
  35. sonny has left
  36. sonny has joined
  37. moparisthebest has joined
  38. sonny has left
  39. sonny has joined
  40. vaulor has left
  41. vaulor has joined
  42. Guus has left
  43. Wojtek has joined
  44. Guus has joined
  45. Guus has left
  46. vaulor has left
  47. vaulor has joined
  48. Syndace has left
  49. Syndace has joined
  50. stpeter has joined
  51. Syndace has left
  52. Syndace has joined
  53. stpeter has left
  54. stpeter has joined
  55. Syndace has left
  56. Syndace has joined
  57. jonas’ 1) Roll Call
  58. Zash here
  59. jonas’
  60. daniel Hi
  61. Ge0rG
  62. jonas’ no dwd?
  63. jonas’ 2) Agenda Bashing
  64. jonas’ crickets!
  65. jonas’ 3) Editor’s Update
  66. jonas’ nothing unusual
  67. jonas’ 4) Items for Voting
  68. jonas’ No new items
  69. jonas’ 5) Pending Votes
  70. jonas’ we need to handle the LCs now
  71. Zash Carbons and MAM eh
  72. jonas’ yep
  73. Kev I think MAM needs at least one round of changes, given my review yesterday, but they’re not major.
  74. Kev (Jumping ahead because I might not notice when (5) comes up)
  75. Ge0rG I think MAM needs at least one round of changes, given my review three weeks ago, but they're rather significant.
  76. jonas’ Kev, we are already at (5) :)
  77. dwd Ah. Sorry, I've been dragged into a meeting.
  78. Zash I've looked at past LCs and there's been a lot of back and forth on things
  79. Ge0rG The agenda items 2 to 5 all arrived in the same second at my end. Some lag might be involved.
  80. Zash <private> vs xep-0334 and whatnot
  81. Ge0rG Should we have some separate discussion of the open points of 0280 and of 0313 before casting final votes?
  82. Ge0rG` has joined
  83. jonas’ so IMO we should factor out the rules in a standards track document which defines disco#info features. The rules should be called "general routing rules" and versioning should go across all of them, but they may be different for the different "routing" protocols (MAM, Carbons, CSI, Push…)
  84. Zash Sounds good.
  85. jonas’ we can think about the issue that such a living document can never advance beyond Draft later.
  86. Ge0rG jonas’: so one namespace for all the routing rules, instead of one namespace per task?
  87. jonas’ ideally that issue resolves itself with IM-NG
  88. jonas’ Ge0rG, yes
  89. jonas’ but I’m not hard-sold on that
  90. Zash The base wire protocols are probably good enough and certainly well-deployed by now,..
  91. jonas’ Zash, exactly
  92. Ge0rG What do we do with urn:xmpp:carbons:rules:0?
  93. jonas’ Ge0rG, make it implicit in urn:xmpp:routing-rules:0
  94. jonas’ and advertise it for up to routing-rules:N, where N is the revision where the rules for carbons are first changed
  95. Kev FWIW, nothing needs factoring out of either 313 or 280 in order for later rules to be defined elsewhere.
  96. Ge0rG well, the feature version was just a quirk to get around bumping carbons, so I'm not fighting to death over it
  97. Kev (At least, the intention when writing the text in 313 was that a later external feature could be advertised for a concrete set of rules, same as 280)
  98. jonas’ but again, not hard sold on unifying them; it seemed sensible to me on a quick thought to have that all under a single version umbrella, but especially when we have to adapt (e.g. only) push rules and then have to forklift all features, it seems a bit overkill
  99. jonas’ yep, separated features are probably waaay better
  100. Zash And then compliance suites that point to recommended versions?
  101. Ge0rG I'm torn on whether to use my 0313 vote to extort somebody to write down those rules for 0313
  102. jonas’ Zash, yes
  103. jonas’ Ge0rG, I get the impression that '313 may be blocked anyway
  104. Kev I don’t think 313 is blocked otherwise in a meaningful sense. I.e. I don’t think any changes need another LC.
  105. Ge0rG Indeed, even if I were to retract my storage rules requirement, there are still the open questions around MUC in personal MAM and client business rules
  106. Ge0rG and of course the bind2 / MAM subscription topic that probably needs to be postponed anyway.
  107. Zash Myeah, recommending against storing MUC messages without additional negotiation would probably be good.
  108. Zash "additional negotiation" something something MIX I guess
  109. Ge0rG against *delivering*
  110. Ge0rG backfilling of MIX history on the personal MAM is still an unsolved problem.
  111. Ge0rG Given that, I'm solidly -1 on 0313.
  112. jonas’ noted
  113. jonas’ how about '280?
  114. Zash The <private> thing seems unresolved.
  115. Ge0rG Kev addressed the "stripping <private> parts" point and I'd like to get a discussion of Hints
  116. Ge0rG My desired way forward would be to remove the stripping requirement, to completely remove Hints, and to Convince Council to go on without a namespace bump.
  117. daniel you'd need to convince the authors. not council
  118. Ge0rG I'd also rewrite the Mobile Considerations to say the opposite of what it does now, but that's the non-normative part.
  119. Syndace has left
  120. Syndace has joined
  121. Ge0rG daniel: given that I'm one of the authors, you can consider it done.
  122. jonas’ my problem with not bumping the namespace there would be, on a theoretical level, that a client relying on <private/> not being stripped may be owned in one way or another by an old server
  123. Ge0rG Still, I've heard some objections from Council members about this suggestion last week
  124. Zash Does anything really bad happen in that case?
  125. Ge0rG jonas’: you mean by a client relying on <private/> *being* stripped?
  126. jonas’ Ge0rG, no
  127. Ge0rG jonas’: ah, now I get you
  128. jonas’ if we don’t bump and a new implementation comes along, relying for $importantFeature on <private/> being there, it will be confused when <private/> is *not* there because the server is on old carbons
  129. Ge0rG So I'd also add an implementation note.
  130. jonas’ and then what?
  131. Ge0rG jonas’: also there used to be different semantics for stripping <private/> before 2013, https://xmpp.org/extensions/xep-0280.html#revision-history-v0.9
  132. Kev urn:xmpp:carbons:doesn't-fuck-with-private:0
  133. Kev Is that a pragmatic compromise?
  134. Zash Would work I guess?
  135. jonas’ Kev, would’ve been my next suggestion :)
  136. dwd Not a valid URN?
  137. Zash doesn&quot;t‽
  138. jonas’ Ge0rG, wait what
  139. Kev It’s in pre-encoded form.
  140. jonas’ it was changed again?
  141. jonas’ it was changed already back and forth?
  142. Ge0rG jonas’: as I read the log, it was stripped by the *sending* server before
  143. Zash <server author hat> I think it does that still?
  144. jonas’ huh.
  145. Zash or what
  146. jonas’ okay
  147. jonas’ that makes me think that we should not at all rely on <private/> being there or not being there
  148. jonas’ too many versions
  149. jonas’ and adding another change is not going to make it any better
  150. Ge0rG So can I move forward with my grand plan?
  151. jonas’ Ge0rG, no, I think that you should leave <private/> alone
  152. Ge0rG jonas’: is that an opinion or a foreshadowed Council vote?
  153. jonas’ that is an opinion
  154. jonas’ because I don’t see what good it brings
  155. Ge0rG` Sorry, my prosody is stalled
  156. jonas’ I hope this wasn’t me
  157. Ge0rG` Only if you suddenly took over VaxBot
  158. Ge0rG jonas’: I think that Kev has a great point about letting the receiving client know that it received a Carbon that won't get delivered to any other resource.
  159. Kev I think it’s a not-insignificant security consideration to strip private.
  160. Ge0rG` > jonas’: I think that Kev has a great point about letting the receiving client know that it received a Carbon that won't get delivered to any other resource.
  161. Kev Letting another user modify my server’s routing rules without telling me does not seem at all safe.
  162. jonas’ Kev, I agree, but just removing that rule doesn’t mean that anyone can rely on it
  163. Kev Thus feature.
  164. jonas’ Ge0rG`, so you could do it with a feature flag IMO
  165. Kev But this isn’t a case of clients relying on it.
  166. Kev It’s a case of a user of a server relying on the server not doing questionable things without trace.
  167. Ge0rG` But we are also still in Experimental, so it's all not so bad from a protocol point of view. Right?
  168. Ge0rG` (from a Council protocol...)
  169. jonas’ Ge0rG`, yes
  170. Kev I would be ok (not that my opinion matters) with removing that (or rather, flipping that to a must not) rule without adding the feature. But adding the feature is cheap, and not without value, so why not.
  171. jonas’ what Kev says tho
  172. Ge0rG Alright, I can live with what Kev says.
  173. jonas’ then do that please
  174. Ge0rG Now what about stripping Hints from the XEP?
  175. jonas’ do we know how widely implementations rely on that?
  176. Zash Do we not like Hints anymore?
  177. Ge0rG Ironically, current-0280 requires to strip <private/> but doesn't mention strpping the Hint.
  178. Kev I would probably form an opinion on that given time to think, but don’t currently have one on the hop.
  179. jonas’ Ge0rG, what is the harm of keeping it?
  180. Ge0rG jonas’: we are enshrining a protocol that we don't want to keep.
  181. Zash We don't?
  182. Ge0rG jonas’: there was a version of 0280 that only required adding <private/> and later a version that required adding both <private/> and the Hint.
  183. Ge0rG Thus, removing the Hint requirement won't break any compliant implementations.
  184. Ge0rG I dislike the inconsistency of https://xmpp.org/extensions/xep-0280.html#avoiding
  185. jonas’ section 9 reads very confusing
  186. jonas’ > The sending client MAY exclude a <message/> from being forwarded to other Carbons-enabled resources, by adding a <private/> element qualified by the namespace "urn:xmpp:carbons:2" and a <no-copy/> hint as described in Message Processing Hints (XEP-0334) [8] as child elements of the <message/> stanza.
  187. jonas’ the sending client is not excluding anything, protocol wise
  188. jonas’ and then the enumeration just goes on as if it was on the same side of the contract ... very weird
  189. jonas’ Ge0rG, put that on your list of things to fix please
  190. Ge0rG jonas’: I'd improve the wording while removing Hints.
  191. jonas’ if
  192. jonas’ if *both* are currently required, we can remove hints without damage indeed
  193. Ge0rG jonas’: that's what the XEP says, right?
  194. jonas’ yep
  195. jonas’ I think
  196. jonas’ I mean I think the XEP makes no statement at all about that in the text as written because of that wording weirdness, but the intent is clear
  197. Ge0rG Yes, that's also my reading of it
  198. daniel The concept of private messages is out dated anyway. I think a variant version of carbons todo wouldn't even have it
  199. Ge0rG daniel: what about OTR?
  200. daniel Yes
  201. jonas’ "out dated"
  202. daniel My point exactly
  203. Kev Private goes away in IMNG, I think, but I’m not sure until then.
  204. daniel Otr was the only thing that used it
  205. Ge0rG Kev: but it goes away because we introduce a different mechanism to route a message just to a single specific resource, right?
  206. daniel And even otrv3 technically didn't event need it
  207. Kev Ge0rG: Right.
  208. Ge0rG So just the XML element goes away, not the semantics.
  209. Kev The new syntax for sending just to one resource becomes to=‘fulljid’ :D
  210. Ge0rG Unless we decide that we do not have any more need to route messages just to a single resource.
  211. jonas’ okay
  212. jonas’ we’re a bit over time at this point
  213. jonas’ Ge0rG, do you need any further input?
  214. Ge0rG But I'm pretty sure we will have some use for that in IOT or PubSub events
  215. Ge0rG jonas’: no.
  216. jonas’ excellent
  217. jonas’ 6) Date of Next
  218. jonas’ +1w wfm
  219. Ge0rG Is the CVE PR applied already? :D
  220. jonas’ (waking up Zash and dwd )
  221. daniel +1w wfm
  222. Zash +1w wfm
  223. Ge0rG +1W WFM, but the following two weeks I'm going to be on vacation (from the computer screen)
  224. jonas’ Ge0rG, good for you!
  225. jonas’ 7) AOB
  226. jonas’ skipped because time
  227. jonas’ 8) Ite Meeting Est
  228. Ge0rG But but but AOB!
  229. Zash no aob for you
  230. jonas’ Ge0rG, no, not yet, please bring it to the list because there was controversy around that in xsf@ and I’d like to have some rough consensus
  231. Ge0rG Also nobody cast their votes on 0280
  232. jonas’ Thanks everyone
  233. Ge0rG so this makes another failed LC, right?
  234. jonas’ Ge0rG, right, forgot, I wanted to ask
  235. jonas’ 9) Ite Meeting Un-Est
  236. jonas’ votes on '280?
  237. jonas’ I imagine you’ll want to veto
  238. daniel +0
  239. Ge0rG +1 with all the discussed changes applied.
  240. Zash -1 until the <private> thing has consensus and is resolved
  241. jonas’ following Zash here
  242. jonas’ (changing my +1)
  243. Ge0rG Zash: how do you imagine consensus happening here?
  244. daniel I don't think it matters what label we put on a very flawed but de facto draft xep
  245. jonas’ 10) Ite Meeting Est for real
  246. jonas’ Thanks everyone
  247. jonas’ (gotta run, need to prepare for being reaallly quick in 15 minutes)
  248. Zash Ge0rG: apply the changes discussed. I've ran out of coffee, can't think anymore.
  249. Ge0rG Alright. I'll PR and then ask for another LC.
  250. Zash and ... '313 is ..?
  251. jonas’ vetoed
  252. Ge0rG Zash: vetoed by me
  253. Zash check
  254. Ge0rG I've been naughty.
  255. Zash Very well then
  256. pprrks has left
  257. Syndace has left
  258. Syndace has joined
  259. Guus has joined
  260. Lance has joined
  261. Lance has left
  262. sonny has left
  263. sonny has joined
  264. Guus has left
  265. Ge0rG` has left
  266. Ge0rG` has joined
  267. SouL has left
  268. SouL has joined
  269. Ge0rG` has left
  270. Ge0rG` has joined
  271. Wojtek has left
  272. SouL has left
  273. Ge0rG` has left
  274. Ge0rG` has joined
  275. SouL has joined
  276. Ge0rG` has left
  277. Ge0rG` has joined
  278. Ge0rG` has left
  279. Ge0rG` has joined
  280. Ge0rG` has left
  281. Ge0rG` has joined
  282. Ge0rG` has left
  283. Ge0rG` has joined
  284. Ge0rG` has left
  285. Ge0rG` has joined
  286. Ge0rG` has left
  287. Ge0rG` has joined
  288. Syndace has left
  289. Syndace has joined
  290. Ge0rG` has left
  291. Ge0rG` has joined
  292. Syndace has left
  293. Syndace has joined
  294. Lance has joined
  295. Ge0rG` has left
  296. Ge0rG has left
  297. Ge0rG` has joined
  298. Ge0rG has joined
  299. Ge0rG` has left
  300. Ge0rG has left
  301. Ge0rG` has joined
  302. Ge0rG has joined
  303. Tobias has left
  304. Ge0rG` has left
  305. Ge0rG` has joined
  306. Ge0rG has left
  307. Ge0rG has joined
  308. Lance has left
  309. Ge0rG` has left
  310. Ge0rG` has joined
  311. Lance has joined
  312. Ge0rG` has left
  313. Ge0rG` has joined
  314. Syndace has left
  315. Syndace has joined
  316. Zash has left
  317. Syndace has left
  318. Syndace has joined
  319. Ge0rG` has left
  320. Ge0rG` has joined
  321. Lance has left
  322. Lance has joined
  323. Ge0rG` has left
  324. Ge0rG` has joined
  325. paul has left
  326. SouL has left
  327. Ge0rG` has left
  328. Ge0rG` has joined
  329. debacle has left
  330. Lance has left