dwdlarma, There are no ways to extract the info strings used in HKDF from the output, or at least not wihtout having broken HMAC, which is generally considered by cryptographers to be "A bit tricky".
dwdlarma, And you publishing the constants under a difference license wouldn't mean that you exclusively took liability either.
Lancehas joined
Dele (Mobile)has joined
adiaholichas left
lorddavidiiihas left
dwdmoparisthebest, As for whether or not the XSF should take any position on IPR, the XSF does, so in order to change that you'd need to (at least) convince Board to do so. You could, for example, move to the IETF position that IPR constraints are detailed but left the the implementer to decide upon their validity. For patents etc, that's a fine position to take, but for copyright issues, less so (since they're much more rigidly defined).
lorddavidiiihas joined
dwdI suppose one way to reverse engineer the info strings would be to exhaustively search for them, on the assumption they would be ascii strings. It'd take some time, though, and I'm uncertain as to whether anyone would believe you unless you documented it all thoroughly. I don't know enough about the protocol itself to know if yu could get the test vectors out, either.
flowdamn you "WhisperRatchet". But then again, I am fine with a XEP that requires GPLed compatible implementations.
GuusI don't think that the question if we can device a way to legally find those strings is all that important, to be honest. I feel that it is more important that the XSF avoids a legal battle, if it reasonably can. If OWS does not want others to implement their mechanism, any form of reverse engineering - done legally or not - is likely going to be challenged. That makes that approach moot.
flowSo leaving the bad quality of the OMEMO XEP beside, the real question is if you think that encumbers the XEP
flowwhich potentially leads to the question if the GPL increases or decreases your freedom
Lancehas left
flow"If OWS does not want others to implement their mechanism"
OWS wants other to implement their mechanism, that's why they made the implementation available under the GPL
dwdflow, No; I think everyone agrees the GPL forces developers to do certain things (ie, license under the GPL), so the question is whether this is a problem for the XSF.
GuusThat's what confusing me flow - they GPL'ed something, but I've heard (through third parties) that they're actively pursuing legal fights over it.
flowdwd, I am not sure which question the "No" is supposed to answer, but besides that, yes, the question is if we are fine with a XEP that requires GPL compatible implementations
dwdBecause GPL is a useful way to generate a licensing revenue stream for people who don't want to (or cannot) use it.
flowGuus, they can only pursuing legal fights over it if they assume a violation of the GPL
dwdflow, I mean, GPL is definitely an "encumberence" by any reasonable definition. The question is whether the XSF accepts this encumberence.
flowe.g. if matrix would have build OLM on the wire protocol of libsignal, then all matrix implementations would be required to be GPL compatible
flowdwd> flow, I mean, GPL is definitely an "encumberence" by any reasonable definition.
I tend to disagree
dwdflow, But they changed the constants. The wire format can - probably - be reverse engineered.
dwdflow, How is the GPL not an encumberence to developers? It requires them to license a particular way.
debaclehas left
larmaGuus, everybody knows that Signal is not open-source because Moxie believes in open-source, it's open-source because that turned out to be the better business model
dwdlarma, A better business model for a non-profit.
Guus"everbody knows" is not an argument that we can use in any form of decision making.
GuusWhat flow wrote, if accurate, would be a very nice stick against what we can measure things.
GuusThis bit, I mean:
> he question is if we are fine with a XEP that requires GPL compatible implementations
larmadwd, (re info string) I already asked for some help from legal experts on that matter, so we probably should just wait for their input
GuusThis bit, I mean:
> the question is if we are fine with a XEP that requires GPL compatible implementations
larmadwd, it wasn't a non profit back then. There were times when Moxie tried to sell TextSecure as a proprietary messaging app and nobody wanted to buy it
dwdGuus, Well, XEP-0001's Objectives, and particularly Objective 4, would seem to state that we are not.
larmaAlso there was something with Twitter in Signals history (them buying the company and then releasing as open source?)
flowdwd, sure gpl requires some things, but you are free to use it, and especially free of charge. Not sure where the encumbrance comes from. If your buisness model requires you to implement non-gpl compatible software, then the XEP is probably simply not for you and you should probably write your own
Guusdwd I'm open to some back and forth on that, but on broad strokes, that'd settle the entire discussion for me (if all these assumptions hold up).
dwdflow, "requires some things" is surely what encumberence means.
Maxhas joined
adiaholichas joined
flowdwd, well, the gpl is only a burden people who can or are not willing to comply to it
dwdflow, How does that differ from, say, requiring a paid license?
adiaholichas left
flowa, potentially large, part if the xmpp community is probably fine with it
Guusflow, that goes for _any_ restriction. 😃
adiaholichas joined
flowGuus, well there are restrictions that apply to everyone
GuusThe XSF is explicitly not in the business of making things unavailable to non-FLOSS parties.
Guusrequiring GPL would hurt that.
GuusAlso, it'd hurt us - as major players can't use (part of) XMPP.
ZashYou should be able to implement based on spe
flowGuus, it's not like we require all e2ee schemes to be gpl only
ZashYou should be able to implement based on specification alone
Zash+ dependency specs
GuusThe precedent is dangerous.
GuusI strongly feel that we should not go down that path.
GuusI've already had customers worry about licensing as-is.
GuusNote that the people in here are not a good cross section of our users.
Guuspeople in this MUC tend to lean a lot more towards open source principles than many of our (commercial) users.
Guuswhich makes me think that this quote is not quite accurate:
> a, potentially large, part if the xmpp community is probably fine with it
flowI guess OMEMO is so controversial because the FOSS part of the xmpp community is fine with it, which is backed by the various implementations and the high traction it got, while some from for-profit part struggles with the GPL. But then OMEMO is probalby not for them and they are free (and encouraged) to come up with their own e2ee XEP.
flowdwd, what Zash said
dwdflow, What?
GuusI agree to that - but (I'm parroting dwd here) the XSF apparently does not want to publish XEPs that have these limitations (and I'd see value in that).
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
GuusThe XSF _not_ publishing the OMEMO XEP does not limit anyone from implementing it, right?
dwdflow, I also don't understand, "[10:06:40] flow: Guus, well there are restrictions that apply to everyone" - surely the restrictions of the GPL apply to everyone, it's just that for some these are acceptable restrictions?
GuusI'd prefer to publish only XEPs that are usable by both commercial and non commercial parties.
GuusI'd prefer the XSF to publish only XEPs that are usable by both commercial and non commercial parties.
dwdflow, How does this differ from, for example, the RTMP licensing requirements that we rejected?
flowGuus, see that is probably where we differ
Guusflow yeah, I think so. A matter of different opinion.
dwdGuus, An interesting point is that we require "at least one" implementation to be GPL or OSI-approved when moving to Final. What we don't require is that they both cannot be GPL (for example).
flowdwd, sorry, lunch, not ignoring you, but hungy
sonnyhas left
sonnyhas joined
Guusdwd I must admit I'm not up to speed with the details. From what I read here, I feel that the intention of these objectives is to make XEPs as accessible as possible.
Guusaccessible/usable/permissible, license wise. I'm struggling to find the right words.
dwdGuus, Yes; my point is that our process assumes that if something can be implemented as FLOSS it's good. I don't think we considered a case where a protocol would be GPL-only.
Guusdwd right. That may warrant an update of our objectives then.
Guusas I do agree with you that GPL is restrictive.
dwdGuus, The objectives are clear enough, IMO. It's whether the enforcement at the Draft->Final stage needs improvement.
dwdJust in case it's not obvious, I'd be as thoroughly against any XEP that couldn't be implemented fully as GPL (and, moreover, have been in the past n the record).
Guusshoot. I should've done stuff by now.
nycoGuus ralphm MattJ pep. https://mensuel.framapad.org/p/9ece-xsf-board-weekly-meeting-2020-01-09 please review/edit the notes before we/I send them
GuusWhat I'm happy with is that, for me, flow boiled down a discussion that I could not really get a grip on to an essential question. Him and me appear to be on opposite sides of the argument, but if it is acceptable to boil down the discussion to that question, we can make progress.
Guusnyco looks good. I've added some of the standard headings to what you already had.
nycook, thx
Guusshoot. I should've finished stuff by now.
Guusdisappears
pep.> flow> dwd> flow, I mean, GPL is definitely an "encumberence" by any reasonable definition.
> I tend to disagreee
I also disagree
dwdpep., Again, on what basis? Because the actual purpose of the GPL is to enforce that derivative works are under the GPL. SO *if* the GPL applies here, then that surely imposes requirements on developers?
dwd(And again, I say, I've argued against the XSF accepting any XEP which cannot be implemented under the GPL, too).
nyco(minutes sent, thx)
sonnyhas left
dwdnyco, Thanks, I hope I captured the conclusions accurately. Summarizing the debate in an unbiased way would be tricky for me, I think.
nycoagree, unless you are an AD&D "true neutral"
pep."Guus> I'd prefer the XSF to publish only XEPs that are usable by both commercial and non commercial parties." < I think you got the GPL wrong. Nothing prevents a commercial party from using it
!XSF_Martinhas left
dwdpep., I agree with that, but it still requires any software to be itself GPL, which is a restriction, or encumberence.
pep.nyco, thanks for the minutes
!XSF_Martinhas joined
dwdpep., I mean, you're welcome to argue that the GPL is an *acceptable* encumberence - I would disagree, mind. But I don't think you can logically claim it's not an encumberence at all without redefining what an encumberence *is*.
pep.I can agree with that. I don't especially see that as an encumberence, but people who for reasons don't want to use GPL (or say any other copyleft licenses) could see that as an encumberence. Now the reasons as to why not just use copyleft things (and thus be copyleft themselves) is always funny. I would argue it's never a "we can't", it's a "we don't want to".
debaclehas joined
sonnyhas joined
Nekithas left
mukt2has joined
dwdSure, but equally, you may "not want to" use Adobe's RTMP library, or you may "not want to" pay patent license fees. I don't think these are any different.
pep.I don't know about these discussions (RTMP), I'll have a look
dwdpep., One of three cases where a Council I've been on has been presented with a ProtoXEP that relies on encrumbered technology, and I've rejected it.
Nekithas joined
pep.But yes. We clearly have different goals. I am generally in favor of empowering the end user of my projects, that might not be the intent of everyone
dwdpep., In both the other two, there was a material change which meant I could change my vote. However, there have been other cases where we've pushed back on rpoposals before they got to that point - they're just very poorly documented of course.
pep.Mind you, I wouldn't make all this fuss if OMEMO never had been accepted
pep.Because it might not have been such a big thing
pep.In this particular case I'm mostly annoyed that we're not providing a replacement
pep.Wether I want to change Objective 4 of 001 is not something I am trying to answer here (even if I'd certainly agree to)
dwdpep., That implies that I am not interested in empowering my users, thanks for that. I am, but my users are not programmers, so the availability of source code is immaterial. I am also interested in empowering developers, which is why I'm keen not to encumber our protocols.
pep.I said "end-users"
pep.(but yes those on the way as well)
mukt2has left
Ge0rGIt's really astonishing how much vitriol can be released by a bunch of short ASCII strings
pep.:)
dwdpep., The spec generated just as much argument when it was in ProtoXEP stage, actually. Eventually this was diffused by changing it to Olm. I genuinely thought that OWS had released full specifications - they released a lot of cryptographic specs some time back, I thought these had included wire formats and everything else needed.
betahas left
!XSF_MartinIf omemo relies on GPL libs how can monal and Chatsecure support it? I thought the Apple store and GPL are incompatible.
pep.I asked myself the same question. Signal probably has exceptions in the license for iOS, unsure about the others
dwdThe license surely doesn't apply to them. They can release the iOS app under a non-GPL license.
dwdOh, wait, Monal and Chatsecure. Yeah, they're probably technically in breach.
dwdBut not in a way that OWS cares about most likely.
!XSF_Martin> The license surely doesn't apply to them. They can release the iOS app under a non-GPL license.
I'm no lawyer but is this possible when linking gpled libs?
!XSF_MartinAh, you meant signal.
KevYou can't submit anything GPL to the App store, FWIW. Even if there's an exception for iOS made for the virality clause, Apple's terms don't allow it.
Kev(At least, this was true last time I looked at the terms, I suppose they might have changed)
dwdApple might care. OWS probaly not. And copyright licensing is not like patents and trademarks - you don't have to enforce to maintain it.
larma> Open Whisper Systems also grants you the additional permission to convey through the Apple App Store non-source executable versions of the Program as incorporated into each applicable covered work as Executable Versions only under the Mozilla Public License version 2.0
dwdAH, there we go, good spot.
GuusOn Signal's GPL license and Apple, Moxie released this: https://signal.org/blog/license-update/
pep.dwd, yes the license applies to them (independently of what Kev just said about the Apple store). If they wanted to relicense it they'd need at least a CLA that I don't see
pep.Or forbid any contribution that's not from OWS
Guus> Applications that comply with the GPL are now explicitly authorized to be distributed through the Apple App Store and remain in compliance with the license.
larmaSo if anybody wants to: grab a version of ChatSecure from the AppStore and then extract the info strings from there, they are under MPL
pep.larma, they'd be under whatever license Apple says it is rather? If you grab the binary from the AppStore
Lancehas joined
larmapep., no the license remains what the copyright holder grants you
larmait is probably against Apples ToS to do so
pdurbinhas left
larmabut they can only sue you for actual damages caused by being non-compliant with ToS and I don't see damages from extracting strings from a library
debaclehas left
Martinhas joined
debaclehas joined
Martinhas left
adiaholichas left
adiaholichas joined
Wojtekhas left
dwdlarma, I don't see how that removes the copyright.
larmait doesn't
larmabut it's under MPL then
larmawhich is more permissive than GPL
larmaAnd should allow non-free implementations IIRC
flowyep, without re-reading the MPL again, that is probably correct. If so, that's a nice loophole ;)
larmaflow, there are probably a bunch of other loopholes, that's why I have been asking for some legal help on that
larmafor example you could write a program that is under the GPL and outputs those constants. Output of GPL programs that are not the program itself are not under the GPL
flowlarma, i'm sure interested in the result/outcome of that legal help :)
flowhmm, what if the program outputs itself?
larmawell, if the program outputs itself it remains under the GPL
GuusAll this doesn't change the fact that it's a bad idea to publish a XEP on the premise of a loophole.
flowahh, there was a "that are not the program itself"
pep."This week in the XSF: How to use GPL loopholes"
pep.We should do just like "This week in Matrix"
larmaI wouldn't call it a loophole
mukt2has joined
larmaIf that wasn't part of the GPL, then you would be required to deliver the source code of every signal encrypted message (read unencrypted message)
larmabecause you are outputting the hash of that string (kind of)
GuusIf it directly opposes the intended application by OWS, it's undesired for the XSF to act on, in my opinion.
larmaWe can still ask OWS on their opinion on that matter
GuusI'm very much in favor of thta.
GuusI'm very much in favor of that.
pep.Me too
GuusBut any talk about exploiting loopholes would be very unhelpful.
Guusphonecall, afk
Lancehas left
Marandahas left
Marandahas joined
GuusWe'd like to make use of OWS's specification. They've chosen to release that under conditions that we might not agree with, but that does not give us the right to try and find loopholes.
GuusAt the very least not legally.
GuusI'd be pissed if someone uses my stuff in a way that I don't want it to be used.
betahas joined
pep.Guus, aren't that what lawyers are for? :x
pep.Finding loopholes.
GuusAt the very least not morally.
pep.isn't that*
Guus(see my message correction: I ment 'morally', not 'legally')
pep.:)
larmaGuus, I don't think so. If we can argue that legally we are allowed to use those strings and we just ask for permission because we are friendly, that puts us in a completely different position
pep.Guus, the world wouldn't be as it is if people cared about morale
pep.or rather, if more* people cared
larmaCurrently it's like, we have a competing chat system and are begging for permission to use their encryption, that's not the best position to be in
GuusI care about the morality of this.
GuusWe put ourselves in that position - that's not on OWS.
larmaGuus, sure so it's also on us to ensure we are in a better position
GuusIf we are to use their stuff, it needs to be clear that it is permissible to do so - morally and legally.
GuusWe should talk to them. If they say "no", then it's a no.
larmaA moral permission alone does not help, but I am happy to agree that legal permission alone is also not enough
GuusI very much do not want to be in the business of abusing others by means of loopholes.
GuusI very much do not want to be in the business of abusing others by means of legal loopholes.
GuusAlso, by discussing these loopholes, we're actively hurting our chances of getting permission.
GuusIn their shoes, I'd take offense.
larmaalthough I'd like to point out that for the matter of the specification, actually only the legal side matters
larmaIt would be up to implementations then to care about the moral side
GuusOh, whatever we do must be legally valid, I don't argue that.
larmaby using libsignal you would be clearly on the moral side anyway
larmaso the only question that remains (if it is legally fine to extract those strings) is if non-GPL implementations of the spec are moral
GuusMy estimate is that a) OWS explicitly wants all of the implementations to be GPL compatible and b) the XSF does not want to publish XEPs that are implementable only with this restriction. If both are true, I feel that the XSF should not futher pursue the OMEMO XEP in this state.
Guus(note that this does not limit anyone from implementing OMEMO under GPL)
larmaIs it morally better to trick out OWS by not using those strings (like olm)?
SyndaceI don't see why it would be morally bad to implemement the spec under a different license. The spec is CC and there is no mention of copyleft.
GuusI'm assuming OWS has no issue with Olm (as OWS released the specs based on which is was build). That would be fine.
flowlarma, I am not sure if OLM did trick out OWS. As far as I can tell they simple used the open standard and specified their own constants
Guus> I don't see why it would be morally bad to implemement the spec under a different license.
OWS explicitly states: you need to do this under GPL.
flowSyndace, the discussion is not about the spec but about the libsignal implementation(s)
flowwhich are based on the spec but use constants that are not part of the spec
Syndace> My estimate is that a) OWS explicitly wants all of the implementations to be GPL compatible and
flow, ^
flowSyndace, what Guus really ment to say is that "OWS explicitly wants all of the implementations compatible with the libsignal wire protocol to be GPL compatible"
GuusMaybe is should have types "applications of signal" instead of "implementations".
flowthe spec is open standard an implemenations can be under any license as far as I can tell
GuusMaybe is should have typed "applications of signal" instead of "implementations".
larmaIf OWS wants all implementations of what effectively is the signal protocol (minus constants) to be under GPL, it does not give us any moral advantage to use different strings
SyndaceOkay I get it
Guus> If OWS wants all implementations of what effectively is the signal protocol (minus constants) to be under GPL, it does not give us any moral advantage to use different strings
Guustrue, but I don't think that's what OWS wants.
GuusThey've not challenged Olm, did they?
larmaThey don't want signal compatible implementations of the signal protocol in third parties?
pep.> larma> Is it morally better to trick out OWS by not using those strings (like olm)?
This. I don't think it changes anything
mathijshas left
mathijshas joined
larmawhy would they care about those strings, if it wasn't for the protocol?
GuusWe'll have to talk to them to be sure.
Wojtekhas joined
flowwhat Guus said
Guusthe strings might be a way to control interop.
betahas left
pep.Guus, our goal is not to do interop with them
larmathere is no interop between signal and anything because they don't federate
Syndace> They don't want signal compatible implementations of the signal protocol in third parties?
The specification does not specify the "Singal Protocl", it specifies DoubleRatchet and the X3DH key exchange. The "Signal Protocol" just utilizes these two specifications to build their own protocol. The Signal Protocol is not specified at all, you have to read the source code to see how it's done
Guusmaybe it's important to them to only allow interop with GPL stuff (or things they have a side deal with). It's all speculation, and doesn't really matter though.
flowBut it is my interpretation that they want libsignal wire protocol compatible implementations under the GPL, as all their implementations are GPLed. But made the doubleratched/x3dh and open specification so that everyone can implement it and put it under a license they want
Syndaceflow: +1, that's how I understand it
Guusflow meaning that they would be fine with 'Olm', right?
flowGuus, I assume so, yes
flow(But I haven't look at Olm in a while)
GuusThat's also how I think things stand.
Guusbut we'll have to check with them.
betahas joined
mathijshas left
mathijshas joined
flowUnfortunately, and that was because of a bad timeing, e.g. there was no open standard doubleratched/x3dh at that time, OMEMO depends on the GPLed libsignal wire protocol and not the open standard. While nowadays there is no need for OMEMO to depend on the libsignal wire protocol
mukt2has left
SyndaceExactly. The big issue is that we can't change these constants now without a breaking change to OMEMO, which would probably confuse the XMPP ecosystem for quite a while.
lskdjfhas joined
flowI see that people want to keep compability with the libsignal wire protocol in OMEMO for backwards compatibility reasons, but I think OMEMO, in it's current state, could deserve so much (breaking) improvement, that switching the wire protocol would be sensible
SyndaceThe second problem is, that there are other issues with OMEMO that might require a breaking change in the future and we want to make sure that there is one _one_ breaking change and not multiple ones. That's why it's taking so long for us to prepare the improved version of the OMEMO XEP.
dwdflow, I agree, but would add that if omemo were published outside of the XSF it would be perfectly fine to leave it as-is.
flowBut obviously it is not my call but up to the ecosystem and community of (implementation and specificatin) developers to decide
SyndaceBut yes, a breaking change is a must if we don't want OMEMO to stay as it is forever
adiaholichas left
larmaI think it makes sense to upgrade the wire format of OMEMO. And there is a "clean" upgrade path for the wire format, which is having everyone be able to receive the new format and then at some point switch to it. BUT this requires the constants to remain the same
flowSyndace, it is perfectly fine that you want to avoid namespace bumps whenever possible
mukt2has joined
flowSyndace, although I really like to see the current state of the protocol specification, I hear so much about it, you are working on
pep.yeah some transparency would be nice :)
Shellhas left
Shellhas joined
flowSyndace, Is there any reason why you didn't just made an annoucement on standards@ that some are working on OMEMO2? I don't care that the development does not happen within the XSF.
dwdWeird. Someone just pinged my dev workstation's XMPP server from the Seychelles - sent a stream open, waited for the features, and dropped.
Martinhas joined
pep.Teh anonymous are onto you
dwdlarma, I don't think it does need the constants to remain the same if you're doing a flip-over, does it?
SyndaceWe (the SIG-E2EE) plan to do an OMEMO-focussed sprint soon (in the next few months). Our goal is to put together all the things we have collected over the past years into an OMEMO2 kind of XEP.
dwdpep., They'll be massively confused at hitting a healthtech messaging platform that just happened to speak XMPP.
jonas’Shodan.io?
flowNot that it matters, but has the E2EE SIG already offically been formed?
dwdjonas’, This? No, forwardhealth.co
dwdflow, Nobody knows because we can't remember the process. :-)
jonas’dwd, I meant as a candidate for an origin of the scan
jonas’flow, no, at the very least because council didn’t completely vote yet
Danielflow, it's not deliberate secrecy; it's just that a lot of what makes omemo 2 has been discussed in person during multiple events spanning a period of 2 years or so
Danielwe just haven’t had the time to actually write something down
flowI see
Danielwhich is what we are trying to do soon(tm) as Syndace pointed out
dwdDaniel, FWIW, I appreciate that it's transparency that takes effort and deliberation; secrecy is the default unless a considerable effort is made.
j.rhas left
flowIt's not only the tranparency that takes effort, but also collaborative development of specifications is hard, as there are usually many different opinions and finding consensus, which is usually the goal but not always possible, is not trivial
larmadwd, if we change the constants, it will at least break all sessions, so you can't have both at the same time (like one client sending the old version and the other sending the new version when both can receive both versions)
dwdlarma, I think you have to handle it via something similar to happy eyeballs, but it ought to work. It's unpleasant, I agree.
Syndacelarma: I don't think the goal of OMEMO2 is to stay backward compatible.
flowespecially if people insist on their approach without at least looking for compromises
larmaSyndace, I think there are different things going under the name of OMEMO2 😉
MattJresists writing mod_omemo which automatically translates between omemo1 and omemo2
KevIf you can write such a thing, then at least omemo1 is horribly broken, no?
larmaIf we just change the wire format it would be possible
MattJAll E2EE is horribly broken, because the endpoints are users :)
KevRight, if that's the only thing that changed.
Syndacelarma, changing only the wire format doesn't help anybody.
jonas’MattJ, *devices, not users
larmaSyndace, so what issues are there that you'd like to solve?
Danielyes i don’t imagine omemo2 being compatible either. instead we agree on some kind of upgrade path that is somewhat easy for the user
pep.jonas’, in this case I think devices are the lesser evil. Users are those that make e2ee horribly broken :p
MattJjonas’, the devices generally defer trust decisions to the users (or TOFU/BTBV/etc.) which makes life easier
KevI think Dave's right that it'll end up being happy-eyeballs-ish.
Syndacelarma: one second, having trouble to find the link on mobile
j.rhas joined
SyndaceHere you can find a list of things we want to change or consider for OMEMO2: https://github.com/Syndace/xeps/projects/1
SyndaceAnd that list does not include the actual change of the wire format :D
flowpah, no need to state the obvious ;)
sonnyhas left
betahas left
betahas joined
larmaSyndace: those don't really sound like critical breaking changes. Certainly breaking in terms of wire protocol changes, but I don't see anything breaking crypto things
larmaAlso honestly it would be better if we stayed compatible with libsignal if possible
sonnyhas joined
larmaBecause there are a bunch of libsignal implementations already
SyndaceWell then we won't ever move away from GPL
Zash"Because popularity" ?
flowlarma, surely you could take those implementations and change the constants
jonas’flow, if the implementations directly link against libsignal?
flowjonas’, hmm?
SyndaceWe could fork libsignal and change the constants
larmaDynamic linking is a thing
flowof course the outcome would still be GPLed
jonas’flow, if I write a client and link against libsignal, changing the constants is rather meh, because then I need a fork of libsignal
Martinhas left
flowjonas’, potentially yes, but maybe the libsignal library provides an interface to feed those constants into it
Martinhas joined
flowmy point was merely that you could still use those libsignal implementations even if we change the wire protocol. But yes that potentially means forking of those
flowbut I would also expect new generic doubleratched/x3dh implementations to appear. For example in case of Syndace's library, that probably just means creating a new backend and be done
jonas’yes, though that is concerning in its own
jonas’lots of crypto-implementations
jonas’and I don’t think we have as many cryptographers as we have languages in which xmpp clients exist
flowyep, but OTOH omemo implementations have already gone through review, that may happens with new libraries too
jonas’did they?
flowand you can't really forbid people from publishing a library
flowplus a non-gpled doubleratched/x3dh library has potentially a even higher chance from getting audited because of $buisness interest
pep.Even though Copyleft is actually quite aligned with business interests..
Vaulorhas left
emushas left
emushas joined
betahas left
mukt2has left
Martinhas left
Martinhas joined
Shellhas left
Shellhas joined
pdurbinhas joined
sonnyhas left
betahas joined
waqashas left
adiaholichas joined
pdurbinhas left
mukt2has joined
ajhas left
Lancehas joined
Vaulorhas joined
adiaholichas left
adiaholichas joined
sonnyhas joined
moparisthebest> Guus: I'd prefer the XSF to publish only XEPs that are usable by both commercial and non commercial parties.
moparisthebestGreat so for example the GPL
moparisthebestName one large commercial entity that doesn't use Linux for instance
dwdmoparisthebest, I don't think that's what Guus actually intended to mean - I assumed it to mean FLOSS vs non-FLOSS.
moparisthebestThis "gpl is bad for businesses" thing is pretty recent and I don't like it, I feel like it's brainwashing from the likes of Apple etc
eevvoorhas joined
moparisthebestAnd to be honest I couldn't care less about non-FLOSS, they made their bed, they can lay in it
dwdmoparisthebest, Recent? It's ancient - don't you remember the GPL is cancer thing from Ballmer? True to say it *is* bad for *some* business models, but it's essential for others.
moparisthebestThey always have the option to go FLOSS
moparisthebest"doc it hurts when I do this" "stop doing it"
GuusI strongly feel that the XSF should not adopt the strategy of telling people that.
mukt2has left
GuusWe'd loose more potential users than that we'd make people use FLOSS.
dwdmoparisthebest, You're saying any use of XMPP should be GPL? Like, say, Fortnite? I can't see that being viable.
GuusWhat I ment to say was that I feel that the XSF should not publish XEPs that are only suitable for one particular license model.
adiaholichas left
betahas left
flowGuus, I think it's the other way around: we loose potential community members if we forbid "gpl-only-xeps"
betahas joined
flowI think part of the people currently in this room are here because of omemo
Guusflow, I'm talking about "people/organizations applying XMPP", you're talking about "members of the XSF" I think.
moparisthebestSure I'd be fine if all XMPP implementations had to be GPL, actually AGPL would be better
Martinhas left
dwdflow, I think you cannot have a specification that is GPL only. If something is fully specified, then no particular license can exist, and the entire question is moot.
Guus> Sure I'd be fine if all XMPP implementations had to be GPL, actually AGPL would be better
I strongly disagree.
moparisthebestThat's well put flow , I'm explicitly here because of the open source freedom, nothing else
flowGuus, no I mean community members in the bordest sense, taht is XSF members and ppl/orgs applying XMPP
Martinhas joined
jonas’I agree with Guus
dwdmoparisthebest, And I'll continue to defend your right to choose to release under any license you choose, especially FLOSS licensing.
jonas’part of being an open and free standard is the freedom of license model
WojtekI was reading the discussion and it seems that the crux of the issue is whether XSF should push/enforces GPL licencing... IMHO it should not - XSF should define sets of interoperable standards and it's up to users/developers whether they want to implement it under GPL or non-FOSS licence, but in the end their product should be interoperable. If there is no mandate to prefere something GPL than both parties are content.
Guus+1
ZashAn open standard should be complete. If you need to read some stuff out of a library to implement it, regardless of license of that library, then it's not complete and it's a bug in the specification.
j.rhas left
moparisthebestAnd to be clear I'd also be fine with an XSF xep that said "you must pay my company $x to implement this" I would just ignore it
dwdmoparisthebest, What if we put that XEP into a compliance suite?
moparisthebestThat part I wouldn't consider an open standard
moparisthebestA gpl standard I would consider open
Zash"a gpl standard" doesn't even make sense!
dwdmoparisthebest, You literally cannot have a "GPL specification" though.
moparisthebestdwd: no one has to care about that either
moparisthebestIsn't the argument that omemo is gpl
moparisthebestOr requires gpl, that's what I mean
j.rhas joined
ZashThe problem as I see it is that you apparently need to look at something that isn't a specification in order to implement the specification.
flowdwd, right, hence I wrote "gpl-only-xep"
ZashDoesn't help that this thing is a GPL library
flowbut otoh I am not sure if we haven't here the case of a specifcation which requires gpl
dwdflow, Indirectly, we do. But this is a combination of two problems.
flowif I where to write the constants in the xep with a disclaimer that I have extracted them from an gpl implementation…
flowit's complicated → time for coffee
dwdflow, Can't, since that would violate the copyright.
dwdflow, Our XEPs are explicitly under an MIT license.
flowfair point, then I do not write them into the xep but into some other document
Guus> it's complicated → time for coffee
+1 ☕
betahas left
betahas joined
Zash☕ !
Lancehas left
taohas joined
Shellhas left
Shellhas joined
taohas left
pep_has joined
adiaholichas joined
moparisthebestso the fix is just to get the board to allow our XEPs to be under MIT *or* GPL, author's choice
moparisthebestthen the omemo details can be published in the XEP and everyone is happy
winfriedhas left
winfriedhas joined
moparisthebestwe could have a whole new category of GPL'd specs called GEPs :)
GuusI'm very much against this.
GuusPeople will need to start to worry if they can actually use a XEP.
moparisthebestmy point is they already have to
Guusnot from a license perspective - other than with OMEMO?
Guuscurrently? not from a license perspective - other than with OMEMO?
moparisthebestyes, I have no assurance the rest of the XEPs have been thoroughly vetted for license/IPR issues
pep_Guus, of course they would have to.
moparisthebestif my business were to rely on it, I'd need a lawyer or something to do that presumably
pep_As moparisthebest says
adiaholichas left
pep_The IPR only says "if something happens, it's not us!!"
pep_(or at least that its legal value.)
GuusThere's a huge difference in verifying that indeed the implementation that you create base of off a XEP is compliant with the license that you choose to release your work under, and: you can't implement certain XEPs without your work adhering to the license of a very specific third party implementation.
pep_I don't think we're on the same page still
GuusIf XMPP would only be observed as doing the latter, it wouldn't even be considered in many businesses.
GuusYou'd not even get a foot in the door, so to speak. It'd be dismissed outright.
GuusI'm not saying I agree to that, or that those businesses _need_ to dismiss it - but it's what will happen.
moparisthebestit's not considered in many businesses already, I don't think making it less free (and yes I'm definining that as not GPL, sue me) will change that
dwdmoparisthebest, I'm assuming you know that first statement is entirely wrong?
dwdmoparisthebest, And therefore the second.
moparisthebestI don't see any problem whatsoever with a XEP explicitly saying "for $reasons implementations of this must be GPL"
pep_If tomorrow $company wants to use XEP-0987 in $legislation that differs from the XSF's, it needs to do the work of verification itself (that they can legally use it). And even if $company were in the same legislation as the XSF, the XSF is not actually putting any effort in legally vetting the XEPs
moparisthebestit's crystal clear, it's an open standard, what else are we after
GuusYou're not very 'open' if you're requiring a specific license, in my opinion.
pep_This has nothing to do with 0987 referencing $implementation
moparisthebestdwd, no, we don't even have a lawyer on staff so I know for sure they haven't been legally vetted, putting aside we'd need a lawyer for every jurisdiction around the world
pep_This ^
dwdmoparisthebest, You're attempting to require to prove a negative.
adiaholichas joined
GuusI'm off to get the kids. later!
moparisthebestbottom line is this, if $company implements a XEP and that XEP has problems, who is legally responsible? $company or the XSF ?
dwdmoparisthebest, There is a world of difference between striving to achieve a level playing field for everyone, and not aiming for that.
moparisthebestI think it's always $company and therefore they can't rely on anything the XSF says
SyndaceIf xeps start requiring licenses and some of them are incompatible, you suddenly can't implement those xeps in one server/client at the same timr
moparisthebestdwd, I don't think we should aim for that in any way no
dwdmoparisthebest, OK, but that is an entirely different argument. You're arguing we should not be an open standards organisation.
moparisthebestno I'm arguing that a GPL-requiring standard is an open standard
pep_I always enjoy how everybody uses "open" in so many ways
moparisthebestand if someone chooses not to implement it, that's on them
dwdmoparisthebest, Well, you're very much in the rough there. Every other organisation with a definition of what "open standard" means would not agree.
winfriedhas left
winfriedhas joined
jonas’moparisthebest, I don’t see a difference between a standard which requires a proprietary license and a standard which requires GPL. Both hinder implementors.
jonas’(and I’m a very pro-GPL person)
moparisthebestthat's fine, reasonable people can disagree :)
moparisthebestjonas’, I'd disagree, the first hinders implementors (though I'd also be fine with it, just wouldn't call it a open standard)
dwdmoparisthebest, Yes, sure, but if you're going against a well-established definition...
jonas’moparisthebest, the second also hinders implementors who are bound to non-GPL for whichever reason.
moparisthebesta standard which requires GPL doesn't hinder implementors, their act of not choosing the GPL is their own hinderence
jonas’which might very well be external even
dwdmoparisthebest, But the act of not choosing my commercial license is surely their own hinderence too?
dwdmoparisthebest, I mean, I could use a license like the old MSFT license that used to be used for MSVS examples, which allowed any use *except* open source.
moparisthebestand I'd simply choose not to use it
moparisthebestI don't know why we'd require anything else of anyone
dwdmoparisthebest, But itd still be an open standard by your unique definition?
mukt2has joined
moparisthebestnot an open license not an open standard I guess ?
adiaholichas left
adiaholichas joined
dwdmoparisthebest, That's not what the term means.
moparisthebestI guess there is no point in arguing over semantics, which I probably started so my bad
moparisthebestbottom line, I'm perfectly fine with a XEP that requires implementations to be GPL for whatever reason
moparisthebestI'm also fine with a XEP that requires $proprietary_license, I'd just ignore it
dwdAnd I (alongside many others) would say that's not an open standard. So what you're saying is that you're fine with the XSF being something other than an open standards organisation.
moparisthebestwhatever that ends up being I'm fine with
moparisthebestI'd like to point out that Guus 's fear of "no one will consider the XEP if it's GPL" is unfounded, after all look at all the OMEMO implementations
moparisthebestI don't care about non FOSS anything
Guus> I'd like to point out that Guus 's fear of "no one will consider the XEP if it's GPL" is unfounded, after all look at all the OMEMO implementations
That's not what I meant at all
adiaholichas left
Guus> I don't care about non FOSS anything
You don't have to, but the XSF should not exclude XMPP from nonFloss.
adiaholichas joined
moparisthebestI don't mind if it does, since I don't care about any non FLOSS people/things/companies
moparisthebesthow does it help any of us if say slack is using XMPP underneath? meh
calvinhas joined
pep_Relatedly, I'd like to find a way to make these proprietary implementations/usage visible tbh. Some argue they're a majority and I'm sure at least in terms of numbers that's true, but they're invisible to most. (Not that I especially want to be part of any of these proprietary implementations)
moparisthebestideally they should use their own halfbaked buggy protocol, will help them die sooner
Guus> I don't mind if it does, since I don't care about any non FLOSS people/things/companies
> how does it help any of us if say slack is using XMPP underneath? meh
Many of us are employed by people that create proprietary implementations.
pep_moparisthebest, I agree, it doesn't, at least as long as their goal is not to federate and be happy ever after.
dwdFor what it's worth, the UK Government, for example, would explicitly outlaw standardising on XMPP if we didn't allow XMPP in "both open source and proprietary licensed solutions". FSFE, FFI, and OSI all agree.
moparisthebestGuus, and you wouldn't be employed if those were relicensed GPL down the line?
UṣLhas left
moparisthebestinteresting dwd , I'd be curious what the reason is for that or the specific law
Guusmoparisthebest: those solutions wouldn't have been based on XMPP then
pep_dwd, I'm not especially happy with OSI fwiw.
moparisthebestGuus, eeehhh that seems again like "businesses won't use GPL" and that's simply not true, Linux
GuusAnd relicensing is absolutely out of the question in many board rooms.
dwdmoparisthebest, It's not law, but policy.
moparisthebestand I don't care about those board rooms, they can roll their own xmpp-like replacement and die
mukt2has left
dwdmoparisthebest, And I can tell you that my employer wouldn't be using XMPP if it weren't an open standard - they switched from a proprietary solution in part because of this.
moparisthebestsome better company will come along, take over their business, and hire their devs :)
GuusYou severely underestimate how much the XMPP community benefits from these organisations.
pep_Guus, well that's an issue as I said above. They hide themselves.
pep_(or take it the other way if you prefer. They're not visible)
pep_In the meantime, XMPP is still largely influenced by these implementations
GuusGtg, kid is here
moparisthebestyou misunderstand me, maybe that's a huge segment, I don't care about those use-cases or organizations
dwdpep_, I have tried to get some of the organisations I've worked with to be a bit more open abut their usage, but it's quite difficult.
adiaholichas left
pep_dwd, and that's one of my issues with them
moparisthebestthis is an aside, but how many of those non-open-source companies would have implemented OMEMO if not for GPL thing? my guess is none
Vaulorhas left
Vaulorhas joined
moparisthebestI guess a decent proxy might be how many support PGP or OTR? my guess is also none
dwdmoparisthebest, Entirely possible that it's none, I agree. But what if it were something else?
dwdmoparisthebest, I can tell you that my employer will be implenting E2EE this year, but not OMEMO. That's not only due to licensing, though the licensing makes it a non-starter.
moparisthebestI guess that's part of why I'm fine if individual XEPs are marked "in our legal opinion (IANAL) this is only implementable in GPL code"
dwdWe can't *have* a legal opinion if we're not lawyers.
pep_We might, wrongly :-°
HolgerCompanies using XMPP in proprietary ways can obviously help by (as has been said) paying some of us, and by debugging the software we use and having fixes back upstreamed. I don't agree with "let's just fuck them, that'll magically give us better companies". It won't.
MattJAgree. I believe in open standards for interoperability. I think the discussions would be different if a proprietary E2EE protocol was dominant already...
pep_MattJ, free software implementations just wouldn't use it..
MattJRequiring implementations be GPL will not make closed-source implementations become GPL. It will just make closed-source implementations become non-interoperable.
MattJWhich is not a world I want to live in, which is why I dedicate so much to open standards
moparisthebestMattJ, and how is that different than the current situation?
calvinhas left
calvinhas joined
moparisthebestreworded, name an existing public federated interoperable closed source implementation
MattJmoparisthebest, we want to fix the current situation. As I understand it people are arguing that the current situation is acceptable (GPL-only implementations allowed)
MattJmoparisthebest, that doesn't make sense - this whole discussion is about the fact that closed-source interoperable implementations are not possible
moparisthebestso it hasn't happened in 21 years but maybe it'll happen soon? meh
MattJbecause of the GPL restriction
dwdmoparisthebest, *public*? That's difficult. But federated, partially closed-source (and partially open-source), and interoperable: https://en.wikipedia.org/wiki/Federated_Mission_Networking
dwdmoparisthebest, Even includes some GPL clients, I think. Certainly includes open source. That page doesn't actually mention XMPP at all, but a Google for "NATO XMPP" will get you a lot. You might even recognise some company names there.
winfriedhas left
moparisthebestok I'll try another take, e2ee is a bit of a special case and I could make the case that it'd be irresponsible to allow non-open-source implementations, so maybe only e2ee XEPs can enforce GPL? :)
winfriedhas joined
dwdmoparisthebest, Neither TLS, PGP, or MLS require GPL, so that rather falls down as an argument.
moparisthebestdoesn't mean we couldn't do it differently
dwdmoparisthebest, Doesn't mean we have to do it differently either.
mathijshas left
mathijshas joined
mukt2has joined
lorddavidiiihas left
lorddavidiiihas joined
pep_(fwiw, I wouldn't especially be proud that the army is using XMPP..)
moparisthebestgovts aren't really bound by licenses/GPL anyway
MattJpep_, that's going down yet another rabbit-hole - if you want to choose who is even allowed to use your technology/software
MattJAt that point yeah, we might as well just remove any reference to "open"
ralphmI suppose if you want to relegate XMPP to an even more limited group of implementors, users, then excluding commercial entities is the way to go.
dwdmoparisthebest, They seriously are. I could tell some tales about that, but they're real sticklers for licensing.
ralphmI for one find that acceptable for the XSF.
moparisthebestdwd, they aren't even bound by laws, UK for example just broke a ton of laws then changed them retroactively? :)
MattJralphm, acceptable? or unacceptable?
ralphmhah, *not* acceptable.
MattJPhew
pep_MattJ: Sure it is. I'm not saying that's easy. I'm also not saying I want to move in that direction right away, but it's crossed my mind quite a few times
ralphmI do not intend to take any steps to exclude any field of endevour from our standards process or membership.
MattJMe neither
pep_ralphm, who is talking about excluding commercial entities
ralphmpep. expecting commercial entities to adhere to GPL-type licensing for so-called open standards is not a realistic world view in my opinion.
moparisthebestGPL doesn't in any way exclude commercial entities though
pep_^
moparisthebestand we are talking on an individual XEP basis
ralphmexcept it does
pep_ralphm, that's maybe your biased view. Many implementations succeed in using copyleft licenses and being sustainable
MattJmoparisthebest, you said yourself (iirc) that such a XEP wouldn't be able to be included in the compliance suite
MattJI mean, it could, but it means it's not quite as simple as "it's just one XEP"
calvinhas left
ralphmI am happy for people to thrive with GPL code. I think that Open Standard and requiring a specific license to implement said standard is mutually exclusive.
moparisthebestralphm, maybe you mean it excludes non-GPL implementations, sure, but those could be commercial or non commercial
MattJWe're trying to reduce fragmentation in XMPP, or at least that's what I've been working on
pep_MattJ, "we"?
pep_"in XMPP", which part?
ralphmThe XSF, from the very beginning.
pep_"The XSF" is not one person
ZashSo much text produced over this issue.
MattJpep_, compliance suites are for reducing fragmentation
MattJand that has been a community effort
MattJfor years
moparisthebestMattJ, but you just ignore the part you don't want or can't implement, I don't think it matters there
MattJmoparisthebest, I just tried to chat with a non-OMEMO client in Conversations and it took 3 taps through various confirmation boxes
moparisthebestthere are a whole slew of reasons why $company/$project can't or won't implement a XEP, licensing is just one of them
MattJIf we also care about UX, yes, fragmentation matters
moparisthebestMattJ, good? :)
lorddavidiiihas left
ralphmpep., I won't go into legal definitions, but US corporations are actually considered to be equivalent to a person. That aside, the XSF was founded on principles of openness. This is why we have this set out in our bylaws and XEP-0001, and I will do everything in my power to not deviate from those values.
moparisthebestyou are of course free to fork Conversations to fix the UX
pep_#semantics
moparisthebestralphm, and GPL is the pinnacle of openness so that's great! :)
moparisthebestbut yes, what pep_ said
MattJmoparisthebest, and decrease practical security in return
pep_How so?
MattJmoparisthebest, all because the XSF refused to provide a fair standard
pep_"Security by obscurity"?
pep_We all know that doesn't work
ralphmmoparisthebest, I'm sure there are many people that believe this, but I think there's an explicit difference between code and protocols, and I'd like to not muddle those concepts by requiring a license for implementations.
MattJpep_, disabling E2EE silently without informing/confirming with the user is a security problem
lorddavidiiihas joined
moparisthebestI suppose forking is always an option, GXSF publishing GPL'd GEPs anyone? :/
pep_Without informing the user? What client does that?
MattJpep_, the one moparisthebest just suggested I create in order to fix the UX caused by a fragmented ecosystem
dwdmoparisthebest, And the XSF's licensing allows that.
ralphmmoparisthebest, indeed, XMPP standards development is not somehow restricted to the XSF or the IETF. If you want to have your own extension protocols, that's entirely possible. Also by design.
pep_MattJ, I missed that bit sorry
dwdmoparisthebest, Because we're an *open* standards organisation.
ralphmIn fact, the namespaces in XEP-0384 are not even tied to or regulated by the XSF.
pep_It's not the only XEP fwiw
ralphmsure
MattJI guess this whole thing has been enlightening to me
moparisthebestI'm not saying fork all XEPs, I'm saying I (and apparantly at least 1 other person here) don't see any harm in publishing specific XEPs that might require GPL-compatible implementations
moparisthebestI'd like the XSF to change to allow that
moparisthebestbut if it won't it might be valuable to have an open place to publish them
pep_moparisthebest, not entirely sure what I think about it tbh, but I'm not entirely closed to the idea. At least I'm not arguing the other way
dwdmoparisthebest, For OMEMO specifically, that's a fine idea. I suggested it earlier.
MattJmoparisthebest, I think everyone here is totally fine with them being published, just not by the XSF
pdurbinhas joined
pep_I think the copyleft/GPL != business is just very wrong
mukt2has left
ralphmI think a lot of people and corporations (including probably all sponsors) would leave the XSF if we would ever change that, moparisthebest.
ralphmI would.
moparisthebestthat'd be ridiculous
lskdjfhas left
lskdjfhas joined
moparisthebestbut I also couldn't care less if they did, no loss as far as I'm concerned
MattJpep_, another time I'd love to hear your thoughts on how a pure GPL "commercial entity" would work
pep_Sure
MattJBut I think that's even too OT for here right now
jonas’you could try next door
MattJI didn't want to disturb the tranquility there
pep_I'm on a nazi network I only have http available atm..
dwdMattJ, Pure software, not services? Tricky. I've seen people try, but I've seen all of them fail.
MattJdwd, logically that makes sense, yes :)
moparisthebestdwd, wait are their pure software companies that just sell proprietary software with no support or services? :/
pep_I think Conversations is a nice example of this fwiw
moparisthebest*there wow...
pep_Conversations.im being separate from Conversations.
dwdpep_, Possibly. Though I wasn't sure whether Conversations was a serious revenue stream, or if that was mostly the services.
pep_I'm sure he's not making millions, but you don't need that to live anyway
dwdmoparisthebest, By services I meant hosted services. I've seen plenty of GPL-and-support companies fail.
ralphmI'd be very surprised if Conversations' play store income suffices to continue its development other than as a hobby.
DanielConversations’ app store sales make much more money than conversations.im
moparisthebestwhat's Redhat dwd / MattJ ?
Danielnot in absolut numbers (both are pretty low) but in relative terms
ralphmDaniel, could it be your day job?
Danielno
Danieli mean it is. but no
Guushahahaha
ralphm:-D
pep_And you do consulting around it, right
pep_And it's just fine
mukt2has joined
moparisthebestin a past life I made a good living giving away only open source software for free, on a website that had ads on it
moparisthebestso there are plenty of ways, which is beside the point that I think the XSF should be able to publish GPL-requiring XEPs
ralphmI don't see the point and think allowing that is harmful. Maybe even just entertaining the idea is.
moparisthebestI don't think I can be convinced entertaining any idea is ever harmful
moparisthebestralphm, and I don't see the point in non-GPL software existing, different perspectives eh?
ralphmmoparisthebest, different perspectives is fine.
pep_moparisthebest, I'm honestly not convinced copyleft (our hackish use of copyright) is the solution. It's just the least worst solution we have for now :x
Lancehas joined
moparisthebestsure let's get a law banning distribution of binaries ? :D
pep_Obliterate patents and copyright
ralphmBut is literally my job to serve the XSF and the larger XMPP Community the best I can. Protocols and formats should be entirely open. For code, I am happy for people to make their own choices. I am not even a big fan of copyright law (which GPL ironically depends on to work) or patents.
moparisthebestI know we'll never fully agree on everything and that's fine, and I think it'd be ridiculous for all XEPs to require GPL, I know that's not going to happen, probably even shouldn't happen
moparisthebestbut I don't see any problem whatsoever with an e2e XEP requiring GPL, and maybe the rare XEP here and there requiring it
moparisthebestI would like the XSF to change to allow that
moparisthebestand if it doesn't, fine, I'd still like to see it though, that's all
Shellhas left
ralphmmoparisthebest, ok. Do you intend to take a particular course of action?
GuusI do see a problem with the XSF publishing specifications that, from a licensing purpose, limits people from using it. I do not want the XSF to allow for this.
Shellhas joined
ralphmRight.
GuusI do see a problem with the XSF publishing specifications that, from a licensing perspective, limits people from using it. I do not want the XSF to allow for this.
MattJI mean, I'm not 100% against that idea
MattJBut it reduces the XSF to a repository of documents
GuusI'd go further and say that I hope that no-one creates such XEPs and publishes them anywere (out of XSF context), which is clearly out of my hands - but doing so would, in my opinion, hurt XMPP.
moparisthebestgood point ralphm , might be good to bring it up for an official vote by board and/or XSF membership, not entirely clear on how that works
MattJSuch a document could just as easily be hosted elsewhere
pep_MattJ, tbh, the XSF is not far from that to me atm.. a badly organized repository of documents
pdurbinhas left
MattJpep_, sad you feel that way, I think it has quite a bit of expertise to offer as well
pep_> Guus> I'd go further and say that I hope that no-one creates such XEPs and publishes them anywere (out of XSF context), which is clearly out of my hands - but doing so would, in my opinion, hurt XMPP.
You're late to the party, this is already being done (not OMEMO)
pep_Hmm, not license related, but "standards" used in the whole community that are not XEPs
ralphmThat's a hugely different thing there.
pep_Not so different to me. That makes some of them proprietary documents
ralphmXMPP extension protocols published (or not) by entities other than the XSF or the IETF is totally fine. By design!
calvinhas joined
pep_So proprietary is fine, but free software isn't
ralphmWe designed XMPP to be distributedly extensible.
pep_I see
pep_Maybe you weren't replying to what Guus said. because it seems to me we're not in sync
Guus(I was explicitly referring the XEPs with specific license restrictions applied to their implementations - I'm totally fine with XEPs being published outside of the XSF)
pep_Or I'm not reading that correctly
ralphmpep., my own opinion: I think protocols and formats should be entirely open. I don't believe in copyleft, publish all my own code under MIT, and am happy for everyone to make their own choices in this.
dwdI'd rather people didn't actively subvert the XSF's goals, but otherwise I'm fine with people publishing stuff like OMEMO (or RTMP/Jingle, or whatever) outisde the XSF.
pep_Guus, what does it change then if it's published out of the XSF to you? Free software or proprietary
Danieli haven’t been reading the entire backlog but i don’t like the implied hostility towards commercial services. commercial services bring a lot of knowledge into the xsf
Guuspep_ I'm unsure if I understand your question.
pep_I'm trying to reread your message that I quoted and see what I didn't get
pep_> I hope that no-one creates such XEPs and publishes them anywere
eevvoorhas left
dwdDaniel, Yes, but we're evil. So it's evil knowledge. EVIL!
Shellhas left
Shellhas joined
pep_Daniel, personally I'm not hostile towards commercial services
Guuspep_ XEPs that are published for adoption by community at large, that include a restriction that their implementation requires a specific license, hurts XMPP, in my opinion. I hope that no-one publishes that (very specific) type of XEP.
GuusI'm unsure how to word that differently.
ralphmBecause it by its very nature fractures the community.
pep_Guus, so you also don't like practices like say.. MUC avatars?
MattJI personally don't like the way MUC avatars were introduced, no
pep_Multiple attempts to specify that have been rejected by council
dwdAn interesting observation from that is that OMEMO is only a problem because it's fundamentally a useful and desirable feature at its core.
GuusI'm not familiar with MUC avatars, but it doesn't require someone that implements it to release that implementation under a very specific license, does it?
MattJIt crashed at least one client, and I still get a ghost user in some of my clients/MUCs
pep_So we're using some proprietary protocol atm, that sits on processone's website
Lancehas left
pep_But no one is actually complaining about them
pep_weirdly
pep_I mean, no one that is complaining about OMEMO
KevI mean, other that MattJ, two whole lines above.
Guuspep_ I think we're talking about different things.
KevI mean, other than MattJ, two whole lines above.
ZashWhy even have a standards organization, just implement whatever you want and whatever becomes popular is the standard! /s
Danielin that point i disagree with Guus. I think OMEMO can (and maybe should) exist outside the XSF. by using gpl libraries we were able to move (relatively) rapidly with omemo and bring e2ee to 'our' community
j.rhas left
dwdLoosely a +1 to that.
ralphmpep., Do you mean https://xmpp.org/extensions/inbox/muc-avatars.html
matlaghas left
j.rhas joined
winfriedhas left
Shellhas left
Shellhas joined
GuusDaniel OMEMO as-is will never be adopted fully, because of the license issues. If this remains the defacto standard, then potential users that don't want to use it because of the license restrictions will see that as a major disadvantage of XMPP>
winfriedhas joined
pep_ralphm, yes, and another one as well
dwdI do have concerns about doing an "end-run" around the standards process, as indeed pep. is talking about with MUC Avatars. (Honestly I've not followed that - I knew there were implementations, but figured it had gone away).
jonas’dwd, no, MUC avatars are a thing
ZashEveryone has MUC avatars
ralphmpep., so having been submitted to the XSF for consideration already has it bound by our IPR, and is therefore, in fact, without restrictions to implement.
Danielalso the fact that 'our' community (free, open source, publicly federating) gained a little more traction in recent years (in part thanks to OMEMO as a 'brand') also benefits the commercial community because it brings xmpp back into the minds of people who want to build something closed on xmpp
jonas’I’m for sure not setting them manually on search.jabber.network ;)
ralphmpep., I don't remember why it didn't get accepted as a XEP, though.
GuusDaniel I'm not arguing it's all bad at all - but in the long run, I think it hurts more than that it brings benefit - especially if we're going to see more of this.
dwdDaniel, That's true. Though if we bring lots of interest to XMPP for them to find the thing that brought them here isn't available to them, that'd be a bit of a pointless exercise. :-)
DanielGuus, well it is 'fully adopted' in the free open source world
Danieli think any actively developed client has support for it
pep_ralphm, can't find the original document atm, but it wasn't hosted on the XSF infra at all.
KevSwift doesn't (yes, it's still developed) :)
davidhas left
GuusDaniel I can't add it to Apache2-licensed clients, as far as I can tell.
DanielGuus, no. but you can relicense the client
davidhas joined
dwdralphm, That one? Introducing pubsub on MUC, I think, blocked it. Perhaps.
Danielwhich i think some clients have done
GuusBut I don't want to relicense the client.
Danieli don’t like the gpl either and i'm not happy about the current situation. but it is still fairly widely deployed
GuusBecause that might affect people that are using my client as a base for something that they're developing (it'll require them to relicense too)
GuusSure, absolutely, I agree to that.
Danieli mean show me another xep from the past 5 years that is as widely deployed as omemo
GuusMIX
Guusducks, runs.
flowGuus> Daniel I can't add it to Apache2-licensed clients, as far as I can tell.
You can, but the result is GPLv3
mukt2has left
dwdThere were quite a few smaller commercial clients based on Smack which blindly brought in OMEMO support too.
flowSadly, we did not sue them all and made $$$
ralphmDaniel, MAM
Danielralphm, i would like to see stats on that. it might be very close or equal
flowBut yes, just because something isn't behind a paywall on the internet, does not automtaically mean that you can use it in your product. That is true for software, but also for standards
pep_flow: enforcing GPL, with what money? these free software people they're not supposed to produce work for free? 🙂
ZashWasn't OMEMO already on the path to popularity before becoming a XEP?
dwdZash, It was in Conversations for ~1 year before becoming a XEP.
ZashAnd, isn't it still the pre-XEP version that's popular?
GuusLook, OMEMO is pretty great. It gave good value. It's just very unfortunate that we waded into this weird licensing territory with it.
Daniel(also http upload, i'm obviously exaggerating to make a point)
j.rhas left
j.rhas joined
ZashHTTP Upload has at least moved within the standards process since
moparisthebesthas it? (looking at you http upload encryption)
Danielbut is currently stuck for some unknown reason
Danielbut that's a different story
pep_moparisthebest, yeah that's a different XEP..
pep_or ProtoXEP, rather
moparisthebestbasically, we aren't lawyers, and as dwd aren't qualified to have a legal opinion as to whether omemo can be reverse engineered and/or implemented non-GPL, but are somehow still making the decision that it can't and that we shouldn't publish it
moparisthebestI'd prefer to end-run that and just say we are ok with GPL requiring XEPs
emushas left
Shellhas left
Shellhas joined
jonas’moparisthebest, no, you misunderstood
jonas’we made the decision that it’s very ambiguous (much more than the average XEP), and consider that a problem in and of itself
ralphmthis
ZashDaniel, haha what, stuck in last call?
moparisthebestok that's fair I guess jonas’
jonas’we made the decision that the licensing situation is very ambiguous (much more than the average XEP), and consider that a problem in and of itself
jonas’moparisthebest, see my edit tho
moparisthebeststill what's the appropriate method to bring up "allowing GPL-requiring XEPs" for a membership vote or whatever?
pep_All this said, I'm still not happy with the message we're sending, and whatever you may say about it won't make me change my opinion
ralphmmoparisthebest, also, to answer your question on how do do this: (it will take some time to type)
jonas’moparisthebest, send it to Alex or Board I think?
Daniel> The Last Call ends on 2019-01-22
mhh ok
pep_editors should look into that
jonas’Daniel, I think there was unaddressed last call feedback
jonas’but I may be wrong
Guuspep_ I agree with you that this all reflects poorly on us.
jonas’Daniel, ... but I can’t find any evidence of that
Guusand neither 'solution' will be able to fix that.
GuusWe just differ on opinion on which solution is the least worst one, I think.
ralphmmoparisthebest, to get rid of Objective #4 in XEP-0001, you can put in a PR. This will be reviewed by Board. From gauging the current set of Directors, that would not gain a majority.
The next step could be to have it discussed and put up for a vote with the Membership. This you can suggest and schedule with Alex, our Secretary. I'd be surprised if you'd get a majority there.
moparisthebestI'd like to bring it up for a membership vote just out of principle honestly
pep_I guess you can start a thread on the list, without putting it for a vote. There is no majority for sure
moparisthebestjust gauging the room I also suspect it won't reach a majority
Danieljonas’, i think it has had multiple last calls. some had feedback (which got addressed)
ZashI vote no!
ZashNo to everything!
Danieland then the last last call didn’t have any replies at all
moparisthebestZash, thanks I'll just word it negative then :)
jonas’Daniel, I guess we should put it on the next council agenda to restart the LC
jonas’or maybe the editors can just do that
jonas’(or even have to)
dwdjonas’, XEP-0363 had LC feedback, but that was the first LC in Fedb 2018. That all got addressed in Dec 2018, and I don't see any LC feedback at all in Jan 2019.
jonas’reminds me that I need to update the spreadsheet of dooom
Danieli'm going to assume that's because everyone is happy :-)
dwdjonas’, I'd stick an LC on the agenda for the next Council meeting.
dwdjonas’, Oh, you can automatically restart it, actually. Declare it as a Council change auto-restart.
jonas’dwd, exactly
pep_That's a thing?
dwdpep_, Yes, if a Council changes after an LC but before the advancement to Draft is complete, the LC restarts.
pep_Even if the LC is almost a year long? 😛
KevConsideration for advancement to draft*
I think
KevIt doesn't get restarted if one Council rejects the move to Draft.
stpeterhas joined
dwdKev, Yes. Before the vote to Draft or before such a vote completes, I suppose.
dwdpep_, Well, it's not *meant* to happen this way.
pep_(Not that I'm opposing this move)
Shellhas left
Shellhas joined
ralphmmoparisthebest: I don't think trying all these endruns around our procedures is a great idea. It would be great if you'd at least respected the procedures we currently have in place: Council can form its opinion on OMEMO (and they will next week), Board can weigh in because of (at least) liability concerns. If you are then unhappy, please first just do the PR and let Board do its job. Then as a final thing you can still go to the membership. You'd need at least 5% of the membership to put a matter up for a vote, by the way.
Shellhas left
Shellhas joined
moparisthebestI don't have super strong feelings about OMEMO specifically
moparisthebestI do have a strong feeling that we *should* be able to publish GPL-requiring XEPs
ralphmWell, I don't like to waste time on hypotheticals, to be honest.
Danieldwd:
> The second form, "full", presents every message stanza in the results, including all fastenings, errors, and so on.
that's a <result xmlns="mam"> with multiple forwards?
Danielor just multiple results?
moparisthebestwell also it's not a hypothetical, it means whether omemo requires GPL is a non-issue right?
moparisthebestthen it can be evaluated on technical merits as it should (in my opinion)
moparisthebest*only on technical merits
Daniela never mind
Danielthat's kinda the status quo
Shellhas left
Shellhas joined
jonas’moparisthebest, as I see it, you have three options:
(a) Accept that the people who’re currently deciding things in the Council and Board do not agree with you and move on.
(b) Start the process to approve GPL-only XEPs (via PR against XEP-0001 and possibly membership vote)
(c) Continue to fight this fight, consuming lots of resources on all parties, without going through the process, thus making any chance for change very slim
jonas’moparisthebest, I’d like it if you did not take option (c), because it is very streneous on my mental capacities, and I’m sure others too
moparisthebestright, I'd like to just do (b)
jonas’moparisthebest, please do so then
jonas’thank you very much.
moparisthebestyep and I appreciate the discussion and pointers on how to do that
KevDoes Xep1 get a membership vote? Bylaws do, doesn't Xep1 just get Board?
KevI forget, and don't have cycles to look it up
Shellhas left
Shellhas joined
ralphmKev: yes, XEP-0001 is Board only.
ralphmBut, the membership is king
ralphmSo they could override Board.
ralphmThat's why I presented that order.
KevThey could overthrow Board, and elect a new one that would produce a different result. I don't think they can simply overturn Board's decision, though.
KevUnless I'm missing something.
jonas’Kev, in my understanding, membership can start a vote on about anything. If board rejects a PR against '1 which membership wants to have, I don’t see a reason why membership couldn’t start a vote (given the prerequisites for a membership vote) to accept this PR overriding boards decision
winfriedhas left
winfriedhas joined
KevI think they would have to change the process first that says that only Board can approve changes.
mukt2has joined
wojtekhas joined
jonas’couldn’t membership vote for a process exception? :)
dwdDaniel, MAMFC? That's like current MAM, but if it archived everything, not just "traditional IM messages".
Shellhas left
Shellhas joined
Kevjonas’: I hope we don't get to the stage that we need such a discussion.
ralphmKev: in any membership organisation I've served in, what jonas’ described can be done. However, it is also often a huge hammer that Directors walk out over.
ralphmso if moparisthebest thinks this is the best course of action to prove a point, well, I guess that's what has to happen
ralphmI personally think it is irresponsible.
wojtekhas left
Danieldwd, yes. thank you
Danielre: fallback body
pep_I would like to make this a regular practice fwiw, having members vote on things, without all the weight you all just mentioned
KevFor the little it's worth, I'm feeling quite hurt at the moment, as a person who has contributed to the XSF for 'a while' while producing GPL, OSS-but-not-GPL and closed-source XMPP projects, that the the current tone of the conversation is that because I'm involved in non-GPL projects I matter less.
pep_What's wrong with that.
pep_If directors can alleviate some of the work for members, great. if members feel they need to vote themselves, why not
Danieliirc message processing hints was rejected because people thought that the hints should be closer to the XEP they are influencing. like store should be in MAM, no-copy should be in carbons etc
jonas’pep_, because it’s not just members, but also secretary who has to do the work
jonas’and given that we’re all volunteers...
Danielby that defintion shouldn't fallback be in either MAM or mamfc
jonas’Kev, I’m quite unhappy that you feel that way, and I need to say that you or your opinion doesn’t matter less to me.
pep_jonas’, that's fine, that doesn't justify the "that is also often a huge hammer that Directors walk out over"
KevI think fallback being outside MAM/MAMFC/Fastening is preferable, but I'm not sure I would hugely care to see it move.
dwdDaniel, Well, I thought fallback was more general - it could be used by clients which don't know what the fallback is for to mark the message in some way.
Kevjonas’: Thank you.
Danielimho if you like general; put it in hints; if you don’t put it in mamfc
jonas’Kev, and to mitigate some fallout, I also need to say that I’m a strong GPL proponent. I’m however aware that the XSF is not the vehicle for that, and I’m also clear that GPL isn’t always (often, actually) working out for commercial projects.
Danielboth are valid approaches. but a new XEP i don’t get
ZashI hold that an open specification can't mandate licensing of implementations.
ralphmpep., the thing is this: a Board of Directors is there to govern the Corporation on behalf of its membership. It gets elected to do this, and thus a mandate. When you get to the point that you want to *override* the Board on a topic, that's a huge hammer. That was my point.
Marandahas left
Marandahas joined
pep_I don't see that as a hammer, I think it's great actually
pep_Having members participate
Shellhas left
Shellhas joined
KevDaniel: FWIW, I think fallbacks are often harmful, and it's useful for a client to know because it could choose to handle them differently from a normal body.
KevMaybe harmful is hyperbole
ralphmI didn't say we should get rid of the possibility, I just think that it should not be used frivolously.
KevBut out of place in a normal flow.
pep_ralphm: I'd like to see that a lot more often. I'd even like it to be the default. I do understand that people don't have that much time and that's why the board of Directors is appointed
eevvoorhas joined
Keve.g. you could do something like:
[There are some messages in this chat that you can't handle. Would you like to see a fallback rendering? Y/N]
pep_Not the opposite. I don't think I'm here to govern anybody, I'm here to serve
dwdDaniel, I did say I'd go for hints, but that's been pushed back by a previous Council.
jonas’pep_, so how I see it, and I think what ralphm wants to express is: The board gets elected to delegate work and that comes with some trust. If membership overrides decisions by board, that’s effectively a statement of distrust.
Danieli agree on the harmfullness and i was team no-fallback for reactions
jonas’and that’s hurtful, demotivating and unsettling for the elected members of board
KevAnd if the chat was full of +1 noise, it would hide/show that.
Danielbut i wouldn’t know how to handle a fallback message in the client
KevSee above :)
dwdDaniel, <fallback/> is an attempt to allow us to be less anti-fallback.
Zashdwd, I'd like to point out that there's some overlap with the EME XEP
dwdZash, Oh. Yes, there probably is.
ralphmjonas’, yes indeed.
KevAnd on Ralph's point, I agree that Membership overriding Board is a thing that implies a lack of trust in Board and is very possibly a message to Board that they would be best to step down. Or at the least it would be reasonable for a member of Board to feel that that was the message.
Shellhas left
Shellhas joined
ralphmpep., you *are* appointed to govern the XSF, the corporation. This is different from governing its membership.
KevGovern: conduct the policy, actions and affairs of (an organisation) with authority.
KevI think that's pretty much the definition.
KevI think that's pretty much the definition of what Board does.
ralphmYes, I tried to convey that I don't view members as underlings :-D
Kevralphm: And we love you all the more for it ;)
pep_I just prefer to see that from the members' perspective, as I am also one, and I want everybody not to be afraid to express an opinion and push it through our process.
debaclehas left
alameyohas left
Guushas left
ralphmWell, if any topic has been discussed to death in the last week, it has been this one. I'm not sure how much more opinion you can squeeze out of people without rage ensuing.
pep_Sure 🙂
dwdAsking everyone about everything is what gets you Brexit.
pep_That's just wrong
KevWhere 'wrong' means 'demonstrably right' :)
pep_You're forgetting lots of context here
Zashdwd: I also feel like in most cases where the body is there for fallback reasons, that by itself doesn't help with knowing how to treat it. IE an encrypted message should probably be treated as a chat message with a body, but reactions might warrant different treatment. I think Ge0rG touched on this, that you need understand the thing it's a fallback for to treat it right in many cases. But it still feels like it could be useful somewhere.
KevZash: I think my suggestion is actually a fairly reasonable least-knowledge way of handling fallbacks.
Guushas joined
Guushas left
Guushas joined
mukt2has left
ZashKev, where?
ZashI'm having a hard time following everything in this :(
Kev> e.g. you could do something like:
[There are some messages in this chat that you can't handle. Would you like to see a fallback rendering? Y/N]
jonas’pep_, nothing stops a member from proposing a PR against for example '1 and arguing their case
ZashKev, yeah, that's sensible.
pep_jonas’, exactly, and I'm saying people should do it 🙂
pep_(Whether it's this specific case or another)
moparisthebestKev, and just to be clear I mean no insult, I just think the XSF should be able to publish XEPs that require GPL implementations, and anyone can choose whether they want to implement them or not, that's it (I'm explicitly opposed to the idea this is anti-business or anything)
MattJI think that is a reasonable position to hold, fwiw
jonas’pep_, it’s a different thing to say: "Make a PR against '1 and let board decide" and "request a membership vote to bypass board"
alameyohas joined
pep_I don't think so
jonas’One is bypassing the authority of the elected board, one isn’t.
ralphmI agree with jonas’.
jonas’one is sending a message of distrust, one isn’t.
pep_The authority lies with the members.
pep_Board is elected by the members
jonas’yes
jonas’I’m not arguing that point
jonas’the members elect board to delegate authority
jonas’if they do votes to bypass board, they effectively state that they don’t trust that board will execute the delegation as they want them to
jonas’that’s distrust
pep_I understand what you're saying, I just don't see that as distrust
Dele (Mobile)has left
Danielsomething something never ask the people unless you know the outcome
jonas’I fail to see how you can’t, pep_, and I’d like to know your rebuttal to my arguments
mathijshas left
mathijshas joined
stpeterhas left
pep_I'm not sure how to formulate that indeed. I'll sleep over it
larmajonas’, I think it makes sense in cases where the board doesn't want to decide over the members
winfriedhas left
winfriedhas joined
mathijshas left
mathijshas joined
sonnyhas left
mukt2has joined
Danielfrom the e2ee sig proposal
> Represent the interests and requirements of the XMPP community during the development of end-to-end encryption protocols that are non-exclusive to XMPP.
that opens the interesting question if the xsf would be willing to / has the funds to sponsor a representative to go to one of the IETF MLS meetings
larmajonas’, I am not sure if that ever was a thing in the XSF, I personally know that from one organisation, the directors just refuse to do certain things without asking the members first, because they feel obligated to act in the members interests and thus if they feel they don't know exactly what the members want, they will ask them
Kevlarma: I think there are plenty of good reasons for Board to ask the Members on something.
Shellhas left
Shellhas joined
dwdDaniel, Yes, but that line was the single line that I objected to.
Danielbecause i wouldn’t want to pay that out of my own pocket (never mind the fact that i probably wont be a good person to to that because i don’t know anything about cyrpto)
KevI think that's a very different prospect from the Board making a decision on something that our process says is Board's to decide, and the Members then calling a vote to overturn it.
dwdDaniel, Actually, you'd be great - the problem that group has is in practical messaging, not the crypto side.
dwdDaniel, (I objected to that line because I think external representation is a Board thing)
pep_jonas’, or maybe, even if it's distrust, I actually find this healthy, and that it should be common practice to challenge board every so often. "A majority of Yes in a vote for a president/government is not especially a good sign" 🙂
larmaKev, I'd kind of believe that in most cases when it says, board decides, the motivation is not that board does what makes most sense for them, but board does what would be what members want, no?
ralphmDaniel, I don't think physical presense is required to participate in MLS at all.
Danielbut representing our interests within the mls working group is important and should be done before it is too late (i think paul might have actually put that into the proposal because i said something along those lines)
dwdralphm, It's really really helpful.
Danielthat
Kevlarma: I think that's a very complicated question that doesn't have a pithy answer.
ralphmbut I am not opposed to sponsoring a visit to an IETF
dwdDaniel, I've been to a couple of the meetings (London IETF and the London Interim). Really useful to understand where they are, and really useful to be able to provide input.
KevWe have sponsored a visit to an IETF previously, haven't we?
ralphmKev: we did?
dwdKev, Yes, I think so. Previous London IETF, we sponsored Thijs, didn't we?
KevMaybe I'm misremembering, I thought we sponsored Thijs to attend IETF London a while back.
ralphmhttps://ietf.org/how/meetings/upcoming/
ralphmThe next 'close' one for most of us is 108, in July, Madrid
Danielregrets not having participated in the jmap working group before it was too late
emushas joined
dwdralphm, MLS gets a lot of its work done in f2f interims, too.
Marandahas left
Marandahas joined
dwdralphm, Of which there's one tomorrow: https://datatracker.ietf.org/meeting/interim-2020-mls-01/session/mls
ralphmThere's one this weekend it seems
ralphmAgenda is empty though
Shellhas left
Shellhas joined
sonnyhas joined
pep_"When" the E2EE SIG gets approved (when we figure this out :p), I'm also happy to use our dormant money for this
dwdralphm, Daniel https://github.com/mlswg/wg-materials/blob/master/interim-2020-01/README.MD
ralphmhah
ralphmBe sure to read the NOTE WELL!
neshtaxmpphas left
Shellhas left
Shellhas joined
winfriedhas left
winfriedhas joined
adiaholichas joined
Danielthe mls@jabber.ietf.org channel only has known xmpp people in it :-/
dwdI think it only gets traffic during meetings normally.
Ge0rGSeriously people, what happened to this MUC? I've taken most of today just to catch up with the logs
Danielas long as it actually does it's fine
Ge0rGCan we please have a bot that will auto-kickban on mention of "GPL"?
moparisthebestGe0rG, will it exclude AGPL ?
dwdDaniel, Sadly not very much during Interims.
Danielit says i MUST register. it doesn’t say where
moparisthebestok I'll just start using GNU General Public License everywhere, break my keyboard
Ge0rGmoparisthebest: after seeing other people engage with you on this topic, let's just agree to disagree.
moparisthebestone person seemed to at least semi-agree, and I suspect membership in general might agree more than majority of this room, but I guess we'll find out won't we
Ge0rGKev: I somewhat like your idea of [show fallback messages? (y/n)], but I fear that having different unsupported fallbacks in the same chat flow might cause issues as well.
KevGe0rG: It is certainly not a perfect solution.
Ge0rGNor is the fallbacks XEP.
Ge0rGBut we don't strive for perfect, merely for good enough.
KevI can't immediately think of anything better - although that might be a lack of imagination.
dwd[Unable to display message, fallback displayed]
** Something like this? **
Ge0rGKev: add the namespace and a human-readable description of the fallback-inducing element into the fallback element, have the client maintain a list of checkboxes :P
Ge0rGdwd: that's an interesting angle indeed: "Your client is too old and doesn't support all elements of this message"
pdurbinhas joined
Lancehas joined
dwdThat was what I was thinking a client might do. A server might not index it for MAM, or something.
Ge0rGdwd: is there a reason for <fallback> not containing the namespace of the causing element?
stpeterhas joined
dwdGe0rG, Yes.
dwdGe0rG, I didn't think of it.
Ge0rGdwd: what is the reason for <fallback> not containing the namespace of the causing element?
Ge0rGGreat!
Ge0rGdwd: is there _still_ a reason for <fallback> not containing the namespace of the causing element?
dwdGe0rG, I'm somewhat ambivalent to that - I don't know what a client/server would do differently.
dwdGe0rG, But equally, it does no harm.
dwdGe0rG, It'd be a good reason *not* to try to put this in Hints, though.
Ge0rGdwd: it could fetch the XEP that defines that namespace from the registry :P
dwdAND USE MACHINE LEARNING TO AUTOMATICALLY IMPLEMENT THE XEP AND THEN STORE THE RESULT IN THE BLOCKCHAIN.
dwdSorry, don't know what came over me then.
Ge0rGdwd: who are you and what have you done to dwd?
Ge0rGwith all the roster shenanigans, probably dwd got replaced by aliens.
adiaholichas left
adiaholichas joined
mathijshas left
mathijshas joined
larmadwd, happened to have read my comment re partial fallback body?
Ge0rGlarma: please don't add more complexity
pep_It does actually seem pretty useful though..
Ge0rGlarma: I know it's sexy to put five different things into one message, but it makes everything more complicated
larmaGe0rG, if it's not in there it has to be somewhere else
Ge0rGpep_: it should be redefined in terms of fastenings.
larmaSo this is only for fastening, not for anything else?
dwdNo, it's for everything where we're only using <body/> as a fallback.
Ge0rGlarma: do you have a convincing use case for that?
pdurbinhas left
larmaGe0rG, reply to
Ge0rGI think we need to revive https://xmpp.org/extensions/xep-0226.html
Ge0rGlarma: ah, right. Hm....
Ge0rGlarma: what if we just ignore the problem of legacy clients showing a fallback body in a slightly awkward way?
larmaGe0rG, what do you mean?
dwdlarma, Ah, that. Yeah, I figured that it'd be an all-or-nothing; I think something like you're proposing ought to be in one of our many markup/down/sideways things.
Ge0rGlarma: I'm just thinking out loud. I suppose we'd have to add a new <reply> element that would contain just the body of the reply for that to work
dwdlarma, But, mea culpa for not responding.
larmaGe0rG, I was thinking along those lines https://gist.github.com/mar-v-in/8f66872bb533f7e805fb174e341be992
eevvoorhas left
j.rhas left
calvinhas left
Ge0rGlarma: yeah, I understand that. Would also work great for Reaction fallbacks :D
larmaGe0rG, you mean: we can explore if this would also work great for reactions fallbacks and then decide it doesn't 😀
larmabut yeah, there are various things where it would be handy
Ge0rGlarma: the question is: is it worth the added complexity?
larmaIf the complexity is not added to <fallback /> it would have to be added to reply-to or reply-to will not be backwards compatible
larmaI don't like the third option really
larmaalternatively we can have something else for that
dwdlarma, It's what we have now.
dwdlarma, By which I mean, I've just replied to you. And again here.
mukt2has left
Shellhas left
Shellhas joined
larmadwd, I think we can also do this as an annotation mostly for fastenings, then both (what it is a fallback for and the begin/end thing) wouldn't be necessary
j.rhas joined
larmaIt would still make sense to have the other thing though
larmabut could be separated from each other
larmabecause my usecase is obviously completely unrelated to fastening
XSF Discussion - 2020-01-10