XMPP Council - 2020-01-15

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

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

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

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

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

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

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

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

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

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

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

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

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

("Waiting for the Bus")

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

Snow!

Zash, bring some

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

it's 14°C where I am.

on the outside, not in the room.

But we still call it "winter".

only by convention.

’tis time

sorry

1) Roll Call

i’m here

It rained earlier and yesterday

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

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

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

2) Agenda Bashing

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

Here, reconnected

jonas’: #878

SIG-E2EE?

Ge0rG, part of OMEMO

pep., SIG-E2EE started voting last week

so that’s part of "outstanding votes"

right

okay, let’s dive right in

3) Items for voting

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

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

no need to

though that’d be a detail we can discuss

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

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

daniel, I think that’s actually desirable.

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

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

So are some historical things, no?

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

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

Sorry for the lateness! Busy day in work.

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

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

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

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

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

otherwise this is going to cause lots of confusion

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

*it

jonas’ why not Rejected, then?

be it OMEMO 2.0 or something else

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

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.

Kev: I like that

Kev, also a valid point

Isn't that what the experimental status is for

Experiment.

pep., it is

in fact, we started it out being based on OLM

so what do we want to have as procedure here?

Not rush the whole thing

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.

For a start

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

by having incompatible stuff out there

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

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

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.

Kev, Exactly that.

why a LC?

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

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

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

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.

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

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?

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

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.

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

"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

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

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

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

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

daniel, fair

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.

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

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.

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

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

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

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

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

Kev, our versioning is most certainly not discoverable

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

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

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

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

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

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.

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

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

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.

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)

(regarding Objective 4 and our IPR Policy)

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

ralphm, Which seems to show intent.

dwd: I agree, to be sure.

Okay.

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 [..]"

which is used in 0001 to mean Draft.

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.

jonas’, How has it changed?

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

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. ✏

Kev: I like that

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

(to me either way)

larma, right, #878

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

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

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

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

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

I think #878 makes matters worse.

larma: That bit, yes.

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

I think #878 reflects the truth though

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.

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

jonas’, +1

I would simply instruct the editor to inject that wording.

do we need a vote on this?

if so, I’m obviously +1

jonas’: +1 on this wording

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

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.

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

*means

looking at the clock, I further propose that:

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.

It meets after FOSDEM so probably not much progress

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

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

moving on

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

At the IETF etc.?

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

which leads me to:

4) Outstanding Votes

Three ProtoXEP votes are expiring today

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?

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.

daniel, Right, that.

I think that's explicit in 002 no?

Surely we can add a note

that can be arranged i guess

i'll talk to paul after the meeting

Sounds good.

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

Is there a leader for the proposed SIG-E2EE?

I'm happy to extend.

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.

yes please extend by 15

ralphm, MLS, perhaps.

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

jonas’: sure.

jonas’: +1

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

okay

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

retroactively 4a) SIG- E2EE

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

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

Well there's an obvious one which is the author

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

yes

pep., Sounds like a solid choice.

hum?

vanitasvitae, yes you!

I didn't do it!

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

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

yes I can do that

(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)

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

The only requirement is Membership.

(of the XSF)

alright

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

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

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

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

I think so.

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

sounds like way overhead

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

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

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

Ge0rG, before even accepting the SIG?

on voting to make

I don’t think so

alright

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

4b) Outstanding votes on three other ProtoXEPs

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

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

I’m +1 on MAM FC going ot experimental

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

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

5) Date of Next

+1w wfm

+1w

+1

+1w

does not actually work for me

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

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

does anyone volunteer?

jonas’, I can if you do the agenda.

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

dwd, I’ll try :)

(should work tho, as usual)

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

6) AOB

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

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

jonas’: thanks

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

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

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.

(wow lag)

client side i had no problems implementing that

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

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

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

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

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

is it?

for client devs :P

*sigh*

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

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

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

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

Ge0rG, not with me it doesn’t

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

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

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

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

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

we also have SASL2 on the table

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

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

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

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

OMEMO easy? /troll.

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

Ge0rG, I can get on board with that

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

(for certain definitions of whatever)

I've discussed with Ge0rG previously

alright

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

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

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

so we probably should ask them

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

*recommend Marc to ask them

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

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

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

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

> *recommend Marc to ask them +1

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

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

it's experimental anyway

alright, moving on

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

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

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

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

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

Ge0rG, I think I'm +0

Ge0rG, Or would be if we were voting.

dwd: awesome, thanks.

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

dwd: SASL2!

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

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

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

we need more VC

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

not from my side

none here

Nor from me.

right

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

then, thanks for participating and sorry for the chaotic meeting

7) Ite Meeting Est

thank you, jonas’

it was a dense one.