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