XSF Discussion - 2018-11-16

  1. lovetox

    MattJ, this does not really answer the question for what you use it, i wonder too what use case this could have

  2. lovetox

    maybe something like teamwork, where different people in a groupchat can add stuff to a message?

  3. lovetox

    something like threads ^^

  4. lovetox

    seems converse shows now in front of every groupchat message a green checkmark i wonder what it means

  5. lovetox

    hm we could use it for omemo because right now we cant send a message AND a httpupload link

  6. lovetox

    this way we could send pictures with comments but encrypted

  7. lovetox

    daniel ^

  8. pep.

    lovetox: it's 0184 I think, the checkmark

  9. lovetox

    i dont think so, that would make absolutly no sense at all

  10. lovetox

    i think it means the message was reflected by the muc

  11. lovetox

    but instead of now seeing on *every* message a green check mark, i would have opted for seeing a red mark for the 1 in 1000 messages that is not received because the muc is down or my connection

  12. lovetox

    ok they recently added 0184

  13. lovetox

    wow now i know one of the 100 participants of this chat received my message

  14. lovetox


  15. daniel

    I think in groups the checkmark should be generated by the reflection

  16. daniel

    That's how Conversations does it

  17. daniel

    In 1:1 it uses 184. In groups it's reflection. Same UI to the user

  18. MattJ

    Makes sense

  19. lovetox

    didnt look through the code, lets assume they did that 🙂

  20. Ge0rG

    daniel [08:07]: > In 1:1 it uses 184. In groups it's reflection. Same UI to the user Same in yaxim

  21. jonas’

    MattJ, I’m asking because somebody is attempting to use attaching for quotations

  22. jonas’

    and I think that would lead to suboptimal UI if clients show the "quoting" message right below the other one

  23. jonas’

    (which is however a sensible UI for attachments)

  24. lovetox

    we have some other xep for quoting

  25. lovetox

    references or something like that

  26. jonas’


  27. MattJ

    jonas’, I agree with you

  28. jonas’

    MattJ, tell than to them: https://github.com/siacs/Conversations/issues/3125

  29. MattJ


  30. jonas’

    MattJ, tell that to them: https://github.com/siacs/Conversations/issues/3125

  31. MattJ

    I think I have an outstanding diff for that XEP anyway

  32. jonas’

    granted, in my original critique I forgot to mention *how* clients display it

  33. jonas’

    ("out of order", which may be more grave than what sam expects)

  34. MattJ

    Don't have time today

  35. jonas’

    ah, right

  36. ralphm

    With the recent news around http/3, I was wondering if anyone here has thought about a QUIC binding for XMPP.

  37. flow

    ralphm, what would the advantages be, besides "it's http"?

  38. ralphm

    I'm especially interested in the decrease in required roundtrips and if it behaves more efficiently in mobile networks (compared to TCP).

  39. ralphm

    I'm talking about QUIC, not http/3 (which is HTTP-over-QUIC).

  40. flow

    but isn't http-over-quic http/3?

  41. flow

    ahh now I got it

  42. flow

    don't we have most round trips on the xmpp protocol layer? I don't see how quic would e.g. decrease the SASL roundtips. But I'm curious if there are any other advantages of using quic, but right now, I can't think of any.

  43. daniel

    Doesn't quic have multipath tcp basically

  44. jonas’

    (because using multipath tcp directly would be too sane?)

  45. daniel

    So we wouldn't have to reauth after every network change

  46. daniel

    > (because using multipath tcp directly would be too sane?) Nobody supports that and quic has the power of Google behind it

  47. ralphm

    Well, from what I understand, the initial setup, which incliudes TLS 1.3, would be a nice benefit.

  48. jonas’

    daniel, yes, talking about google etc. not using existing IETF standards and rolling their own instead

  49. daniel

    Right. But if you can't stop them you could at least benefit from it

  50. daniel

    (I don't actually have any stakes or opinion in Quic or xmpp over quic)

  51. flow

    ahh that multipath fature sure would be nice

  52. ralphm

    There's a nice picture here: https://www.zdnet.com/article/http-over-quic-to-be-renamed-http3/

  53. flow

    also it appears that XMPP over QUIC would be for most parts trivial

  54. flow

    like you could replace your languages Socket object with a QuicSocket object and be done

  55. ralphm

    I could also see a use for in-(quic)-band file transfers, but that's indeed a bit more advanced.

  56. Ge0rG

    ralphm: a mobile client has too many roundtrips to count, _after_ the TLS handshake

  57. Ge0rG

    ralphm: I made a proposal to have the client dump all desired connection state into bind2, and let the server figure out everything

  58. flow

    Ge0rG, but that is only true for the intital connection

  59. ralphm

    Ge0rG: I know this, but the SASL-2 suggestions from dwd could help with that.

  60. ralphm

    So sure, there's work to be done on both fronts

  61. flow

    if you mostly resume your xmpp connection using quic the round trips should go down to near zero

  62. Ge0rG

    flow: 0198 also has a bunch of round-trips, at least the one you need to ensure whether the session got resumed

  63. flow

    Ge0rG, I dunno if xep198 would be that involved when using quic

  64. flow

    hmm it also appwars that quic is a IETF thing, at least there appears to be an IETF WG

  65. daniel

    > Ge0rG, I dunno if xep198 would be that involved when using quic At least the resume part

  66. daniel

    You'd still need the acks

  67. flow

    daniel, do you?

  68. flow

    I mean there are still nice

  69. daniel

    I don't think quic has acks

  70. flow

    but if the resumption of the stream is performed on the quic layer, without the upper layers being bothered

  71. flow

    hmm I though quic has stream properties, but could be wrong

  72. Ge0rG

    you know, TCP has got acks, and if we had sane APIs instead of Unix sockets, we could actually query the TCP ack state from the OS and not need 0198 acks.

  73. flow

    true, that is why I said acks are still nice, but I'm not sure if you still need xep198 resumption when using quic to handle a network switch

  74. flow

    I also believe that unix sockets are sane APIs and that you don't get nothing by checking the TCP ack state

  75. flow

    cause eventually you want application protocol acks, which tcp acks are not

  76. ralphm

    I guess that's the upshot of QUIC, it moves this to userland.

  77. jonas’

    yes, because re-implementing decade-proven stuff in userland is always good /s

  78. ralphm

    yes, because re-thinking decade-proven stuff is never a viable approach.

  79. Ge0rG

    it's not about re-thinking it but about working around limitations in its entrenched implementation

  80. ralphm

    Indeed. I think QUIC is a very interesting development, and was just curious if it could benefit XMPP, too.

  81. Ge0rG

    somebody should do a quic prototype.

  82. daniel

    Ge0rG: I see what you did there

  83. Guus

    Hey, my summit announcement blogpost didn't pop up in the blog. Did I mess something up?

  84. ralphm

    There are some interesting comments about QUIC here: https://www.codavel.com/2018/09/17/quic-vs-tcptls-and-why-quic-is-not-the-next-big-thing/. Despite the title, it seems the benefits for something like XMPP might be greater than for HTTP.

  85. Ge0rG

    surprisingly, HTTP is slowly approching XMPP, protocol-wise

  86. flow

    not sure if I'd call it surprisingly, but true, true

  87. Zash

    HTTP/2 seems an awful lot like SSH

  88. Ge0rG

    And WS is a TCP socket exchanging framed messages.

  89. Zash


  90. ralphm

    Like Beep

  91. MattJ

    Hmm, not sure I see the benefits of QUIC specifically

  92. MattJ

    ...given in-order requirements in XMPP, and a single stream between client and server

  93. Zash

    Something something having two channels could be useful for large binary low-priority transfers

  94. Zash

    SCTP :(

  95. MattJ

    RTT reduction is already possible without QUIC, and changing IP is just 198

  96. jonas’


  97. MattJ


  98. fippo

    mattj: do you work at google? they seem to think that way

  99. MattJ

    fippo: regarding SCTP? I tried to keep the dream alive for quite some time, but short of renaming to HTTP/4, it's never going to see sensible adoption

  100. jonas’


  101. Zash

    MattJ: Could change IP with less overhead if MPTCP got done and deployed

  102. Zash

    Oh and SCTP is deployed and used! .. in WebRTC

  103. Zash

    SCTP over DTLS over UDP

  104. jonas’


  105. fippo

    well, google wants to kill that

  106. fippo

    and usrsctp is the only usable library and has funding issues :-|

  107. fippo

    I think mattias wimmer (of jabberd1) once proposed s2s over sctp...

  108. flow

    MattJ, I'm not sure, but QUIC could get you free instant stream resumption it appears

  109. flow

    and i'm not sure how xmpp's in-order requirement is related to quic

  110. MattJ

    QUIC's main purpose is multiplexing without head-of-line blocking. XMPP needs neither of those

  111. MattJ

    The other things QUIC provides can be done with TCP

  112. flow

    you mean "on top of TCP"

  113. MattJ


  114. flow

    sure, but quic gives you resumption for free

  115. MattJ

    So instead of reimplementing TCP semantics on top of UDP

  116. flow

    you don't have to implement xep198 resumption

  117. Zash

    MPTCP would also give you that

  118. flow

    probably, in the end the surviver will likely be the thing with widely available libraries

  119. flow

    and which works in the current IP environment

  120. MattJ

    Which QUIC is not from a glance

  121. flow

    (in reality, and not on paper)

  122. Zash

    XMPP over HTTP over QUIQ over DTLS over UDP with ugly hacks to make it look like plain text DNS?

  123. flow

    quic libraries seem to be sparse, true

  124. Zash

    flow: Do you think we should just go along with stupid things like that or try to do it right? Because I want to do things right.

  125. flow

    but it doesn't appear to be unlikely that there will be some for android (and java), possibly even from google itself

  126. flow

    Zash, well, doing things right is usually what one should do, but I don't see how quic is doing things wrong, feel free to feed me the missing pieces

  127. Zash

    I haven't looked at QUIC recently, but isn't it supposed to be a transport protocol? So, running it over another transport protocol is meh

  128. flow

    I don't see a point for sticking to the OSI model just for the sake of it

  129. flow

    it appears sensible to run such a thing over udp

  130. Zash

    HTTP over UDP was a thing already tho

  131. flow

    "it breaks layering" is never a good argument, unless it is followed by an argument why it is bad

  132. daniel

    Or what layers are

  133. Guus

    An Ogre is like an onion...

  134. flow

    right now I think of quick as an TCP socket on steriods with tls, compression, automatic resumption in case of connectivity/network change

  135. flow

    and looking at the XEPs we have, those are propertys XMPP also wants

  136. flow

    it is true that XMPPs doesn't need quic's multiplexing feature, but, yah know, nobody forces you to use it

  137. flow

    then again, didn't we have a XEP (or ProtoXEP) which multiplexes multiple sessions over the same stream?

  138. jonas’

    for s2s

  139. ralphm

    MattJ: flow, of course the number of libraries is still a bit sparse. QUIC is not even finished yet.

  140. ralphm

    And to be sure, Google QUIC was taken apart to IETF QUIC (with a handful of specs) + HTTP-on-QUIC.

  141. ralphm

    Some background here: https://blog.cloudflare.com/the-road-to-quic/

  142. jonas’

    Guus, I think I know what went wrong with your blog post

  143. jonas’

    it went into some "drafts" folder

  144. jonas’

    my suspicion is that it treated the publish timestamp as UTC, and since that was greater than the time of the build, it treated it as unpublished draft

  145. jonas’

    I retriggered the build

  146. Guus

    ah, I didn't take notice much of the timestamp

  147. jonas’

    (you can see that it went into some draft folder by searching this https://hub.docker.com/r/xmppxsf/xmpp.org/builds/bgajpfwqegw7nfzcthinnui/ for the file name)

  148. jonas’

    (and you can find the build by clicking the "docker|building" tag thing in the readme after a merge)

  149. Guus

    That's some kind of implementation that can be used to schedule posts, then?

  150. jonas’

    it could, if we had automatic rebuilds

  151. Guus

    well, thanks for figuring that one out 🙂

  152. jonas’

    you’re welcome

  153. jonas’

    thanks for boarding :)

  154. Guus

    where are my warm nuts?

  155. jonas’

    I have questions about that question

  156. Guus

    wait, don't answer that one.

  157. jonas’

    it’s either delicious or TMI

  158. Guus

    I _just_ realised.

  159. jonas’

    and here I was wondering which double-entendre I could’ve missed in "thanks for boarding" which doesn’t go into the direction of airplanes or torture.

  160. Guus

    Ok, I'm off to pick up my kids from daycare, before I make more of a fool of myself here. 🙂

  161. jonas’

    good luck!

  162. Guus

    (I shall be making a fool of myself elsewhere now)

  163. jonas’

    you’ll blend in

  164. Link Mauve

    SCTP got some adoption as part of WebRTC, but now there are discussions about replacing it with QUIC too.

  165. jonas’

    Guus, your blog post is up :)

  166. Link Mauve

    At the last Rustfest in Paris, there was someone working on a QUIC parser, but I don’t remember who, nor what kind of milestone they reached.

  167. pep.

    Yeah I remember one guy implementing a bunch of stuff from the spec during the impl days

  168. ralphm

    Link Mauve: I also found this https://tools.ietf.org/html/draft-aboba-avtcore-quic-multiplexing-02, and https://w3c.github.io/webrtc-quic/

  169. ralphm

    I.e. the QUIC WG actually made changes to the initial packet byte to accomodate multiplixing with RTP/STUN/etc.

  170. Guus

    jonas’: tx!