XSF Discussion - 2020-01-10

  1. adiaholic has left

  2. mukt2 has joined

  3. andy has left

  4. stpeter has joined

  5. mukt2 has left

  6. debacle has left

  7. murabito has left

  8. beta has left

  9. beta has joined

  10. stpeter has left

  11. beta has left

  12. beta has joined

  13. lskdjf has left

  14. beta has left

  15. beta has joined

  16. Vaulor has left

  17. Vaulor has joined

  18. stpeter has joined

  19. mukt2 has joined

  20. krauq has left

  21. mukt2 has left

  22. krauq has joined

  23. andrey.g has left

  24. adiaholic has joined

  25. neshtaxmpp has left

  26. neshtaxmpp has joined

  27. stpeter has left

  28. stpeter has joined

  29. pdurbin has joined

  30. beta has left

  31. Yagiza has joined

  32. beta has joined

  33. andrey.g has joined

  34. pdurbin has left

  35. mukt2 has joined

  36. Nekit has joined

  37. Lance has joined

  38. stpeter has left

  39. mukt2 has left

  40. andy has joined

  41. beta has left

  42. pdurbin has joined

  43. lorddavidiii has joined

  44. beta has joined

  45. adiaholic has left

  46. adiaholic has joined

  47. beta has left

  48. karoshi has joined

  49. pdurbin has left

  50. beta has joined

  51. paul has joined

  52. stpeter has joined

  53. pdurbin has joined

  54. stpeter has left

  55. serge90 has left

  56. serge90 has joined

  57. sonny has left

  58. Tobias has joined

  59. sonny has joined

  60. sonny has left

  61. serge90 has left

  62. serge90 has joined

  63. wurstsalat has joined

  64. serge90 has left

  65. lorddavidiii has left

  66. lorddavidiii has joined

  67. lorddavidiii has left

  68. lorddavidiii has joined

  69. lorddavidiii has left

  70. lorddavidiii has joined

  71. sonny has joined

  72. Steve Kille has left

  73. Steve Kille has joined

  74. sonny has left

  75. lovetox has joined

  76. lovetox has left

  77. serge90 has joined

  78. Steve Kille has left

  79. goffi has joined

  80. mathijs has left

  81. mathijs has joined

  82. beta has left

  83. UṣL has joined

  84. emus has joined

  85. beta has joined

  86. beta has left

  87. emus has left

  88. emus has joined

  89. alameyo has left

  90. alameyo has joined

  91. Lance has left

  92. mathijs has left

  93. mathijs has joined

  94. Lance has joined

  95. waqas has joined

  96. mukt2 has joined

  97. sonny has joined

  98. Lance has left

  99. beta has joined

  100. mukt2 has left

  101. debacle has joined

  102. beta has left

  103. Max has left

  104. Lance has joined

  105. beta has joined

  106. Wojtek has joined

  107. Lance has left

  108. serge90 has left

  109. larma has left

  110. larma has joined

  111. serge90 has joined

  112. Nekit has left

  113. Nekit has joined

  114. 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".

  115. dwd

    larma, And you publishing the constants under a difference license wouldn't mean that you exclusively took liability either.

  116. Lance has joined

  117. Dele (Mobile) has joined

  118. adiaholic has left

  119. lorddavidiii has left

  120. 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).

  121. lorddavidiii has joined

  122. 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.

  123. flow

    damn you "WhisperRatchet". But then again, I am fine with a XEP that requires GPLed compatible implementations.

  124. 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.

  125. flow

    So leaving the bad quality of the OMEMO XEP beside, the real question is if you think that encumbers the XEP

  126. flow

    which potentially leads to the question if the GPL increases or decreases your freedom

  127. Lance has left

  128. 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

  129. 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.

  130. 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.

  131. 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

  132. dwd

    Because GPL is a useful way to generate a licensing revenue stream for people who don't want to (or cannot) use it.

  133. flow

    Guus, they can only pursuing legal fights over it if they assume a violation of the GPL

  134. dwd

    flow, I mean, GPL is definitely an "encumberence" by any reasonable definition. The question is whether the XSF accepts this encumberence.

  135. 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

  136. flow

    dwd> flow, I mean, GPL is definitely an "encumberence" by any reasonable definition. I tend to disagree

  137. dwd

    flow, But they changed the constants. The wire format can - probably - be reverse engineered.

  138. dwd

    flow, How is the GPL not an encumberence to developers? It requires them to license a particular way.

  139. debacle has left

  140. 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

  141. dwd

    larma, A better business model for a non-profit.

  142. Guus

    "everbody knows" is not an argument that we can use in any form of decision making.

  143. Guus

    What flow wrote, if accurate, would be a very nice stick against what we can measure things.

  144. Guus

    This bit, I mean: > he question is if we are fine with a XEP that requires GPL compatible implementations

  145. 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

  146. Guus

    This bit, I mean: > the question is if we are fine with a XEP that requires GPL compatible implementations

  147. 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

  148. dwd

    Guus, Well, XEP-0001's Objectives, and particularly Objective 4, would seem to state that we are not.

  149. larma

    Also there was something with Twitter in Signals history (them buying the company and then releasing as open source?)

  150. 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

  151. 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).

  152. dwd

    flow, "requires some things" is surely what encumberence means.

  153. Max has joined

  154. adiaholic has joined

  155. flow

    dwd, well, the gpl is only a burden people who can or are not willing to comply to it

  156. dwd

    flow, How does that differ from, say, requiring a paid license?

  157. adiaholic has left

  158. flow

    a, potentially large, part if the xmpp community is probably fine with it

  159. Guus

    flow, that goes for _any_ restriction. 😃

  160. adiaholic has joined

  161. flow

    Guus, well there are restrictions that apply to everyone

  162. Guus

    The XSF is explicitly not in the business of making things unavailable to non-FLOSS parties.

  163. Guus

    requiring GPL would hurt that.

  164. Guus

    Also, it'd hurt us - as major players can't use (part of) XMPP.

  165. Zash

    You should be able to implement based on spe

  166. flow

    Guus, it's not like we require all e2ee schemes to be gpl only

  167. Zash

    You should be able to implement based on specification alone

  168. Zash

    + dependency specs

  169. Guus

    The precedent is dangerous.

  170. Guus

    I strongly feel that we should not go down that path.

  171. Guus

    I've already had customers worry about licensing as-is.

  172. Guus

    Note that the people in here are not a good cross section of our users.

  173. Guus

    people in this MUC tend to lean a lot more towards open source principles than many of our (commercial) users.

  174. 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

  175. 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.

  176. flow

    dwd, what Zash said

  177. dwd

    flow, What?

  178. 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).

  179. sonny has left

  180. sonny has joined

  181. sonny has left

  182. sonny has joined

  183. Guus

    The XSF _not_ publishing the OMEMO XEP does not limit anyone from implementing it, right?

  184. 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?

  185. Guus

    I'd prefer to publish only XEPs that are usable by both commercial and non commercial parties.

  186. Guus

    I'd prefer the XSF to publish only XEPs that are usable by both commercial and non commercial parties.

  187. dwd

    flow, How does this differ from, for example, the RTMP licensing requirements that we rejected?

  188. flow

    Guus, see that is probably where we differ

  189. Guus

    flow yeah, I think so. A matter of different opinion.

  190. 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).

  191. flow

    dwd, sorry, lunch, not ignoring you, but hungy

  192. sonny has left

  193. sonny has joined

  194. 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.

  195. Guus

    accessible/usable/permissible, license wise. I'm struggling to find the right words.

  196. 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.

  197. Guus

    dwd right. That may warrant an update of our objectives then.

  198. Guus

    as I do agree with you that GPL is restrictive.

  199. dwd

    Guus, The objectives are clear enough, IMO. It's whether the enforcement at the Draft->Final stage needs improvement.

  200. 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).

  201. Guus

    shoot. I should've done stuff by now.

  202. 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

  203. 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.

  204. Guus

    nyco looks good. I've added some of the standard headings to what you already had.

  205. nyco

    ok, thx

  206. Guus

    shoot. I should've finished stuff by now.

  207. Guus disappears

  208. pep.

    > flow> dwd> flow, I mean, GPL is definitely an "encumberence" by any reasonable definition. > I tend to disagreee I also disagree

  209. 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?

  210. dwd

    (And again, I say, I've argued against the XSF accepting any XEP which cannot be implemented under the GPL, too).

  211. nyco

    (minutes sent, thx)

  212. sonny has left

  213. dwd

    nyco, Thanks, I hope I captured the conclusions accurately. Summarizing the debate in an unbiased way would be tricky for me, I think.

  214. nyco

    agree, unless you are an AD&D "true neutral"

  215. 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

  216. !XSF_Martin has left

  217. dwd

    pep., I agree with that, but it still requires any software to be itself GPL, which is a restriction, or encumberence.

  218. pep.

    nyco, thanks for the minutes

  219. !XSF_Martin has joined

  220. 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*.

  221. 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".

  222. debacle has joined

  223. sonny has joined

  224. Nekit has left

  225. mukt2 has joined

  226. 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.

  227. pep.

    I don't know about these discussions (RTMP), I'll have a look

  228. 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.

  229. Nekit has joined

  230. 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

  231. 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.

  232. pep.

    Mind you, I wouldn't make all this fuss if OMEMO never had been accepted

  233. pep.

    Because it might not have been such a big thing

  234. pep.

    In this particular case I'm mostly annoyed that we're not providing a replacement

  235. 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)

  236. 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.

  237. pep.

    I said "end-users"

  238. pep.

    (but yes those on the way as well)

  239. mukt2 has left

  240. Ge0rG

    It's really astonishing how much vitriol can be released by a bunch of short ASCII strings

  241. pep.


  242. 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.

  243. beta has left

  244. !XSF_Martin

    If omemo relies on GPL libs how can monal and Chatsecure support it? I thought the Apple store and GPL are incompatible.

  245. pep.

    I asked myself the same question. Signal probably has exceptions in the license for iOS, unsure about the others

  246. dwd

    The license surely doesn't apply to them. They can release the iOS app under a non-GPL license.

  247. dwd

    Oh, wait, Monal and Chatsecure. Yeah, they're probably technically in breach.

  248. dwd

    But not in a way that OWS cares about most likely.

  249. !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?

  250. !XSF_Martin

    Ah, you meant signal.

  251. 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.

  252. Kev

    (At least, this was true last time I looked at the terms, I suppose they might have changed)

  253. larma


  254. 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.

  255. 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

  256. dwd

    AH, there we go, good spot.

  257. Guus

    On Signal's GPL license and Apple, Moxie released this: https://signal.org/blog/license-update/

  258. 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

  259. pep.

    Or forbid any contribution that's not from OWS

  260. 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.

  261. 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

  262. pep.

    larma, they'd be under whatever license Apple says it is rather? If you grab the binary from the AppStore

  263. Lance has joined

  264. larma

    pep., no the license remains what the copyright holder grants you

  265. larma

    it is probably against Apples ToS to do so

  266. pdurbin has left

  267. 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

  268. debacle has left

  269. Martin has joined

  270. debacle has joined

  271. Martin has left

  272. adiaholic has left

  273. adiaholic has joined

  274. Wojtek has left

  275. dwd

    larma, I don't see how that removes the copyright.

  276. larma

    it doesn't

  277. larma

    but it's under MPL then

  278. larma

    which is more permissive than GPL

  279. larma

    And should allow non-free implementations IIRC

  280. flow

    yep, without re-reading the MPL again, that is probably correct. If so, that's a nice loophole ;)

  281. larma

    flow, there are probably a bunch of other loopholes, that's why I have been asking for some legal help on that

  282. 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

  283. flow

    larma, i'm sure interested in the result/outcome of that legal help :)

  284. flow

    hmm, what if the program outputs itself?

  285. larma

    well, if the program outputs itself it remains under the GPL

  286. Guus

    All this doesn't change the fact that it's a bad idea to publish a XEP on the premise of a loophole.

  287. flow

    ahh, there was a "that are not the program itself"

  288. pep.

    "This week in the XSF: How to use GPL loopholes"

  289. pep.

    We should do just like "This week in Matrix"

  290. larma

    I wouldn't call it a loophole

  291. mukt2 has joined

  292. 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)

  293. larma

    because you are outputting the hash of that string (kind of)

  294. Guus

    If it directly opposes the intended application by OWS, it's undesired for the XSF to act on, in my opinion.

  295. larma

    We can still ask OWS on their opinion on that matter

  296. Guus

    I'm very much in favor of thta.

  297. Guus

    I'm very much in favor of that.

  298. pep.

    Me too

  299. Guus

    But any talk about exploiting loopholes would be very unhelpful.

  300. Guus

    phonecall, afk

  301. Lance has left

  302. Maranda has left

  303. Maranda has joined

  304. 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.

  305. Guus

    At the very least not legally.

  306. Guus

    I'd be pissed if someone uses my stuff in a way that I don't want it to be used.

  307. beta has joined

  308. pep.

    Guus, aren't that what lawyers are for? :x

  309. pep.

    Finding loopholes.

  310. Guus

    At the very least not morally.

  311. pep.

    isn't that*

  312. Guus

    (see my message correction: I ment 'morally', not 'legally')

  313. pep.


  314. 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

  315. pep.

    Guus, the world wouldn't be as it is if people cared about morale

  316. pep.

    or rather, if more* people cared

  317. 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

  318. Guus

    I care about the morality of this.

  319. Guus

    We put ourselves in that position - that's not on OWS.

  320. larma

    Guus, sure so it's also on us to ensure we are in a better position

  321. Guus

    If we are to use their stuff, it needs to be clear that it is permissible to do so - morally and legally.

  322. Guus

    We should talk to them. If they say "no", then it's a no.

  323. larma

    A moral permission alone does not help, but I am happy to agree that legal permission alone is also not enough

  324. Guus

    I very much do not want to be in the business of abusing others by means of loopholes.

  325. Guus

    I very much do not want to be in the business of abusing others by means of legal loopholes.

  326. Guus

    Also, by discussing these loopholes, we're actively hurting our chances of getting permission.

  327. Guus

    In their shoes, I'd take offense.

  328. larma

    although I'd like to point out that for the matter of the specification, actually only the legal side matters

  329. larma

    It would be up to implementations then to care about the moral side

  330. Guus

    Oh, whatever we do must be legally valid, I don't argue that.

  331. larma

    by using libsignal you would be clearly on the moral side anyway

  332. 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

  333. 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.

  334. Guus

    (note that this does not limit anyone from implementing OMEMO under GPL)

  335. larma

    Is it morally better to trick out OWS by not using those strings (like olm)?

  336. 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.

  337. 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.

  338. 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

  339. 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.

  340. flow

    Syndace, the discussion is not about the spec but about the libsignal implementation(s)

  341. flow

    which are based on the spec but use constants that are not part of the spec

  342. Syndace

    > My estimate is that a) OWS explicitly wants all of the implementations to be GPL compatible and flow, ^

  343. 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"

  344. Guus

    Maybe is should have types "applications of signal" instead of "implementations".

  345. flow

    the spec is open standard an implemenations can be under any license as far as I can tell

  346. Guus

    Maybe is should have typed "applications of signal" instead of "implementations".

  347. 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

  348. Syndace

    Okay I get it

  349. 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

  350. Guus

    true, but I don't think that's what OWS wants.

  351. Guus

    They've not challenged Olm, did they?

  352. larma

    They don't want signal compatible implementations of the signal protocol in third parties?

  353. 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

  354. mathijs has left

  355. mathijs has joined

  356. larma

    why would they care about those strings, if it wasn't for the protocol?

  357. Guus

    We'll have to talk to them to be sure.

  358. Wojtek has joined

  359. flow

    what Guus said

  360. Guus

    the strings might be a way to control interop.

  361. beta has left

  362. pep.

    Guus, our goal is not to do interop with them

  363. larma

    there is no interop between signal and anything because they don't federate

  364. 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

  365. 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.

  366. 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

  367. Syndace

    flow: +1, that's how I understand it

  368. Guus

    flow meaning that they would be fine with 'Olm', right?

  369. flow

    Guus, I assume so, yes

  370. flow

    (But I haven't look at Olm in a while)

  371. Guus

    That's also how I think things stand.

  372. Guus

    but we'll have to check with them.

  373. beta has joined

  374. mathijs has left

  375. mathijs has joined

  376. 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

  377. mukt2 has left

  378. 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.

  379. lskdjf has joined

  380. 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

  381. 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.

  382. 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.

  383. flow

    But obviously it is not my call but up to the ecosystem and community of (implementation and specificatin) developers to decide

  384. Syndace

    But yes, a breaking change is a must if we don't want OMEMO to stay as it is forever

  385. adiaholic has left

  386. 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

  387. flow

    Syndace, it is perfectly fine that you want to avoid namespace bumps whenever possible

  388. mukt2 has joined

  389. 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

  390. pep.

    yeah some transparency would be nice :)

  391. Shell has left

  392. Shell has joined

  393. 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.

  394. dwd

    Weird. Someone just pinged my dev workstation's XMPP server from the Seychelles - sent a stream open, waited for the features, and dropped.

  395. Martin has joined

  396. pep.

    Teh anonymous are onto you

  397. dwd

    larma, I don't think it does need the constants to remain the same if you're doing a flip-over, does it?

  398. 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.

  399. dwd

    pep., They'll be massively confused at hitting a healthtech messaging platform that just happened to speak XMPP.

  400. jonas’


  401. flow

    Not that it matters, but has the E2EE SIG already offically been formed?

  402. dwd

    jonas’, This? No, forwardhealth.co

  403. dwd

    flow, Nobody knows because we can't remember the process. :-)

  404. jonas’

    dwd, I meant as a candidate for an origin of the scan

  405. jonas’

    flow, no, at the very least because council didn’t completely vote yet

  406. 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

  407. Daniel

    we just haven’t had the time to actually write something down

  408. flow

    I see

  409. Daniel

    which is what we are trying to do soon(tm) as Syndace pointed out

  410. dwd

    Daniel, FWIW, I appreciate that it's transparency that takes effort and deliberation; secrecy is the default unless a considerable effort is made.

  411. j.r has left

  412. 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

  413. 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)

  414. 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.

  415. Syndace

    larma: I don't think the goal of OMEMO2 is to stay backward compatible.

  416. flow

    especially if people insist on their approach without at least looking for compromises

  417. larma

    Syndace, I think there are different things going under the name of OMEMO2 😉

  418. MattJ resists writing mod_omemo which automatically translates between omemo1 and omemo2

  419. Kev

    If you can write such a thing, then at least omemo1 is horribly broken, no?

  420. larma

    If we just change the wire format it would be possible

  421. MattJ

    All E2EE is horribly broken, because the endpoints are users :)

  422. Kev

    Right, if that's the only thing that changed.

  423. Syndace

    larma, changing only the wire format doesn't help anybody.

  424. jonas’

    MattJ, *devices, not users

  425. larma

    Syndace, so what issues are there that you'd like to solve?

  426. 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

  427. pep.

    jonas’, in this case I think devices are the lesser evil. Users are those that make e2ee horribly broken :p

  428. MattJ

    jonas’, the devices generally defer trust decisions to the users (or TOFU/BTBV/etc.) which makes life easier

  429. Kev

    I think Dave's right that it'll end up being happy-eyeballs-ish.

  430. Syndace

    larma: one second, having trouble to find the link on mobile

  431. j.r has joined

  432. Syndace

    Here you can find a list of things we want to change or consider for OMEMO2: https://github.com/Syndace/xeps/projects/1

  433. Syndace

    And that list does not include the actual change of the wire format :D

  434. flow

    pah, no need to state the obvious ;)

  435. sonny has left

  436. beta has left

  437. beta has joined

  438. 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

  439. larma

    Also honestly it would be better if we stayed compatible with libsignal if possible

  440. sonny has joined

  441. larma

    Because there are a bunch of libsignal implementations already

  442. Syndace

    Well then we won't ever move away from GPL

  443. Zash

    "Because popularity" ?

  444. flow

    larma, surely you could take those implementations and change the constants

  445. jonas’

    flow, if the implementations directly link against libsignal?

  446. flow

    jonas’, hmm?

  447. Syndace

    We could fork libsignal and change the constants

  448. larma

    Dynamic linking is a thing

  449. flow

    of course the outcome would still be GPLed

  450. 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

  451. Martin has left

  452. flow

    jonas’, potentially yes, but maybe the libsignal library provides an interface to feed those constants into it

  453. Martin has joined

  454. 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

  455. 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

  456. jonas’

    yes, though that is concerning in its own

  457. jonas’

    lots of crypto-implementations

  458. jonas’

    and I don’t think we have as many cryptographers as we have languages in which xmpp clients exist

  459. flow

    yep, but OTOH omemo implementations have already gone through review, that may happens with new libraries too

  460. jonas’

    did they?

  461. flow

    and you can't really forbid people from publishing a library

  462. flow

    jonas’, https://conversations.im/omemo/audit.pdf

  463. flow

    plus a non-gpled doubleratched/x3dh library has potentially a even higher chance from getting audited because of $buisness interest

  464. pep.

    Even though Copyleft is actually quite aligned with business interests..

  465. Vaulor has left

  466. emus has left

  467. emus has joined

  468. beta has left

  469. mukt2 has left

  470. Martin has left

  471. Martin has joined

  472. Shell has left

  473. Shell has joined

  474. pdurbin has joined

  475. sonny has left

  476. beta has joined

  477. waqas has left

  478. adiaholic has joined

  479. pdurbin has left

  480. mukt2 has joined

  481. aj has left

  482. Lance has joined

  483. Vaulor has joined

  484. adiaholic has left

  485. adiaholic has joined

  486. sonny has joined

  487. moparisthebest

    > Guus: I'd prefer the XSF to publish only XEPs that are usable by both commercial and non commercial parties.

  488. moparisthebest

    Great so for example the GPL

  489. moparisthebest

    Name one large commercial entity that doesn't use Linux for instance

  490. dwd

    moparisthebest, I don't think that's what Guus actually intended to mean - I assumed it to mean FLOSS vs non-FLOSS.

  491. 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

  492. eevvoor has joined

  493. moparisthebest

    And to be honest I couldn't care less about non-FLOSS, they made their bed, they can lay in it

  494. 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.

  495. moparisthebest

    They always have the option to go FLOSS

  496. moparisthebest

    "doc it hurts when I do this" "stop doing it"

  497. Guus

    I strongly feel that the XSF should not adopt the strategy of telling people that.

  498. mukt2 has left

  499. Guus

    We'd loose more potential users than that we'd make people use FLOSS.

  500. dwd

    moparisthebest, You're saying any use of XMPP should be GPL? Like, say, Fortnite? I can't see that being viable.

  501. 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.

  502. adiaholic has left

  503. beta has left

  504. flow

    Guus, I think it's the other way around: we loose potential community members if we forbid "gpl-only-xeps"

  505. beta has joined

  506. flow

    I think part of the people currently in this room are here because of omemo

  507. Guus

    flow, I'm talking about "people/organizations applying XMPP", you're talking about "members of the XSF" I think.

  508. moparisthebest

    Sure I'd be fine if all XMPP implementations had to be GPL, actually AGPL would be better

  509. Martin has left

  510. 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.

  511. Guus

    > Sure I'd be fine if all XMPP implementations had to be GPL, actually AGPL would be better I strongly disagree.

  512. moparisthebest

    That's well put flow , I'm explicitly here because of the open source freedom, nothing else

  513. flow

    Guus, no I mean community members in the bordest sense, taht is XSF members and ppl/orgs applying XMPP

  514. Martin has joined

  515. jonas’

    I agree with Guus

  516. dwd

    moparisthebest, And I'll continue to defend your right to choose to release under any license you choose, especially FLOSS licensing.

  517. jonas’

    part of being an open and free standard is the freedom of license model

  518. 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.

  519. Guus


  520. 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.

  521. j.r has left

  522. 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

  523. dwd

    moparisthebest, What if we put that XEP into a compliance suite?

  524. moparisthebest

    That part I wouldn't consider an open standard

  525. moparisthebest

    A gpl standard I would consider open

  526. Zash

    "a gpl standard" doesn't even make sense!

  527. dwd

    moparisthebest, You literally cannot have a "GPL specification" though.

  528. moparisthebest

    dwd: no one has to care about that either

  529. moparisthebest

    Isn't the argument that omemo is gpl

  530. moparisthebest

    Or requires gpl, that's what I mean

  531. j.r has joined

  532. 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.

  533. flow

    dwd, right, hence I wrote "gpl-only-xep"

  534. Zash

    Doesn't help that this thing is a GPL library

  535. flow

    but otoh I am not sure if we haven't here the case of a specifcation which requires gpl

  536. dwd

    flow, Indirectly, we do. But this is a combination of two problems.

  537. flow

    if I where to write the constants in the xep with a disclaimer that I have extracted them from an gpl implementation…

  538. flow

    it's complicated → time for coffee

  539. dwd

    flow, Can't, since that would violate the copyright.

  540. dwd

    flow, Our XEPs are explicitly under an MIT license.

  541. flow

    fair point, then I do not write them into the xep but into some other document

  542. Guus

    > it's complicated → time for coffee +1 ☕

  543. beta has left

  544. beta has joined

  545. Zash

    ☕ !

  546. Lance has left

  547. tao has joined

  548. Shell has left

  549. Shell has joined

  550. tao has left

  551. pep_ has joined

  552. adiaholic has joined

  553. moparisthebest

    so the fix is just to get the board to allow our XEPs to be under MIT *or* GPL, author's choice

  554. moparisthebest

    then the omemo details can be published in the XEP and everyone is happy

  555. winfried has left

  556. winfried has joined

  557. moparisthebest

    we could have a whole new category of GPL'd specs called GEPs :)

  558. Guus

    I'm very much against this.

  559. Guus

    People will need to start to worry if they can actually use a XEP.

  560. moparisthebest

    my point is they already have to

  561. Guus

    not from a license perspective - other than with OMEMO?

  562. Guus

    currently? not from a license perspective - other than with OMEMO?

  563. moparisthebest

    yes, I have no assurance the rest of the XEPs have been thoroughly vetted for license/IPR issues

  564. pep_

    Guus, of course they would have to.

  565. moparisthebest

    if my business were to rely on it, I'd need a lawyer or something to do that presumably

  566. pep_

    As moparisthebest says

  567. adiaholic has left

  568. pep_

    The IPR only says "if something happens, it's not us!!"

  569. pep_

    (or at least that its legal value.)

  570. 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.

  571. pep_

    I don't think we're on the same page still

  572. Guus

    If XMPP would only be observed as doing the latter, it wouldn't even be considered in many businesses.

  573. Guus

    You'd not even get a foot in the door, so to speak. It'd be dismissed outright.

  574. Guus

    I'm not saying I agree to that, or that those businesses _need_ to dismiss it - but it's what will happen.

  575. 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

  576. dwd

    moparisthebest, I'm assuming you know that first statement is entirely wrong?

  577. dwd

    moparisthebest, And therefore the second.

  578. moparisthebest

    I don't see any problem whatsoever with a XEP explicitly saying "for $reasons implementations of this must be GPL"

  579. 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

  580. moparisthebest

    it's crystal clear, it's an open standard, what else are we after

  581. Guus

    You're not very 'open' if you're requiring a specific license, in my opinion.

  582. pep_

    This has nothing to do with 0987 referencing $implementation

  583. 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

  584. pep_

    This ^

  585. dwd

    moparisthebest, You're attempting to require to prove a negative.

  586. adiaholic has joined

  587. Guus

    I'm off to get the kids. later!

  588. moparisthebest

    bottom line is this, if $company implements a XEP and that XEP has problems, who is legally responsible? $company or the XSF ?

  589. dwd

    moparisthebest, There is a world of difference between striving to achieve a level playing field for everyone, and not aiming for that.

  590. moparisthebest

    I think it's always $company and therefore they can't rely on anything the XSF says

  591. 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

  592. moparisthebest

    dwd, I don't think we should aim for that in any way no

  593. dwd

    moparisthebest, OK, but that is an entirely different argument. You're arguing we should not be an open standards organisation.

  594. moparisthebest

    no I'm arguing that a GPL-requiring standard is an open standard

  595. pep_

    I always enjoy how everybody uses "open" in so many ways

  596. moparisthebest

    and if someone chooses not to implement it, that's on them

  597. 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.

  598. winfried has left

  599. winfried has joined

  600. 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.

  601. jonas’

    (and I’m a very pro-GPL person)

  602. moparisthebest

    that's fine, reasonable people can disagree :)

  603. 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)

  604. dwd

    moparisthebest, Yes, sure, but if you're going against a well-established definition...

  605. jonas’

    moparisthebest, the second also hinders implementors who are bound to non-GPL for whichever reason.

  606. moparisthebest

    a standard which requires GPL doesn't hinder implementors, their act of not choosing the GPL is their own hinderence

  607. jonas’

    which might very well be external even

  608. dwd

    moparisthebest, But the act of not choosing my commercial license is surely their own hinderence too?

  609. 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.

  610. moparisthebest

    and I'd simply choose not to use it

  611. moparisthebest

    I don't know why we'd require anything else of anyone

  612. dwd

    moparisthebest, But itd still be an open standard by your unique definition?

  613. mukt2 has joined

  614. moparisthebest

    not an open license not an open standard I guess ?

  615. adiaholic has left

  616. adiaholic has joined

  617. dwd

    moparisthebest, That's not what the term means.

  618. moparisthebest

    I guess there is no point in arguing over semantics, which I probably started so my bad

  619. moparisthebest

    bottom line, I'm perfectly fine with a XEP that requires implementations to be GPL for whatever reason

  620. moparisthebest

    I'm also fine with a XEP that requires $proprietary_license, I'd just ignore it

  621. 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.

  622. moparisthebest

    whatever that ends up being I'm fine with

  623. 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

  624. moparisthebest

    I don't care about non FOSS anything

  625. 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

  626. adiaholic has left

  627. Guus

    > I don't care about non FOSS anything You don't have to, but the XSF should not exclude XMPP from nonFloss.

  628. adiaholic has joined

  629. moparisthebest

    I don't mind if it does, since I don't care about any non FLOSS people/things/companies

  630. moparisthebest

    how does it help any of us if say slack is using XMPP underneath? meh

  631. calvin has joined

  632. 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)

  633. moparisthebest

    ideally they should use their own halfbaked buggy protocol, will help them die sooner

  634. 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.

  635. pep_

    moparisthebest, I agree, it doesn't, at least as long as their goal is not to federate and be happy ever after.

  636. 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.

  637. moparisthebest

    Guus, and you wouldn't be employed if those were relicensed GPL down the line?

  638. UṣL has left

  639. moparisthebest

    interesting dwd , I'd be curious what the reason is for that or the specific law

  640. Guus

    moparisthebest: those solutions wouldn't have been based on XMPP then

  641. pep_

    dwd, I'm not especially happy with OSI fwiw.

  642. moparisthebest

    Guus, eeehhh that seems again like "businesses won't use GPL" and that's simply not true, Linux

  643. Guus

    And relicensing is absolutely out of the question in many board rooms.

  644. dwd

    moparisthebest, It's not law, but policy.

  645. moparisthebest

    and I don't care about those board rooms, they can roll their own xmpp-like replacement and die

  646. mukt2 has left

  647. 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.

  648. moparisthebest

    some better company will come along, take over their business, and hire their devs :)

  649. Guus

    You severely underestimate how much the XMPP community benefits from these organisations.

  650. pep_

    Guus, well that's an issue as I said above. They hide themselves.

  651. pep_

    (or take it the other way if you prefer. They're not visible)

  652. pep_

    In the meantime, XMPP is still largely influenced by these implementations

  653. Guus

    Gtg, kid is here

  654. moparisthebest

    you misunderstand me, maybe that's a huge segment, I don't care about those use-cases or organizations

  655. 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.

  656. adiaholic has left

  657. pep_

    dwd, and that's one of my issues with them

  658. 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

  659. Vaulor has left

  660. Vaulor has joined

  661. moparisthebest

    I guess a decent proxy might be how many support PGP or OTR? my guess is also none

  662. dwd

    moparisthebest, Entirely possible that it's none, I agree. But what if it were something else?

  663. 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.

  664. 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"

  665. dwd

    We can't *have* a legal opinion if we're not lawyers.

  666. pep_

    We might, wrongly :-°

  667. 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.

  668. MattJ

    Agree. I believe in open standards for interoperability. I think the discussions would be different if a proprietary E2EE protocol was dominant already...

  669. pep_

    MattJ, free software implementations just wouldn't use it..

  670. MattJ

    Requiring implementations be GPL will not make closed-source implementations become GPL. It will just make closed-source implementations become non-interoperable.

  671. MattJ

    Which is not a world I want to live in, which is why I dedicate so much to open standards

  672. moparisthebest

    MattJ, and how is that different than the current situation?

  673. calvin has left

  674. calvin has joined

  675. moparisthebest

    reworded, name an existing public federated interoperable closed source implementation

  676. 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)

  677. MattJ

    moparisthebest, that doesn't make sense - this whole discussion is about the fact that closed-source interoperable implementations are not possible

  678. moparisthebest

    so it hasn't happened in 21 years but maybe it'll happen soon? meh

  679. MattJ

    because of the GPL restriction

  680. 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

  681. 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.

  682. winfried has left

  683. 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? :)

  684. winfried has joined

  685. dwd

    moparisthebest, Neither TLS, PGP, or MLS require GPL, so that rather falls down as an argument.

  686. moparisthebest

    doesn't mean we couldn't do it differently

  687. dwd

    moparisthebest, Doesn't mean we have to do it differently either.

  688. mathijs has left

  689. mathijs has joined

  690. mukt2 has joined

  691. lorddavidiii has left

  692. lorddavidiii has joined

  693. pep_

    (fwiw, I wouldn't especially be proud that the army is using XMPP..)

  694. moparisthebest

    govts aren't really bound by licenses/GPL anyway

  695. MattJ

    pep_, that's going down yet another rabbit-hole - if you want to choose who is even allowed to use your technology/software

  696. MattJ

    At that point yeah, we might as well just remove any reference to "open"

  697. 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.

  698. dwd

    moparisthebest, They seriously are. I could tell some tales about that, but they're real sticklers for licensing.

  699. ralphm

    I for one find that acceptable for the XSF.

  700. moparisthebest

    dwd, they aren't even bound by laws, UK for example just broke a ton of laws then changed them retroactively? :)

  701. MattJ

    ralphm, acceptable? or unacceptable?

  702. ralphm

    hah, *not* acceptable.

  703. MattJ


  704. 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

  705. ralphm

    I do not intend to take any steps to exclude any field of endevour from our standards process or membership.

  706. MattJ

    Me neither

  707. pep_

    ralphm, who is talking about excluding commercial entities

  708. 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.

  709. moparisthebest

    GPL doesn't in any way exclude commercial entities though

  710. pep_


  711. moparisthebest

    and we are talking on an individual XEP basis

  712. ralphm

    except it does

  713. pep_

    ralphm, that's maybe your biased view. Many implementations succeed in using copyleft licenses and being sustainable

  714. MattJ

    moparisthebest, you said yourself (iirc) that such a XEP wouldn't be able to be included in the compliance suite

  715. MattJ

    I mean, it could, but it means it's not quite as simple as "it's just one XEP"

  716. calvin has left

  717. 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.

  718. moparisthebest

    ralphm, maybe you mean it excludes non-GPL implementations, sure, but those could be commercial or non commercial

  719. MattJ

    We're trying to reduce fragmentation in XMPP, or at least that's what I've been working on

  720. pep_

    MattJ, "we"?

  721. pep_

    "in XMPP", which part?

  722. ralphm

    The XSF, from the very beginning.

  723. pep_

    "The XSF" is not one person

  724. Zash

    So much text produced over this issue.

  725. MattJ

    pep_, compliance suites are for reducing fragmentation

  726. MattJ

    and that has been a community effort

  727. MattJ

    for years

  728. moparisthebest

    MattJ, but you just ignore the part you don't want or can't implement, I don't think it matters there

  729. MattJ

    moparisthebest, I just tried to chat with a non-OMEMO client in Conversations and it took 3 taps through various confirmation boxes

  730. 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

  731. MattJ

    If we also care about UX, yes, fragmentation matters

  732. moparisthebest

    MattJ, good? :)

  733. lorddavidiii has left

  734. 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.

  735. moparisthebest

    you are of course free to fork Conversations to fix the UX

  736. pep_


  737. moparisthebest

    ralphm, and GPL is the pinnacle of openness so that's great! :)

  738. moparisthebest

    but yes, what pep_ said

  739. MattJ

    moparisthebest, and decrease practical security in return

  740. pep_

    How so?

  741. MattJ

    moparisthebest, all because the XSF refused to provide a fair standard

  742. pep_

    "Security by obscurity"?

  743. pep_

    We all know that doesn't work

  744. 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.

  745. MattJ

    pep_, disabling E2EE silently without informing/confirming with the user is a security problem

  746. lorddavidiii has joined

  747. moparisthebest

    I suppose forking is always an option, GXSF publishing GPL'd GEPs anyone? :/

  748. pep_

    Without informing the user? What client does that?

  749. MattJ

    pep_, the one moparisthebest just suggested I create in order to fix the UX caused by a fragmented ecosystem

  750. dwd

    moparisthebest, And the XSF's licensing allows that.

  751. 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.

  752. pep_

    MattJ, I missed that bit sorry

  753. dwd

    moparisthebest, Because we're an *open* standards organisation.

  754. ralphm

    In fact, the namespaces in XEP-0384 are not even tied to or regulated by the XSF.

  755. pep_

    It's not the only XEP fwiw

  756. ralphm


  757. MattJ

    I guess this whole thing has been enlightening to me

  758. 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

  759. moparisthebest

    I'd like the XSF to change to allow that

  760. moparisthebest

    but if it won't it might be valuable to have an open place to publish them

  761. 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

  762. dwd

    moparisthebest, For OMEMO specifically, that's a fine idea. I suggested it earlier.

  763. MattJ

    moparisthebest, I think everyone here is totally fine with them being published, just not by the XSF

  764. pdurbin has joined

  765. pep_

    I think the copyleft/GPL != business is just very wrong

  766. mukt2 has left

  767. ralphm

    I think a lot of people and corporations (including probably all sponsors) would leave the XSF if we would ever change that, moparisthebest.

  768. ralphm

    I would.

  769. moparisthebest

    that'd be ridiculous

  770. lskdjf has left

  771. lskdjf has joined

  772. moparisthebest

    but I also couldn't care less if they did, no loss as far as I'm concerned

  773. MattJ

    pep_, another time I'd love to hear your thoughts on how a pure GPL "commercial entity" would work

  774. pep_


  775. MattJ

    But I think that's even too OT for here right now

  776. jonas’

    you could try next door

  777. MattJ

    I didn't want to disturb the tranquility there

  778. pep_

    I'm on a nazi network I only have http available atm..

  779. dwd

    MattJ, Pure software, not services? Tricky. I've seen people try, but I've seen all of them fail.

  780. MattJ

    dwd, logically that makes sense, yes :)

  781. moparisthebest

    dwd, wait are their pure software companies that just sell proprietary software with no support or services? :/

  782. pep_

    I think Conversations is a nice example of this fwiw

  783. moparisthebest

    *there wow...

  784. pep_

    Conversations.im being separate from Conversations.

  785. dwd

    pep_, Possibly. Though I wasn't sure whether Conversations was a serious revenue stream, or if that was mostly the services.

  786. pep_

    I'm sure he's not making millions, but you don't need that to live anyway

  787. dwd

    moparisthebest, By services I meant hosted services. I've seen plenty of GPL-and-support companies fail.

  788. ralphm

    I'd be very surprised if Conversations' play store income suffices to continue its development other than as a hobby.

  789. Daniel

    Conversations’ app store sales make much more money than conversations.im

  790. moparisthebest

    what's Redhat dwd / MattJ ?

  791. Daniel

    not in absolut numbers (both are pretty low) but in relative terms

  792. ralphm

    Daniel, could it be your day job?

  793. Daniel


  794. Daniel

    i mean it is. but no

  795. Guus


  796. ralphm


  797. pep_

    And you do consulting around it, right

  798. pep_

    And it's just fine

  799. mukt2 has joined

  800. 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

  801. pep_

    Nobody "just" sells software anyway. You sell support, training, hosting, contracting (adding features/fixing bugs)

  802. 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

  803. ralphm

    I don't see the point and think allowing that is harmful. Maybe even just entertaining the idea is.

  804. moparisthebest

    I don't think I can be convinced entertaining any idea is ever harmful

  805. moparisthebest

    ralphm, and I don't see the point in non-GPL software existing, different perspectives eh?

  806. ralphm

    moparisthebest, different perspectives is fine.

  807. 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

  808. Lance has joined

  809. moparisthebest

    sure let's get a law banning distribution of binaries ? :D

  810. pep_

    Obliterate patents and copyright

  811. 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.

  812. 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

  813. 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

  814. moparisthebest

    I would like the XSF to change to allow that

  815. moparisthebest

    and if it doesn't, fine, I'd still like to see it though, that's all

  816. Shell has left

  817. ralphm

    moparisthebest, ok. Do you intend to take a particular course of action?

  818. 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.

  819. Shell has joined

  820. ralphm


  821. 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.

  822. MattJ

    I mean, I'm not 100% against that idea

  823. MattJ

    But it reduces the XSF to a repository of documents

  824. 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.

  825. 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

  826. MattJ

    Such a document could just as easily be hosted elsewhere

  827. pep_

    MattJ, tbh, the XSF is not far from that to me atm.. a badly organized repository of documents

  828. pdurbin has left

  829. MattJ

    pep_, sad you feel that way, I think it has quite a bit of expertise to offer as well

  830. 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)

  831. pep_

    Hmm, not license related, but "standards" used in the whole community that are not XEPs

  832. ralphm

    That's a hugely different thing there.

  833. pep_

    Not so different to me. That makes some of them proprietary documents

  834. ralphm

    XMPP extension protocols published (or not) by entities other than the XSF or the IETF is totally fine. By design!

  835. calvin has joined

  836. pep_

    So proprietary is fine, but free software isn't

  837. ralphm

    We designed XMPP to be distributedly extensible.

  838. pep_

    I see

  839. pep_

    Maybe you weren't replying to what Guus said. because it seems to me we're not in sync

  840. 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)

  841. pep_

    Or I'm not reading that correctly

  842. 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.

  843. 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.

  844. pep_

    Guus, what does it change then if it's published out of the XSF to you? Free software or proprietary

  845. 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

  846. Guus

    pep_ I'm unsure if I understand your question.

  847. pep_

    I'm trying to reread your message that I quoted and see what I didn't get

  848. pep_

    > I hope that no-one creates such XEPs and publishes them anywere

  849. eevvoor has left

  850. dwd

    Daniel, Yes, but we're evil. So it's evil knowledge. EVIL!

  851. Shell has left

  852. Shell has joined

  853. pep_

    Daniel, personally I'm not hostile towards commercial services

  854. 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.

  855. Guus

    I'm unsure how to word that differently.

  856. ralphm

    Because it by its very nature fractures the community.

  857. pep_

    Guus, so you also don't like practices like say.. MUC avatars?

  858. MattJ

    I personally don't like the way MUC avatars were introduced, no

  859. pep_

    Multiple attempts to specify that have been rejected by council

  860. 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.

  861. 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?

  862. MattJ

    It crashed at least one client, and I still get a ghost user in some of my clients/MUCs

  863. pep_

    So we're using some proprietary protocol atm, that sits on processone's website

  864. Lance has left

  865. pep_

    But no one is actually complaining about them

  866. pep_


  867. pep_

    I mean, no one that is complaining about OMEMO

  868. Kev

    I mean, other that MattJ, two whole lines above.

  869. Guus

    pep_ I think we're talking about different things.

  870. Kev

    I mean, other than MattJ, two whole lines above.

  871. Zash

    Why even have a standards organization, just implement whatever you want and whatever becomes popular is the standard! /s

  872. 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

  873. j.r has left

  874. dwd

    Loosely a +1 to that.

  875. ralphm

    pep., Do you mean https://xmpp.org/extensions/inbox/muc-avatars.html

  876. matlag has left

  877. j.r has joined

  878. winfried has left

  879. Shell has left

  880. Shell has joined

  881. 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>

  882. winfried has joined

  883. pep_

    ralphm, yes, and another one as well

  884. 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).

  885. jonas’

    dwd, no, MUC avatars are a thing

  886. Zash

    Everyone has MUC avatars

  887. 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.

  888. 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

  889. jonas’

    I’m for sure not setting them manually on search.jabber.network ;)

  890. ralphm

    pep., I don't remember why it didn't get accepted as a XEP, though.

  891. 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.

  892. 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. :-)

  893. Daniel

    Guus, well it is 'fully adopted' in the free open source world

  894. Daniel

    i think any actively developed client has support for it

  895. pep_

    ralphm, can't find the original document atm, but it wasn't hosted on the XSF infra at all.

  896. Kev

    Swift doesn't (yes, it's still developed) :)

  897. david has left

  898. Guus

    Daniel I can't add it to Apache2-licensed clients, as far as I can tell.

  899. Daniel

    Guus, no. but you can relicense the client

  900. david has joined

  901. dwd

    ralphm, That one? Introducing pubsub on MUC, I think, blocked it. Perhaps.

  902. Daniel

    which i think some clients have done

  903. Guus

    But I don't want to relicense the client.

  904. Daniel

    i don’t like the gpl either and i'm not happy about the current situation. but it is still fairly widely deployed

  905. 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)

  906. Guus

    Sure, absolutely, I agree to that.

  907. Daniel

    i mean show me another xep from the past 5 years that is as widely deployed as omemo

  908. Guus


  909. Guus ducks, runs.

  910. 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

  911. mukt2 has left

  912. dwd

    There were quite a few smaller commercial clients based on Smack which blindly brought in OMEMO support too.

  913. flow

    Sadly, we did not sue them all and made $$$

  914. ralphm

    Daniel, MAM

  915. Daniel

    ralphm, i would like to see stats on that. it might be very close or equal

  916. 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

  917. pep_

    flow: enforcing GPL, with what money? these free software people they're not supposed to produce work for free? 🙂

  918. Zash

    Wasn't OMEMO already on the path to popularity before becoming a XEP?

  919. dwd

    Zash, It was in Conversations for ~1 year before becoming a XEP.

  920. Zash

    And, isn't it still the pre-XEP version that's popular?

  921. 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.

  922. Daniel

    (also http upload, i'm obviously exaggerating to make a point)

  923. j.r has left

  924. j.r has joined

  925. Zash

    HTTP Upload has at least moved within the standards process since

  926. moparisthebest

    has it? (looking at you http upload encryption)

  927. Daniel

    but is currently stuck for some unknown reason

  928. Daniel

    but that's a different story

  929. pep_

    moparisthebest, yeah that's a different XEP..

  930. pep_

    or ProtoXEP, rather

  931. 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

  932. moparisthebest

    I'd prefer to end-run that and just say we are ok with GPL requiring XEPs

  933. emus has left

  934. Shell has left

  935. Shell has joined

  936. jonas’

    moparisthebest, no, you misunderstood

  937. 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

  938. ralphm


  939. Zash

    Daniel, haha what, stuck in last call?

  940. moparisthebest

    ok that's fair I guess jonas’

  941. 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

  942. jonas’

    moparisthebest, see my edit tho

  943. moparisthebest

    still what's the appropriate method to bring up "allowing GPL-requiring XEPs" for a membership vote or whatever?

  944. 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

  945. ralphm

    moparisthebest, also, to answer your question on how do do this: (it will take some time to type)

  946. jonas’

    moparisthebest, send it to Alex or Board I think?

  947. Daniel

    > The Last Call ends on 2019-01-22 mhh ok

  948. pep_

    editors should look into that

  949. jonas’

    Daniel, I think there was unaddressed last call feedback

  950. jonas’

    but I may be wrong

  951. Guus

    pep_ I agree with you that this all reflects poorly on us.

  952. jonas’

    Daniel, ... but I can’t find any evidence of that

  953. Guus

    and neither 'solution' will be able to fix that.

  954. Guus

    We just differ on opinion on which solution is the least worst one, I think.

  955. 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.

  956. moparisthebest

    I'd like to bring it up for a membership vote just out of principle honestly

  957. pep_

    I guess you can start a thread on the list, without putting it for a vote. There is no majority for sure

  958. moparisthebest

    just gauging the room I also suspect it won't reach a majority

  959. Daniel

    jonas’, i think it has had multiple last calls. some had feedback (which got addressed)

  960. Zash

    I vote no!

  961. Zash

    No to everything!

  962. Daniel

    and then the last last call didn’t have any replies at all

  963. moparisthebest

    Zash, thanks I'll just word it negative then :)

  964. jonas’

    Daniel, I guess we should put it on the next council agenda to restart the LC

  965. jonas’

    or maybe the editors can just do that

  966. jonas’

    (or even have to)

  967. 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.

  968. jonas’

    reminds me that I need to update the spreadsheet of dooom

  969. Daniel

    i'm going to assume that's because everyone is happy :-)

  970. dwd

    jonas’, I'd stick an LC on the agenda for the next Council meeting.

  971. dwd

    jonas’, Oh, you can automatically restart it, actually. Declare it as a Council change auto-restart.

  972. jonas’

    dwd, exactly

  973. pep_

    That's a thing?

  974. dwd

    pep_, Yes, if a Council changes after an LC but before the advancement to Draft is complete, the LC restarts.

  975. pep_

    Even if the LC is almost a year long? 😛

  976. Kev

    Consideration for advancement to draft* I think

  977. Kev

    It doesn't get restarted if one Council rejects the move to Draft.

  978. stpeter has joined

  979. dwd

    Kev, Yes. Before the vote to Draft or before such a vote completes, I suppose.

  980. dwd

    pep_, Well, it's not *meant* to happen this way.

  981. pep_

    (Not that I'm opposing this move)

  982. Shell has left

  983. Shell has joined

  984. 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.

  985. Shell has left

  986. Shell has joined

  987. moparisthebest

    I don't have super strong feelings about OMEMO specifically

  988. moparisthebest

    I do have a strong feeling that we *should* be able to publish GPL-requiring XEPs

  989. ralphm

    Well, I don't like to waste time on hypotheticals, to be honest.

  990. 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?

  991. Daniel

    or just multiple results?

  992. moparisthebest

    well also it's not a hypothetical, it means whether omemo requires GPL is a non-issue right?

  993. moparisthebest

    then it can be evaluated on technical merits as it should (in my opinion)

  994. moparisthebest

    *only on technical merits

  995. Daniel

    a never mind

  996. Daniel

    that's kinda the status quo

  997. Shell has left

  998. Shell has joined

  999. 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

  1000. 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

  1001. moparisthebest

    right, I'd like to just do (b)

  1002. jonas’

    moparisthebest, please do so then

  1003. jonas’

    thank you very much.

  1004. moparisthebest

    yep and I appreciate the discussion and pointers on how to do that

  1005. Kev

    Does Xep1 get a membership vote? Bylaws do, doesn't Xep1 just get Board?

  1006. Kev

    I forget, and don't have cycles to look it up

  1007. Shell has left

  1008. Shell has joined

  1009. ralphm

    Kev: yes, XEP-0001 is Board only.

  1010. ralphm

    But, the membership is king

  1011. ralphm

    So they could override Board.

  1012. ralphm

    That's why I presented that order.

  1013. 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.

  1014. Kev

    Unless I'm missing something.

  1015. 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

  1016. winfried has left

  1017. winfried has joined

  1018. Kev

    I think they would have to change the process first that says that only Board can approve changes.

  1019. mukt2 has joined

  1020. wojtek has joined

  1021. jonas’

    couldn’t membership vote for a process exception? :)

  1022. dwd

    Daniel, MAMFC? That's like current MAM, but if it archived everything, not just "traditional IM messages".

  1023. Shell has left

  1024. Shell has joined

  1025. Kev

    jonas’: I hope we don't get to the stage that we need such a discussion.

  1026. 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.

  1027. 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

  1028. ralphm

    I personally think it is irresponsible.

  1029. wojtek has left

  1030. Daniel

    dwd, yes. thank you

  1031. Daniel

    re: fallback body

  1032. pep_

    I would like to make this a regular practice fwiw, having members vote on things, without all the weight you all just mentioned

  1033. 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.

  1034. pep_

    What's wrong with that.

  1035. pep_

    If directors can alleviate some of the work for members, great. if members feel they need to vote themselves, why not

  1036. 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

  1037. jonas’

    pep_, because it’s not just members, but also secretary who has to do the work

  1038. jonas’

    and given that we’re all volunteers...

  1039. Daniel

    by that defintion shouldn't fallback be in either MAM or mamfc

  1040. 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.

  1041. pep_

    jonas’, that's fine, that doesn't justify the "that is also often a huge hammer that Directors walk out over"

  1042. Kev

    I think fallback being outside MAM/MAMFC/Fastening is preferable, but I'm not sure I would hugely care to see it move.

  1043. 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.

  1044. Kev

    jonas’: Thank you.

  1045. Daniel

    imho if you like general; put it in hints; if you don’t put it in mamfc

  1046. 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.

  1047. Daniel

    both are valid approaches. but a new XEP i don’t get

  1048. Zash

    I hold that an open specification can't mandate licensing of implementations.

  1049. 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.

  1050. Maranda has left

  1051. Maranda has joined

  1052. pep_

    I don't see that as a hammer, I think it's great actually

  1053. pep_

    Having members participate

  1054. Shell has left

  1055. Shell has joined

  1056. 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.

  1057. Kev

    Maybe harmful is hyperbole

  1058. ralphm

    I didn't say we should get rid of the possibility, I just think that it should not be used frivolously.

  1059. Kev

    But out of place in a normal flow.

  1060. 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

  1061. eevvoor has joined

  1062. 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]

  1063. pep_

    Not the opposite. I don't think I'm here to govern anybody, I'm here to serve

  1064. dwd

    Daniel, I did say I'd go for hints, but that's been pushed back by a previous Council.

  1065. 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.

  1066. Daniel

    i agree on the harmfullness and i was team no-fallback for reactions

  1067. jonas’

    and that’s hurtful, demotivating and unsettling for the elected members of board

  1068. Kev

    And if the chat was full of +1 noise, it would hide/show that.

  1069. Daniel

    but i wouldn’t know how to handle a fallback message in the client

  1070. Kev

    See above :)

  1071. dwd

    Daniel, <fallback/> is an attempt to allow us to be less anti-fallback.

  1072. Zash

    dwd, I'd like to point out that there's some overlap with the EME XEP

  1073. dwd

    Zash, Oh. Yes, there probably is.

  1074. ralphm

    jonas’, yes indeed.

  1075. 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.

  1076. Shell has left

  1077. Shell has joined

  1078. ralphm

    pep., you *are* appointed to govern the XSF, the corporation. This is different from governing its membership.

  1079. Kev

    Govern: conduct the policy, actions and affairs of (an organisation) with authority.

  1080. Kev

    I think that's pretty much the definition.

  1081. Kev

    I think that's pretty much the definition of what Board does.

  1082. ralphm

    Yes, I tried to convey that I don't view members as underlings :-D

  1083. Kev

    ralphm: And we love you all the more for it ;)

  1084. 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.

  1085. debacle has left

  1086. alameyo has left

  1087. Guus has left

  1088. 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.

  1089. pep_

    Sure 🙂

  1090. dwd

    Asking everyone about everything is what gets you Brexit.

  1091. pep_

    That's just wrong

  1092. Kev

    Where 'wrong' means 'demonstrably right' :)

  1093. pep_

    You're forgetting lots of context here

  1094. 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.

  1095. Kev

    Zash: I think my suggestion is actually a fairly reasonable least-knowledge way of handling fallbacks.

  1096. Guus has joined

  1097. Guus has left

  1098. Guus has joined

  1099. mukt2 has left

  1100. Zash

    Kev, where?

  1101. Zash

    I'm having a hard time following everything in this :(

  1102. 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]

  1103. jonas’

    pep_, nothing stops a member from proposing a PR against for example '1 and arguing their case

  1104. Zash

    Kev, yeah, that's sensible.

  1105. pep_

    jonas’, exactly, and I'm saying people should do it 🙂

  1106. pep_

    (Whether it's this specific case or another)

  1107. 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)

  1108. MattJ

    I think that is a reasonable position to hold, fwiw

  1109. 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"

  1110. alameyo has joined

  1111. pep_

    I don't think so

  1112. jonas’

    One is bypassing the authority of the elected board, one isn’t.

  1113. ralphm

    I agree with jonas’.

  1114. jonas’

    one is sending a message of distrust, one isn’t.

  1115. pep_

    The authority lies with the members.

  1116. pep_

    Board is elected by the members

  1117. jonas’


  1118. jonas’

    I’m not arguing that point

  1119. jonas’

    the members elect board to delegate authority

  1120. 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

  1121. jonas’

    that’s distrust

  1122. pep_

    I understand what you're saying, I just don't see that as distrust

  1123. Dele (Mobile) has left

  1124. Daniel

    something something never ask the people unless you know the outcome

  1125. jonas’

    I fail to see how you can’t, pep_, and I’d like to know your rebuttal to my arguments

  1126. mathijs has left

  1127. mathijs has joined

  1128. stpeter has left

  1129. pep_

    I'm not sure how to formulate that indeed. I'll sleep over it

  1130. larma

    jonas’, I think it makes sense in cases where the board doesn't want to decide over the members

  1131. winfried has left

  1132. winfried has joined

  1133. mathijs has left

  1134. mathijs has joined

  1135. sonny has left

  1136. mukt2 has joined

  1137. 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

  1138. 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

  1139. Kev

    larma: I think there are plenty of good reasons for Board to ask the Members on something.

  1140. Shell has left

  1141. Shell has joined

  1142. dwd

    Daniel, Yes, but that line was the single line that I objected to.

  1143. 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)

  1144. 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.

  1145. dwd

    Daniel, Actually, you'd be great - the problem that group has is in practical messaging, not the crypto side.

  1146. dwd

    Daniel, (I objected to that line because I think external representation is a Board thing)

  1147. 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" 🙂

  1148. 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?

  1149. ralphm

    Daniel, I don't think physical presense is required to participate in MLS at all.

  1150. 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)

  1151. dwd

    ralphm, It's really really helpful.

  1152. Daniel


  1153. Kev

    larma: I think that's a very complicated question that doesn't have a pithy answer.

  1154. ralphm

    but I am not opposed to sponsoring a visit to an IETF

  1155. 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.

  1156. Kev

    We have sponsored a visit to an IETF previously, haven't we?

  1157. ralphm

    Kev: we did?

  1158. dwd

    Kev, Yes, I think so. Previous London IETF, we sponsored Thijs, didn't we?

  1159. Kev

    Maybe I'm misremembering, I thought we sponsored Thijs to attend IETF London a while back.

  1160. ralphm


  1161. ralphm

    The next 'close' one for most of us is 108, in July, Madrid

  1162. Daniel regrets not having participated in the jmap working group before it was too late

  1163. emus has joined

  1164. dwd

    ralphm, MLS gets a lot of its work done in f2f interims, too.

  1165. Maranda has left

  1166. Maranda has joined

  1167. dwd

    ralphm, Of which there's one tomorrow: https://datatracker.ietf.org/meeting/interim-2020-mls-01/session/mls

  1168. ralphm

    There's one this weekend it seems

  1169. ralphm

    Agenda is empty though

  1170. Shell has left

  1171. Shell has joined

  1172. sonny has joined

  1173. pep_

    "When" the E2EE SIG gets approved (when we figure this out :p), I'm also happy to use our dormant money for this

  1174. ralphm


  1175. dwd

    ralphm, Daniel https://github.com/mlswg/wg-materials/blob/master/interim-2020-01/README.MD

  1176. ralphm


  1177. ralphm

    Be sure to read the NOTE WELL!

  1178. neshtaxmpp has left

  1179. Shell has left

  1180. Shell has joined

  1181. winfried has left

  1182. winfried has joined

  1183. adiaholic has joined

  1184. Daniel

    the mls@jabber.ietf.org channel only has known xmpp people in it :-/

  1185. dwd

    I think it only gets traffic during meetings normally.

  1186. Ge0rG

    Seriously people, what happened to this MUC? I've taken most of today just to catch up with the logs

  1187. Daniel

    as long as it actually does it's fine

  1188. Ge0rG

    Can we please have a bot that will auto-kickban on mention of "GPL"?

  1189. moparisthebest

    Ge0rG, will it exclude AGPL ?

  1190. dwd

    Daniel, Sadly not very much during Interims.

  1191. Daniel

    it says i MUST register. it doesn’t say where

  1192. moparisthebest

    ok I'll just start using GNU General Public License everywhere, break my keyboard

  1193. Ge0rG

    moparisthebest: after seeing other people engage with you on this topic, let's just agree to disagree.

  1194. 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

  1195. 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.

  1196. Kev

    Ge0rG: It is certainly not a perfect solution.

  1197. Ge0rG

    Nor is the fallbacks XEP.

  1198. Ge0rG

    But we don't strive for perfect, merely for good enough.

  1199. Kev

    I can't immediately think of anything better - although that might be a lack of imagination.

  1200. dwd

    [Unable to display message, fallback displayed] ** Something like this? **

  1201. 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

  1202. Ge0rG

    dwd: that's an interesting angle indeed: "Your client is too old and doesn't support all elements of this message"

  1203. pdurbin has joined

  1204. Lance has joined

  1205. dwd

    That was what I was thinking a client might do. A server might not index it for MAM, or something.

  1206. Ge0rG

    dwd: is there a reason for <fallback> not containing the namespace of the causing element?

  1207. stpeter has joined

  1208. dwd

    Ge0rG, Yes.

  1209. dwd

    Ge0rG, I didn't think of it.

  1210. Ge0rG

    dwd: what is the reason for <fallback> not containing the namespace of the causing element?

  1211. Ge0rG


  1212. Ge0rG

    dwd: is there _still_ a reason for <fallback> not containing the namespace of the causing element?

  1213. dwd

    Ge0rG, I'm somewhat ambivalent to that - I don't know what a client/server would do differently.

  1214. dwd

    Ge0rG, But equally, it does no harm.

  1215. dwd

    Ge0rG, It'd be a good reason *not* to try to put this in Hints, though.

  1216. Ge0rG

    dwd: it could fetch the XEP that defines that namespace from the registry :P

  1217. dwd


  1218. dwd

    Sorry, don't know what came over me then.

  1219. Ge0rG

    dwd: who are you and what have you done to dwd?

  1220. Ge0rG

    with all the roster shenanigans, probably dwd got replaced by aliens.

  1221. adiaholic has left

  1222. adiaholic has joined

  1223. mathijs has left

  1224. mathijs has joined

  1225. larma

    dwd, happened to have read my comment re partial fallback body?

  1226. Ge0rG

    larma: please don't add more complexity

  1227. pep_

    It does actually seem pretty useful though..

  1228. Ge0rG

    larma: I know it's sexy to put five different things into one message, but it makes everything more complicated

  1229. larma

    Ge0rG, if it's not in there it has to be somewhere else

  1230. Ge0rG

    pep_: it should be redefined in terms of fastenings.

  1231. larma

    So this is only for fastening, not for anything else?

  1232. dwd

    No, it's for everything where we're only using <body/> as a fallback.

  1233. Ge0rG

    larma: do you have a convincing use case for that?

  1234. pdurbin has left

  1235. larma

    Ge0rG, reply to

  1236. Ge0rG

    I think we need to revive https://xmpp.org/extensions/xep-0226.html

  1237. Ge0rG

    larma: ah, right. Hm....

  1238. Ge0rG

    larma: what if we just ignore the problem of legacy clients showing a fallback body in a slightly awkward way?

  1239. larma

    Ge0rG, what do you mean?

  1240. 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.

  1241. 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

  1242. dwd

    larma, But, mea culpa for not responding.

  1243. larma

    Ge0rG, I was thinking along those lines https://gist.github.com/mar-v-in/8f66872bb533f7e805fb174e341be992

  1244. eevvoor has left

  1245. j.r has left

  1246. calvin has left

  1247. Ge0rG

    larma: yeah, I understand that. Would also work great for Reaction fallbacks :D

  1248. larma

    Ge0rG, you mean: we can explore if this would also work great for reactions fallbacks and then decide it doesn't 😀

  1249. larma

    but yeah, there are various things where it would be handy

  1250. Ge0rG

    larma: the question is: is it worth the added complexity?

  1251. 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

  1252. larma

    I don't like the third option really

  1253. larma

    alternatively we can have something else for that

  1254. dwd

    larma, It's what we have now.

  1255. dwd

    larma, By which I mean, I've just replied to you. And again here.

  1256. mukt2 has left

  1257. Shell has left

  1258. Shell has joined

  1259. 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

  1260. j.r has joined

  1261. larma

    It would still make sense to have the other thing though

  1262. larma

    but could be separated from each other

  1263. larma

    because my usecase is obviously completely unrelated to fastening

  1264. waqas has joined

  1265. Shell has left

  1266. Shell has joined

  1267. matkor has left

  1268. matkor has joined

  1269. mathijs has left

  1270. mathijs has joined

  1271. mukt2 has joined

  1272. Shell has left

  1273. Shell has joined

  1274. Dele (Mobile) has joined

  1275. Zash has left

  1276. Zash has joined

  1277. Yagiza has left

  1278. adiaholic has left

  1279. adiaholic has joined

  1280. mukt2 has left

  1281. alameyo has left

  1282. alameyo has joined

  1283. Shell has left

  1284. pep_ has left

  1285. mukt2 has joined

  1286. Lance has left

  1287. Lance has joined

  1288. Nekit has left

  1289. mukt2 has left

  1290. rion has left

  1291. rion has joined

  1292. Nekit has joined

  1293. calvin has joined

  1294. Nekit has left

  1295. pdurbin has joined

  1296. winfried has left

  1297. winfried has joined

  1298. winfried has left

  1299. winfried has joined

  1300. sonny has left

  1301. pep_ has joined

  1302. calvin has left

  1303. calvin has joined

  1304. pdurbin has left

  1305. calvin has left

  1306. calvin has joined

  1307. pep_ has left

  1308. Alex has left

  1309. debacle has joined

  1310. winfried has left

  1311. winfried has joined

  1312. winfried has left

  1313. winfried has joined

  1314. calvin has left

  1315. calvin has joined

  1316. Alex has joined

  1317. Lance has left

  1318. calvin has left

  1319. calvin has joined

  1320. sonny has joined

  1321. mukt2 has joined

  1322. lorddavidiii has left

  1323. sonny has left

  1324. lorddavidiii has joined

  1325. winfried has left

  1326. winfried has joined

  1327. Lance has joined

  1328. emus has left

  1329. sonny has joined

  1330. Wojtek has left

  1331. Wojtek has joined

  1332. Wojtek has left

  1333. Wojtek has joined

  1334. sarxb has joined

  1335. sarxb has left

  1336. calvin has left

  1337. sonny has left

  1338. sonny has joined

  1339. mathijs has left

  1340. mathijs has joined

  1341. mukt2 has left

  1342. edhelas has left

  1343. nyco has left

  1344. nyco has joined

  1345. mukt2 has joined

  1346. emus has joined

  1347. calvin has joined

  1348. sonny has left

  1349. sonny has joined

  1350. pdurbin has joined

  1351. pdurbin has left

  1352. emus has left

  1353. emus has joined

  1354. Wojtek has left

  1355. sonny has left

  1356. Lance has left

  1357. winfried has left

  1358. winfried has joined

  1359. emus has left

  1360. Nekit has joined

  1361. emus has joined

  1362. andrey.g has left

  1363. eevvoor has joined

  1364. sonny has joined

  1365. mukt2 has left

  1366. eevvoor has left

  1367. matlag has joined

  1368. sonny has left

  1369. Dele (Mobile) has left

  1370. andrey.g has joined

  1371. sonny has joined

  1372. Lance has joined

  1373. Zash has left

  1374. Zash has joined

  1375. mathijs has left

  1376. mathijs has joined

  1377. lorddavidiii has left

  1378. sonny has left

  1379. sonny has joined

  1380. sonny has left

  1381. Shell has joined

  1382. sonny has joined

  1383. goffi has left

  1384. Shell has left

  1385. Shell has joined

  1386. adiaholic has left

  1387. calvin has left

  1388. sonny has left

  1389. Shell has left

  1390. Shell has joined

  1391. karoshi has left

  1392. Nekit has left

  1393. sonny has joined

  1394. winfried has left

  1395. winfried has joined

  1396. winfried has left

  1397. winfried has joined

  1398. Shell has left

  1399. Shell has joined

  1400. Shell has left

  1401. Shell has joined

  1402. Martin has left

  1403. edhelas has joined

  1404. paul has left

  1405. j.r has left

  1406. sonny has left

  1407. Shell has left

  1408. Shell has joined

  1409. sonny has joined

  1410. neshtaxmpp has joined

  1411. sonny has left

  1412. sonny has joined

  1413. Shell has left

  1414. stpeter has left

  1415. Lance has left

  1416. Lance has joined

  1417. sonny has left

  1418. Shell has joined

  1419. Shell has left

  1420. Shell has joined

  1421. sonny has joined

  1422. neshtaxmpp has left

  1423. neshtaxmpp has joined

  1424. stpeter has joined