XMPP Council - 2017-05-17

What time's the meeting this afternoon folks?

15:00Z

Ta

Remko mentioned he's waiting on an OMEMO PR and asked if it could please be agendad (he's on the road when the meeting happens): "I'm waiting on my proposed changes to XEP-0384 to get processed (these are the changes agreed a month and a half ago, but where nobody seemed to take any action on getting them in the XEP)."

> "I'm waiting on my proposed changes to XEP-0384 to get processed (these are the changes agreed a month and a half ago I think agreed is a bit of an overstatement. To my knowledge andy doesn't like the changes

(not speaking as council member here of course)

Well, probably Council can discuss and do something appropriate ;)

I'll ping that PR; I should have updated to let him know that PRs can't be processed right now

I don't believe that's true.

*easily processed

AFAIK I've got a docker image working to build and serve the XEPs, so it just needs someone to tell me when to build a new one. and I do a bit of manual fiddling to send it up,

Oh, I didn't know all that was working; can we rebuild automatically several times a day? I'd rather not have to try and pester people for "manual fiddling"

SamWhited, btw: how is the XSF editor infrastructure coming along?

The building isn't happening on the server, I do it locally and upload. If you'd like to get the docker hub building the images and uploading to there, I could probably set the server to pull new images somehow.

I don't have access to modify CI, but we could have it easily push to somewhere probably

I don't know what's needed to get the Docker Hub stuff building, but if someone wants to set it up (or tell me which buttons to press), it would be sensible.

I assume it just needs an API key and then you do docker login and just start pushing; if you can add an API key to Travis' encrypted storage thing I can probably setup the plan to push a new container when we merge to master

Ah, no, because Docker Hub can do trusted builds in some way, where you don't just upload an arbitrary image yourself.

Which is presumably what we'd like.

Oh I've never heard of that

Goid overview with setup instructions: https://blog.docker.com/2013/11/introducing-trusted-builds/

That seems even better to me

Let's do it

OK. I'll try to run through those instructions shortly.

Thanks for the link.

Seems it's about time

1) Roll call

Hiya

Hi

hi

Dave Cridland, Link Mauve, ping

ok..seems they're not available

2) Minute taker

I can write todays minutes

👍

3) SHA-1 migration plan update

there is no update, have yet to receive the current state of the plan from Link Mauve

4) XSF Editor infrastructure state

SamWhited, where are we with that? I think two weeks ago we decided to hold off on voting on XEPs as long as the editor is unable to process the changes due to missing infrastrucutre

*infrastructure

I'm not sure; I was under the impression that the new infrastructure wasn't setup yet, but Kev said this morning that he could manually push containers once they were built. I don't know if that means the /extensions dir is being served from a container yet or not thoughh

Kev is working on automating the process, once that is done I assume that means I'll be able to start processing XEPs again

Sorry, horribly late.

I believe Kev has a working container for HTML, and I *thought* he was working on PDF now?

Wasn't that #464 (merged)?

It was, but I'm not sure if that means anything is being done with the Dockerfile yet ¯\_(ツ)_/¯

I think it's a manuel job for now.

"Manual".

Not Manuel. I don't think he works for us.

Does that mean the extensions directory is currently being served out of a container built with that file?

Maybe...?

Anyways, this morning he said he would setup docker trusted builds to automatically build when we merged to master; after that is done, and we're actually serving out of the container, we can process XEPs again.

SamWhited, ok..then let us know if you confirmed that this is working and we can continue with our usual procedure.

Wilco

5) AOB

well Kev had questions about the state of OMEMO...

Were they relating to Remko's PR?

i'm not really sure what there is to talk about for council

Dave Cridland, yes. about it not being merged

RE the Remko PR I'll reach out to Andy as soon as we can publish stuff again and get a yes or a no from him on that

I updated the PR (which I should have done earlier) and let him know that we couldn't currently publish things

sounds good to me

We should be able to nudge Andy even without the ability to publish the result, though.

(and to daniel, presumably you have opinions too)

That's fair

sounds fine to me

Any other AOB?

not really council but maybe someone can comment on my XEP-0060 questions

Not from me.

daniel, on the ML?

which i send to the list yesterday

ok

will try to read them this evening

6) Date of next

same time same day of week next week?

WFM

wfm

WFM2

great

thanks everybody

thank you Tobias for writing the minutes

Just FYI, I may be about to start a new job (the details are still being finalized, so that's a "may"). I don't think it will affect anything, but there is a chance that I'll have the worst possible timing and as soon as the editor tooling is fixed I won't be able to do editor things for a while. Will advise when I know more.

SamWhited: congrats on the new job (I hope)!

Thanks; we'll see :) still negotiating.

yep, understood :-)

FWIW, as an outsider this OMEMO thing is sounding quite a bit like another "We've got a spec, it's implemented, no we're not open to changing an Experimental XEP because it's deployed" instance.

(Missed Council meeting because I was on a work call)

s/no /now /

So if that's not the case, it'd be nice to better understand it.

Kev, I agree, but also, Council accepted it on the basis that it would be based on Olm.

That sounds like a counterpoint to what I was saying, but I *think* it's an alongside?

I can't quite parse the tone.

Kev, Well, Council accepted it on the basis that it'd be based on Olm, and now it's being reverted *after* accepting.

Kev, The tone is increasingly pissed off.

Dave Cridland, primarily though because we were in need of a public domain spec which olm was at that point but the normal double ratchet wasn't

daniel, That is *a* reason. But the authors appear to have decided that Council's decision no longer stands, without consultation.

Personally, it feels to me like Council need to be getting involved here, because it feels like it's going somewhat off the rails.

Dave Cridland, it wasn't clear to be that the council accepting OMEMO as experimental was somehow conditioned by it being based on olm specifically. not having a dependency on proprietary code is obvious. but the reasons for a hard depenency on olm is not

daniel, Well, the Council accepted one XEP and it's been changed materially to another. I might as well pick one of my experimentals and rewrite it into something different that's been rejected before.

daniel, I could get that new component protocol design in, that way.

That depends on our definition of materially

daniel, Well, it's absolutely changed to something that was rejected before.

daniel, Without the input of Council.

It was rejected on the grounds of there not being a public specification

Also was it? Actually rejected? Did council ever vote on that?

Yes.

Council held off accepting OMEMO for a long time.

Kev, not voting on is not the same as rejecting

FWIW, switching back seems fine to me if that's what andy et al. want ¯\_(ツ)_/¯ the council held off because there wasn't a public specification, and now their is one.

Saying "We're not going to accept it until X" is equivalent in all but name.

And now the "until X" constraint is satisfied

SamWhited: How would you address Remko's comments that you can only implement it by either writing your own crypto primatives, or by using the single library that Council originally wanted to avoid?

what Sam said

*there

It wasn't just "public specification", was it, it was "Is able to be sensibly independently implemented".

That's not what I remeber

That's fair if that was also an issue; I do agree that I would rather not have to use a GPLed library or write crypto primitives, but I'm not sure that I personally would have blocked on that

Maybe I would have; doesn't really matter what I think, matters what the previous council gave as reasons. Maybe we can dig up minutes.

Anyways, I have no problem with switching if andy thinks that's best.

I do think that if one of the smartest people in the community is saying "There's problems implementing this", it would be good to listen.

i just don't see why we would standardize a protocol in the XEP based on implementing own crypto primitives or using patched GPL libraries with some legal controversy around it, and comes with technical debt, when we can make a protocol that was developed in the open, comes with audited libraries in different languages.

s/make/use/

OMEMO's priorities (being able to use libsignal, maintain backwards compatibility, ...) make sense for the OMEMO community, but are IMO in conflict with XSF's priorities. I sometimes wonder that, if the priorities are non-negotiable, maybe this isn't a protocol that needs to be developed at the XSF (not all protocols need to be standardized at the XSF, and that's fine).

When I was unhappy with some aspects of OMEMO at this year's summit, I was told to fork it

Flow, By whom?

FWIW, I don't like that idea either. I don't have enough knowledge of the situation anymore to know which way is better (and frankly, I don't even know who's arguing for what anymore), but we should focus our efforts on one thing and not fragment the implementations.

i'd also much rather have everyone come together on something

Flow's comment, BTW, really worries me. "Fork it if you don't like it" is surely not an XSF position.

I do remember that being said at the summit; don't remember who though. I think it was more of a "if you feel that strongly about it, fork, rewrite, and submit as a replacement" not as a new separate experimental XEP

or as an update, rather

but the XSF needs to be able to justify the choices made in the protocol, and as far as I understand, I don't see how it can right now. The technical tradeoffs seem to all made based on easiness to adapt current implementations, not implementability in a wider setting (IMO).

Doesn't look like "independent, interoperable implementations" can be built (though I'm quoting IETF RFC 2026 rather than XSF docs here)

Samwhited: right, hence my attempt to discuss this in the open (everything seems to be discussed somewhere behind closed doors) in a previous mailing list thread, but that just ended with people raising concerns. Hence my attempt to address those concerns in a PR.

i don't care if the PR is rejected and rewritten, but i do care about the points made in the PR, and don't immediately see how they can be addressed differently.

Remko: Yah, I think opening a PR was absolutely the right thing for you to do, to be clear. Thanks for that!

Dave Cridland: regarding your email. The PR wasn't rejected. That's for the author to do. I was merely communicating thoughts some omemo developers have or clear up how that other PR came to be