XMPP Council - 2019-04-17

  1. Link Mauve

    Just a reminder that I’ll be in another meeting this afternoon, and thus not here.

  2. dwd

    Are we sitting comfortably?

  3. jonas’

    I am

  4. Kev

    Then let's begin. Only not quite yet because it's not 4 yet.

  5. Ge0rG

    Good morning, ladies.

  6. dwd


  7. dwd

    1) Roll Call

  8. Kev


  9. jonas’


  10. Ge0rG

  11. dwd

    Missing Link Mauve as expected - he sent apologies last week.

  12. dwd

    2) Agenda Bashing

  13. dwd

    We've four items this week, all PRs.

  14. Kev

    I've been busy all day and not in a position to bash, sadly.

  15. dwd

    #736, #778, #784, and #785

  16. dwd

    Any others?

  17. dwd

    Assuming not.

  18. dwd

    3) Items for a vote (or discussion):

  19. dwd

    a) https://github.com/xsf/xeps/pull/736 XEP-0308: Allow message correction in MUC

  20. Kev

    I'm concerned about this one.

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

  22. Kev

    Mostly about the idea of servers needing to store data on every past occupant.

  23. jonas’

    yeah, I don’t think that’s sane

  24. Kev

    As the current text doesn't seem to have any sort of time limit on corrections.

  25. jonas’

    clients cannot rely on the feature unless we impose O(+infty) amount of work on servers

  26. Ge0rG

    isn't it sufficient to store the real bare JID on all messages in the history log?

  27. jonas’

    the history log may be +infty long

  28. jonas’

    and you need to do a search for the corrected message

  29. jonas’

    for each correction

  30. jonas’

    that sounds like a very easy DoS vector to me

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

  32. jonas’

    -> no server right in their minds is going to implement this.

  33. Ge0rG

    right. unless you have... an index!

  34. jonas’

    even then it’s complex

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

  36. jonas’

    even then it’s computationally complex

  37. Kev

    " If it does so, the receiver can trust any message correction received through this room, be it live or from history."

  38. dwd

    That is, a server saying Nope every time is, I think, conformant as written.

  39. Kev

    I think it's clear that the intent is that advertising the feature means that every correction has been checked for validity.

  40. Ge0rG

    Kev: I agree

  41. dwd

    Kev, Yes, but not that every correction has been accepted that could have been.

  42. Kev

    Yes, that is true. But also quite unhelpful.

  43. Ge0rG

    I think it's a useful feature to have, and I don't know how Link Mauve implemented it.

  44. dwd

    In any case, the "SHOULD" and "should" and things scare me at the moment.

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

  46. dwd

    So I'm -1 for now, but I think this can be fixed.

  47. Ge0rG

    jonas’: because you can flood the server with bare JIDs?

  48. jonas’

    if clients cannot rely on it (because the server is allowed to age out information), it is not useful

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

  50. jonas’

    Ge0rG, for example, or simply with messages

  51. Ge0rG

    dwd: you are -1 because what can be fixed?

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

  53. Kev

    Dave is right there, I think.

  54. dwd

    Ge0rG, Language. I don't think it's actually describing what's normative very well.

  55. jonas’

    Kev, that needs to be spelt out clearly though

  56. Kev

    I think so, yes.

  57. jonas’

    -1 until the DoS vector and how it is to be mitigated and what clients can expect there is clarified

  58. dwd

    Kev, Ge0rG ?

  59. Ge0rG

    on-list to see what comes out of your questions.

  60. Kev

    Already -1d.

  61. dwd


  62. Ge0rG

    I feel like +1, but the raised points are valid as well.

  63. dwd

    aa) XEP-0308: relax from-full-JID requirement https://github.com/xsf/xeps/pull/784

  64. dwd

    I feel like this is intimately tied in with #736, myself.

  65. jonas’

    I’m +1 on that one

  66. jonas’

    dwd, it’s not necessarily

  67. Kev

    dwd: Why's that?

  68. Ge0rG

    dwd: #736 is implying it, but it's not tied in any way.

  69. dwd

    Or perhaps I misread - is this purely client-side?

  70. jonas’

    it can be done purely client side

  71. jonas’

    (and the text suggests that)

  72. Ge0rG

    dwd: the text is deliberately open about client- or server-side

  73. Kev

    Oh, you're right, that 'or the MUC service' does imply it. Because a client cannot do the verification itself.

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

  75. Kev

    (Unless it's non-anonymous)

  76. jonas’

    Kev, it can

  77. dwd

    Ah, yes. OK, in that case it's fine. +1

  78. jonas’

    if there was a part/join in-between, it might not be the same JID -> discard

  79. Kev

    So that means that where the recipient can't do it, to satisfy that requirement the MUC service must have done it.

  80. jonas’

    if there was a part/join in-between, it might not be the same s ender -> discard

  81. jonas’

    if there was a part/join in-between, it might not be the same sender -> reject

  82. Kev

    Which puts requirements on a MUC service where there were none before.

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

  84. jonas’

    it’s not a requirement -- clients already implement that check, actually.

  85. Ge0rG

    Kev: the recipient can do it if neither you nor the sending occupant did leave the MUC between the original and the correction.

  86. Ge0rG

    some clients.

  87. jonas’

    yeah, other default the check to "not allowed" ;)

  88. jonas’

    yeah, others default the check to "not allowed" ;)

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

  90. Ge0rG

    other clients ignore it altogether because identity of occupants in a semi-anon muc is pointless.

  91. jonas’

    maybe, but I still think this can stand on its own, so +1

  92. dwd

    Kev, See, when I said that everyone disagreed. :-)

  93. Ge0rG

    +1 obviously.

  94. Kev

    dwd: I didn't. I asked why.

  95. Ge0rG

    Kev: I could provide a better wording of #784 once #736 is approved. Which it isn't.

  96. Ge0rG

    as it is now, I think that the wording is sufficient for either outcome of #736.

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

  98. Ge0rG

    Kev: we are speaking of a footnote.

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

  100. Kev

    As without 736 the MUC service doing things doesn't help at all anyway.

  101. Ge0rG

    Kev: if that is your prerequisite for accepting, I can re-word.

  102. dwd

    Kev, Or at least, without '736, the recipient has no idea if the MUC service is doing anything.

  103. Kev

    Ok, +1 after tweaking.

  104. Kev

    dwd: Indeed.

  105. dwd

    OK, then.

  106. Ge0rG


  107. dwd

    c) https://github.com/xsf/xeps/pull/785 - XEP-0260: Replace broken link with archive.org

  108. Kev

    Not a Council voting item, I think, just Editorial.

  109. Ge0rG

    as a matter of form, I'd not replace the anchor text, just the link.

  110. jonas’

    I think that’s sensible

  111. Kev

    That makes more sense.

  112. Ge0rG

    But I agree with Kev that this is Editorial, so +1.

  113. jonas’

    will take care of that

  114. Kev

    I think I'd be inclined for Council to instead decide it's Editorial, rather than voting as if it wasn't.

  115. Kev

    It affects versioning, for example.

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

  117. dwd

    No, I'm fine with this being Editorial.

  118. jonas’

    yeah, editorial

  119. jonas’

    I wouldn’t even have raised this to council

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

  121. dwd

    Is there a better specification for SOCKS5 we could/should be using here?

  122. Kev

    dwd: Oh, I didn't read it that way. Maybe I've misunderstood.

  123. Ge0rG

    So let's re-vote on this kind of things being Editorial Changes?

  124. Kev

    I thought it was saying "And for people who remember this old proposal, this is much the same".

  125. jonas’

    yeah, it should probably be moved to the XEP, if we can get this sorted out legally

  126. Kev

    (When I say "Maybe I've misunderstood", I'm actually fairly confident that I haven't)

  127. dwd

    Kev, Yes, you probably haven't misunderstood. I'm just a little sensitive to external links in the XEPs.

  128. Kev

    Agreed that this is Editorial, suggest to the Editors to not change the link text, just the link, and move on?

  129. dwd

    ANyway, the change itself is certainly Editorial. I just wanted to make sure we're happy with the linking at all.

  130. Ge0rG

    That requires obtaining permission from Justin to incorporate the text as an informational part? as a dedicated informational XEP?

  131. Ge0rG

    dwd: +1 to that motion.

  132. dwd

    Ge0rG, You're happy?

  133. dwd

    Anyway, probably no conclusions to be made here.

  134. dwd

    4) Outstanding Votes

  135. dwd

    Please check 'em.

  136. Ge0rG

    dwd: what about d)

  137. dwd

    Ge0rG, Oh, I skipped one, didn't I?

  138. Ge0rG

    no, wait. it was b) which should have preceded your c) but probably was missed due to aa).

  139. Ge0rG

    b) Discussion: https://github.com/xsf/xeps/pull/778 XEP-0280: Rewrite of the 'Messages Eligible for Carbons Delivery' section

  140. dwd

    ndeed, that ^^

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

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

  143. Ge0rG

    Formally, 0280 is somewhere between Experimental and Abandoned.

  144. dwd

    Ge0rG, Yeah. XEP-0280 isn't in a happy place, in terms of process.

  145. jonas’

    dwd, we’re on the road to that, it’s called IM-NG

  146. dwd

    jonas’, That road is very long and shows no sign of getting shorter.

  147. Ge0rG

    dwd: it also had a bunch of Last Calls.

  148. Kev

    I don't think roads typically get shorter, you just move along them :)

  149. dwd

    Ge0rG, This, too, I'm aware of.

  150. Ge0rG

    Kev: that road is a kind of moebius strip, apparently.

  151. Kev

    I would be much happier with the idea of formal rules in a XEP with its own feature.

  152. dwd

    Kev, Yes, I don't think that's happening either.

  153. Kev

    Ge0rG: But at least it doesn't change in its infinite length.

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

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

  156. jonas’

    from what I can see, this PR mostly clarifies how carbons interact with MUCs

  157. jonas’

    the other rules seem untouched

  158. Ge0rG

    jonas’: the other rules move from MAY to BREX^W SHOULD

  159. jonas’

    ah, right

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

  161. jonas’

    one could advertise this ruleset in a feature if it makes people happy

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

  163. jonas’

    dwd, it can also be made MUST in the same XEP with a feature

  164. jonas’

    and I’d prefer that

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

  166. jonas’

    I am a bit wary of the XEP proliferation we have

  167. dwd

    jonas’, We should write a XEP on that.

  168. jonas’

    right, so a new feature which advertises this exact ruleset?

  169. Ge0rG

    As it is now, 0280 is not only in a very sad place process-wise, it is also a very sad specification.

  170. Ge0rG

    or rather, a very saddening one.

  171. dwd

    With a new feature, I'd suggest that many of the SHOULDs in Georg's PR could be MUSTs.

  172. Kev

    I'm going to need to think about this at-length and on-list, in any case, because I'm a bit rubbish.

  173. Ge0rG

    Kev: please also read up the many discussions of that from the last five years.

  174. jonas’

    I’m +0 on this without feature, +1 with a feature + MUSTification.

  175. Ge0rG

    dwd: I can make that a feature-conditioned MUST in 0280.

  176. jonas’

    (obviously, the error tracking stuff should stay non-MUST)

  177. Kev

    Ge0rG: I'm confident you don't want me to do that.

  178. Ge0rG

    > (obviously, the error tracking stuff should stay non-MUST)

  179. Ge0rG

    I disagree with that, and that makes a good distinct discussion point.

  180. Ge0rG

    What to do with errors.

  181. Ge0rG

    Practically, it sucks to not receive errors for carbonated messages.

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

  183. dwd

    FWIW, I think I'm the same as jonas’ here - +0 but +1 with a feature.

  184. jonas’

    Ge0rG, but error-tracking is expensive

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

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

  187. jonas’

    I don’t think that a separate XEP is the right tool here

  188. Ge0rG

    jonas’: error-tracking is expensive. What about fanning out all message errors?

  189. jonas’

    that would probably work

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

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

  192. dwd

    OK - I'm going to move on, but we can come back to this after the meeting.

  193. Kev

    But also that we couldn't sensibly Draft 280 with the rules in for some time.

  194. Kev

    And this would also let us decide that other rules were better in the future.

  195. jonas’

    I think other rulesets should be developed in the IM-NG realm of things

  196. dwd

    5) Next Meeting

  197. dwd

    Next week?

  198. jonas’


  199. Ge0rG

    Kev: what is the point of Drafting 0280 without the rules?

  200. Ge0rG

    +1W WFM

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

  202. dwd

    I'm in the office next week, so might be disrupted - I'll try to make it though.

  203. dwd

    6) AOB

  204. Ge0rG

    Oh, there is _yet another_ dimension on Carbons: Transports

  205. dwd

    Anything other than '280?

  206. Ge0rG

    No AOB

  207. dwd

    7) Ite, Meeting Est.

  208. dwd

    Ge0rG, I'm of the general opinion that transports are often rubbish, but how so in this particular case?

  209. Ge0rG

    dwd: we should allow a Transport to send sent-carbons when the user sent a message from a native-protocol client.

  210. dwd

    Ge0rG, Ah. Funnily enough, I do exactly this. Or did.

  211. Ge0rG

    There was a weirdly worded list inquiry by Владимир.

  212. Ge0rG


  213. dwd

    Oh, yeah, I had all those problems.

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

  215. moparisthebest

    my uh, client side transport thing, relies 100% on carbons to work

  216. dwd

    Ge0rG, Yes. Also, MAM needs to archive those messages.

  217. Ge0rG

    dwd: yes.

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

  219. Ge0rG

    But really, _this_ problem of Carbons can be solved most easily outside of 0280.

  220. Ge0rG

    So please let's get back to getting 0280 done.

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

  222. dwd

    pep., See previous discussion about how broken '280 is wrt process.

  223. pep.

    Well it's not yet Draft, at least

  224. pep.

    it's in between Proposed, LC, Experimental

  225. pep.

    So I'd say "if you have to break or bump, do it while you can".

  226. moparisthebest

    implementations wait for no one

  227. moparisthebest

    it doesn't matter if it's experimental or not even submitted, if thousands of devices in the wild implement it

  228. pep.

    Sure, so what?

  229. moparisthebest

    a good XMPP related example is aes-256-gcm file encryption with http upload

  230. pep.

    That's one of the many OMEMO failures indeed

  231. pep.

    But that's not related to what I'm saying

  232. jonas’

    for certain definitions of "good" example

  233. moparisthebest

    it's just, there is a difference between "theoretical" and "practical"

  234. moparisthebest

    theoretically, sure, not-draft/final means you can change anything, in practice, not so much

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

  236. Kev

    pep.: I have limited concerns about breaking 280. My concerns are breaking it in the wrong way.

  237. pep.

    Kev, k

  238. pep.

    I guess my message was mostly directed at people who want another XEP for this

  239. jonas’

    (which includes Kev to a certain extent)

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

  241. dwd

    pep., Our process is meant to reflect reality, and not try to coerce reality into its own image.

  242. pep.

    So you'd change a Final XEP that's not used?

  243. jonas’

    a final xep can’t be not-used

  244. jonas’

    it can only be not-used-anymore, which would mean deprecation

  245. jonas’

    (at least two independent implementations are a requirement for moving to Final)

  246. pep.

    Yeah, not-used-anymore, implementations gone out of existance or sth

  247. dwd

    pep., Very happy to deprecate existing Final specs that are used if we wouldn't recommend people to implement anymore.

  248. pep.

    Not what I asked

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

  250. pep.

    implemented != proven to work, but I guess that's up for debate

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

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

  253. Ge0rG

    dwd: re push-back from server developers, is that only about error tracking or were there other issues?

  254. dwd

    Ge0rG, Honestly, i can't remember. '280 just feels like a death march.

  255. Ge0rG

    I'd rather compare it with quicksand.

  256. Ge0rG

    Anyway, the unanswered question is: would it have unappreciated (side)effects to carbon-copy all messages of type=error?

  257. Ge0rG

    I'm pretty sure there is no problem with errors caused in the context of IM.

  258. Ge0rG

    besides of error messages generally being very ephemeral, which is maybe not what we want for IM-NG.

  259. dwd

    Ge0rG, We won't need errors in IM-NG, though, because everything will always work flawlessly.

  260. Ge0rG

    dwd: that is the MIX mindset.

  261. dwd

    Ge0rG, Every message will eb acrried to its desitnation personally by the magic unicorns riding fairies.

  262. dwd

    Ge0rG, And the stars! Oh, my the stars. They will be so pretty in IM-NG.

  263. Ge0rG

    why should unicorns ride fairies?

  264. dwd

    Ge0rG, IM-NG. It's just like that.

  265. Ge0rG

    are those rainbow-pooping unicorns?

  266. Ge0rG

    What is the amount of recreational drugs imported to the island, currently? Will there be a sensible Summit after Brexit?

  267. dwd

    Ge0rG, What the unicorns poop is currently under-specified.

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

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

  270. Kev

    The rules themselves do seem reasonable enough to me on review.

  271. Kev

    Ge0rG: ^

  272. Kev

    If we can do that, I'm +1, else I need to think further.

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

  274. jonas’

    Kev, yes, I think that’s sane

  275. jonas’

    I think that’d be the best way forward indeed

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

  277. Kev

    Compromise, and all that :)

  278. Ge0rG

    Shall I amend to the XEP

  279. Kev

    Amend to the XEP?

  280. Ge0rG

    Kev: I mean, shall I add another commit to the PR containing what you suggested?

  281. Ge0rG

    And will that be sufficient to satisfy the other Council members?

  282. Kev

    Works for me, thanks.

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