XMPP Council - 2019-06-05


  1. Kev

    I'm in meetings that won't end, don't know if I'll be around for Council. Although I don't think we have Agendums anyway.

  2. Ge0rG

    I've had two AOB-style points where I'd like to hear The Voices Of The Elders

  3. Ge0rG

    but those can be fitted into the mail-to-standards@ format as well

  4. dwd

    Same situation as last week in respect of nothing I can find for the agenda, BTW, but I'd like to hold the meeting anyway for form's sake.

  5. dwd

    And because I wanted to know why we've had nothing at all for two weeks.

  6. jonas’

    summer?

  7. dwd

    Possibly.

  8. Ge0rG

    I'd also like to have a Meeting today, even if only to officially announce that I'm absent for the next two Wednesdays

  9. jonas’

    'tis time

  10. jonas’

    dwd, Ge0rG, Kev?

  11. Kev

    Kinda.

  12. Link Mauve

    Hi.

  13. jonas’

    I’d like to mention that I have a hard deadline on 15:30Z

  14. dwd

    Ooops. Distracted, sorry.,

  15. dwd

    1) Roll Call.

  16. jonas’

  17. Ge0rG

    Yes.

  18. dwd

    Everyone here, by the looks of things, assuming Ge0rG is still about.

  19. dwd

    2) Agenda Bashing.

  20. Ge0rG got two AOBs

  21. dwd

    I saw nothing for the agenda, but I note that Georg wanted to say some things in AOB.

  22. jonas’

    I got nothing

  23. dwd

    As do I.

  24. dwd

    3) No Items For A Vote.

  25. dwd

    4) Outstanding Votes

  26. Ge0rG

    Link Mauve is outstanding

  27. dwd

    I think Link Mauve has one last chance for his which expires today?

  28. dwd

    Link Mauve, Could you look into that please.

  29. Link Mauve

    Yes.

  30. dwd

    5) Next Meeting

  31. jonas’

    +1w wfm

  32. dwd

    Next week - Ge0rG is going to be absent, any other apologies?

  33. Ge0rG

    probably +3W for me, but I somehow managed to sneak in the last two times where I was Officially Absent

  34. jonas’

    Ge0rG, will you be able to vote on list?

  35. Link Mauve

    Err, the only pending vote I have is on a PR of mine, for which I’m obviously +1.

  36. Ge0rG

    jonas’: most probably yes

  37. jonas’

    Link Mauve, you wouldn’t be the first (not even in this period I thik) to veto your own PR.

  38. dwd

    Cool.

  39. Link Mauve

    Indeed. ^^'

  40. dwd

    6) AOB

  41. dwd

    Ge0rG, You first.

  42. Ge0rG

    Thank you very much, dwd

  43. Ge0rG

    6a) Handling of ephemeral messages for offline users

  44. jonas’

    oh dear

  45. jonas’

    that sounds like yet another can of worms :)

  46. Ge0rG

    The latest and greatest ejabberd will only accept messages to offline users if those messages will be stored in offline storage / MAM, and will reject otherwise

  47. Ge0rG

    this leads to massive spam of errors when you send CSNs to an offline contact

  48. jonas’

    I think that behaviour is sane

  49. Ge0rG

    Holger said that this is strict following of the RFC and of https://xmpp.org/extensions/xep-0160.html

  50. Ge0rG

    I think that it's not very helpful to bounce ephemeral messages, and even less helpful for the sending entity

  51. dwd

    Ge0rG, I'd really appreciate that being raised in the Inbox thread I started.

  52. jonas’

    I think the sending entity needs to deal with errors to ephemeral messages sensibly

  53. dwd

    Ge0rG, Since I think it relates.

  54. Ge0rG

    because now every one of your clients needs to track all in-flight messages

  55. Ge0rG

    dwd: I'm curious as to what link you see

  56. jonas’

    does it?

  57. jonas’

    hm, that’s one of those cases where including the original payload would be very valuable

  58. Ge0rG

    jonas’: ephemeral messages will maybe get carbon-copied. errors... maybe but less probably so.

  59. jonas’

    as it saves tracking

  60. Ge0rG

    jonas’: ejabberd does so

  61. dwd

    Well, I see the general problem of dealing with clients coming on and off-line being connected.

  62. Ge0rG

    I'd rather change 0160 to allow silent dropping of ephemeral messages

  63. dwd

    What does a server do if it doesn't bounce them? Drop, or store-and-forward?

  64. Ge0rG

    because there is no benefit in those errors

  65. jonas’

    didn’t we agree that OTR was ephemeral?

  66. Link Mauve

    dwd, not necessarily, these may also be interested in ephemeral messages.

  67. jonas’

    silently dropping OTR or equivalent would be not-so-great

  68. dwd

    Link Mauve, Yes indeed.

  69. Ge0rG

    dwd: I'd say drop

  70. dwd

    Ge0rG, So for some messages - like CSN - I'd agree. For others, like receipts...

  71. Ge0rG

    jonas’: worse than delivering OTR messages to another client?

  72. Kev

    Receipts aren't ephemeral.

  73. Ge0rG

    dwd: what Kev said

  74. jonas’

    Ge0rG, under IM 2.0, they would not be re-routed

  75. dwd

    Ah, indeed.

  76. jonas’

    Ge0rG, under IM-NG, they would not be re-routed

  77. Ge0rG

    I'd even argue that message errors shouldn't be ephemeral, if they are a bounce of a non-ephemeral message

  78. dwd

    jonas’, Under IM 2.0, we have exactly-once delivery even during network outage, though.

  79. jonas’

    Ge0rG, that would require to include the original payload in the error

  80. Ge0rG

    jonas’: they wouldn't be stored offline either, then

  81. Ge0rG

    dwd: do we?

  82. Kev

    I keep coming back to an idea I hate about this.

  83. dwd

    Ge0rG, Probably. We have evertything else.

  84. jonas’

    which would also help with bouncing ephemeral messages because clients could recognize the errors to belong to an ephemeral message

  85. Kev

    Which is that we need another stanza, or another message type :p

  86. Ge0rG

    dwd: I'm not sure we have per-client offline stores

  87. jonas’

    Ge0rG, re OTR: that’s the point -- they should be reject-ed instead of dropped

  88. Ge0rG

    jonas’: that's a good point

  89. jonas’

    Ge0rG, re OTR: that’s the point -- they should be reject-ed instead of dropped or rerouted

  90. Ge0rG

    jonas’: but I don't think any of the OTR plugins will make effective use of those bounces

  91. jonas’

    so maybe we should amend '160 to require the bouncer to include the orignial payload completely

  92. dwd

    Ge0rG, Do you have enough from The Voices to start a reasoned thread on standards@?

  93. jonas’

    that would give clients the ability to treat bounces of ephemeral messages as such, without having to track them

  94. Ge0rG

    Kev: that's something we could achieve in IM 2.0, right?

  95. Ge0rG

    dwd: I think so, but I lack the time to actually write all that down

  96. Kev

    Ge0rG: It's not inconceivable, but it's more radical than I hope to need.

  97. jonas’

    I’m happy to repeat my own arguments on-list

  98. Ge0rG

    is anybody happy to repeat my arguments on-list? :D

  99. jonas’

    I don’t think another message type is a solution to anything, since it’ll have to interact e.g. with MUC and MUC-PMs properly.

  100. dwd

    OK - who wants to start this thread on standards@? I don't think it's going to get decided in Council without a lot of over-run.

  101. dwd

    And I think Ge0rG had another item?

  102. Ge0rG

    are there any other AOBs? I didn't write down that item and I'm now pondering what it was again.

  103. jonas’

    I don’t want to put words in Ge0rGs mouth, I’d prefer if Ge0rG did it himself.

  104. dwd

    Ge0rG, Yeah, I have two small ones.

  105. Ge0rG

    jonas’: I'm perfectly fine with you putting words in my mouth

  106. jonas’

    Ge0rG, I’m not ;)

  107. Ge0rG

    or maybe just quoting from today's backlog? ;)

  108. dwd

    Small One The First: Given the quiet period, is it worth us looking for any XEPs worth advancing? Perhaps an Experimental.

  109. Ge0rG

    dwd: feel free to go on then.

  110. jonas’

    dwd, sounds like a good plan

  111. Ge0rG

    I propose XEP-0280!

  112. dwd

    Could I ask each of us to find a XEP to advance? Doesn't matter if we pick the same one, but it might be nice to advance some stuff.

  113. jonas’

    dwd, sounds like a plan again

  114. dwd

    Thanks.

  115. Link Mauve

    Yup, agreed!

  116. Kev

    I think just taking the opportunity to have a few lighter weeks makes sense, personally, but I'm flat out, so ...

  117. dwd

    Small One The Second: I note that MLS has reached a stable point in its development.

  118. dwd

    I don't think there's anything we need to do at this stage, though I might look at an MLS/XMPP XEP if I can find the time.

  119. dwd

    Worth noting, though, since it looks very promising indeed.

  120. dwd

    (MLS = Message Layer Encryption, basically an IETF spec for E2EE).

  121. Kev

    What's the 30 second summary of the properties?

  122. jonas’

    OMEMO

  123. Kev

    Oh, as bad as that?

  124. Ge0rG

    MLS might become very interesting in the context of the Germans demanding messenger interop

  125. jonas’

    (I don’t actually know, but it has PFS again)

  126. dwd

    Kev, It's a ratchet-based solution built around groups, not 1:1.

  127. Kev

    Good start.

  128. dwd

    Kev, Post-Compromise, rather than PFS, since it ratchets on demand and on group membership changes, not on every message.

  129. Ge0rG

    That sounds like a sensible approach

  130. dwd

    Kev, Standardized encrypted form syntax and concepts.

  131. dwd

    Kev, Downside is that it blocks server-side archiving as usual, but I had a design that'd work for earlier versions.

  132. Ge0rG

    I've really lost my trust into IETF doing security when they published MTA-STS.

  133. dwd

    So, that's me - Ge0rG, can you recall your second item?

  134. moparisthebest

    MLS wouldn't be adopted by german govt unless it had mandatory backdoors anyway right?

  135. Ge0rG

    moparisthebest: different parts of the govt

  136. Ge0rG

    dwd: I think I can

  137. dwd

    moparisthebest, You can have them if you want, just insert a new member mandatorily on the server. Impossible to do without someone noticing, though, which is a good thing.

  138. dwd

    Ge0rG, Go for it.

  139. Ge0rG

    6d) weird interations of 0198 and 0357

  140. dwd edits "interactions".

  141. Ge0rG

    *interactions, obviously.

  142. Ge0rG

    When a session gets hibernated, and there are unacked stanzas in it, should there be a push notification?

  143. dwd

    Yes, I don't know what the specs say here. But to my mind, a "Maybe Live" 198 disconnected session won't get pushes until some timeout occurs.

  144. jonas’

    sounds like a good thing to me, but I’m not a mobile person

  145. Ge0rG

    This comes from a corner case where yax.im was causing significant battery churn on Monal/iOS, as follows:

  146. jonas’

    (I have to leave in 3min)

  147. jonas’

    (but I’m not a mobile person either, so you might as well continue without me)

  148. Ge0rG

    1. server sends a stanza 2. Monal sends CSI inactive 3. Monal gets background-killed 4. prosody notices the dead socket 5. prosody sends push, wakes up Monal 6. monal connects, sends CSI inactive,

  149. dwd

    Given the time, this sounds absolutely reaosnable. I'm interested in this, but shall we continue for those interested afterward (and maybe in xsf@?)

  150. Ge0rG

    there is no requirement to require an <a> after each stanza, so I'm not doing that on my instance

  151. Link Mauve

    So there is also 0352 being involved?

  152. jonas’

    maybe clients should send a pro-active <a/> when entering CSI-inactive?

  153. jonas’

    especially mobile

  154. jonas’

    to avoid issues with unacked stanzas when they get background-killed

  155. Ge0rG

    jonas’: yes, that's the workaround, but it's racy

  156. jonas’

    is it?

  157. Ge0rG

    jonas’: because they can't send an <a> when they are killed

  158. dwd

    ETIMEDOUT - I'm going to end this meeting, but feel free to stay if you're interested.

  159. jonas’

    if you don’t want to be woken up for a stana, send <a/>

  160. dwd

    7) Ite, Meeting Est.

  161. dwd

    Thanks all.

  162. jonas’

    if you can’t send <a/>, you need to be woken up

  163. jonas’

    even only for the server to be able to release the stanza memory

  164. jonas’

    gotta run now :)

  165. Link Mauve

    So +3W for the next meeting?

  166. Ge0rG

    Link Mauve: +1W without Ge0rG I think

  167. dwd

    Ge0rG, I think we may need to revisit advice on when to send an <r/> - we want to send one any time you want to start a timer, loosely.

  168. Ge0rG

    dwd: that's an interesting PoV, yeah

  169. dwd

    And anytime you get a push notification, or get a traditional offline message (or fish them from MAM), you might get duplicates. It's just going to happen sometimes.

  170. dwd

    <=1 or >=1, after all.

  171. Ge0rG

    this is a solvable problem

  172. Ge0rG

    it's not pretty, but it's straight-forward