XMPP Council - 2020-01-15


  1. Ge0rG

    jonas’: I'd like to AOB the 0401 PR

  2. Ge0rG

    But only if I can make it to the meeting, which still isn't ensured

  3. ralphm

    If you propose an item before the meeting, is it really AOB? 🤔

  4. Ge0rG

    ralphm: it's after the agenda announcement, so I have no idea

  5. pep.

    I'd like to bring this PR to council's attention before the meeting: https://github.com/xsf/xeps/pull/878

  6. jonas’

    I don’t see how that new wording makes any sense whatsoever

  7. jonas’

    that’s like saying "That’s not a tree" while pointing at a tree

  8. jonas’

    but I’ll bring it up in the discussion, thanks for reminding me

  9. Zash

    Waiting for a bus, might have high latency during the meeting

  10. Ge0rG

    I'm sitting at a real computer, looking at my XMPP client, and there are no distractions.

  11. Ge0rG

    The only potential problem is my android phone disabling the tethering all the time.

  12. Ge0rG

    Also looks like I was able to catch up with the vote from two weeks ago, just in time

  13. jonas’

    Zash, relevant https://www.youtube.com/watch?v=6CXiB5n883I

  14. jonas’

    ("Waiting for the Bus")

  15. Zash

    https://cerdale.zash.se/upload/uOoLXd1YSjadWCB9/XQrNMK3tQ--tHE9oRwngNg.jpg

  16. Zash

    Snow!

  17. jonas’

    Zash, bring some

  18. jonas’

    we haven’t had any snow yet this winter :(

  19. Ge0rG

    it's 14°C where I am.

  20. Ge0rG

    on the outside, not in the room.

  21. ralphm

    But we still call it "winter".

  22. Ge0rG

    only by convention.

  23. jonas’

    ’tis time

  24. jonas’

    sorry

  25. jonas’

    1) Roll Call

  26. Ge0rG ,o/

  27. daniel

    i’m here

  28. Zash

    It rained earlier and yesterday

  29. Zash

    I hope that at least melted most of the thick ice covering everything

  30. jonas’

    to make it a even smoother layer of ice? ;)

  31. jonas’

    okay, three to four out of five, that’s good enough

  32. jonas’

    2) Agenda Bashing

  33. jonas’

    We’ve got "something about OMEMO", and a pre-AOB by Ge0rG. Anything else?

  34. Zash

    Here, reconnected

  35. Ge0rG

    jonas’: #878

  36. pep.

    SIG-E2EE?

  37. jonas’

    Ge0rG, part of OMEMO

  38. jonas’

    pep., SIG-E2EE started voting last week

  39. jonas’

    so that’s part of "outstanding votes"

  40. pep.

    right

  41. jonas’

    okay, let’s dive right in

  42. jonas’

    3) Items for voting

  43. jonas’

    3a) Something about OMEMO Last week, the council expressed a desire to do something to explicitly demote the current OMEMO XEP. Options which floated the room, IIRC, were: - Propose and then (most likely) Reject - Change track to Historical - Change track to Informational and set to Obsoleted

  44. pep.

    This is assuming a take over of the authorship by council?

  45. jonas’

    no need to

  46. jonas’

    though that’d be a detail we can discuss

  47. jonas’

    We don’t have voting tools to decide on either way. I think Informational/Obsoleted would be what I prefer though.

  48. daniel

    people have come forward (including myself) with the sort of promise to produce a revised omemo spec until begining/mid februrary. if we now vote on moving omemo to a state that we can’t get it out of we are forcing them to create a new XEP

  49. jonas’

    daniel, I think that’s actually desirable.

  50. ralphm

    I don't see how it is Informational, though, and Obsoleted implies that it has been Active before.

  51. jonas’

    ralphm, it’s informational, because it’s deployed in a major share of software *right now*

  52. Zash

    So are some historical things, no?

  53. pep.

    Why is it desirable to create a new XEP? OMEMO is still experimental

  54. ralphm

    jonas’, well, it is also Experimental, so changes are a natural thing there.

  55. dwd

    Sorry for the lateness! Busy day in work.

  56. jonas’

    pep., because of the exceptional high degree of deployment. Discovering individual XEP versions is still a PITA, and it needs a major version bump

  57. jonas’

    but then again, I don’t have a strong opinion in which way we demote it

  58. daniel

    i'm torn on whether or not newmemo (working title) should have a new number; i see both sides of the argument

  59. pep.

    Seems to me like we are setting a precedent for lots of things here.

  60. jonas’

    daniel, it needs a new number and a new (technical) name, IMO

  61. jonas’

    otherwise this is going to cause lots of confusion

  62. daniel

    i might actually be beneficial that omemo is still discoverable w/o going to the attic

  63. daniel

    *it

  64. ralphm

    jonas’ why not Rejected, then?

  65. jonas’

    be it OMEMO 2.0 or something else

  66. jonas’

    ralphm, I’m fine with rejected. I said something to get the discussion started.

  67. Kev

    jonas’: There is a counter-argument, which is that 'fixing' OMEMO under the OMEMO name might help matters of future adoption, as anyone implementing the Experimental XEP would have expected to need to update in the future.

  68. ralphm

    Kev: I like that

  69. jonas’

    Kev, also a valid point

  70. pep.

    Isn't that what the experimental status is for

  71. pep.

    Experiment.

  72. ralphm

    pep., it is

  73. ralphm

    in fact, we started it out being based on OLM

  74. jonas’

    so what do we want to have as procedure here?

  75. pep.

    Not rush the whole thing

  76. dwd

    Reading back through the original discussion, the plan was indeed to alter it in-situ after having got a version to point to which had the deployed design.

  77. pep.

    For a start

  78. daniel

    there is also the counter counter argument that it weakens the omemo brand

  79. daniel

    by having incompatible stuff out there

  80. jonas’

    Proposal: - We issue an LC. Due to the expected amount of discussion, we give it 3 weeks or so. - After the LC, it’s beginning of Feb - The new-OMEMO team either has a rough draft for new-OMEMO by that time, or we go with rejection

  81. ralphm

    jonas’, Council can deem it not ready for advancement for the arguments presented over the course of the last two weeks, and then advise it being revised to not depend on libsignal

  82. Kev

    dwd: ISTR this is why the 'roll-back' to signal was allowed by Council in the first place - that it was to be followed by 'fixing' it.

  83. dwd

    Kev, Exactly that.

  84. daniel

    why a LC?

  85. jonas’

    daniel, to be able to go to Rejected from there as per XEP-0001

  86. ralphm

    daniel, good question. I don't expect new arguments going forward.

  87. jonas’

    daniel, also, this can bring in more feedback from the wider community

  88. dwd

    I'm a little unsure of a LC myself - it cannot advance along the Standards Track, so an LC is really only useful as a process workaround.

  89. jonas’

    I expect new-OMEMO to not only fix the licensing issues, but also possible other issues in the OMEMO stack

  90. Kev

    From pride of place in the peanut gallery, LCing here seems to be creating more heat than light. Why not wait a few weeks for the next version of OMEMO to start taking shape, and can work things out from there?

  91. jonas’

    I think possible additional feedback into the new-OMEMO process from the community wouldn’t be a bad thing.

  92. Kev

    The only reason for the urgency that I can see is that our IPR process says that we should be moving to replace it because it's encumbered, and we'd be doing that.

  93. ralphm

    Following Section 7 of XEP-0001, dwd kinda proposed this XEP, and Council can decide it is not ready right now.

  94. pep.

    "The new-OMEMO team either has a rough draft for new-OMEMO by that time, or we go with rejection" I personally don't like this. This is being rushed because this whole drama started. They're not paid to do anything about it, and I don't think they've planned to meet before the arbitrary dates you just set

  95. daniel

    jonas’, i think we (whoever 'we' is in that context) have enough feedback; now it just needs people to process that feedback and produce a working spec

  96. jonas’

    pep., the dates are arbitrary, and not fixed. this is about the concept

  97. dwd

    pep., There has been over two years, in fairness - hardly a rush.

  98. jonas’

    pep., and *again*, exactly what dwd says.

  99. jonas’

    daniel, fair

  100. ralphm

    Kev: I saw an argument that this might only hold for stuff that has progressed beyond Experimental. I'm willing to bend on that point.

  101. pep.

    you mean the act of shutting it down is not rushed?

  102. dwd

    Do we want to ensure that the XSF publishes a findable copy of OMEMO as-is in the future? This was a requirement of the original compromise.

  103. jonas’

    ralphm, this is off-topic, but I meant to reply on that with a differing opinion

  104. pep.

    When has council ever reminded the author/community about the issue?

  105. Kev

    dwd: That's already happened because of the versioning, hasn't it?

  106. larma

    jonas’, to be fair, discussions about "newmemo" have been ongoing for some time already, there just are no visible results yet

  107. jonas’

    pep., it’s not our job to remind everyone

  108. jonas’

    Kev, our versioning is most certainly not discoverable

  109. Kev

    ralphm: That isn't my reading, FWIW, although I think in this case it shouldn't matter.

  110. dwd

    Kev, That was indeed the original idea. My question is more whether we still feel that's sufficient.

  111. larma

    < 2 years is not a lot when it comes to designing a crypto protocol (especially as noone involved is paid for doing this)

  112. jonas’

    Kev, it is very bound to the suboptimal rules in XEP-0001 making it hard to see what’s going on in the revision history, but that’s a topic for a difefrent day

  113. jonas’

    larma, I sure hope we’re not designing a crypto protocol from scratch

  114. Kev

    From my non-voting point of view the most important thing is that there is a plan for resolving the mess, and that it seems OMEMO-as-is in someway sunset. I think the nature of XEP numbers is less important than that.

  115. dwd

    jonas’, I'm sure that's not what larma means.

  116. Ge0rG

    can't we postpone this question until we get somw feedback from the yet-to-be-founded SIG-E2EE?

  117. ralphm

    Well, the current state is Deferred. If somebody wants to take it out, either with the work that was labeled OMEMO:2, or Proposing it as is, Council is bound to act. So the question now is, is the current spec as published a problem.

  118. larma

    it would already be rushing to request all the things that are noted to be written down in 3 months if everyone agreed that this is eveything to consider (and yes, new ideas and things popped up within the last two years repeatedly)

  119. ralphm

    (regarding Objective 4 and our IPR Policy)

  120. dwd

    ralphm, For me, yes, in as much as it's on the Standards Track.

  121. dwd

    ralphm, Which seems to show intent.

  122. ralphm

    dwd: I agree, to be sure.

  123. jonas’

    Okay.

  124. pep.

    I don't think it's a problem as noted by larma on the list. the XEP is experimental and §3.2 of the IPR explicitely states "after approval the XEP must not [..]"

  125. pep.

    which is used in 0001 to mean Draft.

  126. Kev

    Can I suggest that as a minimum, it would be sane to explain that the current XEP (at the top of the XEP) is encumbered, can't advance in our standards process as-is, and that the XSF is looking to replace it? That would satisfy our own policy at least.

  127. jonas’

    The situation obviously changed since -7d. So I propose that we let this rest until some time shortly after Summit and revisit then.

  128. dwd

    jonas’, How has it changed?

  129. larma

    Kev, that's pretty much what https://github.com/xsf/xeps/pull/878 does no?

  130. jonas’

    The situation obviously changed since -7d. So I propose that we let the attempt to move OMEMO into a final-obsoleted state rest until some time shortly after Summit and revisit then.

  131. ralphm

    Kev: I like that

  132. jonas’

    dwd, the clear statement of people actively working on newomemo is new

  133. jonas’

    (to me either way)

  134. jonas’

    larma, right, #878

  135. Kev

    larma: I think 878 is saying "This isn't signal, honest. We'll call it signal, but we totally don't mean it.".

  136. ralphm

    Given that daniel made the last significant change, can we consider him the Author?

  137. jonas’

    I think 878 is about as non-sensical as saying "This is not a tree" while pointing at a tree and does nothing good.

  138. pep.

    jonas’, agreed, I also don't like the lack of transparency around newmemo

  139. larma

    Kev, it's also saying it's not supposed to mean signal in the future, no?

  140. ralphm

    I think #878 makes matters worse.

  141. Kev

    larma: That bit, yes.

  142. Ge0rG

    I agree with ralphm on #878, it's not helping

  143. larma

    I think #878 reflects the truth though

  144. jonas’

    Proposed wording (in a separate box at the top): > This specification is currently under special review by the XSF for potential encumberance as per XEP-0001 § X Objective 4. New implementations are discouraged while work is in progress to replace large portions of this document.

  145. Ge0rG

    jonas’: do we have a hard time limit on the Council Meeting?

  146. ralphm

    jonas’, +1

  147. jonas’

    I would simply instruct the editor to inject that wording.

  148. jonas’

    do we need a vote on this?

  149. jonas’

    if so, I’m obviously +1

  150. Ge0rG

    jonas’: +1 on this wording

  151. dwd

    jonas’, I won't block this, indeed I'll vote as a better-than-nothing.

  152. dwd

    But I suspect we need a better fix for this, longer term, so I'll propose something policy-ish on the list later on today.

  153. larma

    jonas’, funny, add "New implementations are discouraged" to experimental XEPs. It's what experimental already mens

  154. larma

    *means

  155. jonas’

    looking at the clock, I further propose that:

  156. jonas’

    We let the topic of demoting OMEMO rest for another few weeks (until after FOSDEM) to see how the SIG-E2EE plays out on this topic.

  157. pep.

    It meets after FOSDEM so probably not much progress

  158. ralphm

    larma: well, arguably we experimented and found issues that warrent this notice.

  159. jonas’

    larma, I can also leave that part out and burn new implementors for no good reason /s

  160. jonas’

    moving on

  161. dwd

    BTW, on the SIG-E2EE, did anything happen about my remark over the "representation" point?

  162. pep.

    At the IETF etc.?

  163. jonas’

    dwd, not that I know, I need to look into the documents, too, didn’t get around to do it since last week

  164. jonas’

    which leads me to:

  165. jonas’

    4) Outstanding Votes

  166. jonas’

    Three ProtoXEP votes are expiring today

  167. daniel

    dwd, to be clear you just want an additional footnote that representation may only happen by approved members or something? while the sig itself is open to the public?

  168. dwd

    pep., I mean at all. We've not allowed non-members to "represent" the XSF in any form before, and even members have tended to need Board permission.

  169. dwd

    daniel, Right, that.

  170. pep.

    I think that's explicit in 002 no?

  171. pep.

    Surely we can add a note

  172. daniel

    that can be arranged i guess

  173. daniel

    i'll talk to paul after the meeting

  174. dwd

    Sounds good.

  175. jonas’

    dwd, Zash, Ge0rG, daniel: quick show of hands of the council if we can extend by 15 mins, otherwise I need to call for order and move on with the agenda

  176. Zash

    Is there a leader for the proposed SIG-E2EE?

  177. dwd

    I'm happy to extend.

  178. ralphm

    Yes, we can establish liasons, if there needs to be some kind of official representation, but I don't think we need that for IETF at this point.

  179. daniel

    yes please extend by 15

  180. dwd

    ralphm, MLS, perhaps.

  181. pep.

    dwd, also note that SIGs have no authority, so whoever represents them doesn't actually matter does it

  182. Zash

    jonas’: sure.

  183. Ge0rG

    jonas’: +1

  184. ralphm

    I will ask about funding people going to IETF in Board tomorrow.

  185. jonas’

    okay

  186. dwd

    pep., Internally? Not really. Externally? Yes.

  187. jonas’

    retroactively 4a) SIG- E2EE

  188. ralphm

    The thing holding back SIG-E2EE right now is appointing its leadership.

  189. ralphm

    I am not sure if I've seen suggestions there.

  190. pep.

    Well there's an obvious one which is the author

  191. dwd

    pep., That's Paul as in vanitasvitae, correct?

  192. pep.

    yes

  193. dwd

    pep., Sounds like a solid choice.

  194. vanitasvitae

    hum?

  195. pep.

    vanitasvitae, yes you!

  196. vanitasvitae

    I didn't do it!

  197. Ge0rG

    vanitasvitae: do you volunteer as leader of SIG-E2EE?

  198. Ge0rG

    ralphm: isn't appointing the leader a Board thing?

  199. vanitasvitae

    yes I can do that

  200. jonas’

    (FTR, I’m holding back here since I still haven’t figured out how SIGs work and I need to read the documents and bylaws. I’m thus still on-list on that one)

  201. ralphm

    No, in this case, whoever proposes the SIG can provide names for the leadership and Council can give its blessing.

  202. ralphm

    The only requirement is Membership.

  203. ralphm

    (of the XSF)

  204. jonas’

    alright

  205. Ge0rG

    which is given according to https://wiki.xmpp.org/web/Meeting-Minutes-2019-05-28#Announcement_of_Voting_Results

  206. jonas’

    anything else on the SIG-E2EE topic we need to discuss in this meeting?

  207. dwd

    Does it only become an active SIG when the XEP becomes Active?

  208. jonas’

    dwd, one of the many questions I have around SIGs which I intend to research

  209. ralphm

    I think so.

  210. dwd

    And does it therefore need a Last Call etc as well as mere adoption?

  211. jonas’

    sounds like way overhead

  212. jonas’

    but I’d like to note that other SIGs have different XEP types which are not described in XEP-0001

  213. dwd

    jonas’, Yup. I think we've probably over-discussed the SIG formation at this stage in this case.

  214. Ge0rG

    jonas’: would it make sense on making Paul the leader?

  215. jonas’

    Ge0rG, before even accepting the SIG?

  216. Ge0rG

    on voting to make

  217. jonas’

    I don’t think so

  218. Ge0rG

    alright

  219. vanitasvitae

    (when preparing sig-e2ee I basically copied from sig-iot, so some mistakes I made may also apply to this xep)

  220. jonas’

    4b) Outstanding votes on three other ProtoXEPs

  221. jonas’

    I see that Ge0rG cast a few votes on-list, but there are still open votes by me notably

  222. ralphm

    jonas’, I'd be happy for modifications to XEP-0002 to better document things.

  223. jonas’

    I’m +1 on MAM FC going ot experimental

  224. jonas’

    I’m also +1 on Fallback Indication going to experimental

  225. jonas’

    I’ll still be on-list about SIG-E2EE as mentioned

  226. jonas’

    5) Date of Next

  227. jonas’

    +1w wfm

  228. daniel

    +1w

  229. dwd

    +1

  230. Zash

    +1w

  231. jonas’

    does not actually work for me

  232. jonas’

    I’m on a event at that time, so we’ll need a replacement chair.

  233. jonas’

    I promise to cast my SIG-E2EE vote befoer that meeting though

  234. jonas’

    does anyone volunteer?

  235. dwd

    jonas’, I can if you do the agenda.

  236. Ge0rG

    I'm on an event as well, but maybe I'll be able to look into this MUC in parallel

  237. jonas’

    dwd, I’ll try :)

  238. jonas’

    (should work tho, as usual)

  239. dwd

    I will, though, miss +2w I think due to travel.

  240. jonas’

    6) AOB

  241. jonas’

    6a) Ge0rG wants to talk about https://github.com/xsf/xeps/pull/874

  242. jonas’ hands Ge0rG the mic

  243. daniel

    yes +2w will be problematic for me (and probably others) as well. but we can discuss this next week

  244. Ge0rG

    jonas’: thanks

  245. Ge0rG

    actually, about https://mail.jabber.org/pipermail/standards/2020-January/036848.html

  246. Ge0rG

    Marc asked for feedback from the wider community on this change, and it's also controversial, albeit less so than the previous hack of the IBR non-dataform form

  247. ralphm

    jonas’, on the SIG-E2EE XEP, accepting it as Experimental is different from voting it as Active. I'm not even sure an LC is needed, and am a bit surprised that XEP-0001 is not more clear on this for types other than Standards Track.

  248. ralphm

    (wow lag)

  249. daniel

    client side i had no problems implementing that

  250. Ge0rG

    I'm using a pre-IBR unauthenticated IQ to have the server assign a preauth token to my current non-session, and then to use that token in IBR

  251. daniel

    if that's the kind of feedback you are looking for

  252. Ge0rG

    I was made aware that doing pre-auth IQs in servers is BAD.

  253. jonas’

    Ge0rG, I don’t like the decoupling, seems like weird state to keep on the server side

  254. Ge0rG

    jonas’: me neither. but it's very straightforward to implement ;)

  255. jonas’

    is it?

  256. Ge0rG

    for client devs :P

  257. jonas’

    *sigh*

  258. Ge0rG

    I'd have been fine with stuffing the <preauth/> element right into IBR, but...

  259. jonas’

    I don’t like this flow and consider it weird. I don’t see a reason not to stuff preauth into a newly namespaced child of IBR to be honest

  260. jonas’

    but on this matter, I’m not going to stand in the way of implementation experience

  261. Ge0rG

    jonas’: stuffing things into IBR leads to the "but dataforms" discussion

  262. jonas’

    Ge0rG, not with me it doesn’t

  263. dwd

    FWIW, I suggested ages ago that IBR etc would be better done by authenticating anonymously and then doing the IBR, and then reconnecting.

  264. daniel

    that doesn’t solve that problem though, does it?

  265. jonas’

    dwd, I’d find that confusing for different reasons.

  266. dwd

    daniel, I don't know. It certanly moves it about.

  267. Ge0rG

    dwd: I'd like to make some progress in this decade

  268. Ge0rG

    we also have SASL2 on the table

  269. jonas’

    (specifically, "does a server offering ANONYOMOUS mean that I can register that way or is it simply for anonymously joining some MUC?")

  270. jonas’

    In the end, this is Experimental. We can easily rebase on SASL2 before moving on to Draft

  271. jonas’

    so again, I’m not going to stand in the way of implementation experience here, I’ll just say I find it weird.

  272. Ge0rG

    my purely pragmatic opinion is that in the long term, we should reinvent IBR by means of SASL2, but in the short term just do whatever hacks work today

  273. pep.

    OMEMO easy? /troll.

  274. jonas’

    input from the server side (looking at you, Zash) makes sense probably

  275. jonas’

    Ge0rG, I can get on board with that

  276. Ge0rG

    jonas’: that got implemented in https://modules.prosody.im/mod_easy_invite.html

  277. jonas’

    (for certain definitions of whatever)

  278. Zash

    I've discussed with Ge0rG previously

  279. jonas’

    alright

  280. Ge0rG

    I'm sure we have more server devs in the Council

  281. jonas’

    am I summarizing correctly if I say that noone is truly happy with this, but it works and we hope for SASL2?

  282. daniel

    i think ejabberd is traditionally more careful with session states such as that

  283. daniel

    so we probably should ask them

  284. daniel

    (their clustering and stuff makes that more complicated; also memory is expensive)

  285. jonas’

    *recommend Marc to ask them

  286. Zash

    We had sooooo many hacks in Prosody to accomodate pre-auth iq stanzas

  287. Ge0rG

    daniel: would you like to, or is it sufficient if I bump that on Holger?

  288. jonas’

    daniel, I’m not sure this is important in this case since the state is bound to a single session which cannot even be resumed on a different node, but I don’t know the details tehre

  289. daniel

    jonas’, yes maybe. i haven’t thought that all the way through

  290. daniel

    > *recommend Marc to ask them +1

  291. Ge0rG

    dwd: do you have an opinion that would result in a -1?

  292. jonas’

    (noting that council dosen’t even vote on this)

  293. daniel

    it's experimental anyway

  294. jonas’

    alright, moving on

  295. Ge0rG

    jonas’: Council will eventually have to vote on it, though

  296. jonas’

    Ge0rG, yes, but hopefully we’ve got SASL2 by then ;)

  297. jonas’

    any further discussion on this proposal can be held in xsf@, no need to have it in this meeting

  298. daniel

    (note that i have much bigger issues with 'easy xmpp', cc Ge0rG)

  299. jonas’

    Is there any other any other business we need to discuss?

  300. dwd

    Ge0rG, I think I'm +0

  301. dwd

    Ge0rG, Or would be if we were voting.

  302. Ge0rG

    dwd: awesome, thanks.

  303. dwd

    Ge0rG, But I'll quite possibly kill it at Proposed if it stays this way.

  304. Ge0rG

    dwd: SASL2!

  305. dwd

    Ge0rG, I am doing my level best to make that a reality.

  306. dwd

    Ge0rG, And, as seems to be the vogue, I note that I am not paid to do that.

  307. Ge0rG

    I'm also not paid to do preauth, so it looks like we are a good match.

  308. jonas’

    we need more VC

  309. jonas’

    Is there any other any other business we need to discuss?

  310. daniel

    not from my side

  311. Zash

    none here

  312. dwd

    Nor from me.

  313. jonas’

    right

  314. Ge0rG

    We also need more time. We are over the overtime already.

  315. jonas’

    then, thanks for participating and sorry for the chaotic meeting

  316. jonas’

    7) Ite Meeting Est

  317. Ge0rG

    thank you, jonas’

  318. Ge0rG

    it was a dense one.

  319. Ge0rG &