XMPP Summit - 2019-02-02

  1. kingu

    I didnt see a XMPP table next to the matrix one

  2. kingu

    an*

  3. Zash

    Bit early then tho

  4. Tobias

    .@NSAGov, the webcam covers you're giving out have an interesting defect: the purple ones are transparent. 🤔 https://t.co/WUDXPJt9hs https://twitter.com/EFF/status/1091449476613468160

  5. Zash

    Haha

  6. Tobias

    The fosdem shirt design looks kind of recycled this year

  7. Zash

    :)

  8. mathieui

    It is quite crowded

  9. Zash

    It is

  10. Zash

    Someone was asking for link mauve earlier

  11. mathieui

    They always do

  12. mathieui

    Tell them to follow the cone hats

  13. jonas’

    is "follow the orange cones" the new "follow the white rabbit"?

  14. Tobias

    They are easy to find http://www.asset1.net/tv/pictures/movie/coneheads-1993/Coneheads-DI.jpg

  15. mathieui

    https://upload.mathieui.net/upload/zFzyHccvRhopyFOU/RK_cNYYKTPOQg3tTPaF_Rw.jpg

  16. mathieui

    Nice

  17. jonas’

    awesome

  18. debacle

    there seems to be a long queue now at the design booth, most of them seem to be XMPP developers

  19. debacle

    can someone fix the year in https://xmpp.org/2019/01/the-xmpp-newsletter-31-january-2018/ please?

  20. jonas’

    on it

  21. debacle

    thanks! :)

  22. jonas’

    push’d

  23. jonas’

    will take 5 to 10 minutes to appear on the website

  24. MattJ

    jonas’: er, but now the URL is broken

  25. MattJ

    And it was linked to from various places

  26. Tobias

    Why does the web need to be so complicated

  27. jonas’

    derp

  28. jonas’

    MattJ, I don’t know of a way to fix that

  29. jonas’

    but I’ll see what I can do

  30. Zash

    Web!

  31. MattJ

    nginx redirect I guess

  32. jonas’

    I reverted the URL to the old version, but kept the title in tact

  33. jonas’

    that should minimize the impact for now

  34. Seve/SouL

    Appreciated jonas’ :)

  35. Kev

    Talking about compression, as we were, I wonder what would happen if we were to (per-hop) introduce a <c /> stream element, whose job would be to hold attributes for a dictionary that you could later inject into stanza headers.

  36. Kev

    <c c='1' to='some.jids.get.quite.long@and.maybe.domains.get.pretty.long.too/' from='blah@blah.lit' type='chat'/> <message id='uhestuh' c='1'><body>Hi!</body></message>

  37. Kev

    Or whatever

  38. Zash

    HPACK but X?

  39. Kev

    Roughly, yeah. Less smart because I'm less smart, but yeah.

  40. Zash

    Or FunXMPP but dynamic

  41. Kev

    FunXMPP's mostly about element name contraction isn't it?

  42. Kev

    Well, yeah, ok, I guess it is like that but dynamic.

  43. Zash

    It's string substitution if I remember correctly

  44. Kev

    FunXMPP is more or less doing EXI with preexchanged schemas (in principle, not technically), right?

  45. Kev

    But with additional substitutions for things like common substrings.

  46. Zash

    Fixed dictionary simple compression something

  47. Tobias

    Fixed dict definitely limits the stuff that leaks

  48. Zash

    We could do that, I think eg ZStandard can

  49. Kev

    ISTM that the application can make reasonable dictionary-population guesses.

  50. Kev

    If you could get e.g. from='x' to='y' type='z' down to two bytes, that's not an insignificant win.

  51. Kev

    And you're pretty confident when you start a chat with someone in a desktop client, for example, that you'll be sending multiple stanzas with the same header.

  52. Kev

    I wonder how well it would compare to just plain old zlib though.

  53. Zash

    I wanna test but training a dictionary needs a bunch of data

  54. debacle

    https://xmpp.org/2019/01/the-xmpp-newsletter-31-january-2019 404s

  55. mathieui

    debacle, but 2018 works with the correct title

  56. mathieui

    it will probably require a small nginx trick to have 2019 and 2018 work at the same time

  57. jonas’

    debacle, where did you get that link?

  58. Tobias

    Zash: it's probably less training, rather seeing how good it works

  59. debacle

    jonas' from https://xmpp.org/blog.html

  60. jonas’

    nice

  61. jonas’

    I hate this hacked pelican

  62. debacle

    what is the difference to the non-hacked one?

  63. jonas’

    a non-hacked one wouldn’t be so awful to use

  64. jonas’

    and I can’t really test locally because we need an awfully old version due to hacks we do

  65. jonas’

    fix pushed

  66. jjrh

    Is there a fosdem xmpp channel?

  67. Zash

    Tobias: Building the dictionary needs data

  68. jonas’

    use base64 of randomness as a start

  69. Kev

    Random data are known to compress very well.

  70. jonas’

    Kev, base64 of random data

  71. jonas’

    compresses fairly well, actually, approximately 3/4 ratio

  72. Zash

    Extract the xep examples

  73. Kev

    It's not giving any value to know how an xmpp-specific compression mechanism would compress non-xmpp data, is it?

  74. jonas’

    that will probably make 'romeo' and 'juliet' compress to one bit or something ;)

  75. jonas’

    Kev, given that OMEMO, Avatars and other things are b64-encoded, I think it’s pretty XMPP-related actually.

  76. Kev

    You need real streams for it to be of any significant value, I think.

  77. Zash

    We don't want JIDs and user entered data to compress well, that's what leaks the worst

  78. jonas’

    start with base64 of random data, add in some xmpp keywords, see what happens

  79. MattJ

    jjrh: this room is generally the FOSDEM XMPP channel

  80. jjrh

    Ah okay

  81. Tobias

    Well. If you use zlib or zstandard with dict, common XMPP terms will compress everywhere

  82. Zash

    Ca zlib do a fixed dictionary? Don't think I've seen support for that

  83. jonas’

    > zdict is a predefined compression dictionary. This is a sequence of bytes (such as a bytes object) containing subsequences that are expected to occur frequently in the data that is to be compressed. Those subsequences that are expected to be most common should come at the end of the dictionary.

  84. jonas’

    (argument description in python zlib library)

  85. jonas’

    you’d still have to reset the dictionary after each stanza

  86. Tobias

    Zash, Kev, if you want some secure compression for XML it has to be XML aware, so it only compresses outer levels of stanzas

  87. Zash

    Fixed compression dictionary avoids most of the compression related attacks AFAIK

  88. Tobias

    With that would still compress dictionary terms in the bodys and inner stanzas, not?

  89. Zash

    I'm not sure if proper XML aware compression would be better enough to be worth the complexity

  90. Zash

    Eg EXI needs schemas right?

  91. jonas’

    Zash, EXI works better with schemas, but it doesn’t reqiure them

  92. Zash

    Or something that points out what's data and what's structure

  93. Tobias

    You can do something more stupid than EXI

  94. Kev

    I have no doubt I could manage more stupid than most things.

  95. Tobias

    Like only ompress at level 1 and leave the body levels alone

  96. jonas’

    compressing the body with a fixed dictionary isn’t a problem, I think

  97. Tobias

    If you compress strict you might leak in band SVG

  98. debacle

    jonas' Now the link works. It looks strange, that the URL says "2018". But whatever. This is XMPP. We are pragmatic.

  99. Tobias

    -strict

  100. jonas’

    debacle, as the link with 2018 was out in the wild already when we spotted the mistake, we had to roll with that

  101. debacle

    you could have a forward from 2018 to 2019 ✎

  102. debacle

    you can have a forward from 2018 to 2019 ✏

  103. debacle

    only ten lines in Apache (or a half in Nginx) ✎

  104. debacle

    only ten lines in Apache (or a half in Nginx) ✏

  105. jonas’

    debacle, yes, if I had +w to the nginx config, I could do that

  106. vanitasvitae

    Interesting, the Matrix guys also had issues with message ids. They solved their problems by using the hash of a message as the id.

  107. debacle

    jonas' I know that problem. I partly responsible for a Prosody server where I cannot write.

  108. jonas’

    vanitasvitae, I bet they had a lot of fun with that

  109. debacle

    If I send ten times "yes" to different questions...

  110. Zash

    Oh glob. Shall we tell them about c14n?

  111. jonas’

    (and we’d be totally lost because to hash XML you need to canonicalize it, which is a non-trivial operation)

  112. Zash

    "You don't need C14N with JSON!!!!" ?

  113. vanitasvitae

    debacle: not sure what'd happen then

  114. jonas’

    probably timestamp?

  115. Kev

    I think possibly that stanzas are mutable is more of an issue there than normalisation.

  116. debacle

    are both id and content encrypted? if only the content is enrypted, the id leaks the content. ✎

  117. jonas’

    Kev, yes, that too

  118. debacle

    are both id and content encrypted? if only the content is encrypted, the id leaks the content. ✏

  119. vanitasvitae

    Maybe they added some random seed?

  120. debacle

    maybe

  121. jonas’

    if you add a nonce, you can also simply use a random ID.

  122. jonas’

    although, arguably, the hash makes it harder to deliberately create a collision that way

  123. Zash

    ... blockchain?

  124. Holger

    They also reinvented spec versioning, SRV records, s2s cert checking (backwards incompatible), POSH, ...

  125. jonas’

    re-invent ALL THE THINGS

  126. Zash

    Should I be glad I'm at a different talk?

  127. jonas’

    yes

  128. debacle

    Holger, you are in JanSON?

  129. Holger

    "You have one month to upgrade your servers."

  130. Holger

    If everyone does that, there will be totally no fragmentation at all!

  131. Holger

    Yeah.

  132. mathieui

    and since most people use matrix.org you don’t have much choice

  133. Kev

    And people feel I'm going overboard on radically upgrading the network by adding some features that old clients can't use :p

  134. vanitasvitae

    The fingerprint solution and key backup stuff they have in place is *really* impressive!

  135. Kev

    TL;DR?

  136. vanitasvitae

    Somehow they can sync the history to new devices

  137. vanitasvitae

    They backup keys to the server (optionally)

  138. vanitasvitae

    Well and they do cross signing

  139. Kev

    I'm going to assume they make 'put private keys in the cloud' somehow less stupid than it sounds :)

  140. vanitasvitae

    He oretty much rushed through all of this but I'll definitely have to look this up

  141. vanitasvitae

    Yeah first of all its optional and secondly its encrypted with a password (basically what OX does as well

  142. vanitasvitae

    )

  143. debacle

    Isn't OX supposed to (optionally) store (encrypted) private PGP keys in a PEP node?

  144. debacle

    you were faster in typing

  145. vanitasvitae

    :D

  146. Kev

    Right, much less stupid :)

  147. mathieui

    btw the "decentralized & privacy room" has a whiteboard "ideas for privacy & decentralization" that says "OTRv4 + matrix"

  148. mathieui

    kind of depressing

  149. MattJ

    "lol"

  150. mathieui

    Also apparently xmpp dns is too tricky so nextcloud nihed their chat

  151. MattJ

    Yeah

  152. jonas’

    not to mention that SRV is entirely optional

  153. mathieui

    They did say that they did not want to run an xmpp server

  154. mathieui

    but then they apparently considered writing a matrix server for some reason, since a matrix developer had to advise against that

  155. jonas’

    wat

  156. mathieui

    idk

  157. Zash

    BOSH-only server anyone?

  158. MattJ

    Someone raised "Why not XMPP?" during the ActivityPub panel discussion and got a round of applause

  159. jonas’

    <3

  160. jonas’

    thanks for the first bit of good news from FOSDEM :)

  161. MattJ

    Heh

  162. Kev

    What was the answer?

  163. MattJ

    Chris Webber: "XMPP is awesome, and more people should use it"

  164. MattJ

    "but $stuff"

  165. MattJ

    Pretty vague, to be honest... along the lines of "it wasn't clear how it would work, e.g. would you treat every user as a user? or would you act on the service?"

  166. Kev

    Not the most useful of feedback.

  167. Daniel

    What was that panel called? And/or can someone give me a link to the schedule

  168. Zash

    Federated social room I think. Last talk

  169. mathieui

    Fwiw it was "activitypub panel" on my schedule

  170. edhelas

    XMPP was doing social network before it was cool

  171. MattJ

    @Thon lobby

  172. mathieui

    https://connectycube.com/ I didn’t know about that thing

  173. Tobias

    Is that using XMPP?

  174. mathieui

    apparently

  175. mathieui

    https://twitter.com/ConnectyCube

  176. mathieui

    XMPP & webrtc

  177. debacle

    they even mention OMEMO support

  178. Tobias

    True