jdev - 2023-03-14

  1. opal

    am i right to think that xep-0116 has been superceded by omemo or are they unrelated

  2. Zash

    Esessions? Yeah that's ancient and obsolete

  3. opal

    for context im reading through existing security-related xeps before reinventing any wheels if i draft my own standards

  4. opal

    cool thanks lol it looked like that but i couldnt be too sure cus the summary was a bit indecipherable for me

  5. Zash

    Maybe something for Editor to formally obsolete even

  6. opal

    yeah it may be helpful to have a note for what active standard(s) replace it

  7. opal

    in a nutshell i'm tired of hearing about what everything else has but xmpp doesnt, although "everything else" tends to be less solid of an experience than this, so maybe theres some easy (and not so easy) stuff i can do both on standards and client/server dev side to bridge the gap

  8. opal

    voice/video i think was the last milestone i can think of

  9. opal

    which is a good one, ive used it on my phone to call friends on the road when we were planning to meet up lol

  10. Zash

    opal, I learned that it's useless to argue with people who make such statements, usually they already made up their mind and will find another reason if contradicted

  11. opal

    im only focusing on the valid shortcomings ive seen of xmpp

  12. opal

    things i'd want too

  13. Zash

    like, with how voice/video and e2ee existed over a decade ago in XMPP

  14. Zash

    maybe not widely implemented, but existed in some form

  15. opal

    was voip ready-to-use a decade ago though? afaict gajim had it for a while but it worked poorly

  16. opal

    succumbed to code rot probably lol

  17. Zash

    I remember testing voice and video with Gajim in like 2010

  18. opal

    yeah i tried much later in gajim and failed to get it working right

  19. Zash

    I could make video calls from my N900 phone over XMPP around that time, all your arguments are invalid!

  20. opal


  21. Zash

    Of course, nobody cared about video calls, so nobody maintained the code and it decayed

  22. Zash

    Further evidence that those feature based arguments should be ignored

  23. guus.der.kinderen

    Nimbuzz had a voice transport to/from Skype in ... well before 2010.

  24. opal

    my biggest personal complaint is with how unwieldy omemo is; olm in matrix tries to do something better with cross-key signing but thats ugly too

  25. opal

    as for the easier side of things: arbitrary message editing / replies / redacts are a common enough ask

  26. opal

    and all that needs is to refer to specific message ids for those commands

  27. Zash

    opal: Both OMEMO and (Meg)OLM are based on Signals protocol. But MLS is the future!

  28. opal

    https://en.wikipedia.org/wiki/Messaging_Layer_Security i assume, and not major league soccer lol

  29. guus.der.kinderen

    I'm reviving a server-sided EXI implementation. Basic functionality seems to be working fine. I'd like to test this against a client that's not written by the same authors of the server-sided implementation. Does anyone have a client (or library) that does XEP-0322 ?

  30. opal

    oh wow dino 0.4.1 completely ignores my gtk theme cool

  31. opal

    and now i see the reaction popup nvm

  32. opal

    its different from the emote menu

  33. opal

    and im talking in the wrong channel lol

  34. opal

    > and im talking in the wrong channel lol i guess replies are a thing though now, lets see how this looks

  35. Zash

    finally, the one feature that was holding XMPP back! oh wait, now it's something else

  36. opal

    i dont need the sass from you, ive successfully brought people onto xmpp who didnt use it before

  37. opal

    save it for someone relevant

  38. Zash

    don't mind me, I'm just bitter after some 15+ years of hearing things like that

  39. opal

    i know you are but im bitter after years of hearing "dont do things because they arent worth it"

  40. opal

    so we'll butt heads at this rate

  41. Zash

    I like to do things instead of arguing, so that's what I did

  42. opal

    good philosophy

  43. pep.

    opal, re encryption, maybe join xmpp:e2ee@muc.xmpp.org?join

  44. opal

    thanks i will

  45. guus.der.kinderen

    > I'm reviving a server-sided EXI implementation. Basic functionality seems to be working fine. I'd like to test this against a client that's not written by the same authors of the server-sided implementation. Does anyone have a client (or library) that does XEP-0322 ? We have now blogged about this effort: https://discourse.igniterealtime.org/t/developing-openfire-efficient-xml-interchange-exi-functionality

  46. Peter Waher

    Cool. Great work.

  47. guus.der.kinderen

    Thanks. It's pedigree might trace back to people close to you. :)

  48. guus.der.kinderen

    You mentioned a student - I think this was him.

  49. Peter Waher

    Yes, correct

  50. Peter Waher

    Sent him the link also. An unexpected but happy surprise, I’m sure.

  51. Peter Waher

    As you write, it would be good to do interoperability-testing, also in a federated environment. Need to find a slot for that.

  52. Peter Waher

    I would also like to encourage an experimental UDP/DTLS-binding to the broker. That, in conjunction with EXI, would be very interesting.

  53. Peter Waher

    Perhaps something for summer-of-code?

  54. Peter Waher

    I can assist as mentor, if needed. Also help editing/writing a XEP for such a binding.

  55. Peter Waher

    A server with such a binding would be able to support millions of online devices (depending on actual amount of device-data, of course), even on a modest computer and resource-constrained network. A serious challenger to CoAP and LWM2M.

  56. Peter Waher

    Perhaps something for summer-of-code? (Or some master students)

  57. guus.der.kinderen

    I'd welcome that - although I cannot commit to mentoring myself

  58. guus.der.kinderen

    This years GSoC might already be underway though?

  59. guus.der.kinderen

    Ah, proposals can be submitted until April 4th, it seems. So we might be able to get in, if things work out.

  60. Peter Waher

    Perhaps I read this wrong:

  61. Peter Waher


  62. Peter Waher


  63. Peter Waher

    "mentoring organizations"

  64. Peter Waher

    Would the XSF be one of those?

  65. guus.der.kinderen

    The XSF got accepted as a mentoring organization this year.

  66. Peter Waher

    ah, ok, I see

  67. moparisthebest

    guus.der.kinderen, Peter Waher: any thoughts about whether EXI might be vulnerable to CRIME-like attacks?

  68. guus.der.kinderen


  69. guus.der.kinderen

    moparisthebest: I have no idea.

  70. moparisthebest

    > I would also like to encourage an experimental UDP/DTLS-binding to the broker. That, in conjunction with EXI, would be very interesting. Peter Waher: what binding? Is it still relevant with QUIC existing?

  71. Peter Waher

    Sufficient with UDP & DLTS directly; more light-weight.

  72. Peter Waher

    Regarding CRIME & EXI: Not sure there are any secret web cookies involved… While a speed session does not list which namespaces & schemas are to be used explicitly, this is for speed only, not meant for hiding which schemas & namespaces are used.

  73. Peter Waher

    EXI is not meant to hide information. The DTLS-layer does that. And while the DTLS-layer uses such cookies & session counters instead of socket connections, they are not included in the EXI-layer (as it is built on/for TCP initally).

  74. moparisthebest

    Peter Waher: what makes you think UDP & DTLS is lighter weight than QUIC ?

  75. Peter Waher

    It might be an interesting side project to study as well…

  76. moparisthebest

    CRIME explicitly leaked data from inside the TLS connection, that was the bug

  77. moparisthebest

    So saying "exi is inside an encrypted stream" means nothing

  78. Zash

    If you have compression and mix sensitive and attacker controlled data, there might be CRIME-like bugs.

  79. Zash

    deflate/zlib etc kind of compression

  80. Zash

    See https://blog.thijsalkema.de/blog/2014/08/07/https-attacks-and-xmpp-2-crime-and-breach/

  81. moparisthebest

    Well any kind of compression, of which exi is a kind, so implementation details matter, hence my question

  82. Peter Waher

    EXI differs from other compression methods, in that it retains the semantics of the XML

  83. Peter Waher

    while other typical compression methods work on tokens, not related to the XML syntax

  84. Zash

    Compression based on fixed dictionaries should be relatively fine, and simple things like FunXMPP

  85. Peter Waher

    They are not fixed dictionaries either. Instead a state-machine is built based on schemas the client understands/want to include in a session

  86. Peter Waher

    XML is then normalized

  87. Peter Waher

    and encoded, by evaluating the number of possible options available in each step, during serialization

  88. Zash

    I vaguely recall you could use deflate or something with EXI?

  89. Peter Waher

    Not by itself

  90. Peter Waher

    you could add it as a layer

  91. Peter Waher

    for transport

  92. Peter Waher

    but EXI can be seen as normal XML, except it’s serialized using minimum number of bits, as deduced from schema files and normalizing XML and alphabets.

  93. Peter Waher

    So it doesn't take transport-layer input

  94. Peter Waher

    And it does not consider schemas to be secret

  95. Guus

    Peter Waher: If you're interested in getting under the XSF umbrella for GSOC, then this page is of interest: https://wiki.xmpp.org/web/Google_Summer_of_Code_2023

  96. Guus

    I can facilitate, but cannot commit to mentoring.

  97. moparisthebest

    > Peter Waher: what makes you think UDP & DTLS is lighter weight than QUIC ? Any thoughts on this one?

  98. Peter Waher

    The main difference is that resource constrained devices are typically datagram-oriented, not stream-oriented, even though DTLS permits fragmentation and reassembly of larger blocks of data. Protocols for such devices are therefore already based on UDP/DTLS-based protocols. This means that communication libraries and operating systems already support this. (XMPP in a sense is BTW also easily made into a datagram-oriented approach, with its quite small minimum(maximum(stanza-size)), if order of stanzas is ignored, which Google Talk suffered from.) So, available communication libraries typically support UDP & DTLS. Availabe/comparable protocol competitors are based on UDP datagrams and DTLS. QUIC attempts to solve similar problems as UDP & DTLS. QUIC is therefore only comparable to UDP/DTLS, if this standard library support for UDP/DTLS is also removed at the same time, and if no protocols based on these are supported by the device (otherwise QUIC represents an addition to existing code, making the device less light-weight, not to mention more work intensive, having to maintain parallel stacks updated over time). This is the point.

  99. Peter Waher

    Interesting side note: EXI is very resource conserving for devices, as collections of schema files can be converted to compilable C-code automatically, and stanzas are therefore easilly serialized into binary blocks, easilly fitted into single datagrams, and vice versa, a datagram received is easilly decoded in the app, via the same automatically generated code. For the EXI case, a datagram approach is therefore favorable, compared to a streamed approach. One of the problems solved in 0322 is how to separate the stanzas in the stream. Over UDP & DTLS this is not necessary, as datagrams separate them naturally.

  100. Peter Waher

    This might also perhaps be seen as a vulnerability in some cases (see CRIME above), in the sense that observers can observe sizes of datagrams, not readily sizes of stanzas in a stream. For resource-constrained-devices, this is typically readilly available anyway, as it’s easy to learn the sizes of automatically generated repetitive stanzas from machines.

  101. Peter Waher

    Hope this answers the question

  102. moparisthebest

    So tiny resource constrained devices support multiple protocols at the same time, instead of just XMPP?

  103. Peter Waher

    Typically, a device RTOS supports multiple IP-based protocols out-of-the-box, yes. As do communication libraries. Unless you choose to build everything from scratch. This also happens. The smallest XMPP-implementation I’ve seen was 12 kB, which was impressive.

  104. moparisthebest

    Also is that still a thing? A sub-$1 esp8266 will do real XMPP over TLS over encrypted WiFi just fine

  105. Peter Waher

    WiFi is not considered resource constrained

  106. Peter Waher


  107. Peter Waher

    Also, you have two ends: By using DTLS you avoid the socket connections that are quickly consumed on the server end, if many devices are connected.

  108. Peter Waher

    resource constrained typically refer to one (or typically more) of: 1. Power consumption 2. Bandwidth 3. Memory

  109. Peter Waher

    (with 4 MB Flash you typically have no problems building a complete communication stack. Resource-constrained devices typically do not have such resources; they are often battery-powered, and must remain on battery for long periods of time. XMPP is not the first choice in such cases, but with UDP, DTLS (with PSK instead of X.509), EXI, it could be.)

  110. Peter Waher

    XMPP have exceptionally many other benefits its competitors do not share.

  111. Peter Waher

    XMPP has exceptionally many other benefits its competitors do not share.

  112. techmetx11

    Peter Waher: it's not just flash, its also RAM

  113. Peter Waher


  114. Peter Waher

    (EXI C-code, and datagram processing, is very RAM efficient also, btw.)

  115. techmetx11

    in some cases, i would assume you have to write the XML parser in assembly

  116. Peter Waher

    yes, of course, or as an efficient C-code state-machine

  117. Peter Waher

    A resource-constrained device would probably not implement a generic DOM

  118. techmetx11


  119. techmetx11

    what is this resource-constraint device, if it doesn't support WiFi, is it meant to be connected via wired ethernet?

  120. Peter Waher

    There are many alternatives

  121. Peter Waher

    Fore more references, you can check: CoRE, CoAP, LWM2M, 6LOWPAN, IPSO, for example. This would be the main competitor. It’s very successful, but suffers from tight coupling, and is difficult to extend

  122. Peter Waher

    XMPP offers a much wider and richer networking environment

  123. Peter Waher

    (especially if its weaknesses are resolved: verbosity, socket connections, power consumption, etc.)

  124. Peter Waher

    Many (or most) of these are resolved using EXI over UDP/TCP.

  125. moparisthebest

    It seemed like the only reason to prefer udp+DTLS over quic is "maybe library support" ?

  126. techmetx11

    moparisthebest: can quic be implemented in a resourcee-efficient way?

  127. Peter Waher

    It cannot still compete with CoRE & LWM2M, if only byte count and uW is counted. But it provides a completely different set of possibities for interoperability, extensibilty, privacy and security compared to what CoRE-LWM2M can provide.

  128. moparisthebest

    Anyway what I mean is there are plenty of very small, very cheap, very light power usage chips today that can just run regular XMPP

  129. moparisthebest

    I'm not sold that anything needs something lighter than regular XML and quic today

  130. Peter Waher

    yes, it is getting better. But the requirements are also moved further…

  131. moparisthebest

    10 years ago? Sure

  132. moparisthebest

    > moparisthebest: can quic be implemented in a resourcee-efficient way? techmetx11: why not? It's just UDP with some TLS, basically