XSF Discussion - 2021-06-09

  1. inez

    hello, this is my first XMPP message.

  2. Zash

    Hi, welcome

  3. inez

    this is a very cool technology, I wish more people were on here.

  4. inez

    is there anything I should know about XMPP? are there any stupid mistakes to avoid? or should I just learn as I go.

  5. Daniel

    as a developer or as a user?

  6. inez

    Just as a user for now.

  7. eevvoor

    just learn, dont share private confidential information and enjoy.

  8. eevvoor

    Heartly welcome :-) inez

  9. eevvoor

    Perhaps you wanno explore the group chats.

  10. eevvoor

    Perhaps you wanna explore the group chats.

  11. Dan C

    Is this the right forum to ask questions about XEPs?

  12. Dan C

    I've been reading XEP-0045, and either there's an error, or I've misunderstood

  13. Zash

    Yes, this is a good place to ask.

  14. Dan C

    https://xmpp.org/extensions/xep-0045.html#example-61 shows the one-to-one messages exchanged between two users prior to converting to a MUC

  15. Dan C

    https://xmpp.org/extensions/xep-0045.html#example-63 shows the owner of the new muc emitting the one-to-one conversation history into the muc

  16. Dan C

    Is the 2nd message in the 2nd example incorrect? It doesn't contain any context of the original author of the message (wiccarocks@...)

  17. inez

    thank you eevvoor

  18. jonas’

    Dan C, hi! Yes, this is a good place.

  19. Zash

    Dan C, the text under talks about the delayed delivery stamp indicating that, but you are right in that the example seems to be wrong.

  20. Dan C

    How can I contribute fixes?

  21. jonas’

    The question is complicated though. I don’t know if any client actually implements that. You’re right to point out that the information is missing, but I’m hesitant to call the example wrong; I don’t think there is any protocol which could be used instead.

  22. jonas’

    Zash, the delayed delivery does not indicate the original sedner.

  23. jonas’

    and the delayed delivery havign from="original sender" would be wrong, because the original sender wasn’t the entity delaying

  24. jonas’

    this would be more of a case for Stanza Forwarding, but that didn’t exist yet

  25. jonas’

    Dan C, in general, fixes can be contributed on github (https://github.com/xsf/xeps).

  26. jonas’

    For XEPs which are Draft or later (see the graphic at the top of the document), the fixes need to be approved by the XMPP Council (to avoid unintended breaking changes)

  27. jonas’

    we are also currently trialing a thing where changes must be brought to the standards@ mailing list first

  28. John

    Welcome inez

  29. John

    Anybody else know their first XMPP message?

  30. jonas’

    -> https://mail.jabber.org/mailman/listinfo/standards

  31. jonas’

    Dan C, and changing what you pointed out... definitley needs to have broader discussion, as it wouldn’t be immediately clear to me (and probably many others) what the *right* fix would be

  32. inez

    Thanks, John. How do you do that colored text thing? Is it just when someone mentions your name automatically? (Maybe something my client does? I'm using Gajim)

  33. Dan C

    On it. Thanks Jonas!

  34. John

    inez: yes because I mentioned your nickname

  35. Ge0rG

    Dan C: the challenge is how to add 1:1 messages into a room in a secure fashion

  36. inez

    Oh, okay, cool! Thank you for explaining that. :)

  37. jonas’

    Dan C, so the concrete way forward would be either: - Propose a patch on github and bring it up for discussion on standards@ - Bring the issue up on standards@ first and look for consensus for a fix there

  38. jonas’

    A specific patch is generally good because it gives something to discuss about, so if it’s not too much hassle to you, I suggest the first option.

  39. Dan C

    Perfect! Thanks!

  40. Ge0rG

    I would suggest using https://xmpp.org/extensions/xep-0297.html and some useful client-side indication that history might be fake.

  41. jonas’

    +1 for stanza forwarding, because it’ll render blank on unsupporting clients :)

  42. jonas’

    though I don’t want to imagine what <forwarded/> inside type="groupchat" does to stupid '280 implementations

  43. Ge0rG

    also it allows proper attribution

  44. Ge0rG

    jonas’: I hope we have sorted them all out

  45. Ge0rG

    you could also have some weird in-body quote style

  46. Zash

    Not just ``` <delay xmlns='urn:xmpp:delay' - from='crone1@shakespeare.lit/desktop' + from='wiccarocks@shakespeare.lit/laptop' ``` on the second message in example 63?

  47. Dan C

    That was my initial thought, Zash, to simply fix the current example.

  48. John

    inez: also the text can be colored with XHTML

  49. Zash

    which seems to be supported by > Note: Use of the Delayed Delivery protocol enables the room creator to specify the datetime [...], as well as the JID of the original sender of each message (via the 'from' attribute);

  50. inez

    <p style="color: fuchsia"> I've never used XHTML before, I don't think I'll do it right the first time.</p>

  51. Dan C

    But certainly the security considerations are worrying. The idea of someone choosing to put "our" private conversation into a potentially public MUC without consent is worrying. The XEP says "Sends history of the one-to-one chat to the room (this is purely discretionary; however, because it might cause information leakage, the client ought to warn the user before doing so)" but this is a note, not a requirement. There's nothing I, as a user, could do to restrict that loss of privacy. Enforcing that it's a members-only MUC might alleviate that specific example?

  52. inez

    wait no tha's CSS

  53. jonas’

    Zash, no, because wiccarocks is not who delayed it.

  54. jonas’

    > The Jabber ID of the entity that originally sent the XML stanza or that delayed the delivery of the stanza (e.g., the address of a multi-user chat room).

  55. jonas’


  56. jonas’

    of course it’s unclear what @from means

  57. jonas’

    well, then that could do

  58. Dan C


  59. Zash

    Oh great

  60. Zash

    Wait does that mean I'm wrong about needing an origin-timestamp xep?

  61. John

    inez, LIKE TISH

  62. Dan C

    Is there a use case where it would be useful to have crone1 in that field?

  63. jonas’

    Dan C, well, the privacy stuff isn’t something you can fix in a standard. A client (or user) can always take a screeshot of your conversation and post it to facebook :)

  64. inez

    I can see the color, but I can't see how you did it :/

  65. John

    inez, your client does not fully support it

  66. inez

    oh, what client do you use?

  67. John


  68. Ge0rG

    Dan C: in practice, anybody can forward any private messages to any public room. It's just a matter of clients doing it by default / automatically / without user consent

  69. inez

    Maybe I will try out other clients. I've only used Gajim and Pidgin.

  70. Dan C

    Thanks Zash, jonas’, Ge0rG ❤️

  71. şişio

    > https://www.w3schools.com/js/js_json_xml.asp What about

  72. şişio

    Imo XMPP better 😂

  73. John

    şişio, I think they intentionally used that XML example to show JSON shorter

  74. şişio

    > John wrote: > şişio, I think they intentionally used that XML example to show JSON shorter Maybe

  75. şişio

    I will stay XMPP

  76. şişio

    I will stay on the XMPP

  77. croax

    şişio: A humble opinion: XML / JSON don't really matter at all. XMPP is much more than XML and could also be JSON one day. It's the modular approach of the protocol (can be extremely simple or lots of funtionalities) and federation that makes its strength.

  78. MattJ


  79. jonas’

    or EXI

  80. Zash

    or ASN.1

  81. jonas’

    or s-expressions

  82. qy shudders

  83. deuill

    CSV or bust

  84. moparisthebest


  85. Zash

    Is there an ASN.1 serialization format for s-expressions?

  86. croax

    or CBOR

  87. deuill

    I seem to remember there as an XEP (perhaps one with no number assigned) that proposed a binary encoding for C2S stanzas, for devices where XML encoding and decoding was too resource-intensive?

  88. Zash


  89. deuill

    Hmmmm yeah that seems about right (though I remembered one of the authors with an @nokia.com email, for some reason). I guess there's no real need for such complexity these days, when an ESP32 can run circles around most mobile CPUs from 20 years ago.

  90. Zash

    I hear it's good for IoT devices and stuff.

  91. mathieui

    deuill: consuming the least required power is always a good thing in tight scenarios

  92. moparisthebest

    I'd be surprised if EXI consumed a measurable amount of power less than XML

  93. Menel

    Maybe its measurable if you have millions of messages per day. But then other micro optimizations would also be a big chance.

  94. mathieui

    moparisthebest: power (and bandwidth!) for data transfer aswell

  95. mathieui

    The #1 power draw in my laptop is the wifi chip :p

  96. jonas’

    tell me about it

  97. jonas’

    I am deep down in the XML parsing/processing optimization rabbithole :)

  98. moparisthebest

    I'd be surprised if EXI consumed a measurable amount of bandwidth less than compressed XML

  99. Ge0rG

    Compressed XML is a security risk

  100. Ge0rG

    Also the benefit I see with EXI is that you can filter stanzas unknown to the client on the server side

  101. moparisthebest

    As implemented currently yes, doesn't have to be

  102. Ge0rG

    moparisthebest: the problem is known for how long now? Eight years?

  103. moparisthebest

    Also what evidence do you have that EXI isn't a security risk, I think last time we discussed it we determined it had the same security problem

  104. Zash

    How was it, EXI has optional zlib or such?

  105. Menel

    I always wonderd why we don't use compression anymore with an updated method. Also that security risk sounds highly theoretical in the first place..

  106. moparisthebest

    The compression fix has been known for that long too iirc?

  107. moparisthebest

    Just no one has written a spec or implemented it

  108. jonas’

    moparisthebest, EXI knows more about the stream, so my base assumption (from experience of benchmarking different compression algorithms on small subsets of data against a specialized one) would be that it’s better than generic compression

  109. jonas’

    and that without the risk of generic compressoin

  110. jonas’

    and that without the risk of generic compression

  111. jonas’

    because it knows more about the stream :)

  112. jonas’

    one major use case would be for instance to tell it about base64 things

  113. jonas’

    you get the base64 overhead completely reverted, with zero risk of generic compression schemes

  114. Zash


  115. jonas’

    and of course put the stream-level element name in a single byte, because they fit in that (with 0xff for "unexpected thing, localname/nsuri pair follows" for instance) instead of N bytes.

  116. jonas’

    (disclaimer: I only briefly looked at EXI and talked to Arc about it a bit, but my understanding is that this is essentially how it works)

  117. jonas’

    next, generic compression is memory intensive (IIRC that was also a good reason not to have it enabled server side?); EXI would probably not be that, or at least you can more easily share the state across streams

  118. moparisthebest

    EXI has dictionaries and such too which could make it vulnerable to CRIME style attacks

  119. Zash

    <hat:server-implementer>Yes, compression uses a ton of extra memory per connection. Happy without that</>

  120. Zash

    moparisthebest, only if the dictionaries can be influenced by an attacker

  121. moparisthebest

    and yes, you are right of course that specialized compression can be better, but it's an issue of how much better, and if it's worth actually doing it

  122. moparisthebest

    vs throwing XML at zstd or whatever

  123. Zash

    Using a fixed dictionary likely falls in between generic zlib and EXI

  124. qy

    > moparisthebest wrote: > HL7 *screams*

  125. moparisthebest

    a fellow healthcare ~~sufferer~~worker I see

  126. şişio

    > > <@wuuko:matrix.org> But I still don't understand how XMPP is central. > XMPP as a whole isn't; your user account exists on the server you choose, and all the servers talk to each other, so it's federated (a form of decentralization) just like Matrix in that sense. but when you create a MUC, it exists on the server that it's created on, and that server is responsible for it - if the server goes down, the room is down too

  127. şişio

    What about?

  128. şişio

    But ı think public chats are not important. And XMPP has got default e2e

  129. şişio


  130. şişio

    But rvick doc files e2e is partial

  131. qy

    moparisthebest; i only worked there temporarily

  132. qy

    that was enough...

  133. moparisthebest

    qy: the brain damage is permanent though

  134. şişio

    What's the hell happened?

  135. robertooo

    E2EE in XMPP is not partial. It's perfectly secure, just like Signal.

  136. şişio

    > robertooo wrote: > E2EE in XMPP is not partial. It's perfectly secure, just like Signal. Yes default

  137. şişio

    I shared the picture

  138. şişio

    I between the XMPP and Matrix. Which and why is better? My goal is security and privacy.

  139. qrpnxz

    robertooo, has it been audited at all. That's the only thing that concerns me.

  140. MattJ

    qrpnxz, https://conversations.im/omemo/audit.pdf

  141. qrpnxz


  142. emus

    For my talk today (with some fun in mind) I defined the XMPP Bermuda triangle 😉 😊️

  143. emus


  144. mdosch

    > I between the XMPP and Matrix. Which and why is better? > My goal is security and privacy. I'd go for xmpp, but what answer did you expect in an xmpp MUC?

  145. mdosch

    If your goal is most privacy/security neither xmpp nor matrix are what you want.

  146. şişio

    > mdosch wrote: > If your goal is most privacy/security neither xmpp nor matrix are what you want. What do I need?

  147. mdosch

    No idea, maybe tox or briar?

  148. Zash

    Maybe a cabin in the woods?

  149. moparisthebest

    ^ yep, need to just turn off all electronics and live in a cave

  150. mdosch

    > Maybe a cabin in the woods? And potatoe fields!

  151. moparisthebest

    but if you want tech, XMPP is the best

  152. moparisthebest

    of course you aren't going to get a fair comparison here, people here have generally already evaluated options and chosen XMPP

  153. şişio

    > mdosch wrote: > No idea, maybe tox or briar? Briar is best but only Android

  154. şişio

    And Briar hasnt got offline message

  155. şişio

    Bucause there is no server

  156. şişio

    So the remaining xmpp and matrix

  157. şişio

    But true, Briar is best.

  158. mdosch

    > And Briar hasnt got offline message > Bucause there is no server You want maximum security or comfort? Offline messages need a server to be stored on. A server storing stuff is not 100% security (if such a thing even exists).

  159. John

    > And potatoe fields! And furnace to craft some primitive XEPs

  160. mdosch goes and listens to Bloodbaths 'Furnace Funeral'.

  161. mathieui

    mdosch: you technically don't need a "server" for offline messages, but to handle that in a p2p network you need to replicate it across several nodes to maximize the probability of getting it delivered, and now since nodes store things for the others that opens a whole new can of worms

  162. şişio

    > mdosch wrote: > You want maximum security or comfort? Offline messages need a server to be stored on. A server storing stuff is not 100% security (if such a thing even exists). So how does your own server compare to Briar?

  163. dwd

    What's the threat model? Who do you wish to be secure *from*?

  164. Menel

    I remember you asked the same questions some days ago already. What is bothering you that you are again and again uneasy with xmpp, and in between post "❤️xmpp " and stuff? Maybe think about what you don't like about xmpp that you can't settle