XMPP Council - 2019-06-05


  1. Wojtek has joined

  2. Wojtek has left

  3. Wojtek has joined

  4. Wojtek has left

  5. Zash has left

  6. Zash has joined

  7. debacle has joined

  8. debacle has left

  9. debacle has joined

  10. Remko has joined

  11. lnj has joined

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

  13. Ge0rG

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

  14. Ge0rG

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

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

  16. dwd

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

  17. jonas’

    summer?

  18. dwd

    Possibly.

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

  20. jonas’

    'tis time

  21. jonas’

    dwd, Ge0rG, Kev?

  22. Kev

    Kinda.

  23. Link Mauve

    Hi.

  24. jonas’

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

  25. dwd

    Ooops. Distracted, sorry.,

  26. dwd

    1) Roll Call.

  27. jonas’

  28. Ge0rG

    Yes.

  29. dwd

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

  30. dwd

    2) Agenda Bashing.

  31. Ge0rG got two AOBs

  32. dwd

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

  33. jonas’

    I got nothing

  34. dwd

    As do I.

  35. dwd

    3) No Items For A Vote.

  36. dwd

    4) Outstanding Votes

  37. Ge0rG

    Link Mauve is outstanding

  38. dwd

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

  39. dwd

    Link Mauve, Could you look into that please.

  40. Link Mauve

    Yes.

  41. dwd

    5) Next Meeting

  42. jonas’

    +1w wfm

  43. dwd

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

  44. Ge0rG

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

  45. jonas’

    Ge0rG, will you be able to vote on list?

  46. Link Mauve

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

  47. Ge0rG

    jonas’: most probably yes

  48. jonas’

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

  49. dwd

    Cool.

  50. Link Mauve

    Indeed. ^^'

  51. dwd

    6) AOB

  52. dwd

    Ge0rG, You first.

  53. Ge0rG

    Thank you very much, dwd

  54. Ge0rG

    6a) Handling of ephemeral messages for offline users

  55. jonas’

    oh dear

  56. jonas’

    that sounds like yet another can of worms :)

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

  58. Ge0rG

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

  59. jonas’

    I think that behaviour is sane

  60. Ge0rG

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

  61. Ge0rG

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

  62. dwd

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

  63. jonas’

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

  64. dwd

    Ge0rG, Since I think it relates.

  65. Ge0rG

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

  66. Ge0rG

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

  67. jonas’

    does it?

  68. jonas’

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

  69. Ge0rG

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

  70. jonas’

    as it saves tracking

  71. Ge0rG

    jonas’: ejabberd does so

  72. dwd

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

  73. Ge0rG

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

  74. dwd

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

  75. Ge0rG

    because there is no benefit in those errors

  76. jonas’

    didn’t we agree that OTR was ephemeral?

  77. Link Mauve

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

  78. jonas’

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

  79. dwd

    Link Mauve, Yes indeed.

  80. Ge0rG

    dwd: I'd say drop

  81. dwd

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

  82. Ge0rG

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

  83. Kev

    Receipts aren't ephemeral.

  84. Ge0rG

    dwd: what Kev said

  85. jonas’

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

  86. dwd

    Ah, indeed.

  87. jonas’

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

  88. Ge0rG

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

  89. dwd

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

  90. jonas’

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

  91. Ge0rG

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

  92. Ge0rG

    dwd: do we?

  93. Kev

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

  94. dwd

    Ge0rG, Probably. We have evertything else.

  95. jonas’

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

  96. Kev

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

  97. Ge0rG

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

  98. jonas’

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

  99. Ge0rG

    jonas’: that's a good point

  100. jonas’

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

  101. Ge0rG

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

  102. jonas’

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

  103. dwd

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

  104. jonas’

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

  105. Ge0rG

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

  106. Ge0rG

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

  107. Kev

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

  108. jonas’

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

  109. Ge0rG

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

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

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

  112. dwd

    And I think Ge0rG had another item?

  113. Ge0rG

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

  114. jonas’

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

  115. dwd

    Ge0rG, Yeah, I have two small ones.

  116. Ge0rG

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

  117. jonas’

    Ge0rG, I’m not ;)

  118. Ge0rG

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

  119. dwd

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

  120. Ge0rG

    dwd: feel free to go on then.

  121. jonas’

    dwd, sounds like a good plan

  122. Ge0rG

    I propose XEP-0280!

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

  124. jonas’

    dwd, sounds like a plan again

  125. dwd

    Thanks.

  126. Link Mauve

    Yup, agreed!

  127. Kev

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

  128. dwd

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

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

  130. dwd

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

  131. dwd

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

  132. Kev

    What's the 30 second summary of the properties?

  133. jonas’

    OMEMO

  134. Kev

    Oh, as bad as that?

  135. Ge0rG

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

  136. jonas’

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

  137. dwd

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

  138. Kev

    Good start.

  139. dwd

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

  140. Ge0rG

    That sounds like a sensible approach

  141. dwd

    Kev, Standardized encrypted form syntax and concepts.

  142. dwd

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

  143. Ge0rG

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

  144. dwd

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

  145. moparisthebest

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

  146. Ge0rG

    moparisthebest: different parts of the govt

  147. Ge0rG

    dwd: I think I can

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

  149. dwd

    Ge0rG, Go for it.

  150. Ge0rG

    6d) weird interations of 0198 and 0357

  151. dwd edits "interactions".

  152. Ge0rG

    *interactions, obviously.

  153. Ge0rG

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

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

  155. jonas’

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

  156. Ge0rG

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

  157. jonas’

    (I have to leave in 3min)

  158. jonas’

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

  159. 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,

  160. 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@?)

  161. Ge0rG

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

  162. Link Mauve

    So there is also 0352 being involved?

  163. jonas’

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

  164. jonas’

    especially mobile

  165. jonas’

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

  166. Ge0rG

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

  167. jonas’

    is it?

  168. Ge0rG

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

  169. dwd

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

  170. jonas’

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

  171. dwd

    7) Ite, Meeting Est.

  172. dwd

    Thanks all.

  173. jonas’

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

  174. jonas’

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

  175. jonas’

    gotta run now :)

  176. Link Mauve

    So +3W for the next meeting?

  177. Ge0rG

    Link Mauve: +1W without Ge0rG I think

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

  179. Ge0rG

    dwd: that's an interesting PoV, yeah

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

  181. dwd

    <=1 or >=1, after all.

  182. Ge0rG

    this is a solvable problem

  183. Ge0rG

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

  184. Wojtek has joined

  185. Wojtek has left

  186. Kev_ has left

  187. ivucica has left

  188. ivucica has joined

  189. dwd has left

  190. dwd has joined

  191. Zash has left

  192. Zash has joined

  193. ivucica has left

  194. ivucica has joined

  195. debacle has left

  196. Remko has left

  197. debacle has joined

  198. Wojtek has joined

  199. dwd has left

  200. dwd has joined

  201. Wojtek has left

  202. lnj has left

  203. dwd has left

  204. dwd has joined

  205. dwd has left

  206. dwd has joined

  207. debacle has left

  208. dwd has left

  209. dwd has joined

  210. dwd has left

  211. dwd has joined