XMPP Council - 2019-04-10

  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. lnj has joined
  8. daniel has left
  9. daniel has joined
  10. moparisthebest has left
  11. lnj has left
  12. lnj has joined
  13. lnj has left
  14. lnj has joined
  15. lnj has left
  16. lnj has joined
  17. lnj has left
  18. lnj has joined
  19. debacle has joined
  20. lnj has left
  21. lnj has joined
  22. lnj has left
  23. debacle has left
  24. lnj has joined
  25. lnj has left
  26. lnj has joined
  27. lnj has left
  28. lnj has joined
  29. lnj has left
  30. lnj has joined
  31. debacle has joined
  32. daniel has left
  33. Zash has left
  34. Zash has joined
  35. moparisthebest has joined
  36. moparisthebest has left
  37. moparisthebest has joined
  38. Kev I should be back for Council today, but there's a chance of lateness or missing, depending on traffic etc.
  39. moparisthebest has left
  40. moparisthebest has joined
  41. dos has left
  42. jonas’ has left
  43. jonas’ has joined
  44. Ge0rG has joined
  45. Kev 'Tis time.
  46. Link Mauve Good morning. :)
  47. jonas’ oh hai
  48. Ge0rG The times they are a-changin'!
  49. Kev Come gather 'round, people.
  50. Kev dwd?
  51. Kev Ge0rG: Did you see https://github.com/xsf/xeps/pull/781 ?
  52. Ge0rG Kev: sorry, no.
  53. Ge0rG There seems to have been a bit of a lack of agenda.
  54. Kev We seem to be missing a Dave, so ...
  55. Kev 1) Roll call
  56. Kev I'm here.
  57. Link Mauve o/
  58. Ge0rG .o/
  59. jonas’ here
  60. Kev 2) I think there's been nothing on the published agenda, other than me mentioning https://github.com/xsf/xeps/pull/781 yesterday morning, right?
  61. jonas’ I think that’s true
  62. Kev This is the PR to try to address the metadata/content during LMC thing, as promised.
  63. Kev As it's a 30 second review, I suggest people just do that now, if they've not seen it yet.
  64. Ge0rG Kev: I have another interesting proposal in that context to make. A receiving entity should accept a correction both to the original ID and to intermediate correction IDs.
  65. debacle has left
  66. jonas’ Kev, my problem with that proposal is that "metadata" isn’t really clearly defined
  67. Ge0rG Kev: that essentially boils down to the philosophical question dwd brought up last time
  68. Ge0rG what jonas’ said
  69. Kev Ge0rG: I'm not keen, as that drastically increases complexity everywhere.
  70. Link Mauve What was this XEP saying that you shouldn’t bloat a stanza with many unrelated payloads?
  71. jonas’ Ge0rG, yeah, I don’t want to track multiple IDs to merge corrections, and neither will an archive want to
  72. Kev We'll never manage to fully define it, but I think at least the idea is clear enough here. Welcome to further text tweaks, obviously.
  73. Ge0rG Kev: I'm +0 for the sake of not dying on hills.
  74. jonas’ it makes me think we should’ve defined a metadata block in stanzas at the beginning
  75. jonas’ but I guess we can’t
  76. jonas’ and I think the text makes things clearer
  77. jonas’ so +1
  78. Kev jonas’: When we next get to 1999, we can consider that :D
  79. Kev Thanks.
  80. Ge0rG Kev: due to the current GPS week rollover, we _are_ technically in 1999.
  81. jonas’ (one way out would be to spell out correctable payloads)
  82. jonas’ ha!
  83. jonas’ Ge0rG, but we’re also in 1979, aren’t we?
  84. Ge0rG https://twitter.com/ChinaAvReview/status/1114802018919411712
  85. Kev Link Mauve ?
  86. Link Mauve +1 as for the previous version.
  87. Kev Ta.
  88. jonas’ (xep-0308: and go ahead and patch all the other xeps with explicit mention when they can be corrected)
  89. Kev 3) Date of next
  90. jonas’ (but yeah, current text is fine)
  91. Kev SBTSBC?
  92. jonas’ Kev, I think you wanted to start a discusison about compliance suites, didn’t you?
  93. Ge0rG +1W WFM
  94. jonas’ +1wwfm
  95. Kev I do, I think it's AOBish, rather than a voting item, though.
  96. Link Mauve There are many XEPs which I’d like to revisit to mention that they are metadata, and how it should behave. For FSE especially.
  97. Link Mauve +1W wfm.
  98. Zash https://xmpp.org/extensions/xep-0226.html comes to mind
  99. Kev 4) AOB. Anyone else got any before I do mine?
  100. Link Mauve Zash, right, this one.
  101. jonas’ I don’t have any
  102. Ge0rG Yeah, two of them
  103. Link Mauve Me neither.
  104. Ge0rG AOB-a: https://github.com/xsf/xeps/pull/779
  105. Ge0rG AOB-b: https://github.com/xsf/xeps/pull/778
  106. Ge0rG the former is for a Draft XEP so needs to be voted on, sooner or later.
  107. Ge0rG The latter is essentially what I brought up back in 2017, but without the reliance on Hints.
  108. Ge0rG Also I'm not sure whether we are going to hear back from the nominal author, so bringing this up before Council
  109. Kev I'm not ready to express opinions on either yet - can we schedule them as full items for next week?
  110. Link Mauve AOB-a +1 for me.
  111. Link Mauve Or we can reschedule.
  112. Ge0rG I've waited for two years now, can't you see how urgent the 0280 issue is?
  113. Link Mauve Ge0rG, would you want to become a shepherd for AOB-b?
  114. jonas’ *squint*
  115. Ge0rG > BTW, I volunteer to take over 0280 authorship if the need arises.
  116. Ge0rG Link Mauve: ^ from the PR
  117. Link Mauve Great. :)
  118. Ge0rG https://github.com/xsf/xeps/pull/779 is surely a five-minute review thing.
  119. Kev You'd think, yes.
  120. Ge0rG But I'm not going to push anyone into anything, so +1W is fine with me.
  121. jonas’ I’m +1 on that one
  122. Kev I'm just struggling to decide on an opinion about making existing implementations non-compliant, which the MUC block surely does.
  123. jonas’ Kev, it doesn’t matter, because sending type="groupchat" to full jid is an error already
  124. Kev And that's a good reason for me to do a proper review, I suspect.
  125. Ge0rG Unless you are responding to a MUC request with a PM receipt.
  126. Ge0rG Which is also a possible way to do things.
  127. Kev Anyway, I think everyone else is +1 on 779, so we may as well treat that as item 2b rather than AOB.
  128. Kev And suggest we put 778 in for proper discussion next week.
  129. Kev And I'll on-list 799.
  130. jonas’ I think that’s sane
  131. dwd Afternoon, sorry, meeting overrun.
  132. Kev And I'll on-list 779.
  133. jonas’ oh, wb dwd
  134. jonas’ oh, welcome dwd
  135. Kev Welcome.
  136. Kev You're not taking my gavel ;D
  137. Kev AOB3, then. Compliance suites.
  138. Kev I suggested that we move away from yearly compliance suites that try to encapsulate everything, and frequently lead to heat in trying to update them on time, and instead move to a pair of 'living documents'.
  139. dwd Kev, You're welcome to it.
  140. Ge0rG small note re next meetings: I'm going to be gone on three of the May Council meetings
  141. Kev The intention being that one defines where we think the network is, and the other where we see it going. So it's a bit easier to look at Current and see what's needed for interop right now, and Future to see what would be a good idea to do for future interop.
  142. jonas’ Kev, I think that’s a very sensible idea
  143. Ge0rG Kev: this is a great idea.
  144. dwd Kev, The general idea seems fine. But are these living documents XEPs?
  145. Link Mauve Oh indeed, next week I am away during this meeting, I will be back the week after.
  146. Kev dwd: I think that's the sensible next question. For my money, I think they are, yes, but I think that detail less important than the direction of travel.
  147. Link Mauve Kev, excellent idea.
  148. Kev (I think they're Informational, rather than Standards-Track, at least)
  149. jonas’ they could easily be Informational XEPs in Active mode
  150. jonas’ they could easily be Informational XEPs in Active status, maintained by Council
  151. Kev ^5s jonas’.
  152. jonas’ although arguably XEP-0001 explicitly states compliance suites-like things to be Standards Trak ;)
  153. jonas’ although arguably XEP-0001 explicitly states compliance suites-like things to be Standards Track ;)
  154. Kev Indeed, but these aren't compliance suites :)
  155. jonas’ then again, if it isn’t about compliance but about a "what to implement" it’s not that
  156. jonas’ ^5 again
  157. dwd One of the reasons we named the existing compliance suites the way they are is to encourage implementors to use them as marketing terms. What do implementations say they're compliant to, in this brave new world?
  158. Zash So a "how XMPP works now" and a "how we want XMPP to look in the future" documents? I approve.
  159. jonas’ "XMPP Core XEPs version X"
  160. jonas’ that works nicely with the badge system, too
  161. Ge0rG jonas’: I propose X to be mapped to time periods of sufficient length.
  162. Ge0rG i.e. years.
  163. Kev Assuming (and this is a significant assumption, based on behaviour I've seen) that the need to announce you're compliant to something is important, XEP-0467 version 1.1 would be fine, I think.
  164. jonas’ Ge0rG, versions can easily be YYYYMM.x
  165. Kev jonas’: They can't, actually, given xep1.
  166. jonas’ XEP-0001 has some opinions about version numbers, but I think we can get an override from board for that ;)
  167. Kev One of the things I'm fairly keen we do is not have dates involved in this.
  168. Link Mauve dwd, from what I’ve gathered, people would very much prefer things like “XMPP 2019” for marketing purposes, compliance suites don’t fit that role very well except for technical people.
  169. Ge0rG Kev: what's your rationale for that?
  170. jonas’ Kev, not at all?
  171. Link Mauve And for technical people, Conversations’s website does a much better work at that.
  172. Kev The argument keeps getting presented that having a suite with a date in it that isn't the current year makes us look unprofessional and the sky falls in.
  173. Ge0rG Kev: does that argument have any merit?
  174. Kev And that leads us to trying to rush through new versions without (I think) due consideration.
  175. Kev And ISTM the cost of not having the date in the version is approximately zero.
  176. jonas’ that’s a good point, but independent of that, I don’t think we can stay with the vanilla XEP-1 version schema for those documents, because version "1.234" looks stupid.
  177. Kev jonas’: If these are updated more often than every year, I'll be pleasantly surprised.
  178. dwd Can't we call it after animals? Seems to work well for Ubuntu.
  179. Kev I also point to XEP-0045 1.31.2
  180. Ge0rG Kev: I think that the year is a much better indicator of up-to-date-ness than an arbitrary version number
  181. jonas’ dwd, no, with my editor hat on, I require version numbers to be numeric and totally ordered
  182. jonas’ as long as XEP-0001 permits me to require that
  183. Kev Ge0rG: I think my argument is that using versions to give an idea of up-to-dateness isn't helpful here.
  184. jonas’ Kev, but do you point to '45 1.13.2 for marketing purposes?
  185. Kev jonas’: No, for an example of a XEP with a daft number of revisions without the sky falling :)
  186. dwd I'd be happier with versions of XEPs if we could also reliably point to them, but I'm not entirely sure how.
  187. jonas’ point is, it looks weird to me, and it will look weird to folks outside the XSF when used for marketing
  188. Kev dwd: We could make a point of including the changelog fully in these XEPs, if we wanted.
  189. jonas’ I’d like to throw in that I started tagging things on github and I’m looking into automating that kind of stuff more
  190. jonas’ even though that might mean, in the long run, that I run my own infrastructure next to the XSF’s
  191. Ge0rG Kev: I think that having an immediate idea of up-to-dateness outweighs the drawback of us not having a 2019 suite by April 2019 being doomsday.
  192. dwd Otherwise, I'm fine with running a year-long experiment on "living" documents of this form, with an expectation that we define what success looks like and revisit after 6 and 12 months.
  193. Kev Anyway, it sounds to me like people think this is a sensible direction of travel, and we're mostly discussing versioning details, does that sound fair?
  194. jonas’ Kev, yes
  195. jonas’ I think what dwd says is good
  196. Link Mauve Kev, indeed.
  197. Kev dwd: Although I note we never defined what success looks like for the Compliance Suites, and I've considered them a failure for many years :)
  198. dwd Kev, Yes, but it'd be nice to have some idea of what constitutes success.
  199. Kev But we've gotten out of this discussion what I was hoping to get out of it at this point. Can we Agendaify another discussion on the topic for, say, the start of June, please?
  200. dwd Kev, If only to determine that we have failed once more.
  201. dwd Kev, Sounds sensible.
  202. jonas’ Kev, do we have long-term agenda planning techniques? ;)
  203. jonas’ (other than open PRs against xeps)
  204. Kev jonas’: I call it Dave.
  205. Kev AOAOB?
  206. jonas’ not from me
  207. Ge0rG I think that with our current tooling, the current form of CS is the least failed way to do it.
  208. Kev bangs the gavel and hands it back to Dave.
  209. Kev Thanks all.
  210. dwd Kev, Thanks for stepping up there.
  211. Kev dwd: You've got two votes from today, I believe, to on-list (and I've got one).
  212. Kev goes back to his day off.
  213. Ge0rG I'm actually unconvinced of everything proposed above except for the general idea.
  214. dwd Ge0rG, Was there more than a general idea?
  215. Ge0rG And that general idea can easily be mapped onto yearly CS XEPs.
  216. Ge0rG ...provided somebody does the actual work.
  217. dwd Ge0rG, Aye, there's the rub.
  218. Ge0rG dwd: > I suggested that we move away from yearly compliance suites that try to encapsulate everything, and frequently lead to heat in trying to update them on time, and instead move to a pair of 'livingdocuments'.
  219. Ge0rG > The intention being that one defines where we think the network is, and the other where we see it going. So it's a bit easier to look at Current and see what's needed for interop right now, and Future to see what would be a good idea to do for future interop.
  220. dwd Ge0rG, Ah. So *some* of that neatly fits onto Compliance Suites.
  221. dwd Ge0rG, Mostly the first document.
  222. Ge0rG dwd: yes.
  223. Ge0rG Now would be a good time to start a proto-CS-2020, or maybe a proto-future-CS
  224. dwd Ge0rG, The key change is a single mutating document instead of multiple documents.
  225. Ge0rG dwd: and due to tooling reasons, I actually object to _that_ change.
  226. jonas’ why?
  227. Ge0rG Because XEP versioning is an ugly business.
  228. dwd Ge0rG, And one I noted.
  229. jonas’ I find non-obvious XEP numbers for CS worse
  230. jonas’ we can fix the versioning
  231. Zash BCP-0001
  232. Ge0rG We don't have good link-ability to old versions, and we don't have good diff views.
  233. jonas’ the diff views are an argument, but that doesn’t get fixed with separate documents at all
  234. Ge0rG can has xep-2019.xml
  235. Ge0rG jonas’: touché
  236. jonas’ if anything, it is worse, because in the future, we might get diff tools back, but those will work between versions, not xeps
  237. dwd Ge0rG, Link-ability would be interesting. We could link to old versions via the changelog, too.
  238. jonas’ and link-ability to old versions can be fixed, too
  239. jonas’ for those which are built, that is
  240. Ge0rG dwd: the changelog is just a muddy reflection
  241. jonas’ that’s the authors fault though
  242. jonas’ or maybe the editors, but the author can do something about it
  243. Ge0rG so let's mandate *proper* changelog maintenance for Compliance Suites, whatever "proper" means.
  244. Ge0rG If we have link-ability to past versions, we could have the Compliance Badges link to a specific (currently latest) version of the XEP
  245. Ge0rG and change the year each year.
  246. Ge0rG And have a Future-Extensions pseudo-CS XEP that gets updated with nice-to-have things like MIX, bind2 etc. And once a year, we make a campfire and decide which ones to move from FE to CS.
  247. dwd Ge0rG, So #778. What's the rationale here?
  248. dwd For the CS Date, we can of cours ejust change the title on the new version.
  249. Ge0rG dwd: the overall high-level rationale, the specific rationale of individual commits or ... ?
  250. dwd Ge0rG, High level, to begin with.
  251. Zash Have a persistent item at Summit?
  252. Ge0rG dwd: Carbons have many broken corner cases
  253. dwd Zash, Hush now.
  254. Ge0rG dwd: we had a very long time to fix the weasel-words out of the XEP by collecting experience. Mostly nobody cared about it.
  255. dwd Ge0rG, Right, but is that because it doesn't matter?
  256. Zash dwd? :(
  257. Ge0rG dwd: I'm running into ugly corner cases of Carbons every some months, and then spend half a day reading XML logs from multiple entities to determine that it was just one of the corner cases, again.
  258. dwd Zash, It's hardly the only repetitive topic at Summits.
  259. Ge0rG dwd: is that a trick question?
  260. dwd Ge0rG, No, I'm trying to figure out the rationale, and thereby decide on the best way to progress this work.
  261. Ge0rG dwd: let's say the rationale is to have a set of rules that can be applied at the border of a routing2 IM-NG domain.
  262. dwd Ge0rG, To what end?
  263. Ge0rG dwd: to fix the user experience
  264. Ge0rG dwd: the rules written down in the PR are the "collective wisdom" that I have collected over the years that isn't actually written down anywhere.
  265. Ge0rG Also improvements to the rules to make them more consistent
  266. dwd Ge0rG, OK, this seems more useful. So what happens if a server doesn't follow these rules?
  267. Ge0rG like carbons of errors.
  268. Ge0rG dwd: the corner cases remain unfixed
  269. dwd Ge0rG, Yes, but at a high level?
  270. dwd Ge0rG, And if a server doesn't follow these rules, can a client do anything about it? Can it make assumptions if the server does?
  271. Ge0rG dwd: I'm not sure where you are aiming
  272. dwd Sorry, not trying to be difficult here. Trying to get a better feel for how these rules change what a client and/or user can/should do.
  273. Zash Hm. https://xmpp.org/extensions/xep-0001.xml
  274. Ge0rG dwd: yeah, not feeling offended, just not sure how to answer
  275. dwd Ge0rG, OK, let me ask a different question. If these rules were in a different XEP, and servers advertised their compliance, would this be better?
  276. Ge0rG dwd: I don't think so. The "old" rules are very much weasel-worded, so servers are free to bend them in any conceivable way.
  277. Ge0rG dwd: thus clients typically don't rely on anything working
  278. dwd Ge0rG, I'm thinking that they could then be made MUST instead of SHOULD, and clients would know if they were in operation. The result is, I think, more stability and awareness.
  279. Ge0rG dwd: this leads to interesting effects, like Conversations not actually making use of 0184 because sometimes it's not reliable and thus users might question why there is no checkmark
  280. Ge0rG dwd: now you are talking!
  281. dwd Ge0rG, I'm also aware that server implementations tend to adopt things faster if they can advertise their support.
  282. Ge0rG dwd: the reasons why I didn't go for MUST are essentially: - I only know of IM, not of IoT, VoIP and all the other shiny use cases of XMPP - with the current weasel-wording, I think what I PRed is the maximum I can bend the XEP to without a namespace bump - I might have overseen something
  283. Ge0rG Also 0280 as it is now is a VERY BAD XEP.
  284. dwd Ge0rG, I think, also, that then as the rules get more refined - and I think they probably will - servers can advertise potentially multiple levels as long as the new rules are a superset.
  285. Ge0rG dwd: I'm still not sure it makes _technical_ sense to advertise some kind of support level for 0280 rules
  286. dwd Ge0rG, I honestly don't know. For diagnostics, it probably does.
  287. dwd Ge0rG, But I'm not sure that clients would alter behaviour.
  288. Ge0rG I wouldn't in mine.
  289. Ge0rG And I'm not often looking into disco#info when diagnosing things.
  290. Ge0rG dwd: also what would happen if the rules get extended? namespace-bump them? Have all versions that are still complied to in disco#info?
  291. dwd Ge0rG, The latter I imagine.
  292. dwd Ge0rG, But also, I think working on it in a separate XEP might prove more politically viable.
  293. Ge0rG I'm not opposing, just wondering if it actually has value.
  294. Ge0rG dwd: see above. > Also 0280 as it is now is a VERY BAD XEP.
  295. dwd Well, you'd eventually have a patch which removes the rules from '280 and points at ${NEWXEP}
  296. Ge0rG not only because the wording is very cumbersome and confusing, but also because the core point of a XEP is to define interop, and you can't define interop by making everything MAY.
  297. Ge0rG (insert Brexit pun)
  298. Ge0rG dwd: how is that formally different from having the rules in 0280 and not having another XEP?
  299. dwd Ge0rG, It isn't, but I see an easier path to get there from here.
  300. jonas’ do you think council will oppose that change?
  301. dwd Ge0rG, But understand: I'm only throwing ideas out there.
  302. Ge0rG dwd: and once we are there, we merge the two XEPs into one?
  303. Ge0rG dwd: is there some special political meaning to the number 0280, that I don't know about because I'm too young?
  304. dwd jonas’, WHich change? The rules update? Probably less likely to cause problems if the new XEP is mature and well-supported.
  305. zinid has joined
  306. dwd Ge0rG, No, I don't think so. But it feels odd replacing a lot of MAY rules with a lot of SHOULD [NOT] instead. If we want firm rules, then it feels simpler to get there via another XEP.
  307. Ge0rG dwd: "simpler" in the sense of the XSF Council process?
  308. dwd Ge0rG, I was thinking community more than Council.
  309. Ge0rG So I start out with a new XEP that only defines specific rules, then I bully server implementors until they follow it, then I get it merged into 0280 as the new norm?
  310. dwd Ge0rG, Well, you wouldn't need to bully server implementors to follow it, but it'd make for a compelling argument to incorporate into '280, whether by reference or directly.
  311. Ge0rG dwd: if I didn't need to bully server implementors, they'd have the Good Rules by now.
  312. Ge0rG (making a PR against 0280 was actually my attempt to bully server implementors)
  313. dwd Ge0rG, Yeah. I think a new XEP might be more persuasive than bullying.
  314. Zash Routing 2.0?
  315. dwd Zash, I'm not mad keen on fork-lifts.
  316. Zash XMPP 2.0 !
  317. Ge0rG I think that with the frustration I've built up over the years of coping with 0280, a large amount of heavy editing would be required if I was to write that new XEP.
  318. Zash dwd: Some videos of omniwheel forklifts ough to change your mind :)
  319. Ge0rG (incidentally, the 0184 PR could have happened half a year ago if it wasn't for some curse words in the XML)
  320. Ge0rG also I'm not sure how much a SHOULD is a fork-lift.
  321. Ge0rG Personally, my history with 0280 is comparable to what other people have experienced with Compliance Suites of various years. You can only withstand so much pointless rejection.
  322. Ge0rG (which is also why it took almost two years for me to re-issue #434)
  323. Ge0rG So if Council actually decides to veto this PR, it might well happen that I won't make any progress on the suggested new-XEP route for another year, or two, or longer. Depending on how soon I'll run into the "why the effinf eff are those messages not arriving" situation again
  324. zinid wut, 280 again?
  325. zinid is it meeting now?
  326. Ge0rG zinid: meeting is over, context is https://github.com/xsf/xeps/pull/778
  327. zinid meeting was at 15:00 UTC?
  328. zinid whatever
  329. Ge0rG zinid: https://logs.xmpp.org/council/2019-04-10#2019-04-10-611d9881cd1a08ca
  330. dwd zinid, The '280 thing is basically a tradition now.
  331. zinid meh
  332. zinid booooring
  333. dwd zinid, Do you happen to know what carbon rules ejabberd implements?
  334. zinid dwd, no 🙂
  335. zinid I'm not the author and don't have any desire to touch the code with 19m pole
  336. zinid it is better not to touch the routing in the server, it always ends up with something borked 😀
  337. dwd Yeah it is always the weirdest, hariest code in any server.
  338. dwd No doubt Zash will tell me that Prosody's routing code is perfect about now. :-)
  339. Zash dwd: Yes, it's perfect, so I don't wanna touch it ever again! /me hides
  340. Ge0rG Zash: LIES!
  341. dwd Ge0rG, No, I believe he never wants to touch it again.
  342. Zash Carbons and MAM are in stable releases now, changing anything will probably be massively painful
  343. zinid do we need to change something? From the PR it's not very clear, looks like just wording improvement
  344. Ge0rG zinid: depends on what you do.
  345. Ge0rG I know that prosody lacks with 0184 payloads of type normal and on error responses.
  346. dwd I think errors is a definite change from previous recommendations, isn't it?
  347. Zash Prosody does carbons with (type=chat or (type=normal and has <body>))
  348. Zash modulo hints
  349. Ge0rG Previous recommendations were all MAY, but they contained error handling
  350. Ge0rG > A <message/> is eligible for carbons delivery if it is of type "error" and sent in response to a <message/> that was itself eligible for carbons delivery (Note that as this would require message tracking and correlation on the server, it is unlikely to be generally appropriate for most implementations).
  351. dwd Ge0rG, Ah, indeed. But not '184.
  352. Ge0rG dwd: CSN and Receipts are new, yes.
  353. Ge0rG Unless your receipts are of type=chat, in which case they magically work.
  354. dwd Ge0rG, So basically if we adopt this text, we're declaring all existing implementations to be non-conformant?
  355. Ge0rG But that in itself is kind of a violation of 0184
  356. Ge0rG dwd: you make it sound negative.
  357. zinid > CSN and Receipts are new, yes abstract leakage again
  358. zinid *abstraction
  359. Ge0rG zinid: that kind of leakage is also happening in LMC currently.
  360. zinid well, maybe, that's client devs problems, I don't care 😀
  361. Ge0rG dwd: the PR consists of a set of patches with varying degrees of controversy. If you feel better about our backward compatibility, I can regroup them into a set of patches that doesn't violate the weasel words, and another one doing substantial improvements.
  362. dwd Ge0rG, I think I like the changes. Just trying to figure out the most effective way of getting them deployed.
  363. Ge0rG But I'm more interested in moving xmpp forward than in fighting process debates.
  364. Ge0rG (at least in this specific case)
  365. dwd Ge0rG, Not so much process as trying to get the server devs to actually implement.
  366. Ge0rG dwd: I'm not sure there is an elegant solution to *that* problem.
  367. dwd Ge0rG, No, but there may be multiple solutions with differeing levels of friction.
  368. zinid and this would require namespace bump?
  369. zinid or you want to avoid it thus the hassle?
  370. dwd zinid, Well, there's no hard and fast rules that Ge0rG's new rules are breaking, so it's not clear that it does.
  371. Ge0rG dwd: that might be true. It's well possible that the many threads on standards@ over the years all just were following the wrong approach to motivate server developers.
  372. zinid so bump the namespace and introduce all this new fancy stuff, what's the problem?
  373. Ge0rG Namespace bumps are one of the most inelegant ways to move forward.
  374. zinid Ge0rG, anyway, would be great if you formed a list of changes the server devs need to make, you can publish it anywhere in whatever format you like
  375. Ge0rG zinid: great idea. Is it sufficient to amend the PR?
  376. Ge0rG As the old rules are all MAY, it would technically suffice to introduce a new feature code.
  377. dwd zinid, https://github.com/xsf/xeps/pull/778 FYI
  378. zinid dwd, yeah, I briefly looked at it
  379. zinid Ge0rG, heh, everything is complicated
  380. zinid anyway, virtually impossible to understand anything from the diff 😀
  381. zinid > it contains payload elements typically used in IM wut?
  382. zinid > it is of type "error" and it was sent in response to a &MESSAGE; that was eligible for carbons delivery this one I will not implement, because tracking responses in clustering is _hard_
  383. Ge0rG Weasel words!
  384. Ge0rG zinid: can't you just forward _all_ error messages?
  385. dwd zinid, Possible if the error includes the original.
  386. dwd Ge0rG, Is that... Good?
  387. Ge0rG dwd: does it ever, in reality?
  388. Ge0rG dwd: it's better than not, in IM
  389. dwd Ge0rG, Sometimes. But it really does vary a lot, even within implementations.
  390. zinid dwd, a better solution would be attaching some "route state" to stanzas, but XMPP doesn't allow this
  391. Ge0rG Except that error generation is broken with some 0198 implementations.
  392. zinid SIP has Record-Route header for this
  393. Ge0rG zinid: IM-NG was supposed to solve that
  394. zinid Ge0rG, what? attaching routing states?
  395. zinid to where?
  396. zinid resource, lmao? 😀
  397. Ge0rG But I suppose it doesn't properly cover error responses.
  398. Ge0rG If you send a message to bare and receive an error from full, what does it even mean?
  399. zinid I don't know
  400. Ge0rG dwd: do you see problems with carbon copying all message errors?
  401. dwd Ge0rG, A bit, yes. I wonder if the right approach would be to manage the state elsewhere, if that's the aim.
  402. dwd Ge0rG, The intent is to ascertain which messages are in what state - so if another client sends a message and that gets bounced, we want to have all clients aware of both the original message and the fact it failed, right?
  403. zinid Ge0rG, ah, all those are MAYs and SHOULDs, I'm okay then 😀
  404. dwd zinid, You know SHOULDs aren't actually optional, right?
  405. zinid dwd, I can always ask you, yeah
  406. Ge0rG dwd: exactly!
  407. zinid like, "hey Dave, is this SHOULD a MUST?"
  408. Ge0rG dwd: I could live with some MAM related hack, because this is all about synchronizing a chat history database
  409. zinid (mastodon approach)
  410. dwd Ge0rG, I wonder if these (like receipts, actually) - yeah, you're thinking the same thing.
  411. dwd zinid, If you have to ask, yes, the SHOULD is a MUST.
  412. Ge0rG dwd: I also want multi receipts
  413. Ge0rG zinid: are error messages stored in mam?
  414. zinid Ge0rG, no
  415. Ge0rG Why not?
  416. dwd Ge0rG, That's a similar thing, right?
  417. zinid Ge0rG, I don't know/
  418. dwd Ge0rG, Better off storing a flag or something, anyway, in MAM.
  419. Ge0rG dwd: yes, slightly related
  420. Ge0rG Let's use the existing wire format to synchronize a message history database
  421. zinid reading the mam code
  422. zinid https://github.com/processone/ejabberd/blob/master/src/mod_mam.erl#L703-L741
  423. zinid hell
  424. zinid seems like errors are stored
  425. zinid ah, no, first line actually 😀
  426. zinid let's just archive everything
  427. Ge0rG zinid [19:24]: > let's just archive everything Awesome idea! Just replay all the CSN changes on each login!
  428. Zash Maybe what MattJ said about doing CSN over presence instead is better
  429. Ge0rG Zash: yes. Do it! Now!
  430. zinid yeah, we are in the situation where we need a special semantics on what should be retained
  431. Ge0rG IM-NG!
  432. zinid how about jingle calls? anyone?
  433. zinid you want to know who called you
  434. zinid should we add jingle calls to 280?
  435. Ge0rG Yeah, just don't start ringing when receiving a call from mam
  436. zinid since we allow abstraction leakage anyways
  437. zinid Ge0rG, how to fork the jingle call?
  438. Ge0rG Do you jungle call a bare JID or a full JID? What if there are multiple capable devices?
  439. zinid Ge0rG, SIP!
  440. Ge0rG zinid: serious question
  441. Zash Ge0rG: Do what?
  442. Ge0rG Zash [19:34]: > Maybe what MattJ said about doing CSN over presence instead is better > Zash: yes. Do it! Now!
  443. zinid Ge0rG, I have actually the serious answer, don't you know my stance on Jingle yet? 😉
  444. zinid Jingle doesn't even have basic functionality like forking, which SIP had since day 1
  445. Ge0rG zinid: what about this: Carbon copy each message payload for which a Carbons-enabled client advertises support.
  446. zinid each message payload?
  447. zinid and how to advertise it?
  448. zinid not sure I understand this
  449. Ge0rG If a client supports Carbons and 0184, send receipt Carbons. If it supports jingle, send call Carbons!
  450. Zash Ge0rG: Is there a map of features to xmlns?
  451. zinid Zash, carbons#foo?
  452. Ge0rG Zash: most features carry a namespace
  453. Zash Features (in disco#info) are not the same as xmlns
  454. zinid Ge0rG, so the server should inspect the cached disco response? Never liked the idea since there are races
  455. Ge0rG Zash [19:47]: > Features (in disco#info) are not the same as xmlns One of the bigger design failures of xmpp
  456. Ge0rG We had that in the context of MAM I think
  457. Zash Ge0rG: Useful in case there are more than one feature per spec
  458. Ge0rG zinid: do you want to get an explicit list of namespaces in Carbons enable iq?
  459. Ge0rG Zash: those should be suffixes to the xmlns
  460. zinid Ge0rG, not sure... the server must understand them all, right?
  461. Ge0rG zinid: can't it just make a set of all namespaces contained in the message?
  462. zinid Ge0rG, probably, but what about errors?
  463. zinid I mean message type=error
  464. Ge0rG zinid: what about them?
  465. zinid Ge0rG, how to know a client wants to receive them?
  466. zinid or is it supposed to be by default?
  467. Ge0rG Yes, by default. Unless you can track the original and determine whether it was copied
  468. zinid all solutions are ugly as hell 🙂
  469. Ge0rG zinid: is there a way to make an elegant solution by fixing other places?
  470. zinid I don't have any solution
  471. daniel has joined
  472. zinid btw, SIP requires in every document to specify forking rules for new messages
  473. Ge0rG That's not bad.
  474. Ge0rG We could require error messages to contain the original type, from and to.
  475. zinid well, that's maybe not a requirement, but I frequently saw "Forking" section here in there in SIP RFCs
  476. Ge0rG That doesn't solve 0184 of course. But it helps a little.
  477. Ge0rG And it will be sufficient with IM-NG
  478. zinid you see, as a server dev I see very little problems with carbons, so I don't think I'm competent enough in the carbons "problem"
  479. zinid I can only say what is hard or easy to implement in the server
  480. zinid which boils down "shared state" is evil
  481. Zash I'm more concerned about unclear rules and different sets of people having different requirements that are not written down anywhere
  482. Zash Like here, XEP-0280 says one thing. Ge0rG wants something else. Other client devs want yet something else.
  483. zinid even if you write them down not everyone will be happy
  484. zinid like some clients don't want to receive bounced CSN when a contact is offline
  485. Ge0rG I've written them down. Many times. Still waiting for client developers to comment.
  486. zinid (which is basic RFC requriement)
  487. Ge0rG zinid: bounced CSN = errors?
  488. zinid Ge0rG, yes, service-unavailable
  489. Zash In the words of https://tools.ietf.org/html/rfc7282 > Rough consensus is achieved when all issues are addressed, but not necessarily accommodated
  490. zinid Ge0rG, we even have mod_bounce_something for some customers! the very loud ones
  491. Zash Writing things down is a prerequisite of that
  492. Ge0rG zinid: what does it bounce?
  493. dwd Also, we should really look at the whole "Inbox" concept again. I think both ESL and Xabber have such a concept live, these days.
  494. zinid Ge0rG, everything that wasn't put in mam or offline in transit
  495. zinid actually it supresses the bouncing, I don't recall how the module is called exactly
  496. Ge0rG Yeah, not bounce anything that's in mam is a good thing!
  497. Zash dwd: Problem statement?
  498. dwd Zash, That'd be nice, yes.
  499. zinid Ge0rG, it's the opposite, when something is not not stored in mam/offline, it gets bounced with a service-unavailble (as per RFC), but the module supresses this behaviour and it just gets silently dropped
  500. zinid Ge0rG, the point is go figure what client devs want
  501. Zash I'd be careful with giving people what they want.
  502. Zash It's not always the same as what they need.
  503. zinid dwd, yeah, ESL introduced recently some inbox protocol
  504. dwd This had some stuff in it: https://twitter.com/miquido/status/1115270391176552450
  505. dwd Quite interesting, that article - really showed XMPP from an outsider's perspective.
  506. zinid Zash, you typically don't want to debate with customers, that's the problem
  507. dwd FWIW, Instagram also works using an inbox concept. It's pretty effective from a protocol standpoint, it just moves a lot of state management to the server (which is where we want it, I think).
  508. Ge0rG dwd: I had a "told you so" feeling for large parts of that post...
  509. dwd Ge0rG, Yeah, I can see that.
  510. zinid we want to put more state on the server?
  511. Ge0rG zinid: yes, smart server, dumb client.
  512. Ge0rG We've moved very far from that design principle.
  513. zinid Ge0rG, show me a dumb client (not to be confused with dumb client dev)
  514. dwd zinid, Yeah, it was one of the original design principles. The key here is that we don't really want clients acting as a heterogeneous distributed system for every operation...
  515. dwd zinid, Look on the plus side - it means us server devs get to show off how smart we are.
  516. zinid dwd, seems like this ends up with smart/complex servers and smart/complex clients
  517. dwd zinid, Yes, but in different ways.
  518. zinid that's why I always prefered SIP over XMPP
  519. Ge0rG To differentiate on features, as somebody once said...
  520. zinid web is also smart client dumb server btw
  521. Ge0rG zinid: web used to be the other way
  522. Ge0rG Some time in the middle
  523. zinid Ge0rG, all complexity in web is revolving around database management
  524. zinid while http servers are dumb as fuck
  525. zinid and that's why they are so efficient
  526. Ge0rG HTTP File servers.
  527. Ge0rG Have a look at rest api implementations
  528. zinid Ge0rG, the current trend is "serverless" (yeah, ugly term), where http server is a database front-end
  529. Ge0rG zinid: we've had that with odata. It was horrible.
  530. dwd zinid, Hmmm? You don't want to do database interaction within an AWS lambda. You want CPU-bound stuff there, not I/O-bound.
  531. zinid dwd, I don't understand the dichotomy, in XMPP you quickly faces I/O problems (database) and 50% of CPU is TLS, lol
  532. zinid and more state means more I/O bound
  533. dwd zinid, Meh. Non-blocking database access and hardware crypto accelerator, problem solved.
  534. zinid so easy, indeed 🙂
  535. zinid whatever, protocol wise (HTTP+JS+HTML+CSS) current web is smart client, if you disagree go write a browser and a http server, compare the results 😀
  536. Zash Writing a browser is impossible.
  537. Zash HTTP/2 haven't given me the impression of being simple tho
  538. zinid HTTP/2 is outdated
  539. Zash True
  540. Zash Gopher is where it's at!
  541. zinid oh, just arrived on Twitter, you will like it: > Google has a 20 year history of building completely open ecosystems
  542. dwd chokes
  543. zinid not sure if trolling
  544. jonas’ what
  545. zinid that's target audience of twitter 🙂
  546. Zash People who like to yell into the void
  547. zinid isn't that any social network about? 🙂
  548. zinid unless you somehow get a million of subscribers
  549. Zash Yup
  550. lnj has left
  551. zinid GoogleNext19 is a wonderful stream of bullshit from Google
  552. zinid "we believe in an open cloud"
  553. zinid where open cloud means you run open source databases in the google cloud of course
  554. lnj has joined
  555. lnj has left
  556. lnj has joined
  557. dwd Presumably forks of open source databases they haven't released the changes to?
  558. lnj has left
  559. lnj has joined
  560. zinid it's all unclear from their dumb marketing presentations
  561. zinid > multiple clouds and hybrid clouds is the future
  562. zinid okay, enough for today 😀
  563. Ge0rG https://twitter.com/QuinnyPig/status/1115647859980943360 is the best commentary on the Google self promotion shitshow
  564. zinid Ge0rG: lol, yeah
  565. zinid > we will not compete with your business wow, why would they say that? businesses started to understand something is wrong with using Google?
  566. moparisthebest > "Thank you for coming, enjoy #GoogleNext19!" and the keynote is over as they begin the process of deprecating everything they just announced.
  567. moparisthebest nailed it!
  568. lnj has left
  569. debacle has joined
  570. daniel has left
  571. daniel has joined
  572. daniel has left
  573. daniel has joined
  574. daniel has left
  575. daniel has joined
  576. debacle has left