XMPP Council - 2018-06-07

  1. SamWhited has left

  2. jere has left

  3. Zash has left

  4. jere has joined

  5. jere has left

  6. Dave has left

  7. Dave has left

  8. Dave has left

  9. Dave has left

  10. Dave has left

  11. flow has left

  12. moparisthebest has left

  13. moparisthebest has joined

  14. Lance has joined

  15. Lance has left

  16. jere has joined

  17. moparisthebest has left

  18. moparisthebest has joined

  19. jere has left

  20. Tobias has left

  21. Tobias has joined

  22. Dave has left

  23. Dave has left

  24. jonasw

    you know that I’m not fond of Ephemeral messages, but voting on it based on "it is NTP over XMPP" was incorrect I think. I was unable to find any NTPy thing in there, and the person who suggested that on the ML backed out of that claim.

  25. jonasw

    also, I’d like to see reasons for the other -1s

  26. guus.der.kinderen has left

  27. guus.der.kinderen has left

  28. Kev has left

  29. guus.der.kinderen has left

  30. guus.der.kinderen has left

  31. guus.der.kinderen has joined

  32. Dave has left

  33. guus.der.kinderen has left

  34. Dave has left

  35. flow has joined

  36. Dave has left

  37. Dave

    Well, it's synchronizing timers and things. I'm basically not convinced of the security guarantees it's possible to offer around ephemeral messaging in general, and this seemed a particularly poor (and over complicated) rendition.

  38. jonasw

    it’s not really synchronizing timers. all it does is saying "hey, your client should keep this message for at most N seconds"

  39. jonasw

    there’s no synchronization going on

  40. guus.der.kinderen has left

  41. guus.der.kinderen has left

  42. guus.der.kinderen has left

  43. guus.der.kinderen has left

  44. Kev

    There's synchronisation of what you want the timers to be.

  45. Kev

    There isn't synchronisation of the time.

  46. Kev

    At least, given my reading.

  47. Kev

    But given that I found it very hard to read and extract what it intended people to do, I think that's a fair reason to reject it at the moment.

  48. jonasw

    I disagree. The ability to extract the intent from the text is (in this case, I think) mostly matter of language and structure, and thus editorial. That should not be reason to reject it from going to Experimental.

  49. jonasw

    (as much as I dislike the thing)

  50. flow

    what jonasw said

  51. flow has joined

  52. Kev

    I'm happy for an Editor to try to clear it up so that it's possible to read it sensibly, but as things stand I can't judge the XEP properly because I can't understand what it's trying to do properly.

  53. jonasw

    so we’re going to reject this based on lack of manpower in the editor team, essentially? ;-)

  54. Kev

    I'm fairly sure that once it's clear what it's trying to do it'll be clear that it would be rejected for technical reasons.

  55. Kev

    So no, not really.

  56. jonasw


  57. Kev

    From what I can tell, it's got this overcomplicated and underspecified synchronisation protocol for the expiry values, which seems out of place here.

  58. Kev

    As well as having this weird overlap between "This isn't for security, it's just for hinting" and "Here's all this extra work we're doing to try to guarantee security".

  59. daniel

    i see if i can find some time next week to come up with a protoxep that’s just the hint

  60. jonasw

    this might offend the authors of that XEP

  61. guus.der.kinderen has left

  62. jonasw

    different question: would adding a note which hints to how things were done in the past (clearly marked up as "note" and "things in the past, but still around in some implementations") be editorial?

  63. jonasw

    I’m "asking for a friend" who wants to add such a note to XEP-0045.

  64. guus.der.kinderen has left

  65. Kev

    "It depends" is I think the answer.

  66. Kev

    I'd normally expect editorial changes in a Draft XEP to be typos and grammar corrections and things.

  67. jonasw


  68. jonasw

    gonna make a proper PR instead

  69. jonasw

    there you go: https://github.com/xsf/xeps/pull/664

  70. ralphm has joined

  71. daniel has left

  72. guus.der.kinderen has left

  73. guus.der.kinderen has left

  74. guus.der.kinderen has joined

  75. Dave

    jonasw, You can't possibly be arguing that a XEP that's too badly written for council to understand should be accepted, can you?

  76. jonasw

    Dave, when you put it that way it sounds horrible.

  77. jonasw

    I don’t think though that it’s impossible to understand and that it can be fixed

  78. Dave

    So you're agreeing it can't be fixed, then? ;-)

  79. jonasw


  80. jonasw

    lanugage is hard

  81. jonasw

    it can be fixed I mean

  82. Dave

    ^^ irony.

  83. jonasw


  84. Dave

    The thing is, I don't believe one can design something that gives a message an expiry for security reasons in an open interoperable way. To get those guarantees, you need restrictions on the server and clients that are unprovable.

  85. jonasw


  86. jonasw

    but isn’t it worthwhile to have a common way to do this, even if it only makes sense in specialised deployments?

  87. jonasw

    that would reduce the setup/development cost for those deployments.

  88. Kev

    Maybe, yes, but I think most of what's in the XEP is trying and failing to get security guarantees it can't achieve.

  89. daniel

    Dave: but arguably it is still valuable to have it standardized and then get library support so people who are using xmpp in closed environments (which I guess is the majority of people) have working solution ready

  90. Kev


  91. Dave

    I live in "specialised deployments", so I appreciate the sentiment. We hgave XEPs for adding classifications etc to messaging, for example. I'm all in favour of that. But those cases still provide guarantees outside of those environments. I'd be worried about the implication, so I'd want - from the outset - a clear scope on such a XEP.

  92. Kev

    But I'm not convinced that /this/ document is the way we would choose to standardise it for closed environments either.

  93. Dave

    Kev, +1 there.

  94. daniel

    Kev: no it's not

  95. jonasw

    okay fine

  96. jonasw

    now I wish those arguments make it into the council minutes

  97. jonasw

    because having "it does NTP" as rejection reason there isn’t great

  98. daniel

    also i think one has to use signal to understand what a timer setting update is

  99. daniel

    because i dont

  100. daniel

    i mean i get that you annotate each message with a burner. but why do you need to send updates?

  101. daniel

    and what does it update?

  102. jonasw

    the update is intended to make sure that the other side will use the new timer value on their next message

  103. jonasw

    i.e.: A and B have agreed on timer value X A wants to use timer value Y, so sends timer update B sends their next message with timer value Y

  104. flow

    FWIW I assumed timer updates to sync all devices a a user

  105. jonasw

    ah, other devices of the same user, too

  106. daniel

    ok. a) weirdly i have never been requested to implement this feature b) arguably it should use different syntax then

  107. daniel

    is this only signal that does this? where my contact can dictate the timeout message?

  108. jonasw

    I really wonder what type of people use this feature.

  109. jonasw

    (well, except people who really, truely need things like that)

  110. daniel

    that seems a bit dangerous. so if i'm just in the process of sending a password or other delicate information my contact increases the time out from 60s to 5 years

  111. jonasw

    good point

  112. pep.

    But this is not a security feature after all so I shouldn't really on this to hide a password right. Or is it still in the context of closed environments

  113. jonasw

    I think the latter, pep.

  114. Kev

    That's the confusion. It's both trying not to be a security document, and also trying to be a security document.

  115. daniel

    no it’s a just a hint; so in case of passwords it's like here i'm sending you information which you should copy paste into your password manager and then delete from the devices history

  116. daniel

    and arguably it is doing that job

  117. daniel

    (speaking about burner messages in general now. not that particular xep)

  118. pep.

    daniel, burner messages as in "marking messages as [sensitive/private]"?

  119. daniel

    no burner messages as in 'hey it's a good idea to delete that message after you mentally or (otherwise) processed that information

  120. daniel

    a friendly reminder between friends

  121. pep.


  122. daniel

    a friendly reminder between friends is also what i'm going to call the XEP

  123. daniel

    so there wont be any confusion

  124. pep.

    err, s/really/rely in a previous sentence

  125. Dave

    pep., Marking messages as sensitive/private is already covered by XEP-0258, incidentally.

  126. pep.

    I see

  127. vanitasvitae has left

  128. moparisthebest has joined

  129. daniel has left

  130. guus.der.kinderen has left

  131. guus.der.kinderen has left

  132. guus.der.kinderen has left

  133. guus.der.kinderen has left

  134. daniel has left

  135. daniel has joined

  136. vanitasvitae has left

  137. jere has joined

  138. guus.der.kinderen has left

  139. moparisthebest has joined

  140. SamWhited has left

  141. jere has left

  142. SamWhited has left

  143. jere has joined

  144. Kev has left

  145. guus.der.kinderen has left

  146. guus.der.kinderen has left

  147. Holger has left

  148. moparisthebest has left

  149. guus.der.kinderen has left

  150. guus.der.kinderen has left

  151. guus.der.kinderen has joined

  152. guus.der.kinderen has left

  153. guus.der.kinderen has left

  154. guus.der.kinderen has joined

  155. guus.der.kinderen has left

  156. daniel has left

  157. daniel has joined

  158. guus.der.kinderen has left

  159. guus.der.kinderen has left

  160. daniel has left

  161. daniel has joined

  162. guus.der.kinderen has left

  163. Lance has joined

  164. Lance has joined

  165. SamWhited has left

  166. guus.der.kinderen has left

  167. guus.der.kinderen has left

  168. vanitasvitae has left

  169. Tobias has joined

  170. Tobias has joined

  171. Zash has left

  172. Zash has left

  173. Zash has joined

  174. Lance has joined

  175. Tobias has left

  176. Tobias has joined

  177. Lance has joined

  178. Kev has left

  179. Kev has left

  180. Zash has left

  181. Tobias has left

  182. Tobias has joined

  183. Lance has joined

  184. Lance has joined

  185. Tobias has left

  186. Tobias has joined

  187. Dave has left

  188. guus.der.kinderen has left

  189. guus.der.kinderen has left

  190. guus.der.kinderen has joined

  191. SamWhited has left

  192. Dave has left

  193. Dave has left

  194. bear has left

  195. bear has joined

  196. SamWhited has left

  197. guus.der.kinderen has left

  198. Tobias has left

  199. Tobias has joined

  200. Tobias has joined

  201. Tobias has joined

  202. Tobias has joined

  203. Tobias has joined

  204. Kev has joined

  205. jere has joined

  206. Tobias has joined

  207. Dave has left

  208. Dave has left

  209. Dave has left

  210. guus.der.kinderen has left

  211. daniel has left

  212. daniel has joined

  213. SouL has left

  214. Dave has left

  215. Dave has left

  216. jere has joined

  217. Dave has left

  218. Dave has left

  219. moparisthebest has left

  220. jere has left

  221. Dave has left

  222. Dave has left

  223. Dave has left