XMPP Council - 2019-04-17

  1. daniel has left
  2. daniel has joined
  3. daniel has left
  4. daniel has joined
  5. daniel has left
  6. daniel has joined
  7. daniel has left
  8. daniel has joined
  9. debacle has left
  10. daniel has left
  11. daniel has joined
  12. daniel has left
  13. daniel has joined
  14. daniel has left
  15. daniel has joined
  16. daniel has left
  17. daniel has joined
  18. daniel has left
  19. daniel has joined
  20. daniel has left
  21. daniel has joined
  22. daniel has left
  23. daniel has joined
  24. daniel has left
  25. Zash has joined
  26. daniel has joined
  27. daniel has left
  28. lnj has joined
  29. daniel has joined
  30. moparisthebest has left
  31. moparisthebest has joined
  32. lnj has left
  33. lnj has joined
  34. daniel has left
  35. daniel has joined
  36. debacle has joined
  37. Link Mauve Just a reminder that I’ll be in another meeting this afternoon, and thus not here.
  38. daniel has left
  39. daniel has joined
  40. daniel has left
  41. daniel has joined
  42. daniel has left
  43. daniel has joined
  44. vanitasvitae has left
  45. vanitasvitae has joined
  46. Ge0rG has joined
  47. dwd Are we sitting comfortably?
  48. jonas’ I am
  49. Kev Then let's begin. Only not quite yet because it's not 4 yet.
  50. Ge0rG Good morning, ladies.
  51. dwd OK.
  52. dwd 1) Roll Call
  53. Kev Here.
  54. jonas’ here
  55. Ge0rG
  56. dwd Missing Link Mauve as expected - he sent apologies last week.
  57. dwd 2) Agenda Bashing
  58. dwd We've four items this week, all PRs.
  59. Kev I've been busy all day and not in a position to bash, sadly.
  60. dwd #736, #778, #784, and #785
  61. dwd Any others?
  62. dwd Assuming not.
  63. dwd 3) Items for a vote (or discussion):
  64. dwd a) https://github.com/xsf/xeps/pull/736 XEP-0308: Allow message correction in MUC
  65. Kev I'm concerned about this one.
  66. dwd I commented on the PR, my feeling is that this is asking for the right things, but not in the right way - language is a bit wooly.
  67. Kev Mostly about the idea of servers needing to store data on every past occupant.
  68. jonas’ yeah, I don’t think that’s sane
  69. Kev As the current text doesn't seem to have any sort of time limit on corrections.
  70. jonas’ clients cannot rely on the feature unless we impose O(+infty) amount of work on servers
  71. Ge0rG isn't it sufficient to store the real bare JID on all messages in the history log?
  72. jonas’ the history log may be +infty long
  73. jonas’ and you need to do a search for the corrected message
  74. jonas’ for each correction
  75. jonas’ that sounds like a very easy DoS vector to me
  76. peter has joined
  77. dwd The way it's currently written, it merely says that where the correcting entity is definitely not the same, the correction should (I think) be rejected. It doesn't say that if the entity is the same it should/must be accepted.
  78. jonas’ -> no server right in their minds is going to implement this.
  79. Ge0rG right. unless you have... an index!
  80. jonas’ even then it’s complex
  81. Kev Ge0rG: No, because you need to know what message the client might be correcting, which requires you to know the most recent message from that client, no matter how long ago it was.
  82. jonas’ even then it’s computationally complex
  83. Kev " If it does so, the receiver can trust any message correction received through this room, be it live or from history."
  84. dwd That is, a server saying Nope every time is, I think, conformant as written.
  85. Kev I think it's clear that the intent is that advertising the feature means that every correction has been checked for validity.
  86. Ge0rG Kev: I agree
  87. dwd Kev, Yes, but not that every correction has been accepted that could have been.
  88. Kev Yes, that is true. But also quite unhelpful.
  89. Ge0rG I think it's a useful feature to have, and I don't know how Link Mauve implemented it.
  90. dwd In any case, the "SHOULD" and "should" and things scare me at the moment.
  91. jonas’ I think it’s a useful feature to have, but I also think it’s a trivial DoS vector for servers if clients are to be rely on this
  92. dwd So I'm -1 for now, but I think this can be fixed.
  93. Ge0rG jonas’: because you can flood the server with bare JIDs?
  94. jonas’ if clients cannot rely on it (because the server is allowed to age out information), it is not useful
  95. Kev I'd have rathered discussed with Link Mauve here. I think I have to tentatively -1 this until we can discuss what's needed.
  96. jonas’ Ge0rG, for example, or simply with messages
  97. Ge0rG dwd: you are -1 because what can be fixed?
  98. Kev jonas’: If a server that has aged out information is allowed to block the corrections it can't verify, clients can trust what they receive. They just can't send as much as they'd like.
  99. Kev Dave is right there, I think.
  100. dwd Ge0rG, Language. I don't think it's actually describing what's normative very well.
  101. jonas’ Kev, that needs to be spelt out clearly though
  102. Kev I think so, yes.
  103. jonas’ -1 until the DoS vector and how it is to be mitigated and what clients can expect there is clarified
  104. dwd Kev, Ge0rG ?
  105. Ge0rG on-list to see what comes out of your questions.
  106. Kev Already -1d.
  107. dwd Thanks.
  108. Ge0rG I feel like +1, but the raised points are valid as well.
  109. dwd aa) XEP-0308: relax from-full-JID requirement https://github.com/xsf/xeps/pull/784
  110. dwd I feel like this is intimately tied in with #736, myself.
  111. jonas’ I’m +1 on that one
  112. jonas’ dwd, it’s not necessarily
  113. Kev dwd: Why's that?
  114. Ge0rG dwd: #736 is implying it, but it's not tied in any way.
  115. dwd Or perhaps I misread - is this purely client-side?
  116. jonas’ it can be done purely client side
  117. jonas’ (and the text suggests that)
  118. Ge0rG dwd: the text is deliberately open about client- or server-side
  119. Kev Oh, you're right, that 'or the MUC service' does imply it. Because a client cannot do the verification itself.
  120. Ge0rG "either the recipient or the MUC service need to ensure that the real bare JID of the sending occupant didn't change in between"
  121. Kev (Unless it's non-anonymous)
  122. jonas’ Kev, it can
  123. dwd Ah, yes. OK, in that case it's fine. +1
  124. jonas’ if there was a part/join in-between, it might not be the same JID -> discard
  125. Kev So that means that where the recipient can't do it, to satisfy that requirement the MUC service must have done it.
  126. jonas’ if there was a part/join in-between, it might not be the same s ender -> discard
  127. jonas’ if there was a part/join in-between, it might not be the same sender -> reject
  128. Kev Which puts requirements on a MUC service where there were none before.
  129. Ge0rG Kev: the recipient can do it if neither you nor the sending occupant didn't leave the MUC between the original and the correction.
  130. jonas’ it’s not a requirement -- clients already implement that check, actually.
  131. Ge0rG Kev: the recipient can do it if neither you nor the sending occupant did leave the MUC between the original and the correction.
  132. Ge0rG some clients.
  133. jonas’ yeah, other default the check to "not allowed" ;)
  134. jonas’ yeah, others default the check to "not allowed" ;)
  135. Kev This feels like it'd be more cleanly written in terms of who's expected to do what when based on top of 736.
  136. Ge0rG other clients ignore it altogether because identity of occupants in a semi-anon muc is pointless.
  137. jonas’ maybe, but I still think this can stand on its own, so +1
  138. dwd Kev, See, when I said that everyone disagreed. :-)
  139. Ge0rG +1 obviously.
  140. Kev dwd: I didn't. I asked why.
  141. Ge0rG Kev: I could provide a better wording of #784 once #736 is approved. Which it isn't.
  142. Ge0rG as it is now, I think that the wording is sufficient for either outcome of #736.
  143. Kev Ge0rG: That would be my preference. I'm fine with the intent as I understand it, but not with that text about MUC services doing stuff, without some form of explanation - either through 736, or locally.
  144. Ge0rG Kev: we are speaking of a footnote.
  145. Kev Just changing "either the recipient or the MUC service" to "the recipient will" will make it ok by me, I think, until we've got 736.
  146. Kev As without 736 the MUC service doing things doesn't help at all anyway.
  147. Ge0rG Kev: if that is your prerequisite for accepting, I can re-word.
  148. dwd Kev, Or at least, without '736, the recipient has no idea if the MUC service is doing anything.
  149. Kev Ok, +1 after tweaking.
  150. Kev dwd: Indeed.
  151. dwd OK, then.
  152. Ge0rG Thanks!
  153. dwd c) https://github.com/xsf/xeps/pull/785 - XEP-0260: Replace broken link with archive.org
  154. Kev Not a Council voting item, I think, just Editorial.
  155. Ge0rG as a matter of form, I'd not replace the anchor text, just the link.
  156. jonas’ I think that’s sensible
  157. Kev That makes more sense.
  158. Ge0rG But I agree with Kev that this is Editorial, so +1.
  159. jonas’ will take care of that
  160. Kev I think I'd be inclined for Council to instead decide it's Editorial, rather than voting as if it wasn't.
  161. Kev It affects versioning, for example.
  162. Kev So if we change the vote to be 'is this Editorial?' then I'm +1. Or if we have to treat it as a substantive change, begrudgingly +1.
  163. dwd No, I'm fine with this being Editorial.
  164. jonas’ yeah, editorial
  165. jonas’ I wouldn’t even have raised this to council
  166. dwd I'm a little concerned with how close to normative behaviour this is, though, being described in an external link that's gone dead.
  167. peter has left
  168. dwd Is there a better specification for SOCKS5 we could/should be using here?
  169. Kev dwd: Oh, I didn't read it that way. Maybe I've misunderstood.
  170. Ge0rG So let's re-vote on this kind of things being Editorial Changes?
  171. Kev I thought it was saying "And for people who remember this old proposal, this is much the same".
  172. jonas’ yeah, it should probably be moved to the XEP, if we can get this sorted out legally
  173. Kev (When I say "Maybe I've misunderstood", I'm actually fairly confident that I haven't)
  174. dwd Kev, Yes, you probably haven't misunderstood. I'm just a little sensitive to external links in the XEPs.
  175. Kev Agreed that this is Editorial, suggest to the Editors to not change the link text, just the link, and move on?
  176. dwd ANyway, the change itself is certainly Editorial. I just wanted to make sure we're happy with the linking at all.
  177. Ge0rG That requires obtaining permission from Justin to incorporate the text as an informational part? as a dedicated informational XEP?
  178. Ge0rG dwd: +1 to that motion.
  179. dwd Ge0rG, You're happy?
  180. dwd Anyway, probably no conclusions to be made here.
  181. dwd 4) Outstanding Votes
  182. dwd Please check 'em.
  183. Ge0rG dwd: what about d)
  184. dwd Ge0rG, Oh, I skipped one, didn't I?
  185. Ge0rG no, wait. it was b) which should have preceded your c) but probably was missed due to aa).
  186. Ge0rG b) Discussion: https://github.com/xsf/xeps/pull/778 XEP-0280: Rewrite of the 'Messages Eligible for Carbons Delivery' section
  187. dwd ndeed, that ^^
  188. Ge0rG Somebody noted that it might be a better way to create a new XEP that defines these rules, hide it behind a new feature and only reference it from 0280 so that 0280 does not break.
  189. dwd So I did talk to Ge0rG about this last week, and wondered aloud if it would be better to have these "fixed" rules as a distinct feature that clients would then see and be able to rely upon.
  190. Ge0rG Formally, 0280 is somewhere between Experimental and Abandoned.
  191. dwd Ge0rG, Yeah. XEP-0280 isn't in a happy place, in terms of process.
  192. jonas’ dwd, we’re on the road to that, it’s called IM-NG
  193. dwd jonas’, That road is very long and shows no sign of getting shorter.
  194. Ge0rG dwd: it also had a bunch of Last Calls.
  195. Kev I don't think roads typically get shorter, you just move along them :)
  196. dwd Ge0rG, This, too, I'm aware of.
  197. Ge0rG Kev: that road is a kind of moebius strip, apparently.
  198. Kev I would be much happier with the idea of formal rules in a XEP with its own feature.
  199. dwd Kev, Yes, I don't think that's happening either.
  200. Kev Ge0rG: But at least it doesn't change in its infinite length.
  201. dwd Yes, I think these rules as a new XEP which can just be advertised by a server (no negotiation needed since it's within scope for '280) is an ideal solution.
  202. Ge0rG Personally, I'd very much prefer to get these rules into 0280, presumingly breaking it for some, but to have a clean and nice specification that we can LC some time this year.
  203. jonas’ from what I can see, this PR mostly clarifies how carbons interact with MUCs
  204. jonas’ the other rules seem untouched
  205. Ge0rG jonas’: the other rules move from MAY to BREX^W SHOULD
  206. jonas’ ah, right
  207. dwd jonas’, I think there are other rules altered. I forget the details. But most importantly, it switches rules from a "Who knows, maybe" state to a "SHOULD" - and a distinct XEP could easily make them MUST.
  208. jonas’ one could advertise this ruleset in a feature if it makes people happy
  209. Ge0rG I have accumulated a large amount of frustration with 0280 and how it is implemented, and I'm not sure I can produce a dedicated new XEP containing just those rules and a feature.
  210. jonas’ dwd, it can also be made MUST in the same XEP with a feature
  211. jonas’ and I’d prefer that
  212. dwd My personal feeling is that a new feature would improve adoption. I'm somewhat ambivalent as to whether we need a new XEP or not.
  213. jonas’ I am a bit wary of the XEP proliferation we have
  214. dwd jonas’, We should write a XEP on that.
  215. jonas’ right, so a new feature which advertises this exact ruleset?
  216. Ge0rG As it is now, 0280 is not only in a very sad place process-wise, it is also a very sad specification.
  217. Ge0rG or rather, a very saddening one.
  218. dwd With a new feature, I'd suggest that many of the SHOULDs in Georg's PR could be MUSTs.
  219. Kev I'm going to need to think about this at-length and on-list, in any case, because I'm a bit rubbish.
  220. Ge0rG Kev: please also read up the many discussions of that from the last five years.
  221. jonas’ I’m +0 on this without feature, +1 with a feature + MUSTification.
  222. Ge0rG dwd: I can make that a feature-conditioned MUST in 0280.
  223. jonas’ (obviously, the error tracking stuff should stay non-MUST)
  224. Kev Ge0rG: I'm confident you don't want me to do that.
  225. Ge0rG > (obviously, the error tracking stuff should stay non-MUST)
  226. Ge0rG I disagree with that, and that makes a good distinct discussion point.
  227. Ge0rG What to do with errors.
  228. Ge0rG Practically, it sucks to not receive errors for carbonated messages.
  229. Kev Ge0rG: Is the sticking point with a separate spec that you don't have the energy for it, or you think it's wrong?
  230. dwd FWIW, I think I'm the same as jonas’ here - +0 but +1 with a feature.
  231. jonas’ Ge0rG, but error-tracking is expensive
  232. Kev That is, if I hypothetically decide I don't want it in 280, but offered to do the split, would that work (not saying that'd happen).
  233. Ge0rG Kev: a bit of both. I won't be able to produce a XEP that's not full of sarcasm and insults, and I think we need to fix the rules in 0280.
  234. jonas’ I don’t think that a separate XEP is the right tool here
  235. Ge0rG jonas’: error-tracking is expensive. What about fanning out all message errors?
  236. jonas’ that would probably work
  237. Kev FWIW, my main arguments for a separate XEP are that if we stripped the rules out of 280, and just left a pointer to the new XEP, we could Draft 280 immediately.
  238. Ge0rG There is also a distinct question of making carbons depend on client-features, i.e. no carbons of CSN if not supported by the client.
  239. dwd OK - I'm going to move on, but we can come back to this after the meeting.
  240. Kev But also that we couldn't sensibly Draft 280 with the rules in for some time.
  241. Kev And this would also let us decide that other rules were better in the future.
  242. jonas’ I think other rulesets should be developed in the IM-NG realm of things
  243. dwd 5) Next Meeting
  244. dwd Next week?
  245. jonas’ wfm
  246. Ge0rG Kev: what is the point of Drafting 0280 without the rules?
  247. Ge0rG +1W WFM
  248. Kev Ge0rG: We don't have rules at the moment, yet Carbons works reasonably well for lots of people. So having that Draft seems not completely without merit.
  249. dwd I'm in the office next week, so might be disrupted - I'll try to make it though.
  250. dwd 6) AOB
  251. Ge0rG Oh, there is _yet another_ dimension on Carbons: Transports
  252. dwd Anything other than '280?
  253. Ge0rG No AOB
  254. dwd 7) Ite, Meeting Est.
  255. dwd Ge0rG, I'm of the general opinion that transports are often rubbish, but how so in this particular case?
  256. Ge0rG dwd: we should allow a Transport to send sent-carbons when the user sent a message from a native-protocol client.
  257. dwd Ge0rG, Ah. Funnily enough, I do exactly this. Or did.
  258. Ge0rG There was a weirdly worded list inquiry by Владимир.
  259. Ge0rG https://mail.jabber.org/pipermail/standards/2018-January/034224.html
  260. dwd Oh, yeah, I had all those problems.
  261. Ge0rG However, this obviously can be solved by its own XEP that allows something like 0321 to override the carbons-must-be-from-own-JID rule.
  262. moparisthebest my uh, client side transport thing, relies 100% on carbons to work
  263. dwd Ge0rG, Yes. Also, MAM needs to archive those messages.
  264. Ge0rG dwd: yes.
  265. Ge0rG Did I mention yet that we should re-invent MAM and Carbons as a unified session protocol with all the insights from the last 5 years?
  266. Ge0rG But really, _this_ problem of Carbons can be solved most easily outside of 0280.
  267. Ge0rG So please let's get back to getting 0280 done.
  268. pep. Reading the discussion on #778 (0280 changes), what's the point of experimental XEPs if council is afraid changes are going to break things? Isn't that what this stage is for? It's already annoying enough when a XEP reaches Draft (not even Final) and people grump about any changes, but I'm not sure what's the point of experimental if nothing can change
  269. dwd pep., See previous discussion about how broken '280 is wrt process.
  270. pep. Well it's not yet Draft, at least
  271. pep. it's in between Proposed, LC, Experimental
  272. pep. So I'd say "if you have to break or bump, do it while you can".
  273. moparisthebest implementations wait for no one
  274. moparisthebest it doesn't matter if it's experimental or not even submitted, if thousands of devices in the wild implement it
  275. pep. Sure, so what?
  276. moparisthebest a good XMPP related example is aes-256-gcm file encryption with http upload
  277. pep. That's one of the many OMEMO failures indeed
  278. pep. But that's not related to what I'm saying
  279. jonas’ for certain definitions of "good" example
  280. moparisthebest it's just, there is a difference between "theoretical" and "practical"
  281. moparisthebest theoretically, sure, not-draft/final means you can change anything, in practice, not so much
  282. moparisthebest there seems to be a lot of that in XMPP land, lots of "in theory, it'd be better done this other-way-no-one-will-ever-do" meanwhile it get's done and deployed the original way
  283. Kev pep.: I have limited concerns about breaking 280. My concerns are breaking it in the wrong way.
  284. pep. Kev, k
  285. pep. I guess my message was mostly directed at people who want another XEP for this
  286. jonas’ (which includes Kev to a certain extent)
  287. dwd pep., One issue is that the proposed rules have had push-back from server developers quite consistently. But council(s) have rejected moving the spec to Draft without them. As such, the spec is highly deployed, yet still nominally in Experimental.
  288. dwd pep., Our process is meant to reflect reality, and not try to coerce reality into its own image.
  289. pep. So you'd change a Final XEP that's not used?
  290. jonas’ a final xep can’t be not-used
  291. jonas’ it can only be not-used-anymore, which would mean deprecation
  292. jonas’ (at least two independent implementations are a requirement for moving to Final)
  293. pep. Yeah, not-used-anymore, implementations gone out of existance or sth
  294. dwd pep., Very happy to deprecate existing Final specs that are used if we wouldn't recommend people to implement anymore.
  295. pep. Not what I asked
  296. dwd pep., Stuff that's unused, but proven to work when it's needed, and remains our best idea of how to solve a problem can stay in Final, I think.
  297. pep. implemented != proven to work, but I guess that's up for debate
  298. dwd pep., I don't think there's any dispute that implementing something doesn't automatically mean it works. The converse is more interesting - if people don't implement, it's definitely not proven to work.
  299. pep. I just wanted to take you up on "Our process is meant to reflect reality, and not try to coerce reality into its own image.". Would that mean these stages are useless?
  300. Ge0rG dwd: re push-back from server developers, is that only about error tracking or were there other issues?
  301. dwd Ge0rG, Honestly, i can't remember. '280 just feels like a death march.
  302. Ge0rG I'd rather compare it with quicksand.
  303. Ge0rG Anyway, the unanswered question is: would it have unappreciated (side)effects to carbon-copy all messages of type=error?
  304. Ge0rG I'm pretty sure there is no problem with errors caused in the context of IM.
  305. Ge0rG besides of error messages generally being very ephemeral, which is maybe not what we want for IM-NG.
  306. dwd Ge0rG, We won't need errors in IM-NG, though, because everything will always work flawlessly.
  307. Ge0rG dwd: that is the MIX mindset.
  308. dwd Ge0rG, Every message will eb acrried to its desitnation personally by the magic unicorns riding fairies.
  309. dwd Ge0rG, And the stars! Oh, my the stars. They will be so pretty in IM-NG.
  310. Ge0rG why should unicorns ride fairies?
  311. dwd Ge0rG, IM-NG. It's just like that.
  312. Ge0rG are those rainbow-pooping unicorns?
  313. Ge0rG What is the amount of recreational drugs imported to the island, currently? Will there be a sensible Summit after Brexit?
  314. dwd Ge0rG, What the unicorns poop is currently under-specified.
  315. debacle has left
  316. Kev Ok, Carbons: Are people amenable to adding a feature in 280 saying that these are the rules used, and text saying that while these rules might be changed in the future they would result in a bump of the carbons-rules feature advertised, not of the carbons namespaces themselves?
  317. Kev I think that would mostly allow us some vague agility in fixing up the rules as we inevitably find better ones, without tying ourselves in knots if the spec goes to Draft or requiring bumps to the core NS because the rules have changed?
  318. Kev The rules themselves do seem reasonable enough to me on review.
  319. Kev Ge0rG: ^
  320. Kev If we can do that, I'm +1, else I need to think further.
  321. Kev I'm a tentative -1 without something like that because I think it needs consideration, but can possibly be talked up to a -0 on discussion.
  322. jonas’ Kev, yes, I think that’s sane
  323. jonas’ I think that’d be the best way forward indeed
  324. debacle has joined
  325. Ge0rG Kev: personally, I don't think that there is any benefit in versioning the rules. My client certainly won't use that to influence behavior. But I think that your proposal is sufficiently sane to not die on that hill.
  326. Kev Compromise, and all that :)
  327. Ge0rG Shall I amend to the XEP
  328. peter has joined
  329. peter has left
  330. Kev Amend to the XEP?
  331. Ge0rG Kev: I mean, shall I add another commit to the PR containing what you suggested?
  332. Ge0rG And will that be sufficient to satisfy the other Council members?
  333. Kev Works for me, thanks.
  334. peter has joined
  335. moparisthebest has left
  336. moparisthebest has joined
  337. debacle has left
  338. lnj has left
  339. peter has left
  340. daniel has left
  341. daniel has joined
  342. daniel has left
  343. moparisthebest Industry standard advice there is to have 1 joint and keep it well oiled, adding another joint is the opposite https://www.imperialviolet.org/2016/05/16/agility.html
  344. daniel has joined