jonas’Haven’t gotten around to read it yet, on-list
Zashon list, haven't read all of it yet
dwdI am +1, predictably.
jonas’that’s it then
jonas’3b) Proposed XMPP Extension: User-Defined Data Transfer
jonas’I’m +1 in the current state
jonas’I’m -0 in the current state
jonas’I think valid points were made on-list about the integration of an API description in a Standards Track XEP
danieli usually try not to -1 xeps; but i'm really unsure that one "fills a gap in xmpp"
Ge0rGI'm sorry, I'm in a meeting and can't really
jonas’dwd, AFAICT, you did not comment on the API/Protocol mingling in the document on-list, what’s your stance on that?
danieli think i'm gonna -0 because i don’t want to block
dwdI'm confident it is useful, but only if I can actually get the buy-in from the library developers.
danieli'm confident that if we can get buy in from library developers we can make it work without that xep
danielby just making extension development super easy
jonas’daniel, but if multiple libraries support it, I’d say it should be a XEP
dwdBut 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.
ZashMandating an API is kinda weird. Having it as a strongly worded implementation note is probably fine tho?
jonas’dwd, what’s your stance on splitting of the API description in an Informational document?
dwdIn fairness, it doesn't need an API as much as consistent terminology in the API.
dwdjonas’, Honestly I'd go for dropping the API entirely, and just go for an implementation note on terminology.
danieli 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
jonas’daniel, I liked dwds point about "If someone is reading our communication in form of specs, they’re not the target audience."
jonas’dwd, alright, I guess that’d work too
danielcommunicating what xmpp is would also somewhat fix the "but the XSF doesn’t provide a xep for use case x"
pep.(I'd also prefer to push for documentation)
dwddaniel, 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.
dwdAnd as I say, nobody's reading our documentation now except the library authors, so...
jonas’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.
jonas’and I think the protoxep at hand adding the type field is a nice touch which is essentially for interop
jonas’I think this XEP allows libraries to reduce the entry hurdle a lot by providing a simple "fire this JSON" API
danielcan we at the very least not define it for IQs
danielif you are at the level of doing IQs just read up on what xmpp is
dwddaniel, 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.
jonas’daniel, good point
jonas’dwd, and I doubt that kind of people would use the IQ interface of UDT
jonas’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]."
jonas’which is an entry point into getting people into knowing what XMPP is
dwdOh, for sure.
jonas’and how to work with it
jonas’so to summarise, the TODO for this XEP would be:
- Remove the IQ usecase
- Change the wording around the API
jonas’I’d be +1 with those changes
jonas’(if reasonably executed, of course)
dwdAnd I can just change it back afterward, right?
danielok; should we move on?
danielif we still want to discuss omemo; and make the 30min
jonas’if nobody else has anything, let’s move on indeed
jonas’so when I commented on-list, I got confused about this one
jonas’but I’m also going to be on-list
jonas’I can’t form an ad-hoc opinion about this vs. hints
dwdI 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.
Zashon list. (hints was rejected?)
dwdZash, 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.
jonas’3d) Most Likely Not For A Vote: Reject XEP-0384 OMEMO (in whatever way)
dwdI've now been told definitively by different people that OMEMO both can, has, and cannot be implemented without the GPL libsignal.
jonas’I think dwds argument is sound
jonas’all implementations I know of either use libsignal or are GPL out of fear of libsignal
danieli'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
jonas’daniel, good idea
dwdWhatever the truth is (and I think the truth is important), it ought to be deferred, which is going to cause confusion.
dwdOf course, none of this should mean people don't use and even implement it.
jonas’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?
ZashSo can you or can't you implement it?
jonas’Zash, you can, the question is whether it’s legal ;)
jonas’and the next question is whether a judge would rule in favour of you in juryland
danieljonas’, i guess…
larmaI 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.
ZashI am not a laywer and what is this?
dwdZash, 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.
pep.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")
dwdpep., Marked as Board. Honestly I just assumed it was a Board thing.
ZashI'm not that fond of other parts of the XEP either, e.g. the PEP bits are weird.
larmadwd, I haven't seen this message by Philip so I can't comment on that, maybe there was some misunderstanding?
jonas’dwd, and Syndace successfully implemented it without directly depending on libsignal (but the wire format plugin for libsignal-compat is still GPL)
jonas’pep., oh, I also assumed SIGs are a Board topic
daniel> 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
jonas’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.
dwddaniel, Sure, but in this case he paid lawyers a lot of money to say the same thing.
jonas’(pep., where did you get that SIG quote from?)
jonas’okay, we’re close to our limit, I’d like to move on
jonas’4) Date of next
jonas’Wed, 2020-01-08 16:00Z here?
dwdjonas’, XEP-0002 I assume.
dwdjonas’, +1 to next week.
jonas’dwd, indeed, going to put it on next weeks agenda then, and fix the XEP
danielWed is fine with me
jonas’we’re out of time, except for quick announcements
jonas’does anyone have anything?
jonas’6) Ite, Meeting Est
dwdAs a heads-up, I'll try and have an Inbox spec done by the end of tomorrow and submitted as a ProtoXEP.
jonas’dwd, okay, if this is your activity peak BEFORE FOSDEM, then I’m scared what will come after ;)
pep."larma> dwd, I haven't seen this message by Philip" < it was part of the thread I forked from.
pep.(I tried to include stuff from it to keep a bit of context)
dwdWell, I've some ideas on FOSDEM and output.
dwdMost 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.
jonas’I think that’s sound
dwdSpam in the Council room?
ZashIt's more likely than you think
dwdOh. I didn't vote on 3b). I'm +1 with jonas’ proposed changes, which I'll get onto now.
jonas’I’m not recording your vote on that in the spreadsheet of doom yet, then
flowdaniel> 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?
jonas’flow, it’s not blocking, because a -1 is a VETO
jonas’while a ±0 can still pass if there is a majority of +1 (as you note), something which got a single -1 cannot ever pass
jonas’while a ±0 can still pass if there is a majority of +1 (as you note), something which got a single -1 cannot pass
flowright, 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
flowor how can it be that nobody blocked a XEP and it still gets not accepted
jonas’they were partially-blocking
jonas’which makes sense
ZashNegative parlamentarism is kinda neat.
danielwell 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
danielwhich makes sense
flowdaniel, the issue I see is that even if you have 4x '0' and 1x '+1', then it won't get accepted
flowso I wonder if we should lower the bar for experimental by only requireing the sum of the votes to be positive
daniel> 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
flowSure, be we are still talking about accepting a ProtoXEP as experimental
danielI think our consensus is currently going in a 'super inbox' direction
danielFor the catch all no bar xeps
flowWell hopefully this leads to us putting less effort in rejecting xeps and more effort into improving existing ones
flowAnd 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
dwdflow, Which XEP is borderlne?
dwdflow, 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. :-)
Zashbut which is which?
jonas’my guess: fallback is borderline, easy accept is UDT
flowdwd, btw, Smack has an API which can be considered similar to UDT since ~20 years, it's called jiveproperties
dwdjonas’, 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.
dwdjonas’, 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.