XMPP Council - 2019-04-10

  1. Kev

    I should be back for Council today, but there's a chance of lateness or missing, depending on traffic etc.

  2. Kev

    'Tis time.

  3. Link Mauve

    Good morning. :)

  4. jonas’

    oh hai

  5. Ge0rG

    The times they are a-changin'!

  6. Kev

    Come gather 'round, people.

  7. Kev


  8. Kev

    Ge0rG: Did you see https://github.com/xsf/xeps/pull/781 ?

  9. Ge0rG

    Kev: sorry, no.

  10. Ge0rG

    There seems to have been a bit of a lack of agenda.

  11. Kev

    We seem to be missing a Dave, so ...

  12. Kev

    1) Roll call

  13. Kev

    I'm here.

  14. Link Mauve


  15. Ge0rG .o/

  16. jonas’


  17. 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?

  18. jonas’

    I think that’s true

  19. Kev

    This is the PR to try to address the metadata/content during LMC thing, as promised.

  20. Kev

    As it's a 30 second review, I suggest people just do that now, if they've not seen it yet.

  21. 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.

  22. jonas’

    Kev, my problem with that proposal is that "metadata" isn’t really clearly defined

  23. Ge0rG

    Kev: that essentially boils down to the philosophical question dwd brought up last time

  24. Ge0rG

    what jonas’ said

  25. Kev

    Ge0rG: I'm not keen, as that drastically increases complexity everywhere.

  26. Link Mauve

    What was this XEP saying that you shouldn’t bloat a stanza with many unrelated payloads?

  27. jonas’

    Ge0rG, yeah, I don’t want to track multiple IDs to merge corrections, and neither will an archive want to

  28. 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.

  29. Ge0rG

    Kev: I'm +0 for the sake of not dying on hills.

  30. jonas’

    it makes me think we should’ve defined a metadata block in stanzas at the beginning

  31. jonas’

    but I guess we can’t

  32. jonas’

    and I think the text makes things clearer

  33. jonas’

    so +1

  34. Kev

    jonas’: When we next get to 1999, we can consider that :D

  35. Kev


  36. Ge0rG

    Kev: due to the current GPS week rollover, we _are_ technically in 1999.

  37. jonas’

    (one way out would be to spell out correctable payloads)

  38. jonas’


  39. jonas’

    Ge0rG, but we’re also in 1979, aren’t we?

  40. Ge0rG


  41. Kev

    Link Mauve ?

  42. Link Mauve

    +1 as for the previous version.

  43. Kev


  44. jonas’

    (xep-0308: and go ahead and patch all the other xeps with explicit mention when they can be corrected)

  45. Kev

    3) Date of next

  46. jonas’

    (but yeah, current text is fine)

  47. Kev


  48. jonas’

    Kev, I think you wanted to start a discusison about compliance suites, didn’t you?

  49. Ge0rG

    +1W WFM

  50. jonas’


  51. Kev

    I do, I think it's AOBish, rather than a voting item, though.

  52. 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.

  53. Link Mauve

    +1W wfm.

  54. Zash

    https://xmpp.org/extensions/xep-0226.html comes to mind

  55. Kev

    4) AOB. Anyone else got any before I do mine?

  56. Link Mauve

    Zash, right, this one.

  57. jonas’

    I don’t have any

  58. Ge0rG

    Yeah, two of them

  59. Link Mauve

    Me neither.

  60. Ge0rG

    AOB-a: https://github.com/xsf/xeps/pull/779

  61. Ge0rG

    AOB-b: https://github.com/xsf/xeps/pull/778

  62. Ge0rG

    the former is for a Draft XEP so needs to be voted on, sooner or later.

  63. Ge0rG

    The latter is essentially what I brought up back in 2017, but without the reliance on Hints.

  64. Ge0rG

    Also I'm not sure whether we are going to hear back from the nominal author, so bringing this up before Council

  65. Kev

    I'm not ready to express opinions on either yet - can we schedule them as full items for next week?

  66. Link Mauve

    AOB-a +1 for me.

  67. Link Mauve

    Or we can reschedule.

  68. Ge0rG

    I've waited for two years now, can't you see how urgent the 0280 issue is?

  69. Link Mauve

    Ge0rG, would you want to become a shepherd for AOB-b?

  70. jonas’


  71. Ge0rG

    > BTW, I volunteer to take over 0280 authorship if the need arises.

  72. Ge0rG

    Link Mauve: ^ from the PR

  73. Link Mauve

    Great. :)

  74. Ge0rG

    https://github.com/xsf/xeps/pull/779 is surely a five-minute review thing.

  75. Kev

    You'd think, yes.

  76. Ge0rG

    But I'm not going to push anyone into anything, so +1W is fine with me.

  77. jonas’

    I’m +1 on that one

  78. Kev

    I'm just struggling to decide on an opinion about making existing implementations non-compliant, which the MUC block surely does.

  79. jonas’

    Kev, it doesn’t matter, because sending type="groupchat" to full jid is an error already

  80. Kev

    And that's a good reason for me to do a proper review, I suspect.

  81. Ge0rG

    Unless you are responding to a MUC request with a PM receipt.

  82. Ge0rG

    Which is also a possible way to do things.

  83. Kev

    Anyway, I think everyone else is +1 on 779, so we may as well treat that as item 2b rather than AOB.

  84. Kev

    And suggest we put 778 in for proper discussion next week.

  85. Kev

    And I'll on-list 799.

  86. jonas’

    I think that’s sane

  87. dwd

    Afternoon, sorry, meeting overrun.

  88. Kev

    And I'll on-list 779.

  89. jonas’

    oh, wb dwd

  90. jonas’

    oh, welcome dwd

  91. Kev


  92. Kev

    You're not taking my gavel ;D

  93. Kev

    AOB3, then. Compliance suites.

  94. 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'.

  95. dwd

    Kev, You're welcome to it.

  96. Ge0rG

    small note re next meetings: I'm going to be gone on three of the May Council meetings

  97. 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.

  98. jonas’

    Kev, I think that’s a very sensible idea

  99. Ge0rG

    Kev: this is a great idea.

  100. dwd

    Kev, The general idea seems fine. But are these living documents XEPs?

  101. Link Mauve

    Oh indeed, next week I am away during this meeting, I will be back the week after.

  102. 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.

  103. Link Mauve

    Kev, excellent idea.

  104. Kev

    (I think they're Informational, rather than Standards-Track, at least)

  105. jonas’

    they could easily be Informational XEPs in Active mode

  106. jonas’

    they could easily be Informational XEPs in Active status, maintained by Council

  107. Kev ^5s jonas’.

  108. jonas’

    although arguably XEP-0001 explicitly states compliance suites-like things to be Standards Trak ;)

  109. jonas’

    although arguably XEP-0001 explicitly states compliance suites-like things to be Standards Track ;)

  110. Kev

    Indeed, but these aren't compliance suites :)

  111. jonas’

    then again, if it isn’t about compliance but about a "what to implement" it’s not that

  112. jonas’

    ^5 again

  113. 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?

  114. Zash

    So a "how XMPP works now" and a "how we want XMPP to look in the future" documents? I approve.

  115. jonas’

    "XMPP Core XEPs version X"

  116. jonas’

    that works nicely with the badge system, too

  117. Ge0rG

    jonas’: I propose X to be mapped to time periods of sufficient length.

  118. Ge0rG

    i.e. years.

  119. 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.

  120. jonas’

    Ge0rG, versions can easily be YYYYMM.x

  121. Kev

    jonas’: They can't, actually, given xep1.

  122. jonas’

    XEP-0001 has some opinions about version numbers, but I think we can get an override from board for that ;)

  123. Kev

    One of the things I'm fairly keen we do is not have dates involved in this.

  124. 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.

  125. Ge0rG

    Kev: what's your rationale for that?

  126. jonas’

    Kev, not at all?

  127. Link Mauve

    And for technical people, Conversations’s website does a much better work at that.

  128. 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.

  129. Ge0rG

    Kev: does that argument have any merit?

  130. Kev

    And that leads us to trying to rush through new versions without (I think) due consideration.

  131. Kev

    And ISTM the cost of not having the date in the version is approximately zero.

  132. 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.

  133. Kev

    jonas’: If these are updated more often than every year, I'll be pleasantly surprised.

  134. dwd

    Can't we call it after animals? Seems to work well for Ubuntu.

  135. Kev

    I also point to XEP-0045 1.31.2

  136. Ge0rG

    Kev: I think that the year is a much better indicator of up-to-date-ness than an arbitrary version number

  137. jonas’

    dwd, no, with my editor hat on, I require version numbers to be numeric and totally ordered

  138. jonas’

    as long as XEP-0001 permits me to require that

  139. Kev

    Ge0rG: I think my argument is that using versions to give an idea of up-to-dateness isn't helpful here.

  140. jonas’

    Kev, but do you point to '45 1.13.2 for marketing purposes?

  141. Kev

    jonas’: No, for an example of a XEP with a daft number of revisions without the sky falling :)

  142. dwd

    I'd be happier with versions of XEPs if we could also reliably point to them, but I'm not entirely sure how.

  143. jonas’

    point is, it looks weird to me, and it will look weird to folks outside the XSF when used for marketing

  144. Kev

    dwd: We could make a point of including the changelog fully in these XEPs, if we wanted.

  145. 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

  146. jonas’

    even though that might mean, in the long run, that I run my own infrastructure next to the XSF’s

  147. 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.

  148. 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.

  149. 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?

  150. jonas’

    Kev, yes

  151. jonas’

    I think what dwd says is good

  152. Link Mauve

    Kev, indeed.

  153. 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 :)

  154. dwd

    Kev, Yes, but it'd be nice to have some idea of what constitutes success.

  155. 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?

  156. dwd

    Kev, If only to determine that we have failed once more.

  157. dwd

    Kev, Sounds sensible.

  158. jonas’

    Kev, do we have long-term agenda planning techniques? ;)

  159. jonas’

    (other than open PRs against xeps)

  160. Kev

    jonas’: I call it Dave.

  161. Kev


  162. jonas’

    not from me

  163. Ge0rG

    I think that with our current tooling, the current form of CS is the least failed way to do it.

  164. Kev bangs the gavel and hands it back to Dave.

  165. Kev

    Thanks all.

  166. dwd

    Kev, Thanks for stepping up there.

  167. Kev

    dwd: You've got two votes from today, I believe, to on-list (and I've got one).

  168. Kev goes back to his day off.

  169. Ge0rG

    I'm actually unconvinced of everything proposed above except for the general idea.

  170. dwd

    Ge0rG, Was there more than a general idea?

  171. Ge0rG

    And that general idea can easily be mapped onto yearly CS XEPs.

  172. Ge0rG

    ...provided somebody does the actual work.

  173. dwd

    Ge0rG, Aye, there's the rub.

  174. 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'.

  175. 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.

  176. dwd

    Ge0rG, Ah. So *some* of that neatly fits onto Compliance Suites.

  177. dwd

    Ge0rG, Mostly the first document.

  178. Ge0rG

    dwd: yes.

  179. Ge0rG

    Now would be a good time to start a proto-CS-2020, or maybe a proto-future-CS

  180. dwd

    Ge0rG, The key change is a single mutating document instead of multiple documents.

  181. Ge0rG

    dwd: and due to tooling reasons, I actually object to _that_ change.

  182. jonas’


  183. Ge0rG

    Because XEP versioning is an ugly business.

  184. dwd

    Ge0rG, And one I noted.

  185. jonas’

    I find non-obvious XEP numbers for CS worse

  186. jonas’

    we can fix the versioning

  187. Zash


  188. Ge0rG

    We don't have good link-ability to old versions, and we don't have good diff views.

  189. jonas’

    the diff views are an argument, but that doesn’t get fixed with separate documents at all

  190. Ge0rG

    can has xep-2019.xml

  191. Ge0rG

    jonas’: touché

  192. jonas’

    if anything, it is worse, because in the future, we might get diff tools back, but those will work between versions, not xeps

  193. dwd

    Ge0rG, Link-ability would be interesting. We could link to old versions via the changelog, too.

  194. jonas’

    and link-ability to old versions can be fixed, too

  195. jonas’

    for those which are built, that is

  196. Ge0rG

    dwd: the changelog is just a muddy reflection

  197. jonas’

    that’s the authors fault though

  198. jonas’

    or maybe the editors, but the author can do something about it

  199. Ge0rG

    so let's mandate *proper* changelog maintenance for Compliance Suites, whatever "proper" means.

  200. 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

  201. Ge0rG

    and change the year each year.

  202. 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.

  203. dwd

    Ge0rG, So #778. What's the rationale here?

  204. dwd

    For the CS Date, we can of cours ejust change the title on the new version.

  205. Ge0rG

    dwd: the overall high-level rationale, the specific rationale of individual commits or ... ?

  206. dwd

    Ge0rG, High level, to begin with.

  207. Zash

    Have a persistent item at Summit?

  208. Ge0rG

    dwd: Carbons have many broken corner cases

  209. dwd

    Zash, Hush now.

  210. 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.

  211. dwd

    Ge0rG, Right, but is that because it doesn't matter?

  212. Zash

    dwd? :(

  213. 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.

  214. dwd

    Zash, It's hardly the only repetitive topic at Summits.

  215. Ge0rG

    dwd: is that a trick question?

  216. dwd

    Ge0rG, No, I'm trying to figure out the rationale, and thereby decide on the best way to progress this work.

  217. 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.

  218. dwd

    Ge0rG, To what end?

  219. Ge0rG

    dwd: to fix the user experience

  220. 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.

  221. Ge0rG

    Also improvements to the rules to make them more consistent

  222. dwd

    Ge0rG, OK, this seems more useful. So what happens if a server doesn't follow these rules?

  223. Ge0rG

    like carbons of errors.

  224. Ge0rG

    dwd: the corner cases remain unfixed

  225. dwd

    Ge0rG, Yes, but at a high level?

  226. 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?

  227. Ge0rG

    dwd: I'm not sure where you are aiming

  228. 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.

  229. Zash

    Hm. https://xmpp.org/extensions/xep-0001.xml

  230. Ge0rG

    dwd: yeah, not feeling offended, just not sure how to answer

  231. 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?

  232. 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.

  233. Ge0rG

    dwd: thus clients typically don't rely on anything working

  234. 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.

  235. 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

  236. Ge0rG

    dwd: now you are talking!

  237. dwd

    Ge0rG, I'm also aware that server implementations tend to adopt things faster if they can advertise their support.

  238. 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

  239. Ge0rG

    Also 0280 as it is now is a VERY BAD XEP.

  240. 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.

  241. Ge0rG

    dwd: I'm still not sure it makes _technical_ sense to advertise some kind of support level for 0280 rules

  242. dwd

    Ge0rG, I honestly don't know. For diagnostics, it probably does.

  243. dwd

    Ge0rG, But I'm not sure that clients would alter behaviour.

  244. Ge0rG

    I wouldn't in mine.

  245. Ge0rG

    And I'm not often looking into disco#info when diagnosing things.

  246. 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?

  247. dwd

    Ge0rG, The latter I imagine.

  248. dwd

    Ge0rG, But also, I think working on it in a separate XEP might prove more politically viable.

  249. Ge0rG

    I'm not opposing, just wondering if it actually has value.

  250. Ge0rG

    dwd: see above. > Also 0280 as it is now is a VERY BAD XEP.

  251. dwd

    Well, you'd eventually have a patch which removes the rules from '280 and points at ${NEWXEP}

  252. 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.

  253. Ge0rG

    (insert Brexit pun)

  254. Ge0rG

    dwd: how is that formally different from having the rules in 0280 and not having another XEP?

  255. dwd

    Ge0rG, It isn't, but I see an easier path to get there from here.

  256. jonas’

    do you think council will oppose that change?

  257. dwd

    Ge0rG, But understand: I'm only throwing ideas out there.

  258. Ge0rG

    dwd: and once we are there, we merge the two XEPs into one?

  259. Ge0rG

    dwd: is there some special political meaning to the number 0280, that I don't know about because I'm too young?

  260. dwd

    jonas’, WHich change? The rules update? Probably less likely to cause problems if the new XEP is mature and well-supported.

  261. 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.

  262. Ge0rG

    dwd: "simpler" in the sense of the XSF Council process?

  263. dwd

    Ge0rG, I was thinking community more than Council.

  264. 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?

  265. 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.

  266. Ge0rG

    dwd: if I didn't need to bully server implementors, they'd have the Good Rules by now.

  267. Ge0rG

    (making a PR against 0280 was actually my attempt to bully server implementors)

  268. dwd

    Ge0rG, Yeah. I think a new XEP might be more persuasive than bullying.

  269. Zash

    Routing 2.0?

  270. dwd

    Zash, I'm not mad keen on fork-lifts.

  271. Zash

    XMPP 2.0 !

  272. 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.

  273. Zash

    dwd: Some videos of omniwheel forklifts ough to change your mind :)

  274. Ge0rG

    (incidentally, the 0184 PR could have happened half a year ago if it wasn't for some curse words in the XML)

  275. Ge0rG

    also I'm not sure how much a SHOULD is a fork-lift.

  276. 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.

  277. Ge0rG

    (which is also why it took almost two years for me to re-issue #434)

  278. 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

  279. zinid

    wut, 280 again?

  280. zinid

    is it meeting now?

  281. Ge0rG

    zinid: meeting is over, context is https://github.com/xsf/xeps/pull/778

  282. zinid

    meeting was at 15:00 UTC?

  283. zinid


  284. Ge0rG

    zinid: https://logs.xmpp.org/council/2019-04-10#2019-04-10-611d9881cd1a08ca

  285. dwd

    zinid, The '280 thing is basically a tradition now.

  286. zinid


  287. zinid


  288. dwd

    zinid, Do you happen to know what carbon rules ejabberd implements?

  289. zinid

    dwd, no 🙂

  290. zinid

    I'm not the author and don't have any desire to touch the code with 19m pole

  291. zinid

    it is better not to touch the routing in the server, it always ends up with something borked 😀

  292. dwd

    Yeah it is always the weirdest, hariest code in any server.

  293. dwd

    No doubt Zash will tell me that Prosody's routing code is perfect about now. :-)

  294. Zash

    dwd: Yes, it's perfect, so I don't wanna touch it ever again! /me hides

  295. Ge0rG

    Zash: LIES!

  296. dwd

    Ge0rG, No, I believe he never wants to touch it again.

  297. Zash

    Carbons and MAM are in stable releases now, changing anything will probably be massively painful

  298. zinid

    do we need to change something? From the PR it's not very clear, looks like just wording improvement

  299. Ge0rG

    zinid: depends on what you do.

  300. Ge0rG

    I know that prosody lacks with 0184 payloads of type normal and on error responses.

  301. dwd

    I think errors is a definite change from previous recommendations, isn't it?

  302. Zash

    Prosody does carbons with (type=chat or (type=normal and has <body>))

  303. Zash

    modulo hints

  304. Ge0rG

    Previous recommendations were all MAY, but they contained error handling

  305. 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).

  306. dwd

    Ge0rG, Ah, indeed. But not '184.

  307. Ge0rG

    dwd: CSN and Receipts are new, yes.

  308. Ge0rG

    Unless your receipts are of type=chat, in which case they magically work.

  309. dwd

    Ge0rG, So basically if we adopt this text, we're declaring all existing implementations to be non-conformant?

  310. Ge0rG

    But that in itself is kind of a violation of 0184

  311. Ge0rG

    dwd: you make it sound negative.

  312. zinid

    > CSN and Receipts are new, yes abstract leakage again

  313. zinid


  314. Ge0rG

    zinid: that kind of leakage is also happening in LMC currently.

  315. zinid

    well, maybe, that's client devs problems, I don't care 😀

  316. 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.

  317. dwd

    Ge0rG, I think I like the changes. Just trying to figure out the most effective way of getting them deployed.

  318. Ge0rG

    But I'm more interested in moving xmpp forward than in fighting process debates.

  319. Ge0rG

    (at least in this specific case)

  320. dwd

    Ge0rG, Not so much process as trying to get the server devs to actually implement.

  321. Ge0rG

    dwd: I'm not sure there is an elegant solution to *that* problem.

  322. dwd

    Ge0rG, No, but there may be multiple solutions with differeing levels of friction.

  323. zinid

    and this would require namespace bump?

  324. zinid

    or you want to avoid it thus the hassle?

  325. 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.

  326. 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.

  327. zinid

    so bump the namespace and introduce all this new fancy stuff, what's the problem?

  328. Ge0rG

    Namespace bumps are one of the most inelegant ways to move forward.

  329. 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

  330. Ge0rG

    zinid: great idea. Is it sufficient to amend the PR?

  331. Ge0rG

    As the old rules are all MAY, it would technically suffice to introduce a new feature code.

  332. dwd

    zinid, https://github.com/xsf/xeps/pull/778 FYI

  333. zinid

    dwd, yeah, I briefly looked at it

  334. zinid

    Ge0rG, heh, everything is complicated

  335. zinid

    anyway, virtually impossible to understand anything from the diff 😀

  336. zinid

    > it contains payload elements typically used in IM wut?

  337. 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_

  338. Ge0rG

    Weasel words!

  339. Ge0rG

    zinid: can't you just forward _all_ error messages?

  340. dwd

    zinid, Possible if the error includes the original.

  341. dwd

    Ge0rG, Is that... Good?

  342. Ge0rG

    dwd: does it ever, in reality?

  343. Ge0rG

    dwd: it's better than not, in IM

  344. dwd

    Ge0rG, Sometimes. But it really does vary a lot, even within implementations.

  345. zinid

    dwd, a better solution would be attaching some "route state" to stanzas, but XMPP doesn't allow this

  346. Ge0rG

    Except that error generation is broken with some 0198 implementations.

  347. zinid

    SIP has Record-Route header for this

  348. Ge0rG

    zinid: IM-NG was supposed to solve that

  349. zinid

    Ge0rG, what? attaching routing states?

  350. zinid

    to where?

  351. zinid

    resource, lmao? 😀

  352. Ge0rG

    But I suppose it doesn't properly cover error responses.

  353. Ge0rG

    If you send a message to bare and receive an error from full, what does it even mean?

  354. zinid

    I don't know

  355. Ge0rG

    dwd: do you see problems with carbon copying all message errors?

  356. dwd

    Ge0rG, A bit, yes. I wonder if the right approach would be to manage the state elsewhere, if that's the aim.

  357. 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?

  358. zinid

    Ge0rG, ah, all those are MAYs and SHOULDs, I'm okay then 😀

  359. dwd

    zinid, You know SHOULDs aren't actually optional, right?

  360. zinid

    dwd, I can always ask you, yeah

  361. Ge0rG

    dwd: exactly!

  362. zinid

    like, "hey Dave, is this SHOULD a MUST?"

  363. Ge0rG

    dwd: I could live with some MAM related hack, because this is all about synchronizing a chat history database

  364. zinid

    (mastodon approach)

  365. dwd

    Ge0rG, I wonder if these (like receipts, actually) - yeah, you're thinking the same thing.

  366. dwd

    zinid, If you have to ask, yes, the SHOULD is a MUST.

  367. Ge0rG

    dwd: I also want multi receipts

  368. Ge0rG

    zinid: are error messages stored in mam?

  369. zinid

    Ge0rG, no

  370. Ge0rG

    Why not?

  371. dwd

    Ge0rG, That's a similar thing, right?

  372. zinid

    Ge0rG, I don't know/

  373. dwd

    Ge0rG, Better off storing a flag or something, anyway, in MAM.

  374. Ge0rG

    dwd: yes, slightly related

  375. Ge0rG

    Let's use the existing wire format to synchronize a message history database

  376. zinid reading the mam code

  377. zinid


  378. zinid


  379. zinid

    seems like errors are stored

  380. zinid

    ah, no, first line actually 😀

  381. zinid

    let's just archive everything

  382. Ge0rG

    zinid [19:24]: > let's just archive everything Awesome idea! Just replay all the CSN changes on each login!

  383. Zash

    Maybe what MattJ said about doing CSN over presence instead is better

  384. Ge0rG

    Zash: yes. Do it! Now!

  385. zinid

    yeah, we are in the situation where we need a special semantics on what should be retained

  386. Ge0rG


  387. zinid

    how about jingle calls? anyone?

  388. zinid

    you want to know who called you

  389. zinid

    should we add jingle calls to 280?

  390. Ge0rG

    Yeah, just don't start ringing when receiving a call from mam

  391. zinid

    since we allow abstraction leakage anyways

  392. zinid

    Ge0rG, how to fork the jingle call?

  393. Ge0rG

    Do you jungle call a bare JID or a full JID? What if there are multiple capable devices?

  394. zinid

    Ge0rG, SIP!

  395. Ge0rG

    zinid: serious question

  396. Zash

    Ge0rG: Do what?

  397. Ge0rG

    Zash [19:34]: > Maybe what MattJ said about doing CSN over presence instead is better > Zash: yes. Do it! Now!

  398. zinid

    Ge0rG, I have actually the serious answer, don't you know my stance on Jingle yet? 😉

  399. zinid

    Jingle doesn't even have basic functionality like forking, which SIP had since day 1

  400. Ge0rG

    zinid: what about this: Carbon copy each message payload for which a Carbons-enabled client advertises support.

  401. zinid

    each message payload?

  402. zinid

    and how to advertise it?

  403. zinid

    not sure I understand this

  404. Ge0rG

    If a client supports Carbons and 0184, send receipt Carbons. If it supports jingle, send call Carbons!

  405. Zash

    Ge0rG: Is there a map of features to xmlns?

  406. zinid

    Zash, carbons#foo?

  407. Ge0rG

    Zash: most features carry a namespace

  408. Zash

    Features (in disco#info) are not the same as xmlns

  409. zinid

    Ge0rG, so the server should inspect the cached disco response? Never liked the idea since there are races

  410. Ge0rG

    Zash [19:47]: > Features (in disco#info) are not the same as xmlns One of the bigger design failures of xmpp

  411. Ge0rG

    We had that in the context of MAM I think

  412. Zash

    Ge0rG: Useful in case there are more than one feature per spec

  413. Ge0rG

    zinid: do you want to get an explicit list of namespaces in Carbons enable iq?

  414. Ge0rG

    Zash: those should be suffixes to the xmlns

  415. zinid

    Ge0rG, not sure... the server must understand them all, right?

  416. Ge0rG

    zinid: can't it just make a set of all namespaces contained in the message?

  417. zinid

    Ge0rG, probably, but what about errors?

  418. zinid

    I mean message type=error

  419. Ge0rG

    zinid: what about them?

  420. zinid

    Ge0rG, how to know a client wants to receive them?

  421. zinid

    or is it supposed to be by default?

  422. Ge0rG

    Yes, by default. Unless you can track the original and determine whether it was copied

  423. zinid

    all solutions are ugly as hell 🙂

  424. Ge0rG

    zinid: is there a way to make an elegant solution by fixing other places?

  425. zinid

    I don't have any solution

  426. zinid

    btw, SIP requires in every document to specify forking rules for new messages

  427. Ge0rG

    That's not bad.

  428. Ge0rG

    We could require error messages to contain the original type, from and to.

  429. zinid

    well, that's maybe not a requirement, but I frequently saw "Forking" section here in there in SIP RFCs

  430. Ge0rG

    That doesn't solve 0184 of course. But it helps a little.

  431. Ge0rG

    And it will be sufficient with IM-NG

  432. 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"

  433. zinid

    I can only say what is hard or easy to implement in the server

  434. zinid

    which boils down "shared state" is evil

  435. Zash

    I'm more concerned about unclear rules and different sets of people having different requirements that are not written down anywhere

  436. Zash

    Like here, XEP-0280 says one thing. Ge0rG wants something else. Other client devs want yet something else.

  437. zinid

    even if you write them down not everyone will be happy

  438. zinid

    like some clients don't want to receive bounced CSN when a contact is offline

  439. Ge0rG

    I've written them down. Many times. Still waiting for client developers to comment.

  440. zinid

    (which is basic RFC requriement)

  441. Ge0rG

    zinid: bounced CSN = errors?

  442. zinid

    Ge0rG, yes, service-unavailable

  443. Zash

    In the words of https://tools.ietf.org/html/rfc7282 > Rough consensus is achieved when all issues are addressed, but not necessarily accommodated

  444. zinid

    Ge0rG, we even have mod_bounce_something for some customers! the very loud ones

  445. Zash

    Writing things down is a prerequisite of that

  446. Ge0rG

    zinid: what does it bounce?

  447. 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.

  448. zinid

    Ge0rG, everything that wasn't put in mam or offline in transit

  449. zinid

    actually it supresses the bouncing, I don't recall how the module is called exactly

  450. Ge0rG

    Yeah, not bounce anything that's in mam is a good thing!

  451. Zash

    dwd: Problem statement?

  452. dwd

    Zash, That'd be nice, yes.

  453. 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

  454. zinid

    Ge0rG, the point is go figure what client devs want

  455. Zash

    I'd be careful with giving people what they want.

  456. Zash

    It's not always the same as what they need.

  457. zinid

    dwd, yeah, ESL introduced recently some inbox protocol

  458. dwd

    This had some stuff in it: https://twitter.com/miquido/status/1115270391176552450

  459. dwd

    Quite interesting, that article - really showed XMPP from an outsider's perspective.

  460. zinid

    Zash, you typically don't want to debate with customers, that's the problem

  461. 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).

  462. Ge0rG

    dwd: I had a "told you so" feeling for large parts of that post...

  463. dwd

    Ge0rG, Yeah, I can see that.

  464. zinid

    we want to put more state on the server?

  465. Ge0rG

    zinid: yes, smart server, dumb client.

  466. Ge0rG

    We've moved very far from that design principle.

  467. zinid

    Ge0rG, show me a dumb client (not to be confused with dumb client dev)

  468. 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...

  469. dwd

    zinid, Look on the plus side - it means us server devs get to show off how smart we are.

  470. zinid

    dwd, seems like this ends up with smart/complex servers and smart/complex clients

  471. dwd

    zinid, Yes, but in different ways.

  472. zinid

    that's why I always prefered SIP over XMPP

  473. Ge0rG

    To differentiate on features, as somebody once said...

  474. zinid

    web is also smart client dumb server btw

  475. Ge0rG

    zinid: web used to be the other way

  476. Ge0rG

    Some time in the middle

  477. zinid

    Ge0rG, all complexity in web is revolving around database management

  478. zinid

    while http servers are dumb as fuck

  479. zinid

    and that's why they are so efficient

  480. Ge0rG

    HTTP File servers.

  481. Ge0rG

    Have a look at rest api implementations

  482. zinid

    Ge0rG, the current trend is "serverless" (yeah, ugly term), where http server is a database front-end

  483. Ge0rG

    zinid: we've had that with odata. It was horrible.

  484. 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.

  485. zinid

    dwd, I don't understand the dichotomy, in XMPP you quickly faces I/O problems (database) and 50% of CPU is TLS, lol

  486. zinid

    and more state means more I/O bound

  487. dwd

    zinid, Meh. Non-blocking database access and hardware crypto accelerator, problem solved.

  488. zinid

    so easy, indeed 🙂

  489. 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 😀

  490. Zash

    Writing a browser is impossible.

  491. Zash

    HTTP/2 haven't given me the impression of being simple tho

  492. zinid

    HTTP/2 is outdated

  493. Zash


  494. Zash

    Gopher is where it's at!

  495. zinid

    oh, just arrived on Twitter, you will like it: > Google has a 20 year history of building completely open ecosystems

  496. dwd chokes

  497. zinid

    not sure if trolling

  498. jonas’


  499. zinid

    that's target audience of twitter 🙂

  500. Zash

    People who like to yell into the void

  501. zinid

    isn't that any social network about? 🙂

  502. zinid

    unless you somehow get a million of subscribers

  503. Zash


  504. zinid

    GoogleNext19 is a wonderful stream of bullshit from Google

  505. zinid

    "we believe in an open cloud"

  506. zinid

    where open cloud means you run open source databases in the google cloud of course

  507. dwd

    Presumably forks of open source databases they haven't released the changes to?

  508. zinid

    it's all unclear from their dumb marketing presentations

  509. zinid

    > multiple clouds and hybrid clouds is the future

  510. zinid

    okay, enough for today 😀

  511. Ge0rG

    https://twitter.com/QuinnyPig/status/1115647859980943360 is the best commentary on the Google self promotion shitshow

  512. zinid

    Ge0rG: lol, yeah

  513. zinid

    > we will not compete with your business wow, why would they say that? businesses started to understand something is wrong with using Google?

  514. moparisthebest

    > "Thank you for coming, enjoy #GoogleNext19!" and the keynote is over as they begin the process of deprecating everything they just announced.

  515. moparisthebest

    nailed it!