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 https://github.com/signalapp/libsignal-protocol-c#license
  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’ Shodan.io?
  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 +1
  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 Phew
  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_ #semantics
  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 sure
  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_ Sure
  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 no
  794. Daniel i mean it is. but no
  795. Guus hahahaha
  796. ralphm :-D
  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 Right.
  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_ weirdly
  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 MIX
  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 this
  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’ yes
  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 that
  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 https://ietf.org/how/meetings/upcoming/
  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 https://github.com/mlswg/wg-materials/blob/master/interim-2020-01/README.MD
  1175. dwd ralphm, Daniel https://github.com/mlswg/wg-materials/blob/master/interim-2020-01/README.MD
  1176. ralphm hah
  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 Great!
  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 AND USE MACHINE LEARNING TO AUTOMATICALLY IMPLEMENT THE XEP AND THEN STORE THE RESULT IN THE BLOCKCHAIN.
  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