XSF Discussion - 2019-12-30


  1. edhelas

    emus can I borrow this? 😃

  2. emus

    > emus can I borrow this? 😃 what exactlt? ^^ xD

  3. dwd

    FYI: https://github.com/xsf/xeps/pull/864

  4. jonas’

    oh, a thing

  5. Zash

    a thing!

  6. dwd

    A thing indeed. Might get a couple more out today.

  7. jonas’

    scary

  8. flow

    dwd, nice job not escaping '>', although I wonder if I could have resited not having "evenness" (escaping '<' but not '>')

  9. dwd

    I generally hand-write XML that way. Seems easier to type. :-)

  10. flow

    uhh, and the indentation of 'section1' from "Protocol Elements" onwards is off

  11. flow

    nice idea to make the namespace definition an entity, I don't think I have seen that before

  12. flow

    dwd, it sure is easier to type, but I feel like it causes me a little headache when reading the XML as my brain searches for the closing &gt;, but that is probably just me

  13. dwd

    I'm hoping it renders OK!

  14. dwd

    Grumble. I just realised I need to change my email in xeps.ent again...

  15. dwd

    But anyway, (2): https://github.com/xsf/xeps/pull/865

  16. dwd

    flow, this continues discussions about ad-hoc JSON handling in libraries that we had some months back.

  17. dwd

    Sorry, jonas’- lots of work for the Editors today: https://github.com/xsf/xeps/pull/866

  18. jonas’

    I’ll take care of that

  19. pep.

    I'm on it

  20. jonas’

    oh ok

  21. pep.

    I was reading the xeps

  22. jonas’

    pep., I can do it too if you’re busy at or around 36c3

  23. pep.

    ok. I can do other things for sure (always :p)

  24. pep.

    Thanks

  25. jonas’

    is it just me or does `git fetch origin refs/pull/$prID/head:$branchName` not work anymore? I get fatal: couldn't find remote ref refs/pull/865/head

  26. jonas’

    aaagh

  27. jonas’

    wrong remote

  28. dwd

    jonas’, pep.- https://github.com/xsf/xeps/pull/867 - This one's tiny, but I'm hoping to get one more out as well.

  29. jonas’

    dwd, so after #867, we have to expect one more?

  30. jonas’

    if so, what’s the ETA?

  31. jonas’

    does it make sense to wait for it to batch the docker build?

  32. dwd

    Yeah. Aiming to document a standards-based (and fastening-aware) variant of https://mongooseim.readthedocs.io/en/latest/modules/mod_inbox/ - but you can kick off builds as you see fit. I don't know I'll get this one done today anyway.

  33. jonas’

    okay

  34. jonas’

    then just the three

  35. jonas’

    dwd, all done

  36. dwd

    Speedy! I'll have to write more...

  37. Ge0rG

    Makes me a bad conscience re 0401

  38. dwd

    Almost got Inbox ready, but I think I'll spend another day to make it less ProtoProtoXEP.

  39. jonas’

    dave motioning to nuke OMEMO -- interesting :)

  40. jonas’

    dwd, for me not to miss your agendum it’s probably good if you CC me

  41. jonas’

    if you want to make this a vote right away

  42. Ge0rG

    https://github.com/xsf/xeps/pull/870 is for marc

  43. flow

    jonas’, rejecting the current omemo xep is probably not the same as nuking omemo. The way I see it, an updated version which builds on the open double ratched standard could get the omemo xep into experimental again

  44. jonas’

    flow, which was promised years back when it was accepted into Experimental state?

  45. jonas’

    I don’t believe this is going to happen due to the lack of action to this point.

  46. dwd

    Rejecting the current OMEMO XEP is not an attempt to nuke OMEMO. It's just saying that the XSF isn't the place to work on something that isn't an open standard, and doesn't claim to be.

  47. flow

    jonas’, I am not sure if it was promised, but a first step was at least tried in https://github.com/xsf/xeps/pull/460/files

  48. Ge0rG

    Also everybody is using the siacs namespace. Everybody expect the fork developers who did a global search & replace.

  49. flow

    jonas’, I am also not sure if you can infer the future from the current and past "lack of action"

  50. jonas’

    past performance is still the best predictor for future behaviour

  51. flow

    the small sprint of every stock chart would disagree with that

  52. flow

    *print

  53. jonas’

    being the best predictor does not mean it’s a good predictor tho

  54. dwd

    flow, XEP-0384 doesn't conform to our criteria for an open standard. I'm not interested in either the future or the past, but the present.

  55. lovetox

    dwd but what does that mean for a crypto spec that is not a standard

  56. lovetox

    does the XEP has to specify the whole thing

  57. flow

    lovetox, no, but it should ideally be able to point to an open standard

  58. dwd

    Specify it, or reference it. Not sure why OMEMO gets a pass here, nothing else has.

  59. flow

    IMHO it was fine while the axolotl protocl was just a github wikipage which some magic numbers

  60. lovetox

    i think back then there was nothing published

  61. dwd

    Right, which was why it was originally rejected.

  62. flow

    but after the double ratched was made an open standard, there is really no reason why we should build omemo on top of that

  63. lovetox

    basically its a wrapper for XMPP around the openwhistersystem libs

  64. dwd

    lovetox, Sure. And so was the RTMP spec, and we rejected that for that reason.

  65. dwd

    Not to say you can't do OMEMO, or RTMP. But the XSF isn't the place for them.

  66. lovetox

    dwd, im not arguing against rejection, i just wanted to get some insight how the new XEP would have to look like

  67. lovetox

    there is a new XEP planned anyway

  68. lovetox

    there was month of discussion about the current xep on the list

  69. lovetox

    if you remember

  70. dwd

    The basic criteria is that anyone should be able to take the specification and implement the protocol from that and any references. Any dependent specifications should be at least as stable and open as ours.

  71. lovetox

    i think for the crypto stuff references could be added now

  72. lovetox

    but the real problem was the protobuf wire protocol

  73. lovetox

    which is under GPL

  74. lovetox

    so people argued its impossible to implement it in their not GPL projects

  75. moparisthebest

    for one moment assuming that's true, so what?

  76. moparisthebest

    why should I or anyone else care whether non-GPL software can implement a XEP

  77. moparisthebest

    that sounds like a "your problem" not a "my problem"

  78. lovetox

    this rules out many clients

  79. dwd

    moparisthebest, No, it means that the specificaiton isn't open.

  80. lovetox

    and we strive to make protocols that everybody can implement

  81. moparisthebest

    GPL isn't open ?

  82. dwd

    moparisthebest, We don't mandate any license for software implementing our specs. Why should we?

  83. moparisthebest

    just seems to me like a lot of whining "well I have to do a ton of work to implement this in non-GPL software" tough, don't pick shitty licenses for your software then?

  84. dwd

    moparisthebest, "A ton of work" is absolutely fine. If it's impossible, that's a whole other problem.

  85. dwd

    moparisthebest, Also, note that most of the XMPP clients and servers aren't GPL. Could be that people disagree that anything other than GPL is shitty.

  86. flow

    I am not sure if discussing GPL being free or not is the discussion we should have. The question is: Do we want XEPs the require implementation to be under a certain license

  87. flow

    I wouldn't oppose that FWIW, but I feel like others would disagree

  88. dwd

    moparisthebest, Or, to put it another way, what makes mandating the GPL for a particular specification different from mandating any other license?

  89. flow

    And I wonder what we have actually written down regarding that

  90. flow

    or if it's just a grey area within the XSF and XEPs process

  91. dwd

    flow, We mandate that our specifications must be implementable by an OSI-approved implementation in order to reach Final.

  92. dwd

    flow, In general, Council has taken that to mean that if that's precluded, we should reject the XEP (or ProtoXEP) early.

  93. moparisthebest

    I don't think a XEP can actually mandate code licenses, the complaints I tend to see are usually complaints about there only being a single GPL impl so far

  94. flow

    dwd isn't the gpl osi-approved?

  95. Ge0rG

    moparisthebest: the main complaint is probably that the only specification is a GPL source code

  96. dwd

    moparisthebest, OK. From the XEP, how would I go about writing a non-GPL one? There's no references, no spec, etc.

  97. Daniel

    Fwiw - as one of the people who pushed for omemo a couple of years ago - I'm fine with rejecting it

  98. Daniel

    It's not a good standard

  99. moparisthebest

    dwd, clean room reverse the implementation? :)

  100. moparisthebest

    again, the how is a "you problem" not a "me problem"

  101. dwd

    moparisthebest, SO you agree there's no specification then?

  102. moparisthebest

    I'm just speaking in general

  103. dwd

    moparisthebest, OK, but the same argument applies to both STANAG 5066 and RTMP. One *can* (now) get a copy of STANAG 5066 and write an implementation, and it's a huge job, but possible. To write one from scratch for OMEMO requires information not in, or pointed too by, XEP-0384.

  104. dwd

    moparisthebest, But for RTMP, you'd need to clean-room Adobe's library. You might get sued by Adobe for doing so. Maybe that is (or was) possible. Is that a "your problem" and not an "our problem" too?

  105. moparisthebest

    I think so

  106. dwd

    moparisthebest, OK, so your argument is that we should accept XEPs that depend on closed-source libraries. That is consistent, at least, but I'll disagree strongly.

  107. moparisthebest

    Accept as draft right? They can't reach final without a open implementation I guess

  108. moparisthebest

    There is no similar "must have a closed source implementation" clause

  109. Ge0rG

    I also disagree with having XEPs that require reverse engineering

  110. dwd

    Oh, I tell a lie. We don't require either implementation to be open source.

  111. dwd

    Oh, yes, we do. FOund it - it's a little buried. We stipulate at least one should be GPL/LGPL or OSI.

  112. dwd

    Still, I think the intent there was to ensure that we didn't preclude open-source imeplementations, not that we mandated them.

  113. moparisthebest

    I guess I'm saying I don't see anything where the xsf should evaluate the license and or patent implications of a xep

  114. moparisthebest

    We require open source implementation to move to final and that's it

  115. moparisthebest

    So rtmp for instance, ok for draft, then if someone reverses the library and makes an open source impl, it can be moved to final, otherwise it can't

  116. dwd

    OK. My view is firmly that we shouldn't devote time and effort to something we know cannot reach Final.

  117. moparisthebest

    I don't think anyone here is qualified to judge license/patent implications world wide anyway, why even try?

  118. Ge0rG

    moparisthebest: luckily, some of us live in regions where you can't patent code

  119. moparisthebest

    right, so say a XEP can't be implemented in the USA for patent reasons, but it can be in Germany, should the XSF reject or accept it?

  120. Ge0rG

    moparisthebest: I'm pretty sure you can't implement a chat app without violating a dozen of trivial software patents. That said, tracing patents is the opposite to checking for the existence of documentation for all parts of a XEP

  121. jonas’

    moparisthebest, no, there’s also the argument that you need data and code which is licensed under GPL to implement it. And since some of that is pretty unique to the implementation *and* there’s no spec to go by, any re-implementation of Signal is automatically a derivative of the GPL’d library, and thus, under GPL. or so the argument goes.

  122. jonas’

    moparisthebest, re " usually complaints about there only being a single GPL impl so far": no, there’s also the argument that you need data and code which is licensed under GPL to implement it. And since some of that is pretty unique to the implementation *and* there’s no spec to go by, any re-implementation of Signal is automatically a derivative of the GPL’d library, and thus, under GPL. or so the argument goes.

  123. jonas’

    in fact, there has been a non-GPL implementation in pure python which converted to GPL for that reason

  124. jonas’

    https://github.com/Syndace/python-omemo though it claims it'll "soon" switch to MIT, I’m pretty sure it was non-GPL in the beginning and switched over to GPL at a later point; though that might’ve been before publication.

  125. jonas’

    Syndace might be able to give more details and confirm or reject my memory.

  126. lovetox

    jonas’, its because of the wire protocol

  127. lovetox

    its not published, so the only way to reimplement it is to look directly at signals code

  128. jonas’

    lovetox, that’s exactly what I said

  129. jonas’

    or tried to say at least

  130. lovetox

    but i think he factored the protobuf stuff out into a own python package

  131. jonas’

    ah, so that’d make sense why it can become MIT

  132. lovetox

    https://github.com/Syndace/python-omemo-backend-signal

  133. Ge0rG

    Luckily, moxie is well known to be welcoming of alternative implementations and forks

  134. jonas’

    luckily

  135. moparisthebest

    Looking at the gpl code isn't the only way

  136. moparisthebest

    That's what clean room reversing is for

  137. moparisthebest

    Though I'd agree the xep should document it

  138. jonas’

    moparisthebest, how’d you do that? look at what happens on the wire and reverse engineer that?

  139. jonas’

    you might be violating the ToS of Signal with that, and if you don’t, the GPL may have a word of that and it’d still be a derivative of GPL’d code in some way.

  140. jonas’

    in any case, it’s not something I’d like to try in court

  141. jonas’

    looks like a grey area where the one with the better lawyer wins the case, especially in jury-land

  142. moparisthebest

    jonas’, https://en.wikipedia.org/wiki/Clean_room_design

  143. moparisthebest

    anyway I don't think the XSF should concern itself with how various implementations might fare in court

  144. marc

    Ge0rG: thanks, feel free to ping me again in a couple of days, I'm still at the Congress

  145. Ge0rG

    marc: your OK is required to merge that pr

  146. marc

    Ge0rG: I know, that's why I said what I said :)

  147. Ge0rG

    marc: well, I'll have to wait then. thanks :)

  148. Syndace

    jonas’, lovetox: your assumptions/memories are correct. I published the library as MIT first and later switched to GPL, because it is a derivative work. I even modified the git history, so that there is no wrongly licensed code in older commits. I then split the "generic" OMEMO code and the signal-specific code, so that I can publish the generic code under MIT, which is what I mean by "switching soon".

  149. Syndace

    And sadly it is not only the wire format, even though that's like 90% of it.

  150. marc

    Ge0rG: how can I put my OK?

  151. marc

    I need a rendered version :)

  152. marc

    I'm on mobile

  153. Ge0rG

    marc: https://op-co.de/tmp/xep-0401.html at your service. Significant changes in §3 (last example), and §5.5

  154. marc

    Ge0rG: is this 'sending an arbitrary iq' normal in XMPP?

  155. Zash

    I would argue than something sent before resource binding should not be considered a stanza, much less an iq stanza, for security reasons.

  156. Ge0rG

    Zash: I would argue that what I've moved forward with, ignoring your advice, is not too ugly and sufficiently workable

  157. Zash

    Ugly hacks do usually work, or there would be no point.

  158. Ge0rG

    yes