ZashI hope that at least melted most of the thick ice covering everything
jonas’to make it a even smoother layer of ice? ;)
jonas’okay, three to four out of five, that’s good enough
jonas’2) Agenda Bashing
jonas’We’ve got "something about OMEMO", and a pre-AOB by Ge0rG. Anything else?
jonas’Ge0rG, part of OMEMO
jonas’pep., SIG-E2EE started voting last week
jonas’so that’s part of "outstanding votes"
jonas’okay, let’s dive right in
jonas’3) Items for voting
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
pep.This is assuming a take over of the authorship by council?
jonas’no need to
jonas’though that’d be a detail we can discuss
jonas’We don’t have voting tools to decide on either way. I think Informational/Obsoleted would be what I prefer though.
danielpeople 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
jonas’daniel, I think that’s actually desirable.
ralphmI don't see how it is Informational, though, and Obsoleted implies that it has been Active before.
jonas’ralphm, it’s informational, because it’s deployed in a major share of software *right now*
ZashSo are some historical things, no?
pep.Why is it desirable to create a new XEP? OMEMO is still experimental
ralphmjonas’, well, it is also Experimental, so changes are a natural thing there.
dwdSorry for the lateness! Busy day in work.
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
jonas’but then again, I don’t have a strong opinion in which way we demote it
danieli'm torn on whether or not newmemo (working title) should have a new number; i see both sides of the argument
pep.Seems to me like we are setting a precedent for lots of things here.
jonas’daniel, it needs a new number and a new (technical) name, IMO
jonas’otherwise this is going to cause lots of confusion
danieli might actually be beneficial that omemo is still discoverable w/o going to the attic
ralphmjonas’ why not Rejected, then?
jonas’be it OMEMO 2.0 or something else
jonas’ralphm, I’m fine with rejected. I said something to get the discussion started.
Kevjonas’: 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.
ralphmKev: I like that
jonas’Kev, also a valid point
pep.Isn't that what the experimental status is for
ralphmpep., it is
ralphmin fact, we started it out being based on OLM
jonas’so what do we want to have as procedure here?
pep.Not rush the whole thing
dwdReading 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.
pep.For a start
danielthere is also the counter counter argument that it weakens the omemo brand
danielby having incompatible stuff out there
- 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
ralphmjonas’, 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
Kevdwd: 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.
dwdKev, Exactly that.
danielwhy a LC?
jonas’daniel, to be able to go to Rejected from there as per XEP-0001
ralphmdaniel, good question. I don't expect new arguments going forward.
jonas’daniel, also, this can bring in more feedback from the wider community
dwdI'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.
jonas’I expect new-OMEMO to not only fix the licensing issues, but also possible other issues in the OMEMO stack
KevFrom 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?
jonas’I think possible additional feedback into the new-OMEMO process from the community wouldn’t be a bad thing.
KevThe 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.
ralphmFollowing Section 7 of XEP-0001, dwd kinda proposed this XEP, and Council can decide it is not ready right now.
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
danieljonas’, 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
jonas’pep., the dates are arbitrary, and not fixed. this is about the concept
dwdpep., There has been over two years, in fairness - hardly a rush.
jonas’pep., and *again*, exactly what dwd says.
ralphmKev: I saw an argument that this might only hold for stuff that has progressed beyond Experimental. I'm willing to bend on that point.
pep.you mean the act of shutting it down is not rushed?
dwdDo 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.
jonas’ralphm, this is off-topic, but I meant to reply on that with a differing opinion
pep.When has council ever reminded the author/community about the issue?
Kevdwd: That's already happened because of the versioning, hasn't it?
larmajonas’, to be fair, discussions about "newmemo" have been ongoing for some time already, there just are no visible results yet
jonas’pep., it’s not our job to remind everyone
jonas’Kev, our versioning is most certainly not discoverable
Kevralphm: That isn't my reading, FWIW, although I think in this case it shouldn't matter.
dwdKev, That was indeed the original idea. My question is more whether we still feel that's sufficient.
larma< 2 years is not a lot when it comes to designing a crypto protocol (especially as noone involved is paid for doing this)
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
jonas’larma, I sure hope we’re not designing a crypto protocol from scratch
KevFrom 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.
dwdjonas’, I'm sure that's not what larma means.
Ge0rGcan't we postpone this question until we get somw feedback from the yet-to-be-founded SIG-E2EE?
ralphmWell, 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.
larmait 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)
ralphm(regarding Objective 4 and our IPR Policy)
dwdralphm, For me, yes, in as much as it's on the Standards Track.
dwdralphm, Which seems to show intent.
ralphmdwd: I agree, to be sure.
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 [..]"
pep.which is used in 0001 to mean Draft.
KevCan 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.
jonas’The situation obviously changed since -7d. So I propose that we let this rest until some time shortly after Summit and revisit then.
dwdjonas’, How has it changed?
larmaKev, that's pretty much what https://github.com/xsf/xeps/pull/878 does no?
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.
ralphmKev: I like that
jonas’dwd, the clear statement of people actively working on newomemo is new
jonas’(to me either way)
jonas’larma, right, #878
Kevlarma: I think 878 is saying "This isn't signal, honest. We'll call it signal, but we totally don't mean it.".
ralphmGiven that daniel made the last significant change, can we consider him the Author?
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.
pep.jonas’, agreed, I also don't like the lack of transparency around newmemo
larmaKev, it's also saying it's not supposed to mean signal in the future, no?
ralphmI think #878 makes matters worse.
Kevlarma: That bit, yes.
Ge0rGI agree with ralphm on #878, it's not helping
larmaI think #878 reflects the truth though
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.
Ge0rGjonas’: do we have a hard time limit on the Council Meeting?
jonas’I would simply instruct the editor to inject that wording.
jonas’do we need a vote on this?
jonas’if so, I’m obviously +1
Ge0rGjonas’: +1 on this wording
dwdjonas’, I won't block this, indeed I'll vote as a better-than-nothing.
dwdBut I suspect we need a better fix for this, longer term, so I'll propose something policy-ish on the list later on today.
larmajonas’, funny, add "New implementations are discouraged" to experimental XEPs. It's what experimental already mens
jonas’looking at the clock, I further propose that:
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.
pep.It meets after FOSDEM so probably not much progress
ralphmlarma: well, arguably we experimented and found issues that warrent this notice.
jonas’larma, I can also leave that part out and burn new implementors for no good reason /s
dwdBTW, on the SIG-E2EE, did anything happen about my remark over the "representation" point?
pep.At the IETF etc.?
jonas’dwd, not that I know, I need to look into the documents, too, didn’t get around to do it since last week
jonas’which leads me to:
jonas’4) Outstanding Votes
jonas’Three ProtoXEP votes are expiring today
danieldwd, 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?
dwdpep., 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.
dwddaniel, Right, that.
pep.I think that's explicit in 002 no?
pep.Surely we can add a note
danielthat can be arranged i guess
danieli'll talk to paul after the meeting
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
ZashIs there a leader for the proposed SIG-E2EE?
dwdI'm happy to extend.
ralphmYes, 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.
danielyes please extend by 15
dwdralphm, MLS, perhaps.
pep.dwd, also note that SIGs have no authority, so whoever represents them doesn't actually matter does it
ralphmI will ask about funding people going to IETF in Board tomorrow.
dwdpep., Internally? Not really. Externally? Yes.
jonas’retroactively 4a) SIG- E2EE
ralphmThe thing holding back SIG-E2EE right now is appointing its leadership.
ralphmI am not sure if I've seen suggestions there.
pep.Well there's an obvious one which is the author
dwdpep., That's Paul as in vanitasvitae, correct?
dwdpep., Sounds like a solid choice.
pep.vanitasvitae, yes you!
vanitasvitaeI didn't do it!
Ge0rGvanitasvitae: do you volunteer as leader of SIG-E2EE?
Ge0rGralphm: isn't appointing the leader a Board thing?
vanitasvitaeyes I can do that
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)
ralphmNo, in this case, whoever proposes the SIG can provide names for the leadership and Council can give its blessing.
ralphmThe only requirement is Membership.
ralphm(of the XSF)
Ge0rGwhich is given according to https://wiki.xmpp.org/web/Meeting-Minutes-2019-05-28#Announcement_of_Voting_Results
jonas’anything else on the SIG-E2EE topic we need to discuss in this meeting?
dwdDoes it only become an active SIG when the XEP becomes Active?
jonas’dwd, one of the many questions I have around SIGs which I intend to research
ralphmI think so.
dwdAnd does it therefore need a Last Call etc as well as mere adoption?
jonas’sounds like way overhead
jonas’but I’d like to note that other SIGs have different XEP types which are not described in XEP-0001
dwdjonas’, Yup. I think we've probably over-discussed the SIG formation at this stage in this case.
Ge0rGjonas’: would it make sense on making Paul the leader?
jonas’Ge0rG, before even accepting the SIG?
Ge0rGon voting to make
jonas’I don’t think so
vanitasvitae(when preparing sig-e2ee I basically copied from sig-iot, so some mistakes I made may also apply to this xep)
jonas’4b) Outstanding votes on three other ProtoXEPs
jonas’I see that Ge0rG cast a few votes on-list, but there are still open votes by me notably
ralphmjonas’, I'd be happy for modifications to XEP-0002 to better document things.
jonas’I’m +1 on MAM FC going ot experimental
jonas’I’m also +1 on Fallback Indication going to experimental
jonas’I’ll still be on-list about SIG-E2EE as mentioned
jonas’5) Date of Next
jonas’does not actually work for me
jonas’I’m on a event at that time, so we’ll need a replacement chair.
jonas’I promise to cast my SIG-E2EE vote befoer that meeting though
jonas’does anyone volunteer?
dwdjonas’, I can if you do the agenda.
Ge0rGI'm on an event as well, but maybe I'll be able to look into this MUC in parallel
jonas’dwd, I’ll try :)
jonas’(should work tho, as usual)
dwdI will, though, miss +2w I think due to travel.
jonas’6a) Ge0rG wants to talk about https://github.com/xsf/xeps/pull/874
jonas’hands Ge0rG the mic
danielyes +2w will be problematic for me (and probably others) as well. but we can discuss this next week
Ge0rGactually, about https://mail.jabber.org/pipermail/standards/2020-January/036848.html
Ge0rGMarc 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
ralphmjonas’, 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.
danielclient side i had no problems implementing that
Ge0rGI'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
danielif that's the kind of feedback you are looking for
Ge0rGI was made aware that doing pre-auth IQs in servers is BAD.
jonas’Ge0rG, I don’t like the decoupling, seems like weird state to keep on the server side
Ge0rGjonas’: me neither. but it's very straightforward to implement ;)
Ge0rGfor client devs :P
Ge0rGI'd have been fine with stuffing the <preauth/> element right into IBR, but...
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
jonas’but on this matter, I’m not going to stand in the way of implementation experience
Ge0rGjonas’: stuffing things into IBR leads to the "but dataforms" discussion
jonas’Ge0rG, not with me it doesn’t
dwdFWIW, I suggested ages ago that IBR etc would be better done by authenticating anonymously and then doing the IBR, and then reconnecting.
danielthat doesn’t solve that problem though, does it?
jonas’dwd, I’d find that confusing for different reasons.
dwddaniel, I don't know. It certanly moves it about.
Ge0rGdwd: I'd like to make some progress in this decade
Ge0rGwe also have SASL2 on the table
jonas’(specifically, "does a server offering ANONYOMOUS mean that I can register that way or is it simply for anonymously joining some MUC?")
jonas’In the end, this is Experimental. We can easily rebase on SASL2 before moving on to Draft
jonas’so again, I’m not going to stand in the way of implementation experience here, I’ll just say I find it weird.
Ge0rGmy 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
pep.OMEMO easy? /troll.
jonas’input from the server side (looking at you, Zash) makes sense probably
jonas’Ge0rG, I can get on board with that
Ge0rGjonas’: that got implemented in https://modules.prosody.im/mod_easy_invite.html
jonas’(for certain definitions of whatever)
ZashI've discussed with Ge0rG previously
Ge0rGI'm sure we have more server devs in the Council
jonas’am I summarizing correctly if I say that noone is truly happy with this, but it works and we hope for SASL2?
danieli think ejabberd is traditionally more careful with session states such as that
danielso we probably should ask them
daniel(their clustering and stuff makes that more complicated; also memory is expensive)
jonas’*recommend Marc to ask them
ZashWe had sooooo many hacks in Prosody to accomodate pre-auth iq stanzas
Ge0rGdaniel: would you like to, or is it sufficient if I bump that on Holger?
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
danieljonas’, yes maybe. i haven’t thought that all the way through
daniel> *recommend Marc to ask them
Ge0rGdwd: do you have an opinion that would result in a -1?
jonas’(noting that council dosen’t even vote on this)
danielit's experimental anyway
jonas’alright, moving on
Ge0rGjonas’: Council will eventually have to vote on it, though
jonas’Ge0rG, yes, but hopefully we’ve got SASL2 by then ;)
jonas’any further discussion on this proposal can be held in xsf@, no need to have it in this meeting
daniel(note that i have much bigger issues with 'easy xmpp', cc Ge0rG)
jonas’Is there any other any other business we need to discuss?
dwdGe0rG, I think I'm +0
dwdGe0rG, Or would be if we were voting.
Ge0rGdwd: awesome, thanks.
dwdGe0rG, But I'll quite possibly kill it at Proposed if it stays this way.
dwdGe0rG, I am doing my level best to make that a reality.
dwdGe0rG, And, as seems to be the vogue, I note that I am not paid to do that.
Ge0rGI'm also not paid to do preauth, so it looks like we are a good match.
jonas’we need more VC
jonas’Is there any other any other business we need to discuss?
danielnot from my side
dwdNor from me.
Ge0rGWe also need more time. We are over the overtime already.
jonas’then, thanks for participating and sorry for the chaotic meeting