- adiaholic has left
- mukt2 has joined
- andy has left
- stpeter has joined
- mukt2 has left
- debacle has left
- murabito has left
- beta has left
- beta has joined
- stpeter has left
- beta has left
- beta has joined
- lskdjf has left
- beta has left
- beta has joined
- Vaulor has left
- Vaulor has joined
- stpeter has joined
- mukt2 has joined
- krauq has left
- mukt2 has left
- krauq has joined
- andrey.g has left
- adiaholic has joined
- neshtaxmpp has left
- neshtaxmpp has joined
- stpeter has left
- stpeter has joined
- pdurbin has joined
- beta has left
- Yagiza has joined
- beta has joined
- andrey.g has joined
- pdurbin has left
- mukt2 has joined
- Nekit has joined
- Lance has joined
- stpeter has left
- mukt2 has left
- andy has joined
- beta has left
- pdurbin has joined
- lorddavidiii has joined
- beta has joined
- adiaholic has left
- adiaholic has joined
- beta has left
- karoshi has joined
- pdurbin has left
- beta has joined
- paul has joined
- stpeter has joined
- pdurbin has joined
- stpeter has left
- serge90 has left
- serge90 has joined
- sonny has left
- Tobias has joined
- sonny has joined
- sonny has left
- serge90 has left
- serge90 has joined
- wurstsalat has joined
- serge90 has left
- lorddavidiii has left
- lorddavidiii has joined
- lorddavidiii has left
- lorddavidiii has joined
- lorddavidiii has left
- lorddavidiii has joined
- sonny has joined
- Steve Kille has left
- Steve Kille has joined
- sonny has left
- lovetox has joined
- lovetox has left
- serge90 has joined
- Steve Kille has left
- goffi has joined
- mathijs has left
- mathijs has joined
- beta has left
- UṣL has joined
- emus has joined
- beta has joined
- beta has left
- emus has left
- emus has joined
- alameyo has left
- alameyo has joined
- Lance has left
- mathijs has left
- mathijs has joined
- Lance has joined
- waqas has joined
- mukt2 has joined
- sonny has joined
- Lance has left
- beta has joined
- mukt2 has left
- debacle has joined
- beta has left
- Max has left
- Lance has joined
- beta has joined
- Wojtek has joined
- Lance has left
- serge90 has left
- larma has left
- larma has joined
- serge90 has joined
- Nekit has left
- Nekit has joined
-
dwd
larma, 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".
-
dwd
larma, And you publishing the constants under a difference license wouldn't mean that you exclusively took liability either.
- Lance has joined
- Dele (Mobile) has joined
- adiaholic has left
- lorddavidiii has left
-
dwd
moparisthebest, 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).
- lorddavidiii has joined
-
dwd
I 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.
-
flow
damn you "WhisperRatchet". But then again, I am fine with a XEP that requires GPLed compatible implementations.
-
Guus
I 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.
-
flow
So leaving the bad quality of the OMEMO XEP beside, the real question is if you think that encumbers the XEP
-
flow
which potentially leads to the question if the GPL increases or decreases your freedom
- Lance has 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
-
dwd
flow, 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.
-
Guus
That'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.
-
flow
dwd, 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
-
dwd
Because GPL is a useful way to generate a licensing revenue stream for people who don't want to (or cannot) use it.
-
flow
Guus, they can only pursuing legal fights over it if they assume a violation of the GPL
-
dwd
flow, I mean, GPL is definitely an "encumberence" by any reasonable definition. The question is whether the XSF accepts this encumberence.
-
flow
e.g. if matrix would have build OLM on the wire protocol of libsignal, then all matrix implementations would be required to be GPL compatible
-
flow
dwd> flow, I mean, GPL is definitely an "encumberence" by any reasonable definition. I tend to disagree
-
dwd
flow, But they changed the constants. The wire format can - probably - be reverse engineered.
-
dwd
flow, How is the GPL not an encumberence to developers? It requires them to license a particular way.
- debacle has left
-
larma
Guus, 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
-
dwd
larma, 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.
-
Guus
What flow wrote, if accurate, would be a very nice stick against what we can measure things.
-
Guus
This bit, I mean: > he question is if we are fine with a XEP that requires GPL compatible implementations✎ -
larma
dwd, (re info string) I already asked for some help from legal experts on that matter, so we probably should just wait for their input
-
Guus
This bit, I mean: > the question is if we are fine with a XEP that requires GPL compatible implementations ✏
-
larma
dwd, 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
-
dwd
Guus, Well, XEP-0001's Objectives, and particularly Objective 4, would seem to state that we are not.
-
larma
Also there was something with Twitter in Signals history (them buying the company and then releasing as open source?)
-
flow
dwd, 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
-
Guus
dwd 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).
-
dwd
flow, "requires some things" is surely what encumberence means.
- Max has joined
- adiaholic has joined
-
flow
dwd, well, the gpl is only a burden people who can or are not willing to comply to it
-
dwd
flow, How does that differ from, say, requiring a paid license?
- adiaholic has left
-
flow
a, potentially large, part if the xmpp community is probably fine with it
-
Guus
flow, that goes for _any_ restriction. 😃
- adiaholic has joined
-
flow
Guus, well there are restrictions that apply to everyone
-
Guus
The XSF is explicitly not in the business of making things unavailable to non-FLOSS parties.
-
Guus
requiring GPL would hurt that.
-
Guus
Also, it'd hurt us - as major players can't use (part of) XMPP.
-
Zash
You should be able to implement based on spe✎ -
flow
Guus, it's not like we require all e2ee schemes to be gpl only
-
Zash
You should be able to implement based on specification alone ✏
-
Zash
+ dependency specs
-
Guus
The precedent is dangerous.
-
Guus
I strongly feel that we should not go down that path.
-
Guus
I've already had customers worry about licensing as-is.
-
Guus
Note that the people in here are not a good cross section of our users.
-
Guus
people in this MUC tend to lean a lot more towards open source principles than many of our (commercial) users.
-
Guus
which makes me think that this quote is not quite accurate: > a, potentially large, part if the xmpp community is probably fine with it
-
flow
I 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.
-
flow
dwd, what Zash said
-
dwd
flow, What?
-
Guus
I 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).
- sonny has left
- sonny has joined
- sonny has left
- sonny has joined
-
Guus
The XSF _not_ publishing the OMEMO XEP does not limit anyone from implementing it, right?
-
dwd
flow, 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?
-
Guus
I'd prefer to publish only XEPs that are usable by both commercial and non commercial parties.✎ -
Guus
I'd prefer the XSF to publish only XEPs that are usable by both commercial and non commercial parties. ✏
-
dwd
flow, How does this differ from, for example, the RTMP licensing requirements that we rejected?
-
flow
Guus, see that is probably where we differ
-
Guus
flow yeah, I think so. A matter of different opinion.
-
dwd
Guus, 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).
-
flow
dwd, sorry, lunch, not ignoring you, but hungy
- sonny has left
- sonny has joined
-
Guus
dwd 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.
-
Guus
accessible/usable/permissible, license wise. I'm struggling to find the right words.
-
dwd
Guus, 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.
-
Guus
dwd right. That may warrant an update of our objectives then.
-
Guus
as I do agree with you that GPL is restrictive.
-
dwd
Guus, The objectives are clear enough, IMO. It's whether the enforcement at the Draft->Final stage needs improvement.
-
dwd
Just 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).
-
Guus
shoot. I should've done stuff by now.
-
nyco
Guus 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
-
Guus
What 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.
-
Guus
nyco looks good. I've added some of the standard headings to what you already had.
-
nyco
ok, thx
-
Guus
shoot. I should've finished stuff by now.
- Guus disappears
-
pep.
> flow> dwd> flow, I mean, GPL is definitely an "encumberence" by any reasonable definition. > I tend to disagreee I also disagree
-
dwd
pep., 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)
- sonny has left
-
dwd
nyco, Thanks, I hope I captured the conclusions accurately. Summarizing the debate in an unbiased way would be tricky for me, I think.
-
nyco
agree, 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_Martin has left
-
dwd
pep., 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_Martin has joined
-
dwd
pep., 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".
- debacle has joined
- sonny has joined
- Nekit has left
- mukt2 has joined
-
dwd
Sure, 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
-
dwd
pep., 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.
- Nekit has 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
-
dwd
pep., 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)
-
dwd
pep., 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)
- mukt2 has left
-
Ge0rG
It's really astonishing how much vitriol can be released by a bunch of short ASCII strings
-
pep.
:)
-
dwd
pep., 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.
- beta has left
-
!XSF_Martin
If 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
-
dwd
The license surely doesn't apply to them. They can release the iOS app under a non-GPL license.
-
dwd
Oh, wait, Monal and Chatsecure. Yeah, they're probably technically in breach.
-
dwd
But 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_Martin
Ah, you meant signal.
-
Kev
You 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)
-
larma
https://github.com/signalapp/libsignal-protocol-c#license
-
dwd
Apple 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
-
dwd
AH, there we go, good spot.
-
Guus
On 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.
-
larma
So 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
- Lance has joined
-
larma
pep., no the license remains what the copyright holder grants you
-
larma
it is probably against Apples ToS to do so
- pdurbin has left
-
larma
but 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
- debacle has left
- Martin has joined
- debacle has joined
- Martin has left
- adiaholic has left
- adiaholic has joined
- Wojtek has left
-
dwd
larma, I don't see how that removes the copyright.
-
larma
it doesn't
-
larma
but it's under MPL then
-
larma
which is more permissive than GPL
-
larma
And should allow non-free implementations IIRC
-
flow
yep, without re-reading the MPL again, that is probably correct. If so, that's a nice loophole ;)
-
larma
flow, there are probably a bunch of other loopholes, that's why I have been asking for some legal help on that
-
larma
for 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
-
flow
larma, i'm sure interested in the result/outcome of that legal help :)
-
flow
hmm, what if the program outputs itself?
-
larma
well, if the program outputs itself it remains under the GPL
-
Guus
All this doesn't change the fact that it's a bad idea to publish a XEP on the premise of a loophole.
-
flow
ahh, 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"
-
larma
I wouldn't call it a loophole
- mukt2 has joined
-
larma
If 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)
-
larma
because you are outputting the hash of that string (kind of)
-
Guus
If it directly opposes the intended application by OWS, it's undesired for the XSF to act on, in my opinion.
-
larma
We can still ask OWS on their opinion on that matter
-
Guus
I'm very much in favor of thta.✎ -
Guus
I'm very much in favor of that. ✏
-
pep.
Me too
-
Guus
But any talk about exploiting loopholes would be very unhelpful.
-
Guus
phonecall, afk
- Lance has left
- Maranda has left
- Maranda has joined
-
Guus
We'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.
-
Guus
At the very least not legally.✎ -
Guus
I'd be pissed if someone uses my stuff in a way that I don't want it to be used.
- beta has joined
-
pep.
Guus, aren't that what lawyers are for? :x
-
pep.
Finding loopholes.
-
Guus
At the very least not morally. ✏
-
pep.
isn't that*
-
Guus
(see my message correction: I ment 'morally', not 'legally')
-
pep.
:)
-
larma
Guus, 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
-
larma
Currently 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
-
Guus
I care about the morality of this.
-
Guus
We put ourselves in that position - that's not on OWS.
-
larma
Guus, sure so it's also on us to ensure we are in a better position
-
Guus
If we are to use their stuff, it needs to be clear that it is permissible to do so - morally and legally.
-
Guus
We should talk to them. If they say "no", then it's a no.
-
larma
A moral permission alone does not help, but I am happy to agree that legal permission alone is also not enough
-
Guus
I very much do not want to be in the business of abusing others by means of loopholes.✎ -
Guus
I very much do not want to be in the business of abusing others by means of legal loopholes. ✏
-
Guus
Also, by discussing these loopholes, we're actively hurting our chances of getting permission.
-
Guus
In their shoes, I'd take offense.
-
larma
although I'd like to point out that for the matter of the specification, actually only the legal side matters
-
larma
It would be up to implementations then to care about the moral side
-
Guus
Oh, whatever we do must be legally valid, I don't argue that.
-
larma
by using libsignal you would be clearly on the moral side anyway
-
larma
so the only question that remains (if it is legally fine to extract those strings) is if non-GPL implementations of the spec are moral
-
Guus
My 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)
-
larma
Is it morally better to trick out OWS by not using those strings (like olm)?
-
Syndace
I 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.
-
Guus
I'm assuming OWS has no issue with Olm (as OWS released the specs based on which is was build). That would be fine.
-
flow
larma, 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.
-
flow
Syndace, the discussion is not about the spec but about the libsignal implementation(s)
-
flow
which 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, ^
-
flow
Syndace, 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"
-
Guus
Maybe is should have types "applications of signal" instead of "implementations".✎ -
flow
the spec is open standard an implemenations can be under any license as far as I can tell
-
Guus
Maybe is should have typed "applications of signal" instead of "implementations". ✏
-
larma
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
-
Syndace
Okay 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
-
Guus
true, but I don't think that's what OWS wants.
-
Guus
They've not challenged Olm, did they?
-
larma
They 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
- mathijs has left
- mathijs has joined
-
larma
why would they care about those strings, if it wasn't for the protocol?
-
Guus
We'll have to talk to them to be sure.
- Wojtek has joined
-
flow
what Guus said
-
Guus
the strings might be a way to control interop.
- beta has left
-
pep.
Guus, our goal is not to do interop with them
-
larma
there 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
-
Guus
maybe 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.
-
flow
But 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
-
Syndace
flow: +1, that's how I understand it
-
Guus
flow meaning that they would be fine with 'Olm', right?
-
flow
Guus, I assume so, yes
-
flow
(But I haven't look at Olm in a while)
-
Guus
That's also how I think things stand.
-
Guus
but we'll have to check with them.
- beta has joined
- mathijs has left
- mathijs has joined
-
flow
Unfortunately, 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
- mukt2 has left
-
Syndace
Exactly. 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.
- lskdjf has joined
-
flow
I 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
-
Syndace
The 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.
-
dwd
flow, I agree, but would add that if omemo were published outside of the XSF it would be perfectly fine to leave it as-is.
-
flow
But obviously it is not my call but up to the ecosystem and community of (implementation and specificatin) developers to decide
-
Syndace
But yes, a breaking change is a must if we don't want OMEMO to stay as it is forever
- adiaholic has left
-
larma
I 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
-
flow
Syndace, it is perfectly fine that you want to avoid namespace bumps whenever possible
- mukt2 has joined
-
flow
Syndace, 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 :)
- Shell has left
- Shell has joined
-
flow
Syndace, 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.
-
dwd
Weird. Someone just pinged my dev workstation's XMPP server from the Seychelles - sent a stream open, waited for the features, and dropped.
- Martin has joined
-
pep.
Teh anonymous are onto you
-
dwd
larma, I don't think it does need the constants to remain the same if you're doing a flip-over, does it?
-
Syndace
We (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.
-
dwd
pep., They'll be massively confused at hitting a healthtech messaging platform that just happened to speak XMPP.
-
jonas’
Shodan.io?
-
flow
Not that it matters, but has the E2EE SIG already offically been formed?
-
dwd
jonas’, This? No, forwardhealth.co
-
dwd
flow, 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
-
Daniel
flow, 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
-
Daniel
we just haven’t had the time to actually write something down
-
flow
I see
-
Daniel
which is what we are trying to do soon(tm) as Syndace pointed out
-
dwd
Daniel, FWIW, I appreciate that it's transparency that takes effort and deliberation; secrecy is the default unless a considerable effort is made.
- j.r has left
-
flow
It'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
-
larma
dwd, 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)
-
dwd
larma, I think you have to handle it via something similar to happy eyeballs, but it ought to work. It's unpleasant, I agree.
-
Syndace
larma: I don't think the goal of OMEMO2 is to stay backward compatible.
-
flow
especially if people insist on their approach without at least looking for compromises
-
larma
Syndace, I think there are different things going under the name of OMEMO2 😉
- MattJ resists writing mod_omemo which automatically translates between omemo1 and omemo2
-
Kev
If you can write such a thing, then at least omemo1 is horribly broken, no?
-
larma
If we just change the wire format it would be possible
-
MattJ
All E2EE is horribly broken, because the endpoints are users :)
-
Kev
Right, if that's the only thing that changed.
-
Syndace
larma, changing only the wire format doesn't help anybody.
-
jonas’
MattJ, *devices, not users
-
larma
Syndace, so what issues are there that you'd like to solve?
-
Daniel
yes 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
-
MattJ
jonas’, the devices generally defer trust decisions to the users (or TOFU/BTBV/etc.) which makes life easier
-
Kev
I think Dave's right that it'll end up being happy-eyeballs-ish.
-
Syndace
larma: one second, having trouble to find the link on mobile
- j.r has joined
-
Syndace
Here you can find a list of things we want to change or consider for OMEMO2: https://github.com/Syndace/xeps/projects/1
-
Syndace
And that list does not include the actual change of the wire format :D
-
flow
pah, no need to state the obvious ;)
- sonny has left
- beta has left
- beta has joined
-
larma
Syndace: 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
-
larma
Also honestly it would be better if we stayed compatible with libsignal if possible
- sonny has joined
-
larma
Because there are a bunch of libsignal implementations already
-
Syndace
Well then we won't ever move away from GPL
-
Zash
"Because popularity" ?
-
flow
larma, surely you could take those implementations and change the constants
-
jonas’
flow, if the implementations directly link against libsignal?
-
flow
jonas’, hmm?
-
Syndace
We could fork libsignal and change the constants
-
larma
Dynamic linking is a thing
-
flow
of 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
- Martin has left
-
flow
jonas’, potentially yes, but maybe the libsignal library provides an interface to feed those constants into it
- Martin has joined
-
flow
my 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
-
flow
but 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
-
flow
yep, but OTOH omemo implementations have already gone through review, that may happens with new libraries too
-
jonas’
did they?
-
flow
and you can't really forbid people from publishing a library
-
flow
jonas’, https://conversations.im/omemo/audit.pdf
-
flow
plus 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..
- Vaulor has left
- emus has left
- emus has joined
- beta has left
- mukt2 has left
- Martin has left
- Martin has joined
- Shell has left
- Shell has joined
- pdurbin has joined
- sonny has left
- beta has joined
- waqas has left
- adiaholic has joined
- pdurbin has left
- mukt2 has joined
- aj has left
- Lance has joined
- Vaulor has joined
- adiaholic has left
- adiaholic has joined
- sonny has joined
-
moparisthebest
> Guus: I'd prefer the XSF to publish only XEPs that are usable by both commercial and non commercial parties.
-
moparisthebest
Great so for example the GPL
-
moparisthebest
Name one large commercial entity that doesn't use Linux for instance
-
dwd
moparisthebest, I don't think that's what Guus actually intended to mean - I assumed it to mean FLOSS vs non-FLOSS.
-
moparisthebest
This "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
- eevvoor has joined
-
moparisthebest
And to be honest I couldn't care less about non-FLOSS, they made their bed, they can lay in it
-
dwd
moparisthebest, 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.
-
moparisthebest
They always have the option to go FLOSS
-
moparisthebest
"doc it hurts when I do this" "stop doing it"
-
Guus
I strongly feel that the XSF should not adopt the strategy of telling people that.
- mukt2 has left
-
Guus
We'd loose more potential users than that we'd make people use FLOSS.
-
dwd
moparisthebest, You're saying any use of XMPP should be GPL? Like, say, Fortnite? I can't see that being viable.
-
Guus
What I ment to say was that I feel that the XSF should not publish XEPs that are only suitable for one particular license model.
- adiaholic has left
- beta has left
-
flow
Guus, I think it's the other way around: we loose potential community members if we forbid "gpl-only-xeps"
- beta has joined
-
flow
I think part of the people currently in this room are here because of omemo
-
Guus
flow, I'm talking about "people/organizations applying XMPP", you're talking about "members of the XSF" I think.
-
moparisthebest
Sure I'd be fine if all XMPP implementations had to be GPL, actually AGPL would be better
- Martin has left
-
dwd
flow, 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.
-
moparisthebest
That's well put flow , I'm explicitly here because of the open source freedom, nothing else
-
flow
Guus, no I mean community members in the bordest sense, taht is XSF members and ppl/orgs applying XMPP
- Martin has joined
-
jonas’
I agree with Guus
-
dwd
moparisthebest, 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
-
Wojtek
I 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
-
Zash
An 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.r has left
-
moparisthebest
And 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
-
dwd
moparisthebest, What if we put that XEP into a compliance suite?
-
moparisthebest
That part I wouldn't consider an open standard
-
moparisthebest
A gpl standard I would consider open
-
Zash
"a gpl standard" doesn't even make sense!
-
dwd
moparisthebest, You literally cannot have a "GPL specification" though.
-
moparisthebest
dwd: no one has to care about that either
-
moparisthebest
Isn't the argument that omemo is gpl
-
moparisthebest
Or requires gpl, that's what I mean
- j.r has joined
-
Zash
The 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.
-
flow
dwd, right, hence I wrote "gpl-only-xep"
-
Zash
Doesn't help that this thing is a GPL library
-
flow
but otoh I am not sure if we haven't here the case of a specifcation which requires gpl
-
dwd
flow, Indirectly, we do. But this is a combination of two problems.
-
flow
if I where to write the constants in the xep with a disclaimer that I have extracted them from an gpl implementation…
-
flow
it's complicated → time for coffee
-
dwd
flow, Can't, since that would violate the copyright.
-
dwd
flow, Our XEPs are explicitly under an MIT license.
-
flow
fair point, then I do not write them into the xep but into some other document
-
Guus
> it's complicated → time for coffee +1 ☕
- beta has left
- beta has joined
-
Zash
☕ !
- Lance has left
- tao has joined
- Shell has left
- Shell has joined
- tao has left
- pep_ has joined
- adiaholic has joined
-
moparisthebest
so the fix is just to get the board to allow our XEPs to be under MIT *or* GPL, author's choice
-
moparisthebest
then the omemo details can be published in the XEP and everyone is happy
- winfried has left
- winfried has joined
-
moparisthebest
we could have a whole new category of GPL'd specs called GEPs :)
-
Guus
I'm very much against this.
-
Guus
People will need to start to worry if they can actually use a XEP.
-
moparisthebest
my point is they already have to
-
Guus
not from a license perspective - other than with OMEMO?✎ -
Guus
currently? not from a license perspective - other than with OMEMO? ✏
-
moparisthebest
yes, 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.
-
moparisthebest
if my business were to rely on it, I'd need a lawyer or something to do that presumably
-
pep_
As moparisthebest says
- adiaholic has left
-
pep_
The IPR only says "if something happens, it's not us!!"
-
pep_
(or at least that its legal value.)
-
Guus
There'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
-
Guus
If XMPP would only be observed as doing the latter, it wouldn't even be considered in many businesses.
-
Guus
You'd not even get a foot in the door, so to speak. It'd be dismissed outright.
-
Guus
I'm not saying I agree to that, or that those businesses _need_ to dismiss it - but it's what will happen.
-
moparisthebest
it'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
-
dwd
moparisthebest, I'm assuming you know that first statement is entirely wrong?
-
dwd
moparisthebest, And therefore the second.
-
moparisthebest
I 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
-
moparisthebest
it's crystal clear, it's an open standard, what else are we after
-
Guus
You're not very 'open' if you're requiring a specific license, in my opinion.
-
pep_
This has nothing to do with 0987 referencing $implementation
-
moparisthebest
dwd, 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 ^
-
dwd
moparisthebest, You're attempting to require to prove a negative.
- adiaholic has joined
-
Guus
I'm off to get the kids. later!
-
moparisthebest
bottom line is this, if $company implements a XEP and that XEP has problems, who is legally responsible? $company or the XSF ?
-
dwd
moparisthebest, There is a world of difference between striving to achieve a level playing field for everyone, and not aiming for that.
-
moparisthebest
I think it's always $company and therefore they can't rely on anything the XSF says
-
Syndace
If 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
-
moparisthebest
dwd, I don't think we should aim for that in any way no
-
dwd
moparisthebest, OK, but that is an entirely different argument. You're arguing we should not be an open standards organisation.
-
moparisthebest
no I'm arguing that a GPL-requiring standard is an open standard
-
pep_
I always enjoy how everybody uses "open" in so many ways
-
moparisthebest
and if someone chooses not to implement it, that's on them
-
dwd
moparisthebest, Well, you're very much in the rough there. Every other organisation with a definition of what "open standard" means would not agree.
- winfried has left
- winfried has 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)
-
moparisthebest
that's fine, reasonable people can disagree :)
-
moparisthebest
jonas’, I'd disagree, the first hinders implementors (though I'd also be fine with it, just wouldn't call it a open standard)
-
dwd
moparisthebest, 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.
-
moparisthebest
a 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
-
dwd
moparisthebest, But the act of not choosing my commercial license is surely their own hinderence too?
-
dwd
moparisthebest, 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.
-
moparisthebest
and I'd simply choose not to use it
-
moparisthebest
I don't know why we'd require anything else of anyone
-
dwd
moparisthebest, But itd still be an open standard by your unique definition?
- mukt2 has joined
-
moparisthebest
not an open license not an open standard I guess ?
- adiaholic has left
- adiaholic has joined
-
dwd
moparisthebest, That's not what the term means.
-
moparisthebest
I guess there is no point in arguing over semantics, which I probably started so my bad
-
moparisthebest
bottom line, I'm perfectly fine with a XEP that requires implementations to be GPL for whatever reason
-
moparisthebest
I'm also fine with a XEP that requires $proprietary_license, I'd just ignore it
-
dwd
And 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.
-
moparisthebest
whatever that ends up being I'm fine with
-
moparisthebest
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
-
moparisthebest
I 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
- adiaholic has left
-
Guus
> I don't care about non FOSS anything You don't have to, but the XSF should not exclude XMPP from nonFloss.
- adiaholic has joined
-
moparisthebest
I don't mind if it does, since I don't care about any non FLOSS people/things/companies
-
moparisthebest
how does it help any of us if say slack is using XMPP underneath? meh
- calvin has 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)
-
moparisthebest
ideally 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.
-
dwd
For 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.
-
moparisthebest
Guus, and you wouldn't be employed if those were relicensed GPL down the line?
- UṣL has left
-
moparisthebest
interesting dwd , I'd be curious what the reason is for that or the specific law
-
Guus
moparisthebest: those solutions wouldn't have been based on XMPP then
-
pep_
dwd, I'm not especially happy with OSI fwiw.
-
moparisthebest
Guus, eeehhh that seems again like "businesses won't use GPL" and that's simply not true, Linux
-
Guus
And relicensing is absolutely out of the question in many board rooms.
-
dwd
moparisthebest, It's not law, but policy.
-
moparisthebest
and I don't care about those board rooms, they can roll their own xmpp-like replacement and die
- mukt2 has left
-
dwd
moparisthebest, 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.
-
moparisthebest
some better company will come along, take over their business, and hire their devs :)
-
Guus
You 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
-
Guus
Gtg, kid is here
-
moparisthebest
you misunderstand me, maybe that's a huge segment, I don't care about those use-cases or organizations
-
dwd
pep_, 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.
- adiaholic has left
-
pep_
dwd, and that's one of my issues with them
-
moparisthebest
this 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
- Vaulor has left
- Vaulor has joined
-
moparisthebest
I guess a decent proxy might be how many support PGP or OTR? my guess is also none
-
dwd
moparisthebest, Entirely possible that it's none, I agree. But what if it were something else?
-
dwd
moparisthebest, 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.
-
moparisthebest
I 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"
-
dwd
We can't *have* a legal opinion if we're not lawyers.
-
pep_
We might, wrongly :-°
-
Holger
Companies 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.
-
MattJ
Agree. 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..
-
MattJ
Requiring implementations be GPL will not make closed-source implementations become GPL. It will just make closed-source implementations become non-interoperable.
-
MattJ
Which is not a world I want to live in, which is why I dedicate so much to open standards
-
moparisthebest
MattJ, and how is that different than the current situation?
- calvin has left
- calvin has joined
-
moparisthebest
reworded, name an existing public federated interoperable closed source implementation
-
MattJ
moparisthebest, we want to fix the current situation. As I understand it people are arguing that the current situation is acceptable (GPL-only implementations allowed)
-
MattJ
moparisthebest, that doesn't make sense - this whole discussion is about the fact that closed-source interoperable implementations are not possible
-
moparisthebest
so it hasn't happened in 21 years but maybe it'll happen soon? meh
-
MattJ
because of the GPL restriction
-
dwd
moparisthebest, *public*? That's difficult. But federated, partially closed-source (and partially open-source), and interoperable: https://en.wikipedia.org/wiki/Federated_Mission_Networking
-
dwd
moparisthebest, 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.
- winfried has left
-
moparisthebest
ok 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? :)
- winfried has joined
-
dwd
moparisthebest, Neither TLS, PGP, or MLS require GPL, so that rather falls down as an argument.
-
moparisthebest
doesn't mean we couldn't do it differently
-
dwd
moparisthebest, Doesn't mean we have to do it differently either.
- mathijs has left
- mathijs has joined
- mukt2 has joined
- lorddavidiii has left
- lorddavidiii has joined
-
pep_
(fwiw, I wouldn't especially be proud that the army is using XMPP..)
-
moparisthebest
govts aren't really bound by licenses/GPL anyway
-
MattJ
pep_, that's going down yet another rabbit-hole - if you want to choose who is even allowed to use your technology/software
-
MattJ
At that point yeah, we might as well just remove any reference to "open"
-
ralphm
I 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.
-
dwd
moparisthebest, They seriously are. I could tell some tales about that, but they're real sticklers for licensing.
-
ralphm
I for one find that acceptable for the XSF.
-
moparisthebest
dwd, they aren't even bound by laws, UK for example just broke a ton of laws then changed them retroactively? :)
-
MattJ
ralphm, acceptable? or unacceptable?
-
ralphm
hah, *not* acceptable.
-
MattJ
Phew
-
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
-
ralphm
I do not intend to take any steps to exclude any field of endevour from our standards process or membership.
-
MattJ
Me neither
-
pep_
ralphm, who is talking about excluding commercial entities
-
ralphm
pep. expecting commercial entities to adhere to GPL-type licensing for so-called open standards is not a realistic world view in my opinion.
-
moparisthebest
GPL doesn't in any way exclude commercial entities though
-
pep_
^
-
moparisthebest
and we are talking on an individual XEP basis
-
ralphm
except it does
-
pep_
ralphm, that's maybe your biased view. Many implementations succeed in using copyleft licenses and being sustainable
-
MattJ
moparisthebest, you said yourself (iirc) that such a XEP wouldn't be able to be included in the compliance suite
-
MattJ
I mean, it could, but it means it's not quite as simple as "it's just one XEP"
- calvin has left
-
ralphm
I 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.
-
moparisthebest
ralphm, maybe you mean it excludes non-GPL implementations, sure, but those could be commercial or non commercial
-
MattJ
We'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?
-
ralphm
The XSF, from the very beginning.
-
pep_
"The XSF" is not one person
-
Zash
So much text produced over this issue.
-
MattJ
pep_, compliance suites are for reducing fragmentation
-
MattJ
and that has been a community effort
-
MattJ
for years
-
moparisthebest
MattJ, but you just ignore the part you don't want or can't implement, I don't think it matters there
-
MattJ
moparisthebest, I just tried to chat with a non-OMEMO client in Conversations and it took 3 taps through various confirmation boxes
-
moparisthebest
there are a whole slew of reasons why $company/$project can't or won't implement a XEP, licensing is just one of them
-
MattJ
If we also care about UX, yes, fragmentation matters
-
moparisthebest
MattJ, good? :)
- lorddavidiii has left
-
ralphm
pep., 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.
-
moparisthebest
you are of course free to fork Conversations to fix the UX
-
pep_
#semantics
-
moparisthebest
ralphm, and GPL is the pinnacle of openness so that's great! :)
-
moparisthebest
but yes, what pep_ said
-
MattJ
moparisthebest, and decrease practical security in return
-
pep_
How so?
-
MattJ
moparisthebest, all because the XSF refused to provide a fair standard
-
pep_
"Security by obscurity"?
-
pep_
We all know that doesn't work
-
ralphm
moparisthebest, 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.
-
MattJ
pep_, disabling E2EE silently without informing/confirming with the user is a security problem
- lorddavidiii has joined
-
moparisthebest
I suppose forking is always an option, GXSF publishing GPL'd GEPs anyone? :/
-
pep_
Without informing the user? What client does that?
-
MattJ
pep_, the one moparisthebest just suggested I create in order to fix the UX caused by a fragmented ecosystem
-
dwd
moparisthebest, And the XSF's licensing allows that.
-
ralphm
moparisthebest, 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
-
dwd
moparisthebest, Because we're an *open* standards organisation.
-
ralphm
In fact, the namespaces in XEP-0384 are not even tied to or regulated by the XSF.
-
pep_
It's not the only XEP fwiw
-
ralphm
sure
-
MattJ
I guess this whole thing has been enlightening to me
-
moparisthebest
I'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
-
moparisthebest
I'd like the XSF to change to allow that
-
moparisthebest
but 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
-
dwd
moparisthebest, For OMEMO specifically, that's a fine idea. I suggested it earlier.
-
MattJ
moparisthebest, I think everyone here is totally fine with them being published, just not by the XSF
- pdurbin has joined
-
pep_
I think the copyleft/GPL != business is just very wrong
- mukt2 has left
-
ralphm
I think a lot of people and corporations (including probably all sponsors) would leave the XSF if we would ever change that, moparisthebest.
-
ralphm
I would.
-
moparisthebest
that'd be ridiculous
- lskdjf has left
- lskdjf has joined
-
moparisthebest
but I also couldn't care less if they did, no loss as far as I'm concerned
-
MattJ
pep_, another time I'd love to hear your thoughts on how a pure GPL "commercial entity" would work
-
pep_
Sure
-
MattJ
But I think that's even too OT for here right now
-
jonas’
you could try next door
-
MattJ
I didn't want to disturb the tranquility there
-
pep_
I'm on a nazi network I only have http available atm..
-
dwd
MattJ, Pure software, not services? Tricky. I've seen people try, but I've seen all of them fail.
-
MattJ
dwd, logically that makes sense, yes :)
-
moparisthebest
dwd, 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.
-
dwd
pep_, 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
-
dwd
moparisthebest, By services I meant hosted services. I've seen plenty of GPL-and-support companies fail.
-
ralphm
I'd be very surprised if Conversations' play store income suffices to continue its development other than as a hobby.
-
Daniel
Conversations’ app store sales make much more money than conversations.im
-
moparisthebest
what's Redhat dwd / MattJ ?
-
Daniel
not in absolut numbers (both are pretty low) but in relative terms
-
ralphm
Daniel, could it be your day job?
-
Daniel
no
-
Daniel
i mean it is. but no
-
Guus
hahahaha
-
ralphm
:-D
-
pep_
And you do consulting around it, right
-
pep_
And it's just fine
- mukt2 has joined
-
moparisthebest
in a past life I made a good living giving away only open source software for free, on a website that had ads on it
-
pep_
Nobody "just" sells software anyway. You sell support, training, hosting, contracting (adding features/fixing bugs)
-
moparisthebest
so there are plenty of ways, which is beside the point that I think the XSF should be able to publish GPL-requiring XEPs
-
ralphm
I don't see the point and think allowing that is harmful. Maybe even just entertaining the idea is.
-
moparisthebest
I don't think I can be convinced entertaining any idea is ever harmful
-
moparisthebest
ralphm, and I don't see the point in non-GPL software existing, different perspectives eh?
-
ralphm
moparisthebest, 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
- Lance has joined
-
moparisthebest
sure let's get a law banning distribution of binaries ? :D
-
pep_
Obliterate patents and copyright
-
ralphm
But 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.
-
moparisthebest
I 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
-
moparisthebest
but I don't see any problem whatsoever with an e2e XEP requiring GPL, and maybe the rare XEP here and there requiring it
-
moparisthebest
I would like the XSF to change to allow that
-
moparisthebest
and if it doesn't, fine, I'd still like to see it though, that's all
- Shell has left
-
ralphm
moparisthebest, ok. Do you intend to take a particular course of action?
-
Guus
I 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.✎ - Shell has joined
-
ralphm
Right.
-
Guus
I 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. ✏
-
MattJ
I mean, I'm not 100% against that idea
-
MattJ
But it reduces the XSF to a repository of documents
-
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.
-
moparisthebest
good 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
-
MattJ
Such 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
- pdurbin has left
-
MattJ
pep_, 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
-
ralphm
That's a hugely different thing there.
-
pep_
Not so different to me. That makes some of them proprietary documents
-
ralphm
XMPP extension protocols published (or not) by entities other than the XSF or the IETF is totally fine. By design!
- calvin has joined
-
pep_
So proprietary is fine, but free software isn't
-
ralphm
We 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
-
ralphm
pep., 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.
-
dwd
I'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
-
Daniel
i 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
-
Guus
pep_ 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
- eevvoor has left
-
dwd
Daniel, Yes, but we're evil. So it's evil knowledge. EVIL!
- Shell has left
- Shell has joined
-
pep_
Daniel, personally I'm not hostile towards commercial services
-
Guus
pep_ 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.
-
Guus
I'm unsure how to word that differently.
-
ralphm
Because it by its very nature fractures the community.
-
pep_
Guus, so you also don't like practices like say.. MUC avatars?
-
MattJ
I personally don't like the way MUC avatars were introduced, no
-
pep_
Multiple attempts to specify that have been rejected by council
-
dwd
An interesting observation from that is that OMEMO is only a problem because it's fundamentally a useful and desirable feature at its core.
-
Guus
I'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?
-
MattJ
It 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
- Lance has left
-
pep_
But no one is actually complaining about them
-
pep_
weirdly
-
pep_
I mean, no one that is complaining about OMEMO
-
Kev
I mean, other that MattJ, two whole lines above.✎ -
Guus
pep_ I think we're talking about different things.
-
Kev
I mean, other than MattJ, two whole lines above. ✏
-
Zash
Why even have a standards organization, just implement whatever you want and whatever becomes popular is the standard! /s
-
Daniel
in 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.r has left
-
dwd
Loosely a +1 to that.
-
ralphm
pep., Do you mean https://xmpp.org/extensions/inbox/muc-avatars.html
- matlag has left
- j.r has joined
- winfried has left
- Shell has left
- Shell has joined
-
Guus
Daniel 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>
- winfried has joined
-
pep_
ralphm, yes, and another one as well
-
dwd
I 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
-
Zash
Everyone has MUC avatars
-
ralphm
pep., 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.
-
Daniel
also 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 ;)
-
ralphm
pep., I don't remember why it didn't get accepted as a XEP, though.
-
Guus
Daniel 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.
-
dwd
Daniel, 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. :-)
-
Daniel
Guus, well it is 'fully adopted' in the free open source world
-
Daniel
i 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.
-
Kev
Swift doesn't (yes, it's still developed) :)
- david has left
-
Guus
Daniel I can't add it to Apache2-licensed clients, as far as I can tell.
-
Daniel
Guus, no. but you can relicense the client
- david has joined
-
dwd
ralphm, That one? Introducing pubsub on MUC, I think, blocked it. Perhaps.
-
Daniel
which i think some clients have done
-
Guus
But I don't want to relicense the client.
-
Daniel
i don’t like the gpl either and i'm not happy about the current situation. but it is still fairly widely deployed
-
Guus
Because 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)
-
Guus
Sure, absolutely, I agree to that.
-
Daniel
i mean show me another xep from the past 5 years that is as widely deployed as omemo
-
Guus
MIX
- Guus ducks, runs.
-
flow
Guus> Daniel I can't add it to Apache2-licensed clients, as far as I can tell. You can, but the result is GPLv3
- mukt2 has left
-
dwd
There were quite a few smaller commercial clients based on Smack which blindly brought in OMEMO support too.
-
flow
Sadly, we did not sue them all and made $$$
-
ralphm
Daniel, MAM
-
Daniel
ralphm, i would like to see stats on that. it might be very close or equal
-
flow
But 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? 🙂
-
Zash
Wasn't OMEMO already on the path to popularity before becoming a XEP?
-
dwd
Zash, It was in Conversations for ~1 year before becoming a XEP.
-
Zash
And, isn't it still the pre-XEP version that's popular?
-
Guus
Look, 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.r has left
- j.r has joined
-
Zash
HTTP Upload has at least moved within the standards process since
-
moparisthebest
has it? (looking at you http upload encryption)
-
Daniel
but is currently stuck for some unknown reason
-
Daniel
but that's a different story
-
pep_
moparisthebest, yeah that's a different XEP..
-
pep_
or ProtoXEP, rather
-
moparisthebest
basically, 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
-
moparisthebest
I'd prefer to end-run that and just say we are ok with GPL requiring XEPs
- emus has left
- Shell has left
- Shell has 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✎ -
ralphm
this
-
Zash
Daniel, haha what, stuck in last call?
-
moparisthebest
ok 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
-
moparisthebest
still 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
-
ralphm
moparisthebest, 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
-
Guus
pep_ I agree with you that this all reflects poorly on us.
-
jonas’
Daniel, ... but I can’t find any evidence of that
-
Guus
and neither 'solution' will be able to fix that.
-
Guus
We just differ on opinion on which solution is the least worst one, I think.
-
ralphm
moparisthebest, 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.
-
moparisthebest
I'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
-
moparisthebest
just gauging the room I also suspect it won't reach a majority
-
Daniel
jonas’, i think it has had multiple last calls. some had feedback (which got addressed)
-
Zash
I vote no!
-
Zash
No to everything!
-
Daniel
and then the last last call didn’t have any replies at all
-
moparisthebest
Zash, 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)
-
dwd
jonas’, 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
-
Daniel
i'm going to assume that's because everyone is happy :-)
-
dwd
jonas’, I'd stick an LC on the agenda for the next Council meeting.
-
dwd
jonas’, Oh, you can automatically restart it, actually. Declare it as a Council change auto-restart.
-
jonas’
dwd, exactly
-
pep_
That's a thing?
-
dwd
pep_, 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? 😛
-
Kev
Consideration for advancement to draft* I think
-
Kev
It doesn't get restarted if one Council rejects the move to Draft.
- stpeter has joined
-
dwd
Kev, Yes. Before the vote to Draft or before such a vote completes, I suppose.
-
dwd
pep_, Well, it's not *meant* to happen this way.
-
pep_
(Not that I'm opposing this move)
- Shell has left
- Shell has joined
-
ralphm
moparisthebest: 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.
- Shell has left
- Shell has joined
-
moparisthebest
I don't have super strong feelings about OMEMO specifically
-
moparisthebest
I do have a strong feeling that we *should* be able to publish GPL-requiring XEPs
-
ralphm
Well, I don't like to waste time on hypotheticals, to be honest.
-
Daniel
dwd: > 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?
-
Daniel
or just multiple results?
-
moparisthebest
well also it's not a hypothetical, it means whether omemo requires GPL is a non-issue right?
-
moparisthebest
then it can be evaluated on technical merits as it should (in my opinion)
-
moparisthebest
*only on technical merits
-
Daniel
a never mind
-
Daniel
that's kinda the status quo
- Shell has left
- Shell has 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
-
moparisthebest
right, I'd like to just do (b)
-
jonas’
moparisthebest, please do so then
-
jonas’
thank you very much.
-
moparisthebest
yep and I appreciate the discussion and pointers on how to do that
-
Kev
Does Xep1 get a membership vote? Bylaws do, doesn't Xep1 just get Board?
-
Kev
I forget, and don't have cycles to look it up
- Shell has left
- Shell has joined
-
ralphm
Kev: yes, XEP-0001 is Board only.
-
ralphm
But, the membership is king
-
ralphm
So they could override Board.
-
ralphm
That's why I presented that order.
-
Kev
They 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.
-
Kev
Unless 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
- winfried has left
- winfried has joined
-
Kev
I think they would have to change the process first that says that only Board can approve changes.
- mukt2 has joined
- wojtek has joined
-
jonas’
couldn’t membership vote for a process exception? :)
-
dwd
Daniel, MAMFC? That's like current MAM, but if it archived everything, not just "traditional IM messages".
- Shell has left
- Shell has joined
-
Kev
jonas’: I hope we don't get to the stage that we need such a discussion.
-
ralphm
Kev: 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.
-
ralphm
so if moparisthebest thinks this is the best course of action to prove a point, well, I guess that's what has to happen
-
ralphm
I personally think it is irresponsible.
- wojtek has left
-
Daniel
dwd, yes. thank you
-
Daniel
re: 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
-
Kev
For 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
-
Daniel
iirc 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...
-
Daniel
by 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"
-
Kev
I think fallback being outside MAM/MAMFC/Fastening is preferable, but I'm not sure I would hugely care to see it move.
-
dwd
Daniel, 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.
-
Kev
jonas’: Thank you.
-
Daniel
imho 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.
-
Daniel
both are valid approaches. but a new XEP i don’t get
-
Zash
I hold that an open specification can't mandate licensing of implementations.
-
ralphm
pep., 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.
- Maranda has left
- Maranda has joined
-
pep_
I don't see that as a hammer, I think it's great actually
-
pep_
Having members participate
- Shell has left
- Shell has joined
-
Kev
Daniel: 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.
-
Kev
Maybe harmful is hyperbole
-
ralphm
I didn't say we should get rid of the possibility, I just think that it should not be used frivolously.
-
Kev
But 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
- eevvoor has joined
-
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]
-
pep_
Not the opposite. I don't think I'm here to govern anybody, I'm here to serve
-
dwd
Daniel, 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.
-
Daniel
i 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
-
Kev
And if the chat was full of +1 noise, it would hide/show that.
-
Daniel
but i wouldn’t know how to handle a fallback message in the client
-
Kev
See above :)
-
dwd
Daniel, <fallback/> is an attempt to allow us to be less anti-fallback.
-
Zash
dwd, I'd like to point out that there's some overlap with the EME XEP
-
dwd
Zash, Oh. Yes, there probably is.
-
ralphm
jonas’, yes indeed.
-
Kev
And 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.
- Shell has left
- Shell has joined
-
ralphm
pep., you *are* appointed to govern the XSF, the corporation. This is different from governing its membership.
-
Kev
Govern: conduct the policy, actions and affairs of (an organisation) with authority.
-
Kev
I think that's pretty much the definition.✎ -
Kev
I think that's pretty much the definition of what Board does. ✏
-
ralphm
Yes, I tried to convey that I don't view members as underlings :-D
-
Kev
ralphm: 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.
- debacle has left
- alameyo has left
- Guus has left
-
ralphm
Well, 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 🙂
-
dwd
Asking everyone about everything is what gets you Brexit.
-
pep_
That's just wrong
-
Kev
Where 'wrong' means 'demonstrably right' :)
-
pep_
You're forgetting lots of context here
-
Zash
dwd: 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.
-
Kev
Zash: I think my suggestion is actually a fairly reasonable least-knowledge way of handling fallbacks.
- Guus has joined
- Guus has left
- Guus has joined
- mukt2 has left
-
Zash
Kev, where?
-
Zash
I'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
-
Zash
Kev, yeah, that's sensible.
-
pep_
jonas’, exactly, and I'm saying people should do it 🙂
-
pep_
(Whether it's this specific case or another)
-
moparisthebest
Kev, 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)
-
MattJ
I 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"
- alameyo has joined
-
pep_
I don't think so
-
jonas’
One is bypassing the authority of the elected board, one isn’t.
-
ralphm
I 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
-
Daniel
something 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
- mathijs has left
- mathijs has joined
- stpeter has left
-
pep_
I'm not sure how to formulate that indeed. I'll sleep over it
-
larma
jonas’, I think it makes sense in cases where the board doesn't want to decide over the members
- winfried has left
- winfried has joined
- mathijs has left
- mathijs has joined
- sonny has left
- mukt2 has joined
-
Daniel
from 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
-
larma
jonas’, 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
-
Kev
larma: I think there are plenty of good reasons for Board to ask the Members on something.
- Shell has left
- Shell has joined
-
dwd
Daniel, Yes, but that line was the single line that I objected to.
-
Daniel
because 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)
-
Kev
I 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.
-
dwd
Daniel, Actually, you'd be great - the problem that group has is in practical messaging, not the crypto side.
-
dwd
Daniel, (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" 🙂
-
larma
Kev, 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?
-
ralphm
Daniel, I don't think physical presense is required to participate in MLS at all.
-
Daniel
but 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)
-
dwd
ralphm, It's really really helpful.
-
Daniel
that
-
Kev
larma: I think that's a very complicated question that doesn't have a pithy answer.
-
ralphm
but I am not opposed to sponsoring a visit to an IETF
-
dwd
Daniel, 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.
-
Kev
We have sponsored a visit to an IETF previously, haven't we?
-
ralphm
Kev: we did?
-
dwd
Kev, Yes, I think so. Previous London IETF, we sponsored Thijs, didn't we?
-
Kev
Maybe I'm misremembering, I thought we sponsored Thijs to attend IETF London a while back.
-
ralphm
https://ietf.org/how/meetings/upcoming/
-
ralphm
The next 'close' one for most of us is 108, in July, Madrid
- Daniel regrets not having participated in the jmap working group before it was too late
- emus has joined
-
dwd
ralphm, MLS gets a lot of its work done in f2f interims, too.
- Maranda has left
- Maranda has joined
-
dwd
ralphm, Of which there's one tomorrow: https://datatracker.ietf.org/meeting/interim-2020-mls-01/session/mls
-
ralphm
There's one this weekend it seems
-
ralphm
Agenda is empty though
- Shell has left
- Shell has joined
- sonny has 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
-
ralphm
https://github.com/mlswg/wg-materials/blob/master/interim-2020-01/README.MD
-
dwd
ralphm, Daniel https://github.com/mlswg/wg-materials/blob/master/interim-2020-01/README.MD
-
ralphm
hah
-
ralphm
Be sure to read the NOTE WELL!
- neshtaxmpp has left
- Shell has left
- Shell has joined
- winfried has left
- winfried has joined
- adiaholic has joined
-
Daniel
the mls@jabber.ietf.org channel only has known xmpp people in it :-/
-
dwd
I think it only gets traffic during meetings normally.
-
Ge0rG
Seriously people, what happened to this MUC? I've taken most of today just to catch up with the logs
-
Daniel
as long as it actually does it's fine
-
Ge0rG
Can we please have a bot that will auto-kickban on mention of "GPL"?
-
moparisthebest
Ge0rG, will it exclude AGPL ?
-
dwd
Daniel, Sadly not very much during Interims.
-
Daniel
it says i MUST register. it doesn’t say where
-
moparisthebest
ok I'll just start using GNU General Public License everywhere, break my keyboard
-
Ge0rG
moparisthebest: after seeing other people engage with you on this topic, let's just agree to disagree.
-
moparisthebest
one 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
-
Ge0rG
Kev: 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.
-
Kev
Ge0rG: It is certainly not a perfect solution.
-
Ge0rG
Nor is the fallbacks XEP.
-
Ge0rG
But we don't strive for perfect, merely for good enough.
-
Kev
I 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? **
-
Ge0rG
Kev: 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
-
Ge0rG
dwd: that's an interesting angle indeed: "Your client is too old and doesn't support all elements of this message"
- pdurbin has joined
- Lance has joined
-
dwd
That was what I was thinking a client might do. A server might not index it for MAM, or something.
-
Ge0rG
dwd: is there a reason for <fallback> not containing the namespace of the causing element?✎ - stpeter has joined
-
dwd
Ge0rG, Yes.
-
dwd
Ge0rG, I didn't think of it.
-
Ge0rG
dwd: what is the reason for <fallback> not containing the namespace of the causing element? ✏
-
Ge0rG
Great!
-
Ge0rG
dwd: is there _still_ a reason for <fallback> not containing the namespace of the causing element?
-
dwd
Ge0rG, I'm somewhat ambivalent to that - I don't know what a client/server would do differently.
-
dwd
Ge0rG, But equally, it does no harm.
-
dwd
Ge0rG, It'd be a good reason *not* to try to put this in Hints, though.
-
Ge0rG
dwd: it could fetch the XEP that defines that namespace from the registry :P
-
dwd
AND USE MACHINE LEARNING TO AUTOMATICALLY IMPLEMENT THE XEP AND THEN STORE THE RESULT IN THE BLOCKCHAIN.
-
dwd
Sorry, don't know what came over me then.
-
Ge0rG
dwd: who are you and what have you done to dwd?
-
Ge0rG
with all the roster shenanigans, probably dwd got replaced by aliens.
- adiaholic has left
- adiaholic has joined
- mathijs has left
- mathijs has joined
-
larma
dwd, happened to have read my comment re partial fallback body?
-
Ge0rG
larma: please don't add more complexity
-
pep_
It does actually seem pretty useful though..
-
Ge0rG
larma: I know it's sexy to put five different things into one message, but it makes everything more complicated
-
larma
Ge0rG, if it's not in there it has to be somewhere else
-
Ge0rG
pep_: it should be redefined in terms of fastenings.
-
larma
So this is only for fastening, not for anything else?
-
dwd
No, it's for everything where we're only using <body/> as a fallback.
-
Ge0rG
larma: do you have a convincing use case for that?
- pdurbin has left
-
larma
Ge0rG, reply to
-
Ge0rG
I think we need to revive https://xmpp.org/extensions/xep-0226.html
-
Ge0rG
larma: ah, right. Hm....
-
Ge0rG
larma: what if we just ignore the problem of legacy clients showing a fallback body in a slightly awkward way?
-
larma
Ge0rG, what do you mean?
-
dwd
larma, 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.
-
Ge0rG
larma: 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
-
dwd
larma, But, mea culpa for not responding.
-
larma
Ge0rG, I was thinking along those lines https://gist.github.com/mar-v-in/8f66872bb533f7e805fb174e341be992
- eevvoor has left
- j.r has left
- calvin has left
-
Ge0rG
larma: yeah, I understand that. Would also work great for Reaction fallbacks :D
-
larma
Ge0rG, you mean: we can explore if this would also work great for reactions fallbacks and then decide it doesn't 😀
-
larma
but yeah, there are various things where it would be handy
-
Ge0rG
larma: the question is: is it worth the added complexity?
-
larma
If the complexity is not added to <fallback /> it would have to be added to reply-to or reply-to will not be backwards compatible
-
larma
I don't like the third option really
-
larma
alternatively we can have something else for that
-
dwd
larma, It's what we have now.
-
dwd
larma, By which I mean, I've just replied to you. And again here.
- mukt2 has left
- Shell has left
- Shell has joined
-
larma
dwd, 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.r has joined
-
larma
It would still make sense to have the other thing though
-
larma
but could be separated from each other
-
larma
because my usecase is obviously completely unrelated to fastening
- waqas has joined
- Shell has left
- Shell has joined
- matkor has left
- matkor has joined
- mathijs has left
- mathijs has joined
- mukt2 has joined
- Shell has left
- Shell has joined
- Dele (Mobile) has joined
- Zash has left
- Zash has joined
- Yagiza has left
- adiaholic has left
- adiaholic has joined
- mukt2 has left
- alameyo has left
- alameyo has joined
- Shell has left
- pep_ has left
- mukt2 has joined
- Lance has left
- Lance has joined
- Nekit has left
- mukt2 has left
- rion has left
- rion has joined
- Nekit has joined
- calvin has joined
- Nekit has left
- pdurbin has joined
- winfried has left
- winfried has joined
- winfried has left
- winfried has joined
- sonny has left
- pep_ has joined
- calvin has left
- calvin has joined
- pdurbin has left
- calvin has left
- calvin has joined
- pep_ has left
- Alex has left
- debacle has joined
- winfried has left
- winfried has joined
- winfried has left
- winfried has joined
- calvin has left
- calvin has joined
- Alex has joined
- Lance has left
- calvin has left
- calvin has joined
- sonny has joined
- mukt2 has joined
- lorddavidiii has left
- sonny has left
- lorddavidiii has joined
- winfried has left
- winfried has joined
- Lance has joined
- emus has left
- sonny has joined
- Wojtek has left
- Wojtek has joined
- Wojtek has left
- Wojtek has joined
- sarxb has joined
- sarxb has left
- calvin has left
- sonny has left
- sonny has joined
- mathijs has left
- mathijs has joined
- mukt2 has left
- edhelas has left
- nyco has left
- nyco has joined
- mukt2 has joined
- emus has joined
- calvin has joined
- sonny has left
- sonny has joined
- pdurbin has joined
- pdurbin has left
- emus has left
- emus has joined
- Wojtek has left
- sonny has left
- Lance has left
- winfried has left
- winfried has joined
- emus has left
- Nekit has joined
- emus has joined
- andrey.g has left
- eevvoor has joined
- sonny has joined
- mukt2 has left
- eevvoor has left
- matlag has joined
- sonny has left
- Dele (Mobile) has left
- andrey.g has joined
- sonny has joined
- Lance has joined
- Zash has left
- Zash has joined
- mathijs has left
- mathijs has joined
- lorddavidiii has left
- sonny has left
- sonny has joined
- sonny has left
- Shell has joined
- sonny has joined
- goffi has left
- Shell has left
- Shell has joined
- adiaholic has left
- calvin has left
- sonny has left
- Shell has left
- Shell has joined
- karoshi has left
- Nekit has left
- sonny has joined
- winfried has left
- winfried has joined
- winfried has left
- winfried has joined
- Shell has left
- Shell has joined
- Shell has left
- Shell has joined
- Martin has left
- edhelas has joined
- paul has left
- j.r has left
- sonny has left
- Shell has left
- Shell has joined
- sonny has joined
- neshtaxmpp has joined
- sonny has left
- sonny has joined
- Shell has left
- stpeter has left
- Lance has left
- Lance has joined
- sonny has left
- Shell has joined
- Shell has left
- Shell has joined
- sonny has joined
- neshtaxmpp has left
- neshtaxmpp has joined
- stpeter has joined
- adiaholic has left
- mukt2 has joined
- andy has left
- stpeter has joined
- mukt2 has left
- debacle has left
- murabito has left
- beta has left
- beta has joined
- stpeter has left
- beta has left
- beta has joined
- lskdjf has left
- beta has left
- beta has joined
- Vaulor has left
- Vaulor has joined
- stpeter has joined
- mukt2 has joined
- krauq has left
- mukt2 has left
- krauq has joined
- andrey.g has left
- adiaholic has joined
- neshtaxmpp has left
- neshtaxmpp has joined
- stpeter has left
- stpeter has joined
- pdurbin has joined
- beta has left
- Yagiza has joined
- beta has joined
- andrey.g has joined
- pdurbin has left
- mukt2 has joined
- Nekit has joined
- Lance has joined
- stpeter has left
- mukt2 has left
- andy has joined
- beta has left
- pdurbin has joined
- lorddavidiii has joined
- beta has joined
- adiaholic has left
- adiaholic has joined
- beta has left
- karoshi has joined
- pdurbin has left
- beta has joined
- paul has joined
- stpeter has joined
- pdurbin has joined
- stpeter has left
- serge90 has left
- serge90 has joined
- sonny has left
- Tobias has joined
- sonny has joined
- sonny has left
- serge90 has left
- serge90 has joined
- wurstsalat has joined
- serge90 has left
- lorddavidiii has left
- lorddavidiii has joined
- lorddavidiii has left
- lorddavidiii has joined
- lorddavidiii has left
- lorddavidiii has joined
- sonny has joined
- Steve Kille has left
- Steve Kille has joined
- sonny has left
- lovetox has joined
- lovetox has left
- serge90 has joined
- Steve Kille has left
- goffi has joined
- mathijs has left
- mathijs has joined
- beta has left
- UṣL has joined
- emus has joined
- beta has joined
- beta has left
- emus has left
- emus has joined
- alameyo has left
- alameyo has joined
- Lance has left
- mathijs has left
- mathijs has joined
- Lance has joined
- waqas has joined
- mukt2 has joined
- sonny has joined
- Lance has left
- beta has joined
- mukt2 has left
- debacle has joined
- beta has left
- Max has left
- Lance has joined
- beta has joined
- Wojtek has joined
- Lance has left
- serge90 has left
- larma has left
- larma has joined
- serge90 has joined
- Nekit has left
- Nekit has joined
- Lance has joined
- Dele (Mobile) has joined
- adiaholic has left
- lorddavidiii has left
- lorddavidiii has joined
- Lance has left
- debacle has left
- Max has joined
- adiaholic has joined
- adiaholic has left
- adiaholic has joined
- sonny has left
- sonny has joined
- sonny has left
- sonny has joined
- sonny has left
- sonny has joined
- sonny has left
- !XSF_Martin has left
- !XSF_Martin has joined
- debacle has joined
- sonny has joined
- Nekit has left
- mukt2 has joined
- Nekit has joined
- mukt2 has left
- beta has left
- Lance has joined
- pdurbin has left
- debacle has left
- Martin has joined
- debacle has joined
- Martin has left
- adiaholic has left
- adiaholic has joined
- Wojtek has left
- mukt2 has joined
- Lance has left
- Maranda has left
- Maranda has joined
- beta has joined
- mathijs has left
- mathijs has joined
- Wojtek has joined
- beta has left
- beta has joined
- mathijs has left
- mathijs has joined
- mukt2 has left
- lskdjf has joined
- adiaholic has left
- mukt2 has joined
- Shell has left
- Shell has joined
- Martin has joined
- j.r has left
- j.r has joined
- sonny has left
- beta has left
- beta has joined
- sonny has joined
- Martin has left
- Martin has joined
- Vaulor has left
- emus has left
- emus has joined
- beta has left
- mukt2 has left
- Martin has left
- Martin has joined
- Shell has left
- Shell has joined
- pdurbin has joined
- sonny has left
- beta has joined
- waqas has left
- adiaholic has joined
- pdurbin has left
- mukt2 has joined
- aj has left
- Lance has joined
- Vaulor has joined
- adiaholic has left
- adiaholic has joined
- sonny has joined
- eevvoor has joined
- mukt2 has left
- adiaholic has left
- beta has left
- beta has joined
- Martin has left
- Martin has joined
- j.r has left
- j.r has joined
- beta has left
- beta has joined
- Lance has left
- tao has joined
- Shell has left
- Shell has joined
- tao has left
- pep_ has joined
- adiaholic has joined
- winfried has left
- winfried has joined
- adiaholic has left
- adiaholic has joined
- winfried has left
- winfried has joined
- mukt2 has joined
- adiaholic has left
- adiaholic has joined
- adiaholic has left
- adiaholic has joined
- calvin has joined
- UṣL has left
- mukt2 has left
- adiaholic has left
- Vaulor has left
- Vaulor has joined
- calvin has left
- calvin has joined
- winfried has left
- winfried has joined
- mathijs has left
- mathijs has joined
- mukt2 has joined
- lorddavidiii has left
- lorddavidiii has joined
- calvin has left
- lorddavidiii has left
- lorddavidiii has joined
- pdurbin has joined
- mukt2 has left
- lskdjf has left
- lskdjf has joined
- mukt2 has joined
- Lance has joined
- Shell has left
- Shell has joined
- pdurbin has left
- calvin has joined
- eevvoor has left
- Shell has left
- Shell has joined
- Lance has left
- j.r has left
- matlag has left
- j.r has joined
- winfried has left
- Shell has left
- Shell has joined
- winfried has joined
- david has left
- david has joined
- mukt2 has left
- j.r has left
- j.r has joined
- emus has left
- Shell has left
- Shell has joined
- stpeter has joined
- Shell has left
- Shell has joined
- Shell has left
- Shell has joined
- Shell has left
- Shell has joined
- Shell has left
- Shell has joined
- winfried has left
- winfried has joined
- mukt2 has joined
- wojtek has joined
- Shell has left
- Shell has joined
- wojtek has left
- Maranda has left
- Maranda has joined
- Shell has left
- Shell has joined
- eevvoor has joined
- Shell has left
- Shell has joined
- debacle has left
- alameyo has left
- Guus has left
- Guus has joined
- Guus has left
- Guus has joined
- mukt2 has left
- alameyo has joined
- Dele (Mobile) has left
- mathijs has left
- mathijs has joined
- stpeter has left
- winfried has left
- winfried has joined
- mathijs has left
- mathijs has joined
- sonny has left
- mukt2 has joined
- Shell has left
- Shell has joined
- emus has joined
- Maranda has left
- Maranda has joined
- Shell has left
- Shell has joined
- sonny has joined
- neshtaxmpp has left
- Shell has left
- Shell has joined
- winfried has left
- winfried has joined
- adiaholic has joined
- pdurbin has joined
- Lance has joined
- stpeter has joined
- adiaholic has left
- adiaholic has joined
- mathijs has left
- mathijs has joined
- pdurbin has left
- eevvoor has left
- j.r has left
- calvin has left
- mukt2 has left
- Shell has left
- Shell has joined
- j.r has joined
- waqas has joined
- Shell has left
- Shell has joined
- matkor has left
- matkor has joined
- mathijs has left
- mathijs has joined
- mukt2 has joined
- Shell has left
- Shell has joined
- Dele (Mobile) has joined
- Zash has left
- Zash has joined
- Yagiza has left
- adiaholic has left
- adiaholic has joined
- mukt2 has left
- alameyo has left
- alameyo has joined
- Shell has left
- pep_ has left
- mukt2 has joined
- Lance has left
- Lance has joined
- Nekit has left
- mukt2 has left
- rion has left
- rion has joined
- Nekit has joined
- calvin has joined
- Nekit has left
- pdurbin has joined
- winfried has left
- winfried has joined
- winfried has left
- winfried has joined
- sonny has left
- pep_ has joined
- calvin has left
- calvin has joined
- pdurbin has left
- calvin has left
- calvin has joined
- pep_ has left
- Alex has left
- debacle has joined
- winfried has left
- winfried has joined
- winfried has left
- winfried has joined
- calvin has left
- calvin has joined
- Alex has joined
- Lance has left
- calvin has left
- calvin has joined
- sonny has joined
- mukt2 has joined
- lorddavidiii has left
- sonny has left
- lorddavidiii has joined
- winfried has left
- winfried has joined
- Lance has joined
- emus has left
- sonny has joined
- Wojtek has left
- Wojtek has joined
- Wojtek has left
- Wojtek has joined
- sarxb has joined
- sarxb has left
- calvin has left
- sonny has left
- sonny has joined
- mathijs has left
- mathijs has joined
- mukt2 has left
- edhelas has left
- nyco has left
- nyco has joined
- mukt2 has joined
- emus has joined
- calvin has joined
- sonny has left
- sonny has joined
- pdurbin has joined
- pdurbin has left
- emus has left
- emus has joined
- Wojtek has left
- sonny has left
- Lance has left
- winfried has left
- winfried has joined
- emus has left
- Nekit has joined
- emus has joined
- andrey.g has left
- eevvoor has joined
- sonny has joined
- mukt2 has left
- eevvoor has left
- matlag has joined
- sonny has left
- Dele (Mobile) has left
- andrey.g has joined
- sonny has joined
- Lance has joined
- Zash has left
- Zash has joined
- mathijs has left
- mathijs has joined
- lorddavidiii has left
- sonny has left
- sonny has joined
- sonny has left
- Shell has joined
- sonny has joined
- goffi has left
- Shell has left
- Shell has joined
- adiaholic has left
- calvin has left
- sonny has left
- Shell has left
- Shell has joined
- karoshi has left
- Nekit has left
- sonny has joined
- winfried has left
- winfried has joined
- winfried has left
- winfried has joined
- Shell has left
- Shell has joined
- Shell has left
- Shell has joined
- Martin has left
- edhelas has joined
- paul has left
- j.r has left
- sonny has left
- Shell has left
- Shell has joined
- sonny has joined
- neshtaxmpp has joined
- sonny has left
- sonny has joined
- Shell has left
- stpeter has left
- Lance has left
- Lance has joined
- sonny has left
- Shell has joined
- Shell has left
- Shell has joined
- sonny has joined
- neshtaxmpp has left
- neshtaxmpp has joined
- stpeter has joined