XSF Discussion - 2021-04-08


  1. deuill

    I think Snikket is doing it right and not focusing on appeasing people with technical opinions.

  2. moparisthebest

    yes! people with technical opinions can set up their own stuff :)

  3. deuill

    I can't remember if I've asked this before, but has there been any research on an alternative, state-less C2S protocol? Something perhaps easier to implement on iOS or Android?

  4. Zash

    mod_rest?

  5. Daniel

    Define research

  6. deuill

    Well, anything perhaps as concrete as an experimental XEP (though not sure if an XEP would cut it).

  7. moparisthebest

    I'm more curious about the definition of "state-less" :)

  8. deuill

    Anything that doesn't require a long-lived TCP connection, where no existing state is assumed to exist beyond what is exchanged in requests.

  9. Zash

    So HTTP REST like Matrix?

  10. moparisthebest

    matrix and everything else requires a long-lived TCP connection too no? the push notifications are that

  11. deuill

    HTTP is state-less yeah, though it wouldn't need to be HTTP. It can still be XML, but where no state is assumed to have been previously established (or where you have session identifiers passed around etc.)

  12. moparisthebest

    but "state" is something like "I know of so many messages, and want to know about ones I don't yet know about" so none of that is stateless

  13. Zash

    Yeah you need to have that state somewhere

  14. Kev

    Technically BOSH can be used in polling mode, but … you don’t want to do that.

  15. Zash

    Say to yourself "IP is stateless, we use TCP over IP, therefore it is stateless"

  16. deuill

    Right, I should clarify -- HTTP is technically state-less since state is application-level, and there's no connection-level state assumed HTTP3 doesnt't even use TCP yet retains the same semantics.

  17. Sam

    moparisthebest: I think he means that the connection is stateless, not that the client literally stores nothing.

  18. Daniel

    A perhaps better way to think about it is atomic operations. Being able to send a message without doing tons of stuff beforehand

  19. moparisthebest

    so the problem then is how does the other end notify you of new messages ?

  20. deuill

    Whereas XMPP currently assumes connection-level state and doesn't need to pass around session identifiers with every stanza etc.

  21. moparisthebest

    I think you either 1) keep a connection open permanently 2) poll for updates

  22. moparisthebest

    and #2 kills battery and is slow

  23. Kev

    Well, there’s something in between, isn’t there.

  24. moparisthebest

    is there?

  25. Kev

    It is not difficult to have a long-lived TCP connection in a running Android or iOS application. The problem is maintaining one in the background.

  26. Kev

    And what you need to do in the background is definitely not the same as what you need to do while in the foreground.

  27. moparisthebest

    both android and ios keep a long-lived TCP connection open in the background for push notifications

  28. Kev

    So Push notifications received by the device triggering a short-lived poll, while the application in the foreground using a long-lived connection doesn’t seem particularly undesirable to me.

  29. moparisthebest

    I wonder if QUIC alone simply solves this ?

  30. Kev

    I don’t see why it would.

  31. deuill

    Hm, does iOS/Android prevent you from listening on TCP/UDP yourself?

  32. moparisthebest

    can you keep open a QUIC connection across application sleeps on android/ios ? probably ???

  33. moparisthebest

    it roams across different networks for free, so no worry about waking up on LTE or a different wifi network

  34. Zash

    That doesn't magically remove Apples policy that you can't have nice things like open connections in the background, does it?

  35. deuill

    Well, QUIC is an application protocol built on UDP, I guess with XMPP we'd look to build on top of those technologies.

  36. deuill

    HTTP 3 today, anyways.

  37. moparisthebest

    at an XMPP level you can basically assume QUIC is TCP that you don't necessarily have to do stream management etc on

  38. moparisthebest

    in theory, you set up your QUIC connection once and just use it every time push notifications wake you up ?

  39. Zash

    You probably want to anyway

  40. Daniel

    What atomic operations (or rest like things) do is that a 'give me my latest messages' or 'send this message' is a lot quicker

  41. Daniel

    Compared with doing the starttls, bind, mam dance

  42. moparisthebest

    so if QUIC cuts out all the starttls/bind etc stuff, then you can just send those type of requests quickly ?

  43. deuill

    I was trying to think of this from a different perspective -- it would be cool if we could deploy XMPP servers on FaaS platforms (of course, C2S is only one side of the equation...), as these typically have CPU time quotas that preclude from having things like long-running connections going.

  44. Kev

    Daniel: Yes. I don’t believe this would be a bad thing. But, then, I’m coming to the conclusion that a full JMAP-like setup wouldn’t be a bad thing either.

  45. Zash

    direct tls and bind2?

  46. deuill

    So you could, in theory, invert the relationship (though I'm not sure if this is possible): client listens for server messages over TCP or UDP. Is NAT an issue there?

  47. moparisthebest

    to the OS, QUIC is not a long-running connection right ?

  48. moparisthebest

    it's just an application sending a UDP packet every now and then

  49. Daniel

    Kev: I'm not sure that jmap specifically maps well to instant messaging

  50. Kev

    Daniel: No, I don’t mean literally JMAP, I just mean JMAP-like.

  51. deuill

    Yeah my impression is that QUIC/HTTP3 is "just" packets over UDP.

  52. moparisthebest

    TFW jmap does not map to jabber

  53. deuill

    jmabber

  54. Daniel

    Kev: yes that I fully agree with

  55. moparisthebest

    deuill, nitpicking here but QUIC is not necessarily HTTP3, HTTP3 just runs over QUIC

  56. Kev

    mparisthebest: You’re suggesting that we should have jabbermap, which would be a jmap-like mapping onto XMPP? :)

  57. Sam

    Second obligatory pitch for the "Towards XMPP 2.0" roundtable next week :)

  58. moparisthebest

    I guess I'm saying what if XMPP 1.0 over QUIC just gives you XMPP 2.0 for free :P

  59. Kev

    When we started work on our web client a while ago, I *strongly* considered just building something like JMAP into M-Link and having our web client talk that instead of XMPP.

  60. Kev

    moparisthebest: I think there is no question that it won’t do that :)

  61. Kev

    “XMPP 2.0” is a vague term, but it definitely implies more than just solving C2S unreliability and cost.

  62. deuill

    I guess an easier question to answer would be, could you conceivably run XMPP over a UDP connection?

  63. moparisthebest

    well ok maybe it only gives you XMPP 1.9 beta, still might solve most of these type of problems

  64. deuill

    C2S connections at least.

  65. moparisthebest

    not pure UDP, you need reliability and such, but QUIC sure

  66. Kev

    deuill: Yes, you can, if by “UDP” you mean “HTTP3"

  67. moparisthebest

    (which to the OS is simply UDP, but to XMPP is TLS)

  68. Daniel

    Kev: does the isode mail server do jmap?

  69. Kev

    It doesn’t.

  70. Kev

    I’m not on that team, and I don’t remember why that wasn’t the way the web messaging client went (I’m not calling it a web email client, because … calling stuff email is complicated :))

  71. Kev

    (I imagine that I had opinions at the time, on the team or not, I just don’t remember)

  72. deuill

    You're absolutely right BTW, for some reason I thought QUIC had been deprecated, but it was actually SPDY. I need to get on my acronym game.

  73. deuill

    QUIC is the transport protocol.

  74. Sam

    Is the board meeting not happening this week?

  75. moparisthebest

    in an ideal world, both XMPP and HTTP3 would sit on top of QUIC in the same, next to each other in other words

  76. moparisthebest

    in the real world we live in, it might make sense for XMPP to sit on top of HTTP3 in the anticipation of evil middleboxen only allowing HTTP

  77. moparisthebest

    I plan to start digging into this soonish

  78. deuill

    That's awesome!

  79. Daniel

    Question to the office hours participants: would you be interested in a talk about JMAP?

  80. Daniel

    (and how awesome json over http is)

  81. vanitasvitae

    Daniel: I'd be up for it

  82. moparisthebest

    I would, couldn't hurt to know more about it

  83. edhelas

    JSON is the new XML (?)

  84. Zash

    CBOR is the new JSON!!!!1eleven

  85. Zash

    And then eventually we'll be back to X.509 DER & co

  86. Zash

    And then eventually we'll be back to ASN.1* DER & co

  87. Sam

    I'd love to know more about it, so yes!

  88. dwd

    Sam, You want to know more about DER? Can I tell you the good news about PER?

  89. Sam

    I meant JMAP, but honestly I've been trying to figure out the various X.509 encoding things, DER and PEM and what not forever, so that would probably be good too.

  90. Zash

    I've mentally classified JMAP as "interesting but why must everything be HTTP and JSON?"

  91. dwd

    Sam, PEM is just base64-encoded DER with some headers and footers.

  92. dwd

    Sam, The more complicated format is PKCS#12, which is an encrypted container holding a private key and a corresponding certificate chain, and I think a potential bunch of other stuff too.

  93. Sam

    oh yah, I forgot about that one

  94. Kev

    Zash:Unless I misremember significantly, JMAP doesn’t have to be HTTP in principle, it’s not using the HTTP verbs or whatever, it’s just a transport protocol for a sequence of commands. So you could websocket it or TCP it or even XMPP it if you were particularly perverse.

  95. Zash

    Sure, the general command and processing model is interesting.

  96. Kev

    I think you could probably use different object definitions and end up with XMPP over JMAP and it’d probably be ‘fine’.

  97. emus

    Daniel: please go ahead, the list is not yet crowded anyway?

  98. emus

    Sam: ?

  99. Sam

    I was summoned?

  100. emus

    Sam: No, about the question

  101. Sam

    What question?

  102. emus

    Is the XOH calendar very full yet?

  103. Sam

    There are infinity many weeks left.

  104. Sam

    (we hope)

  105. emus

    sure

  106. raghavgururajan

    Why IETF should keep XMPP as IM standard, instead of Matrix? [https://mailarchive.ietf.org/arch/msg/tools-discuss/Cj7n-7HwsN8xBzXCjD1pjD1j9Cg/]

  107. raghavgururajan

    * (https://mailarchive.ietf.org/arch/msg/tools-discuss/Cj7n-7HwsN8xBzXCjD1pjD1j9Cg/)