XSF Discussion - 2020-01-21

  1. Guus

    Are there public records of OWS pursuing legal action against people using libsignal while not adhering to GPL?

  2. Ge0rG

    Guus: like https://medium.com/@wireapp/axolotl-and-proteus-788519b186a7

  3. jonas’

    (technically, not using libsignal while not adhering to GPL though)

  4. jonas’

    (but re-implementing libsignal while not adheering to GPL)

  5. Guus

    moar! moar!

  6. jonas’

    Guus, context?

  7. Guus

    I don't want to say stuff about OWS enforcing GPL without proof to back it up.

  8. jonas’

    Guus, then I think that @wireapp thing is what you need

  9. jonas’

    because assuming or suggesting that OWS not enforing GPL on direct uses of libsignal is definitely not a good idea either way

  10. jonas’

    because assuming or suggesting that OWS is not enforing GPL on direct uses of libsignal is definitely not a good idea either way

  11. jonas’

    that they enforce GPL on derivates or users of libsignal should be the default

  12. jonas’

    the main issue here is that they also enforce GPL on reimplementations, which is what @wireapp shows

  13. jonas’

    or am I totally on the wrong track right now?

  14. Guus

    No, you're not. I'd just like to see more documented cases.

  15. jonas’


  16. Guus


  17. jonas’

    (I don’t have any more, tho)

  18. pep.

    Has anybody actually tried a clean-room implementation?

  19. pep.

    is that what wire tried to do?

  20. ralphm

    Of interest: https://moderncrypto.org/mail-archive/messaging/2016/002275.html

  21. ralphm

    Ge0rG, and for what it is worth, Wire sued OWS, and then there was a settlement. Also, Wire's stuff is still GPL3.

  22. jonas’

    pep., according to https://medium.com/@wireapp/axolotl-and-proteus-788519b186a7, I think so

  23. jonas’

    > Like everyone else in the cryptographic community, our team obviously had access to OWS’ GPL’d Java reference implementation online.

  24. jonas’

    well, ok, maybe not

  25. pep.

    the article does mention the gpl'd code yeah

  26. ralphm

    The thread I linked also has Moxie in it somewhere.

  27. Guus


  28. ralphm

    In any case, you'll see that SilentCircle pulled libsalamander in favour of libzina.

  29. MattJ

    The reply from Moxie in that thread basically says they only care about the trademark

  30. jonas’

    (which is part of the evil constants)

  31. MattJ


  32. MattJ


  33. MattJ

    But even GPL doesn't save you from that

  34. jonas’

    I wonder if that was all planned out from the beginning or just a lucky coincidence.

  35. ralphm

    The protocol includes constants with 'signal' in them, no? It seems to me that OWS considers any protocol-compatible implementation to be a derivative work.

  36. jonas’

    ralphm, WhisperSystems even

  37. ralphm

    ah, nice

  38. ralphm

    of course XMPP has literal occurances of 'jabber', but at least there's an arrangement with the XSF for this.

  39. dwd

    ralphm, As I recall, that caused a lot of wrangling in the IETF.

  40. dwd

    ralphm, Not least the name of the protocol changed.

  41. ralphm

    dwd: I thought that XMPP was actually proposed by Jabber, Inc.

  42. fippo

    nah, i think the ietf concluded that having a protocol and a trademark was not going to work. smart. I am looking at you, w3c+webrtc...

  43. dwd

    I don't know where the name came from. I do know that the IETF got very concerned about a protocol name being trademarked.

  44. ralphm

    dwd: interestingly, the first draft (https://tools.ietf.org/html/draft-ietf-xmpp-core-00) had this notice: 1.4 Intellectual Property Notice This document is in full compliance with all provisions of Section 10 of RFC 2026. Parts of this specification use the term "jabber" for identifying namespaces and other protocol syntax. Jabber[tm] is a registered trademark of Jabber, Inc. Jabber, Inc. grants permission to the IETF for use of the Jabber trademark in association with this specification and its successors, if any.

  45. dwd

    Dear Editors. I'm sorry-not-sorry.

  46. ralphm

    I tried to look at the old xmppwg mail archives, but it seems that our mailman doesn't show them (anymore).

  47. ralphm

    MattJ, are they still there?

  48. Zash

    Our mailman?

  49. ralphm

    (they used to be here: https://mail.jabber.org/pipermail/xmppwg/)

  50. dwd

    Guus, You might care about this: https://github.com/xsf/xeps/pull/883

  51. Zash

    I didn't know this

  52. Guus

    Thanks Dave 🙂

  53. Zash

    What has Dave done now?

  54. Guus

    Be a gentleman.

  55. ralphm

    Zash, yeah, the xmppwg mailinglist (first WG) was initially hosted by the JSF.

  56. dwd

    Another two ProtoXEPs. Given my current success rate, I'm not sure why I bother, but still.

  57. MattJ

    dwd: thanks, that's an item off my to-do :)

  58. MattJ

    dwd: for what it's worth my plan was to spec two fields, a universal "plain" search and an "advanced" variant that is implementation/deployment-specific but includes a slot for the server to provide some (localized) help text that clients could display to users

  59. MattJ

    See the popup when you enter the search box in Slack for example

  60. Zash

    {jabber❌data}desc ?

  61. jonas’

    with the emoji?

  62. Zash


  63. ralphm

    Interestingly around that time also a lot of e2e discussion (for RFC 3923)

  64. MattJ


  65. fippo

    ralphm: IIRC peter once said that he wasn't aware of any implementations of 3923. It was more of a mandated checkbox because of the IMPS-requirements

  66. ralphm

    It was, but it still had a lot of discussion

  67. ralphm

    dwd: small typo in PR 883, reviewed.

  68. dwd

    Ah, crap. Yep.

  69. pep.

    https://xmpp.org/about/xsf/mission Is it possible to find context around this? I've been skimming through the member list without success. Added in a71bc1df7a100a72b9e840c2a7308668fa385e32 on Sun Jul 26 23:41:33 2015 -0700 by Adam Brault

  70. pep.

    https://xmpp.org/about/xsf/mission Is it possible to get context around this? I've been skimming through the member list without success. Added in a71bc1df7a100a72b9e840c2a7308668fa385e32 on Sun Jul 26 23:41:33 2015 -0700 by Adam Brault

  71. pep.

    Reading old threads makes me feel like we're a broken record

  72. pep.

    https://mail.jabber.org/pipermail/members/2014-November/007920.html "Abstaining on XSF ballots"

  73. pep.

    Ah, there's https://mail.jabber.org/pipermail/members/2014-November/007932.html "Goals for the XSF board". Not sure if that's what lead to the mission statement, but that's probably worth reading anyway

  74. ralphm

    pep., in 2015 the entire website was redone

  75. ralphm

    The origin of this page is in 2007.

  76. pep.

    I see

  77. ralphm

    I.e. that's how far I've traced it back for now.

  78. ralphm

    Because I think it is even older, and Jan 2007 was an earlier website overhaul

  79. ralphm

    I.e. this is when our site moved to xmpp.org

  80. ralphm

    pep., this page used to be on jabber.org, and virtually hasn't changed since the fall of 2003.

  81. ralphm


  82. ralphm

    Apart from the typo in the current version, it still pretty much captures what I think we should be doing.

  83. pep.

    Thanks for digging it up

  84. ralphm

    If you want drama, that's the best era, I think.

  85. pep.

    not looking for drama no

  86. jonas’

    > ProtoXEP: Inbox

  87. jonas’


  88. dwd

    Yeah, I got around to it eventually, and knocked out the full text thing while I was in the right place. Thanks for processing those.

  89. jonas’

    dwd, you’re also not in council@ at the moment, so I tell you here: my calendar lied to me and I’ll be able to chair tomorrow

  90. dwd


  91. flow

    does anyone do extended stanza adressing over s2s? If not, wouldn't it be a nice way to reduce the bandwith? I assume for example there to be some presence dupes over s2s links

  92. Guus

    I don't think Openfire does that, flow .

  93. Guus

    Interesting thought though

  94. Zash

    IIRC the main issue I ran into was needing to disc#info remote servers and preferably caching the response, and Prosody barelay had PEP-specific bits for that at the time.

  95. Zash

    Is bandwidth that much of an issue for servers tho?

  96. Zash

    Over STANAG maybe

  97. Zash

    And you get more benefits the fewer and larger servers there are. Not sure that's the direction I want to focus on.

  98. flow

    Zash, I see your point. I just like to theorize about potential optimizations. I also think that this could easily lead to stanza-size issues

  99. Zash

    flow: I'm partial for XEP-0288 myself. Reducing the number of s2s connections reduces memory usage and CPU-intensive TLS handshakes.

  100. flow

    Zash, why only "partial"?

  101. Zash

    flow: s/I'm partial for/I like/

  102. Zash

    Something something preference for

  103. pep.

    There's some obvious irony or sarcasm that I'm not getting in the fulltext protoxep

  104. pep.

    Is it just to start a discussion?

  105. Daniel

    pep.: have you been here for yesterday's discussion with Guus?

  106. pep.

    I was. Have you read the document?

  107. Daniel


  108. Daniel

    It's very dave

  109. pep.


  110. Guus

    It serves the purpose.

  111. larma

    Guus, what is the purpose?

  112. larma

    Just registering a standard name for the field to abandon it later because actually using it in a standard at some point would cause incompatibilites?

  113. Guus

    Yes, no.

  114. Guus

    At least have a standard name with a defined set of functionality.

  115. larma

    I am missing the defined set of functionality in that ProtoXEP...

  116. larma

    I mostly read: don't use me because my behavior is undefined

  117. MattJ

    Maybe a defined field with undefined behaviour is better than an undefined field with undefined behaviour

  118. pep.

    Does it help with interoperability? Or is it even less useful than {xmpp:private.foo/mam-fulltext}fulltext? (as behaviour is undefined anyway)

  119. MattJ

    I'd like to expand it as I said yesterday, so it would have two fields

  120. MattJ

    One defined, one undefined

  121. Daniel

    well having a defined undefined field is certainly better than everyone using the undefined 'withtext'

  122. pep.

    The name of that field is obviously bad (no namespace), but how is as single defined undefined field better?

  123. Daniel

    it allows clients to implement search

  124. Daniel

    server side search (obviously)

  125. pep.

    with undefined behaviour

  126. Daniel


  127. MattJ

    That's evidently good enough for some people/use-cases

  128. Daniel

    to me that's good enough

  129. pep.


  130. Daniel

    i mean in practice it won’t be that undefined

  131. pep.

    Well yes, the XEP says so :P

  132. Daniel

    i mean it says you can return nothing but then you have to buy everyone beer; which is like a total logistical nightmare

  133. pep.

    In practice it'll be somewhat undefined rules floating around

  134. Daniel

    i don’t think anyone would go through with that

  135. pep.

    Which is a nightmare for the external dev

  136. larma

    It's probably fine as long as you only send [A-Za-z0-9]+ 😉

  137. MattJ

    and don't send the words NOT, AND or OR

  138. larma

    even then it's unclear if it only searches in body or the full XML

  139. larma

    so you might see very unexpected results

  140. pep.

    And content doesn't only sit in body either

  141. larma

    Yeah, that too

  142. larma

    I can't imagine a proper UX for that

  143. larma

    at least nothing that could compete with Dino search UX 😉