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.)
jonas’that’s a quorum
jonas’2) Agenda Bashing
jonas’we’ve got a ProtoXEP and the OMEMO thing on the list, is there anything I missed?
larmaalso here if needed
jonas’Alright, moving on
3) Items for a vote
jonas’3a) Proposed XMPP Extension: Special Interests Group End to End Encryption
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.✎
jonas’3a) Proposed XMPP Extension: Special Interests Group End to End Encryption
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. ✏
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
ZashAnd this is approved by Council?
pep.(I wasn't entirely sure about that, and I didn't take the time to look it up properly)
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).
jonas’nobody knew, which is why we didn’t vote on this last week
dwdGenerally 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
ralphmAlso noted in our Bylaws
jonas’I’m not sure if this is supposed to be a SIG Formation or a SIG Proposal
jonas’I’m going to be on-list, because the procedure is unclear to me
jonas’anyone else who wants to cast votes in this meeting?
Ge0rGHi! Sorry for being late.
ralphmjonas’, which part is unclear?
dwdI did cast a vote.
- 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)
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.
danielsorry i haven’t had time to read the final draft; i assuming that i'm going to be +1 ; but on list for now
ralphmSIGs are open by nature, however, its leaders must be members
dwdI would assume a SIG Proposal, and needs to be Active for a Formation.
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."
jonas’dwd, things in the past have used SIG Proposal and SIG Formation type of XEPs
jonas’dwd, see, it’s complicated, and I don’t want to waste time in this meeting while I read up on things :)
jonas’I expect the next point to be more contentious.
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).
jonas’dwd, do you want to summarise what this is about?
dwdI think we have already, but it's not clear that OMEMO can (or, possibly, should) be made Draft.
dwdThe "can" relates to whether OMEMO can be implemented without the use of a GPL library. There are people arguing both ways on this.
jonas’dwd, though that’s not a strict requirement for Draft, is it?
dwdjonas’, https://xmpp.org/extensions/xep-0001.html#objectives argues otherwise, since GPL would could as an "encumberance".
ZashCan you implement it based on only specifications or not?
ralphmAs stated on list, I believe that in its current form, this XEP violates Objective 4 of XEP-0001, and can therefore not move forward.
dwdAny particular license would, in fact.
dwdZash, I have been told both yes and no.
jonas’so, I think the ambiguity alone is sufficent
pep.Sufficient to do what?
ralphmIndeed, the (legal) ambiguity alone is an "encumbrance".
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
dwdI 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.
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
larmaOMEMO 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)
jonas’(and this is all in addition to the issues with the "shady" practices around this XEP)
Zashcopyright lawyering doesn't sound like a job for Council :|
dwdlarma, 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.
larmadwd, can you point me their? would like to read/hear reasoning
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
jonas’And on the long-term, we should probably pursue MLS
ralphmIf 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.
Zashjonas’: sounds sensible
jonas’we probably need Boards OK for changing a XEP type after acceptance
dwdralphm, Do we need Board here?
ZashWasn't the current version meant to be what amounts to Historical anyways?
larmajonas’, I think everyone is happy with longterm MLS replacing OMEMO
jonas’larma, that’s at least something
Ge0rGdon't we have a SIG for that?
ralphmI'm not sure how changing to historical is addressing the concern.
jonas’Ge0rG, not yet
pep.And SIGs don't have that authority do they
Ge0rGwould it make sense to postpone those hairy questions for the SIG?
jonas’Ge0rG, I’d rather not until it is clear to me how SIG leadership works.
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
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
jonas’(to me anyways)
ralphmdwd: I think the Editor can change the type at the instruction of Council as long as Council remains its approving body.
ralphmSIGs don't have any authority, in principle.
ralphmjonas’, 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.
dwdSpeaking 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.
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.
ZashI'd happily +1 shuffling this over to Board :)
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
jonas’it does, so I’d also be fine with Informational+Deprecated
ralphmCouncil itself can perfectly decide on what violates the objectives on its own.
ZashI wouldn't oppose tweaking the definition of Historical
jonas’(we’re heading towards the magic :30 mark, and I have a quick AOB, so I’ll terminate this discussion at about :27)
ralphmI would object to tweaking our process just to accomodate the fact that people want to have a specification like OMEMO
danielyeah i also like 'historical' (mostly for what jonas’ said)
dwdI'd be fine with any status that does not make any suggestion that this is a recommended protocol by the XSF.
Ge0rGI'm fine with either Historical or Informational+Deprecated, with a slight preference to the former.
Ge0rGMaybe we also need a blog post explaining the rationale.
ralphmIMO, 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.
jonas’Ge0rG, I think daniel volunteered to do that last week
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)
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
ralphmMy opinion is that both historical and informational+deprecated don't carry the right message.
pep.I'm not entirely fine with Deprecated while we don't have a replacement
pep.Informational is probably ok
jonas’Rejected would work too for me
jonas’though technically rejected would have to go through Proposed
Ge0rGI have a feeling that either change will cause contention outside of the XSF membership
ralphmarguably dwd proposed it to be rejected, so there's that
pep.What's the message we're sending doing this?
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?
Zashpep.: "This isn't the Right Way"
jonas’(if we agree on this, we can figure out the specifics later)
daniel> What's the message we're sending doing this?
that the xsf doesn’t care about e2ee
ralphmpep., that we don't base our standards on libraries
pep.daniel, that, exactly
dwdI'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.
Ge0rGthat the xsf is hostile towards E2EE
daniel(not objecting the proposed changes; but that is the message)
pep.If you're all fine with this then good for you. I'm not
ZashThe XSF likes surveilance!!!11!1eleven /s
ralphmIn the same blog post, you could mention that we (Dave and I) have reached out to the MLS WG to offer our assistence.
pep.ralphm, so it's ready in 5 years instead of 10?
Ge0rGjonas’: +1 on the general demotion
pep.And in implementations in ~7
larmaif 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
ralphmpep., this is not a great argument. Have you even looked at what's there?
jonas’larma, that sohuld happen BEFORE last call
jonas’the XEP has been inactive for a looong while
Ge0rG..in the last year or so, actually
jonas’okay, we’re running out of time
jonas’I see that this clearly needs more discussion. I encourage you to take it to the list or to xsf@.
larmajonas’, yes, it didn't happen, I agree, but what do we do with all the other XEPs that are not maintained?
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).
jonas’4) Date of next
pep.The XSF is not really a symbol of swiftness
jonas’pep., please, outside of this meeting
ralphmpep. indeed swiftness is not a goal, you may disagree, of course
Zashjonas’: +1 +1w
Ge0rGI might be in an overrunning meeting in +1W, so I excuse myself in advance
jonas’5a) Editor Mishap Report
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
jonas’this is mostly an FYI
jonas’(changing the existing version would be confusing and cover-up-ish, so I decided to instead publish a new one)
Ge0rGrelated to this, the author asked for XSF / Council feedback on the proposed change.
jonas’also, what Ge0rG says.
jonas’Ge0rG, can you please re-do your MR on top of current master?
dwdSeems like a good fix.
jonas’should be as simple as a cherry pick
jonas’then you can post to list asking for feedback
Ge0rGAlright, I'll try to do it when I have some more time
jonas’and since we’re already over time
jonas’6) Ite Meeting Est
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
flowGe0rG> 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