XMPP Council - 2020-01-02

quick reminder that we have a council meeting today

I forgot to send an angeda tho, and I won’t get around to do so before the meeting starts

I’m sure you all noticed the amount of ProtoXEPs we have

Here

1) Roll call

I saw Ge0rG just now in the other room

hi

ha, right, why am I summoning Kev

we need daniel instead!

anyone else, Ge0rG?

Hello.

(I’m compoisng the agenda bashing section while we’re waiting)

alright

2) Agenda Bashing - Protoposed XMPP Extension: MAM Fastening Collation https://xmpp.org/extensions/inbox/mamfc.html - Proposed XMPP Extension: User-Defined Data Transfer https://xmpp.org/extensions/inbox/udt.html - Proposed XMPP Extension: Fallback Indication https://xmpp.org/extensions/inbox/fallback.html - Get rid of XEP-0384 (from dwd)

anything I missed?

I’d like to move the XEP-0384 thing to next week because I missed sending out an official agenda beforehands and it’s very controversial.

(at least outside Council)

and I’d like us not to appear like doing anything behind closed doors on that matter

I'd like to discuss it, even if we don't vote.

we can certainly do that

(ge0rg sent apologies in the other room)

It's not 100% clear what to vote on right now anyway.

that, too

okay, moving on

3) Items for a Vote

3a) Protoposed XMPP Extension: MAM Fastening Collation

https://xmpp.org/extensions/inbox/mamfc.html

on list

Haven’t gotten around to read it yet, on-list

on list, haven't read all of it yet

I am +1, predictably.

that’s it then

3b) Proposed XMPP Extension: User-Defined Data Transfer URL: https://xmpp.org/extensions/inbox/udt.html

I’m -0 in the current state ✏

I think valid points were made on-list about the integration of an API description in a Standards Track XEP

i usually try not to -1 xeps; but i'm really unsure that one "fills a gap in xmpp"

I'm sorry, I'm in a meeting and can't really

focus.

dwd, AFAICT, you did not comment on the API/Protocol mingling in the document on-list, what’s your stance on that?

i think i'm gonna -0 because i don’t want to block

I'm confident it is useful, but only if I can actually get the buy-in from the library developers.

i'm confident that if we can get buy in from library developers we can make it work without that xep

by just making extension development super easy

daniel, but if multiple libraries support it, I’d say it should be a XEP

ah, that

But FWIW, I'm expecting at least one high-profile XMPP use case dropped because of a lackof a simple way to exchange blobs of JSON.

Mandating an API is kinda weird. Having it as a strongly worded implementation note is probably fine tho?

dwd, what’s your stance on splitting of the API description in an Informational document?

In fairness, it doesn't need an API as much as consistent terminology in the API.

jonas’, Honestly I'd go for dropping the API entirely, and just go for an implementation note on terminology.

i mean i have seen people put things in bodies too (haven’t seen the subject content-type thing yet; but whatever) - but that is better solved by communicating what xmpp actually is

daniel, I liked dwds point about "If someone is reading our communication in form of specs, they’re not the target audience."

dwd, alright, I guess that’d work too

communicating what xmpp is would also somewhat fix the "but the XSF doesn’t provide a xep for use case x"

(I'd also prefer to push for documentation)

daniel, I think the content-type in subject was a better option than most, yes. But if everyone's doing the <body/> thing I'd feel happier we had some kind of technical approach for it.

And as I say, nobody's reading our documentation now except the library authors, so...

I mean, there’s already the JSON Container XEP, but libraries don’t have API for simply throwing a JSON in a message typically, I guess.

and I think the protoxep at hand adding the type field is a nice touch which is essentially for interop

I think this XEP allows libraries to reduce the entry hurdle a lot by providing a simple "fire this JSON" API

can we at the very least not define it for IQs

daniel, Sure.

if you are at the level of doing IQs just read up on what xmpp is

daniel, I mean, people will write a REST-a-like in <message/> containing UDT, but that's still less awful that what they're doing now.

daniel, good point

dwd, and I doubt that kind of people would use the IQ interface of UDT

another good point about this is that library docs can clearly state: "You can use JSON here, but if you have a more complex usecase than just routing some JSOn data through XMPP, you should read up on our docs on developing your own extension [link]."

which is an entry point into getting people into knowing what XMPP is

Oh, for sure.

and how to work with it

so to summarise, the TODO for this XEP would be: - Remove the IQ usecase - Change the wording around the API

I’d be +1 with those changes

(if reasonably executed, of course)

And I can just change it back afterward, right?

ok; should we move on?

dwd, :P

if we still want to discuss omemo; and make the 30min

if nobody else has anything, let’s move on indeed

I'll just go ahead and +1

3c) Proposed XMPP Extension: Fallback Indication URL: https://xmpp.org/extensions/inbox/fallback.html

so when I commented on-list, I got confused about this one

on list

but I’m also going to be on-list

I can’t form an ad-hoc opinion about this vs. hints

I am +0 on this. In many ways I think this might be better as a hint, but we need to revisit why that was rejected. There were remediations discussed for hints, but not in detail, so I don't know what we can do there.

on list. (hints was rejected?)

okay

Zash, No, it wasn't actually. It was bumped back to Experimental, Sam Whited explicitly rejected no-copy, and there was some discussion about a fix or two.

3d) Most Likely Not For A Vote: Reject XEP-0384 OMEMO (in whatever way)

I've now been told definitively by different people that OMEMO both can, has, and cannot be implemented without the GPL libsignal.

I think dwds argument is sound

all implementations I know of either use libsignal or are GPL out of fear of libsignal

i'm +1 (because it is actually a bad standard); but i'm wondering if we should release a blog post or something to explain what that means/what it doesn’t mean

daniel, good idea

Whatever the truth is (and I think the truth is important), it ought to be deferred, which is going to cause confusion.

Of course, none of this should mean people don't use and even implement it.

daniel, this may sound evil loadpushingly, but since you’re a strong proponent of E2EE in general (or are at least percieved in such a way with Conversations), would you take that on?

So can you or can't you implement it?

Zash, you can, the question is whether it’s legal ;)

and the next question is whether a judge would rule in favour of you in juryland

jonas’, i guess…

I suggest we have SIG-E2EE work over it to make it not say you that it's required to use libsignal (if that is said anywhere) and instead document enough so that one can (with external references) implement it from XEP.

I am not a laywer and what is this?

Zash, Without libsignal? Sam and larma insist you can. Moxie thinks you aren't allowed last I looked. Philip says it's impossble without using the library.

Btw, shouldn't the SIG-E2EE be on the agenda as well? It's up to council right? ("A Special Interest Group (SIG) is a working group approved by the XMPP Council")

pep., Marked as Board. Honestly I just assumed it was a Board thing.

I'm not that fond of other parts of the XEP either, e.g. the PEP bits are weird.

dwd, I haven't seen this message by Philip so I can't comment on that, maybe there was some misunderstanding?

dwd, and Syndace successfully implemented it without directly depending on libsignal (but the wire format plugin for libsignal-compat is still GPL)

pep., oh, I also assumed SIGs are a Board topic

> Moxie thinks you aren't allowed last I looked. independently of whether or not a XEP should contain "use libsignal" (it shouldn’t) i wouldn’t trust a word that guy says

daniel, doesn’t help if he’s willing to sue over it, and to be honest, this whole mess looks grey-area-like enough that you’ll probably lose in the first instance and spend lots of money in court.

daniel, Sure, but in this case he paid lawyers a lot of money to say the same thing.

(pep., where did you get that SIG quote from?)

okay, we’re close to our limit, I’d like to move on

4) Date of next

Wed, 2020-01-08 16:00Z here?

jonas’, XEP-0002 I assume.

jonas’, +1 to next week.

+1

002 yes

dwd, indeed, going to put it on next weeks agenda then, and fix the XEP

Wed is fine with me

5) AOB

we’re out of time, except for quick announcements

does anyone have anything?

no

6) Ite, Meeting Est

Thanks all

As a heads-up, I'll try and have an Inbox spec done by the end of tomorrow and submitted as a ProtoXEP.

dwd, okay, if this is your activity peak BEFORE FOSDEM, then I’m scared what will come after ;)

"larma> dwd, I haven't seen this message by Philip" < it was part of the thread I forked from.

(I tried to include stuff from it to keep a bit of context)

Well, I've some ideas on FOSDEM and output.

Most particularly, I think anytime we do "new" work at the Summit, it generally results in a lot of noise and little outcome. So I'm trying to put the effort into concrete specs beforehand so we can discuss known open issues instead of trying to create something entirely new.

I think that’s sound

Maybe.

https://bit.ly/35n0oOY

Spam in the Council room?

It's more likely than you think

Oh. I didn't vote on 3b). I'm +1 with jonas’ proposed changes, which I'll get onto now.

I’m not recording your vote on that in the spreadsheet of doom yet, then

daniel> i think i'm gonna -0 because i don’t want to block I always wonder if '0'ing a ProtoXEP is not just the same as blocking it, after all, IIRC ProtoXEPs need a majority of +1s to get accepted. Or am I wrong?

flow, it’s not blocking, because a -1 is a VETO

while a ±0 can still pass if there is a majority of +1 (as you note), something which got a single -1 cannot pass ✏

right, but if everyone did vote '0', then the XEP will not be accepted, and then I wouldn't say that the 0-voters did not block the XEP

that’s true

or how can it be that nobody blocked a XEP and it still gets not accepted

they were partially-blocking

which makes sense

Negative parlamentarism is kinda neat.

well if you vote -1 it will get blocked immediately. if I vote +/- 0 it will only get blocked if there are not enough people in favor

which makes sense

to me

daniel, the issue I see is that even if you have 4x '0' and 1x '+1', then it won't get accepted

so I wonder if we should lower the bar for experimental by only requireing the sum of the votes to be positive

> daniel, the issue I see is that even if you have 4x '0' and 1x '+1', then it won't get accepted Yes. That was the intention. Because if that's the case 4 people find it problematic in a way or another

Sure, be we are still talking about accepting a ProtoXEP as experimental

I think our consensus is currently going in a 'super inbox' direction

For the catch all no bar xeps

Well hopefully this leads to us putting less effort in rejecting xeps and more effort into improving existing ones

And I hope nobody here takes this personal, I see that dwd's xep can be viewed as borderline, but he has some valid points and I don't see any harm in it becoming experimental

flow, Which XEP is borderlne?

flow, I see one as borderline, one leaning toward adoption, and one an easy accept. Of course, my views aren't an absolute for Council to follow. :-)

but which is which?

my guess: fallback is borderline, easy accept is UDT

dwd, btw, Smack has an API which can be considered similar to UDT since ~20 years, it's called jiveproperties

jonas’, Nope.

jonas’, For me, MAMFC is the easy one to accept. It's complex, and will need changes, but it's a solid start to a problem that needs solving.

jonas’, You were right with fallback, though - it's unclear if it's the correct solution, although it might be the only one given No Hints.