XMPP Council - 2020-01-08


  1. susmit88 has left

  2. Kev_ has left

  3. Kev has joined

  4. beta has left

  5. beta has joined

  6. stpeter has left

  7. beta has left

  8. debacle has left

  9. stpeter has joined

  10. Kev has left

  11. Kev has joined

  12. paul has left

  13. stpeter has left

  14. stpeter has joined

  15. beta has joined

  16. beta has left

  17. beta has joined

  18. daniel has left

  19. beta has left

  20. daniel has joined

  21. daniel has left

  22. beta has joined

  23. daniel has joined

  24. beta has left

  25. beta has joined

  26. beta has left

  27. vaulor has left

  28. vaulor has joined

  29. stpeter has left

  30. beta has joined

  31. beta has left

  32. Kev has left

  33. Kev has joined

  34. beta has joined

  35. Kev_ has joined

  36. Tobias has joined

  37. paul has joined

  38. beta has left

  39. beta has joined

  40. beta has left

  41. sonny has left

  42. sonny has joined

  43. sonny has left

  44. sonny has joined

  45. Kev_ has left

  46. Kev_ has joined

  47. sonny has left

  48. sonny has joined

  49. sonny has left

  50. sonny has joined

  51. beta has joined

  52. sonny has left

  53. sonny has joined

  54. beta has left

  55. sonny has left

  56. sonny has joined

  57. vaulor has left

  58. vaulor has joined

  59. sonny has left

  60. susmit88 has joined

  61. vanitasvitae has left

  62. beta has joined

  63. sonny has joined

  64. paul has left

  65. paul has joined

  66. susmit88 has left

  67. vanitasvitae has joined

  68. susmit88 has joined

  69. beta has left

  70. beta has joined

  71. susmit88 has left

  72. susmit88 has joined

  73. sonny has left

  74. sonny has joined

  75. undefined has left

  76. undefined has joined

  77. sonny has left

  78. sonny has joined

  79. susmit88 has left

  80. susmit88 has joined

  81. sonny has left

  82. sonny has joined

  83. beta has left

  84. beta has joined

  85. larma has left

  86. larma has joined

  87. daniel has left

  88. daniel has joined

  89. daniel has left

  90. daniel has joined

  91. daniel has left

  92. daniel has joined

  93. daniel has left

  94. daniel has joined

  95. daniel has left

  96. daniel has joined

  97. susmit88 has left

  98. susmit88 has joined

  99. susmit88 has left

  100. sonny has left

  101. sonny has joined

  102. beta has left

  103. sonny has left

  104. susmit88 has joined

  105. sonny has joined

  106. Wojtek has joined

  107. susmit88 has left

  108. susmit88 has joined

  109. sonny has left

  110. sonny has joined

  111. larma has left

  112. sonny has left

  113. larma has joined

  114. beta has joined

  115. sonny has joined

  116. Max has left

  117. Max has joined

  118. larma has left

  119. larma has joined

  120. sonny has left

  121. beta has left

  122. sonny has joined

  123. beta has joined

  124. sonny has left

  125. beta has left

  126. beta has joined

  127. sonny has joined

  128. susmit88 has left

  129. susmit88 has joined

  130. sonny has left

  131. sonny has joined

  132. susmit88 has left

  133. beta has left

  134. beta has joined

  135. stpeter has joined

  136. stpeter has left

  137. beta has left

  138. debacle has joined

  139. beta has joined

  140. sonny has left

  141. sonny has joined

  142. sonny has left

  143. Wojtek has left

  144. sonny has joined

  145. Wojtek has joined

  146. beta has left

  147. beta has joined

  148. stpeter has joined

  149. jonas’

    ’tis time

  150. jonas’

    Let’s get started.

  151. jonas’

    1) Roll Call

  152. jonas’ obviously

  153. dwd

    Me!

  154. daniel

    hi

  155. Zash

    hello

  156. ralphm waves

  157. jonas’

    (I’m also going to implement a 1 minute timeout in this session. Unfortunately, my client doesn’t show typing notifications, so if you need more time to write a reply to an open question like "Anything else?", please send a dot or something first.)

  158. jonas’

    that’s a quorum

  159. jonas’

    2) Agenda Bashing

  160. pep.

    (here too.)

  161. jonas’

    we’ve got a ProtoXEP and the OMEMO thing on the list, is there anything I missed?

  162. larma

    also here if needed

  163. jonas’

    Alright, moving on 3) Items for a vote

  164. jonas’

    3a) Proposed XMPP Extension: Special Interests Group End to End Encryption URL: https://xmpp.org/extensions/inbox/sige2ee.html Abstract: This document proposes the formation of a Special Interest Group (SIG) within the XSF devoted to the development of end-to-end encryption within the context of XMPP.

  165. jonas’

    3a) Proposed XMPP Extension: Special Interests Group End to End Encryption URL: https://xmpp.org/extensions/inbox/sige2ee.html Abstract: This document proposes the formation of a Special Interest Group (SIG) within the XSF devoted to the development of end-to-end encryption within the context of XMPP.

  166. jonas’

    so first of all, it turns out that SIG formations/proposals have their own XEP type, so that’ll have to be adjusted by the editor

  167. Zash

    And this is approved by Council?

  168. jonas’

    yes

  169. pep.

    (I wasn't entirely sure about that, and I didn't take the time to look it up properly)

  170. jonas’

    > A Special Interest Group (SIG) is a working group approved by the XMPP Council to address specific areas of growth or concern within the Jabber/XMPP developer community, usually by means of developing and publishing XMPP Extension Protocols (XEPs).

  171. jonas’

    https://xmpp.org/extensions/xep-0002.html

  172. jonas’

    nobody knew, which is why we didn’t vote on this last week

  173. dwd

    Generally in favour. I had some comments around the second bullet point, but assuming this goes to Experimental before a LC and Active, I'm +1

  174. ralphm

    Also noted in our Bylaws

  175. jonas’

    I’m not sure if this is supposed to be a SIG Formation or a SIG Proposal

  176. ralphm

    Section 8.2

  177. jonas’

    I’m going to be on-list, because the procedure is unclear to me

  178. jonas’

    anyone else who wants to cast votes in this meeting?

  179. Ge0rG

    Hi! Sorry for being late.

  180. ralphm

    jonas’, which part is unclear?

  181. dwd

    I did cast a vote.

  182. jonas’

    ralphm, - Is this a SIG Proposal or a SIG Formation? - If SIG Formation, does the XEP need to specify who is part of the SIG leadership? If not, where is this recorded? - Is it even legitimate for a SIG to be open for non-XSF members? (It isn’t for SIG leadership)

  183. Ge0rG

    3a( +1

  184. jonas’

    ralphm, but I think this isn’t the right venue to figure this out, since all of this should be documented somewhere I can read it. If I’m missing info, I’ll probably head to other council members or board as required.

  185. daniel

    sorry i haven’t had time to read the final draft; i assuming that i'm going to be +1 ; but on list for now

  186. ralphm

    SIGs are open by nature, however, its leaders must be members

  187. dwd

    I would assume a SIG Proposal, and needs to be Active for a Formation.

  188. pep.

    §8.2 of the bylaws says: "Because a SIG is an open forum, participation in a SIG shall not be limited to elected Members of the Corporation, and shall be open to any interested individual. Leadership and direction for a SIG shall be provided by the members (and in particular by the Chair) of the relevant XSF Work Team or the XMPP Council."

  189. jonas’

    dwd, things in the past have used SIG Proposal and SIG Formation type of XEPs

  190. dwd

    jonas’, Oh.

  191. jonas’

    dwd, see, it’s complicated, and I don’t want to waste time in this meeting while I read up on things :)

  192. jonas’

    I expect the next point to be more contentious.

  193. jonas’

    3b) Do something about the OMEMO XEP Dave suggested that we try to get OMEMO into Rejected state (which may meean moving it via Proposed or asking Board for assistance).

  194. jonas’

    dwd, do you want to summarise what this is about?

  195. dwd

    I think we have already, but it's not clear that OMEMO can (or, possibly, should) be made Draft.

  196. dwd

    The "can" relates to whether OMEMO can be implemented without the use of a GPL library. There are people arguing both ways on this.

  197. jonas’

    dwd, though that’s not a strict requirement for Draft, is it?

  198. dwd

    jonas’, https://xmpp.org/extensions/xep-0001.html#objectives argues otherwise, since GPL would could as an "encumberance".

  199. Zash

    Can you implement it based on only specifications or not?

  200. ralphm

    As stated on list, I believe that in its current form, this XEP violates Objective 4 of XEP-0001, and can therefore not move forward.

  201. jonas’

    right, true

  202. dwd

    Any particular license would, in fact.

  203. dwd

    Zash, I have been told both yes and no.

  204. Zash

    Ugh

  205. jonas’

    so, I think the ambiguity alone is sufficent

  206. pep.

    Sufficient to do what?

  207. ralphm

    Indeed, the (legal) ambiguity alone is an "encumbrance".

  208. jonas’

    while normally we don’t require proof (except in form of the IPR) that a protocol is not under any restrictive license, the uncertainty about the signal protocol requires extra proof to let this move forward, IMO

  209. dwd

    I mean, absolutely not right now, because the specification doesn't reference the libsignal docs. Whether the libsignal docs are sufficient to implement a non-GPL clone of libsignal is the ambiguous question.

  210. jonas’

    and the proof might be hard to bring, since I feel that this is a grey area of copyright law (akin to the still-ongoing API debate between google and oracle) which needs to be fought out over courts, and that’s not a good standing for an open standard

  211. larma

    OMEMO lacks a lot of specification / documentation and that is a reason to not move it to Draft. Unfortunately so far, nobody ever tried to gather a conclusive list of what is missing (because everyone just uses libsignal)

  212. jonas’

    (and this is all in addition to the issues with the "shady" practices around this XEP)

  213. Zash

    copyright lawyering doesn't sound like a job for Council :|

  214. ralphm

    It doesn't.

  215. dwd

    larma, I know of at least one effort to make a non-GPL client using OMEMO failed with the author deciding it wasn't possible given available information. I know of other people who claim it is, but there is very little evidence either way.

  216. larma

    dwd, can you point me their? would like to read/hear reasoning

  217. jonas’

    so my concrete suggestion would be to: - Change XEP-0384 to historical type and lock it update-wise - If the community wants to pursue signal-ish E2EE under the umbrella of the XSF, they need to provide a proper (and I think this time we should require "as few references as possible") document to describe how to do it from basic principles

  218. jonas’

    And on the long-term, we should probably pursue MLS

  219. debacle has left

  220. ralphm

    If an actual protocol specifications would exist, we could point to it, and would have a lot less discussion on hypotheticals. Also, prior legal posturing by the Signal authors doesn't help this situation.

  221. Zash

    jonas’: sounds sensible

  222. jonas’

    we probably need Boards OK for changing a XEP type after acceptance

  223. dwd

    ralphm, Do we need Board here?

  224. Zash

    Wasn't the current version meant to be what amounts to Historical anyways?

  225. larma

    jonas’, I think everyone is happy with longterm MLS replacing OMEMO

  226. jonas’

    larma, that’s at least something

  227. Ge0rG

    don't we have a SIG for that?

  228. ralphm

    I'm not sure how changing to historical is addressing the concern.

  229. jonas’

    Ge0rG, not yet

  230. pep.

    And SIGs don't have that authority do they

  231. Ge0rG

    would it make sense to postpone those hairy questions for the SIG?

  232. jonas’

    Ge0rG, I’d rather not until it is clear to me how SIG leadership works.

  233. daniel

    > Wasn't the current version meant to be what amounts to Historical anyways? iirc that was the intent; but was deemed impossible to switch tracks

  234. jonas’

    ralphm, https://xmpp.org/extensions/xep-0001.html#types-Historical I think historical (while you need to stretch the definition of "before" a bit) fits this quite nicely and would be loopholey enough to look in a different direction when someone talks about objective #4

  235. jonas’

    (to me anyways)

  236. ralphm

    dwd: I think the Editor can change the type at the instruction of Council as long as Council remains its approving body.

  237. ralphm

    SIGs don't have any authority, in principle.

  238. ralphm

    jonas’, I think this spec doesn't meet the definition of historical, and as I mentioned above, I'm not sure how it addresses Objective 4.

  239. dwd

    Speaking of Board and remits and so on, it may be that violating Objectives is something that only Board can decide anyway, which neatly makes it someone else's problem.

  240. jonas’

    ralphm, my point being: It is clearly unfit for Standards Track, mainly for the license reason. However, it’s worthwhile to document what’s currently going on in the XMPP ecosystem. Especially in the case of OMEMO, which is a PITA when you don’t have it.

  241. Zash

    I'd happily +1 shuffling this over to Board :)

  242. jonas’

    It doesn’t 100% fit the definition of Historical, but if we want to have this still as a XEP (and I think we should), Historical is probably the best place. Informational may work too, but only if Informational has some type of Deprecated state

  243. jonas’

    it does, so I’d also be fine with Informational+Deprecated

  244. ralphm

    Council itself can perfectly decide on what violates the objectives on its own.

  245. Zash

    I wouldn't oppose tweaking the definition of Historical

  246. jonas’

    (we’re heading towards the magic :30 mark, and I have a quick AOB, so I’ll terminate this discussion at about :27)

  247. ralphm

    I would object to tweaking our process just to accomodate the fact that people want to have a specification like OMEMO

  248. daniel

    yeah i also like 'historical' (mostly for what jonas’ said)

  249. dwd

    I'd be fine with any status that does not make any suggestion that this is a recommended protocol by the XSF.

  250. Ge0rG

    I'm fine with either Historical or Informational+Deprecated, with a slight preference to the former.

  251. Ge0rG

    Maybe we also need a blog post explaining the rationale.

  252. ralphm

    IMO, you can 1) decide to not move it forward until the objective is met, e.g. by switching back to the previous protocol or forward to MLS, 2) dismiss the XEP is unacceptable.

  253. jonas’

    Ge0rG, I think daniel volunteered to do that last week

  254. daniel

    (and again; historical was i believe my original preference before we put in the siacs namespaces; however that wasn’t possible and thus we ended up with the 'compromise' that we have now)

  255. jonas’

    I propose we instruct the Editor to create a patch which: - Moves to Informational - Changes to Deprecated - Adds necessary rewording to make it clear that this is an embedding of the Signal protocol and not a generally preferred and open E2EE scheme

  256. ralphm

    My opinion is that both historical and informational+deprecated don't carry the right message.

  257. pep.

    I'm not entirely fine with Deprecated while we don't have a replacement

  258. pep.

    Informational is probably ok

  259. Zash

    ralphm: Rejected?

  260. ralphm

    Yes

  261. pep.

    (nor Rejected)

  262. jonas’

    Rejected would work too for me

  263. jonas’

    though technically rejected would have to go through Proposed

  264. Ge0rG

    I have a feeling that either change will cause contention outside of the XSF membership

  265. ralphm

    arguably dwd proposed it to be rejected, so there's that

  266. pep.

    What's the message we're sending doing this?

  267. jonas’

    okay, instead of a vote, can we have a quick show of hands from council members: Do you agree that OMEMO as it stands currently should be demoted from its current position and put in a dead end?

  268. Zash

    pep.: "This isn't the Right Way"

  269. jonas’

    (if we agree on this, we can figure out the specifics later)

  270. daniel

    > What's the message we're sending doing this? that the xsf doesn’t care about e2ee

  271. ralphm

    pep., that we don't base our standards on libraries

  272. pep.

    daniel, that, exactly

  273. dwd

    I'm actually fine with putting it through a Last Call, which would then allow us to declare it counter to the objectives and then Rejected.

  274. Ge0rG

    that the xsf is hostile towards E2EE

  275. daniel

    (not objecting the proposed changes; but that is the message)

  276. pep.

    If you're all fine with this then good for you. I'm not

  277. Zash

    The XSF likes surveilance!!!11!1eleven /s

  278. ralphm

    In the same blog post, you could mention that we (Dave and I) have reached out to the MLS WG to offer our assistence.

  279. pep.

    ralphm, so it's ready in 5 years instead of 10?

  280. Ge0rG

    jonas’: +1 on the general demotion

  281. pep.

    And in implementations in ~7

  282. larma

    if you put it to last call, please make the last call more than 2 weeks so that people have the time to extend the specification to make the whole reason to reject it invalid

  283. Zash

    jonas’: hand

  284. ralphm

    pep., this is not a great argument. Have you even looked at what's there?

  285. jonas’

    larma, that sohuld happen BEFORE last call

  286. jonas’

    the XEP has been inactive for a looong while

  287. Ge0rG

    ..in the last year or so, actually

  288. jonas’

    okay, we’re running out of time

  289. jonas’

    I see that this clearly needs more discussion. I encourage you to take it to the list or to xsf@.

  290. dwd

    "hand", BTW.

  291. larma

    jonas’, yes, it didn't happen, I agree, but what do we do with all the other XEPs that are not maintained?

  292. pep.

    ralphm, it's not even a XEP yet. is there even an implementation outside of XMPP at all (that works with proper chat solutions).

  293. jonas’

    4) Date of next

  294. jonas’

    +1w wfm

  295. pep.

    The XSF is not really a symbol of swiftness

  296. jonas’

    pep., please, outside of this meeting

  297. dwd

    jonas’, +1

  298. pep.

    k

  299. ralphm

    pep. indeed swiftness is not a goal, you may disagree, of course

  300. Zash

    jonas’: +1 +1w

  301. Ge0rG

    I might be in an overrunning meeting in +1W, so I excuse myself in advance

  302. jonas’

    alright

  303. jonas’

    5) AOB

  304. jonas’

    5a) Editor Mishap Report

  305. jonas’

    I accidentally merged https://github.com/xsf/xeps/pull/870 which should’ve been Needs Author. I reverted the change just before the meeting and published Version 0.4.0 without the changes from #870

  306. jonas’

    this is mostly an FYI

  307. jonas’

    (changing the existing version would be confusing and cover-up-ish, so I decided to instead publish a new one)

  308. Ge0rG

    related to this, the author asked for XSF / Council feedback on the proposed change.

  309. Zash

    Ack.

  310. jonas’

    also, what Ge0rG says.

  311. jonas’

    Ge0rG, can you please re-do your MR on top of current master?

  312. dwd

    Seems like a good fix.

  313. jonas’

    should be as simple as a cherry pick

  314. jonas’

    then you can post to list asking for feedback

  315. Ge0rG

    Alright, I'll try to do it when I have some more time

  316. jonas’

    Ge0rG, thanks

  317. jonas’

    and since we’re already over time

  318. jonas’

    6) Ite Meeting Est

  319. jonas’

    Thanks everyone

  320. jonas’

    please carry any further technical or procedural discussion about OMEMO to xsf@, where more stakeholders are present and which is more discoverable to the community in general

  321. dwd

    Thanks jonas’!

  322. Zash

    Thanks jonas’

  323. Max has left

  324. Max has joined

  325. flow

    Ge0rG> Maybe we also need a blog post explaining the rationale. A disclaimer, potentially linking to the blog post, in xep-omemo would probably be also a good idea

  326. jonas’

    flow, -> xsf@

  327. jonas’

    (where I already proposed that)

  328. sonny has left

  329. sonny has joined

  330. debacle has joined

  331. Tobias has left

  332. Tobias has joined

  333. Tobias has left

  334. Tobias has joined

  335. sonny has left

  336. sonny has joined

  337. Wojtek has left

  338. sonny has left

  339. sonny has joined

  340. debacle has left

  341. sonny has left

  342. vaulor has left

  343. vaulor has joined

  344. sonny has joined

  345. sonny has left

  346. sonny has joined

  347. sonny has left

  348. sonny has joined

  349. undefined has left

  350. undefined has joined

  351. sonny has left

  352. sonny has joined

  353. sonny has left

  354. sonny has joined

  355. sonny has left

  356. sonny has joined

  357. Tobias has left

  358. Zash has left

  359. debacle has joined

  360. moparisthebest has left

  361. daniel has left

  362. daniel has joined

  363. daniel has left

  364. moparisthebest has joined

  365. moparisthebest has left

  366. moparisthebest has joined

  367. paul has left

  368. daniel has joined