XSF Discussion - 2023-11-20


  1. MattJ

    I know it's your (strongly held) personal opinion, but I think that's a very unfair take. I personally have a low opinion of VC as a business model (been there, done that), and Matrix isn't my preferred choice of IM protocol for a bunch of reasons, but there is nothing that adds up to a "scam". There are far easier and more comfortable ways to scam people than pouring years of effort into building decentralized communication protocols. Unless you know something the rest of us don't, I don't think you can make comments declaring malicious "intent" without crossing a line for me.

  2. Zash

    How about some of that Hanlon's razor?

  3. MattJ

    I don't think we need to bring stupidity into it, either :)

  4. Guus

    I'm taking that as a hint to be quiet.

  5. Guus

    (but yeah, malicious intent is a bridge to far for me, too)

  6. MSavoritias fae.ve

    > > Yet another company "invents" bridges 24 years after XMPP lol https://www.theverge.com/2023/11/14/23960516/nothing-chats-imessage-android-phone > Yet but This Time Its Different ™ > However, less than 24 hours after its launch, investigations into the app revealed that Nothing Chats logged every message in plain text and stored unencrypted data, including text messages, images, videos, and more, making it a significant privacy and security risk. > The company removed the app from the Play Store following these complaints, citing "several bugs" that need fixing.

  7. MSavoritias fae.ve

    > > > Yet another company "invents" bridges 24 years after XMPP lol https://www.theverge.com/2023/11/14/23960516/nothing-chats-imessage-android-phone > > Yet but This Time Its Different ™ However, less than 24 hours after its launch, investigations into the app revealed that Nothing Chats logged every message in plain text and stored unencrypted data, including text messages, images, videos, and more, making it a significant privacy and security risk. The company removed the app from the Play Store following these complaints, citing "several bugs" that need fixing. Quote ^

  8. MSavoritias fae.ve

    so that was short lived

  9. Squeaky Latex Folf

    Doesn't nearly every instant messaging protocol implementation store messages and media unencrypted?

  10. Squeaky Latex Folf

    So what's the deal? MAM stores unencrypted right?

  11. Squeaky Latex Folf

    As long as Nothing wasn't performing MITM on end-to-end encrypted content, there's not that much of an issue besides trust

  12. Kev

    > As long as Nothing wasn't performing MITM on end-to-end encrypted content, Which it was, no?

  13. MSavoritias fae.ve

    > Doesn't nearly every instant messaging protocol implementation store messages and media unencrypted? on the server? no of course not. if its e2ee it doesnt. which a lot of xmpp is. the problem here was that imessage *is* supposed to be e2ee so that breaks the assumption of people using imessage

  14. MSavoritias fae.ve

    same with that signal bridge of Element that there was an outrage about

  15. MattJ

    and slidge

  16. MSavoritias fae.ve

    slidge is different because at least its not that easy for people who dont know to start using it. element was one click and then everything was MIMT by element. but the lack of consent from people using signal is there.

  17. MSavoritias fae.ve

    in both cases

  18. jonas’

    that is an interesting question and we had similar discussions when the GDPR appeared.

  19. jonas’

    at which point does a message sent from user A to user B become "property" of user B?

  20. jonas’

    in the sense that, if the act of communication between A and B itself is exempt from the GDPR (e.g. by being a private, "purely household activity"), to which ToS does A and B have agree to? each to their own server only? each to each other's server in addition?

  21. jonas’

    in the sense that, if the act of communication between A and B itself is exempt from the GDPR (e.g. by being a private, "purely household activity"), which processing do A and B have to be made aware of? Only that of their own server? Or also that of the peer's server, even though that is fully outside their control and more of the responsibility of the peer?

  22. MSavoritias fae.ve

    that goes also to the discussions about message deleting and dissapearing messages a lot

  23. Maranda

    (and also that people just can't read data treatment and privacy policies before doing anything, even if stamped in their faces and clicky at 'em, and just throw a fuss after)

  24. MSavoritias fae.ve

    can you really blame them when there are hundrends of pages of these per site and dozens of "I agree" you have to click everyday?

  25. MSavoritias fae.ve

    its a natural consequence

  26. MSavoritias fae.ve

    if you put it in plain words with a global toggle people would do it more. apple is proof of that

  27. Maranda

    DT doesn't "usually" have hundred of pages, and there's usually a resume and an appendix. Let alone that there wouldn't be the need of a hundred of pages if people and lawyers wouldn't hang always on whatever they can in these cases

  28. Maranda

    > <MSavoritias⃺e.ve> its a natural consequence You don't read it's your fault, another natural consequence

  29. Maranda

    (and in the majority of jurisdictions on that note, GDPR or not)

  30. MSavoritias fae.ve

    i agree that the current way we do things encourages hundrends of pages of TOS and Privacy Notice or whatever other document.

  31. moparisthebest

    New advertisement opportunity: Come to XMPP! You can set your room moderated and then back again without bricking it guaranteed! https://github.com/matrix-org/synapse/issues/14481#issuecomment-1732912581

  32. moparisthebest

    MattJ: I don't know anything that isn't public, but that's enough for me, you saw the them snatching the code back from the foundation and closing it by requiring CLA etc right? Either way I can attempt to avoid the word "scam" here in the future :)

  33. MattJ

    They didn't "snatch", since it was open-source. The conventional term we use is "fork"... and it happens all the time.

  34. moparisthebest

    MSavoritias fae.ve: haha re: nothing phone > i agree that the current way we do things encourages hundrends of pages of TOS and Privacy Notice or whatever other document. Well I'd say we encourage self hosting which requires none of that

  35. MattJ

    The code is still there if you want to maintain it

  36. moparisthebest

    "snatch" is certainly the right word if you "donate" something to a foundation and then take it back without asking

  37. MattJ

    It's not taken back, but future contributions won't be made. I don't see how that's different from e.g. someone financially donating to something, and then years later stopping that because they can't afford to. We don't say that they "snatched" their donation away :)

  38. MSavoritias fae.ve

    > MSavoritias fae.ve: haha re: nothing phone > > i agree that the current way we do things encourages hundrends of pages of TOS and Privacy Notice or whatever other document. > Well I'd say we encourage self hosting which requires none of that we don't do enough to encourage self hosting and xsf certainly takes no stance in it. so i dont know who is "we". if its the xmpp community we dont do enough. and im gonna leave it at this :)

  39. moparisthebest

    Ok then *I* encourage self hosting :)

  40. MSavoritias fae.ve

    fair

  41. MSavoritias fae.ve

    and i know you do work to make it easier

  42. MSavoritias fae.ve

    i didnt mean it directly at you

  43. Guus

    Does FAST have a XEP number? I think as it got accepted by Counciel in September, it should? Is this still in the editor queue (that has since already been processed a couple of times, I think)?

  44. Zash

    Guus, you appear to be correct. Still in the queue.

  45. Kev

    Still in the queue in what sense?

  46. Kev

    I don't *think* I have anything in my inbox about this, although I grant it's possible I accidentally archived Council minutes or something.

  47. Zash

    > Subject: [Standards] Re: Proposed XMPP Extension: Fast Authentication Streamlining Tokens > Dear Editor, > On Tue, Nov 8, 2022 at 9:42 PM Jonas Schäfer <jonas@wielicki.name> wrote: > > URL: https://xmpp.org/extensions/inbox/xep-fast.html > Better late than never: Council has accepted this today.

  48. Kev

    Wow. That *is* buried in my inbox. Apologies.

  49. Guus

    No worries, I'm happy that I wasn't poking you for something you were already aware of

  50. Guus

    but what Zash quotes is the inbox

  51. Guus

    Daniel wrote something on Sept 27, 2023, on acceptance of the XEP.

  52. Guus

    Oh, Zash is probably quoting from the same email, that internally mentions a different date.

  53. Zash

    Ah yes

  54. Guus

    dates are confusing :)

  55. Zash

    Sorry, should have quoted the Date header too

  56. Zash

    > Date: Wed, 19 Jul 2023 16:12:22 +0200 > To: editor@xmpp.org > CC: XMPP Standards <standards@xmpp.org> > Subject: [Standards] Re: Proposed XMPP Extension: Reporting Account Affiliations > Hi Kev, > council has accepted this XEP. Not seeing a number for this one either

  57. Kev

    Oh, that one at least I understand how I missed it.

  58. Daniel

    Guus, are you working on sasl2/bind2/fast for openfire?

  59. Guus

    Daniel, I'm preparing documentation in the hope that this effort will be commissioned.

  60. ralphm

    We got the lounge again: https://fosdem.org/2024/news/2023-11-20-accepted-stands-fosdem-2024/

  61. moparisthebest

    https://github.com/xsf/xeps/pull/1298 / https://www.moparisthebest.com/xeps/host-meta-2.html looking forward to comments, tl;dr it's my long-implemented and long-promised-to-write-down replacement for all of SRV and POSH and public key pinning without DNSSEC and discovery for QUIC and WebSocket S2S etc etc...

  62. moparisthebest

    soon it'll also be the way to discover webtransport c2s & s2s connections, once those are defined :) (they'll look exactly like websocket)

  63. singpolyma

    You know my vote :P id rather keep using SRV and use it for WebTransport as well

  64. moparisthebest

    Except it's impossible for the reasons I outlined there

  65. moparisthebest

    Can't include more needed parameters etc

  66. singpolyma

    WebTransport we don't need any extra parameters though

  67. moparisthebest

    There is no scenario where we interop with off the shelf web proxies and can pretend path doesn't matter

  68. moparisthebest

    A *seperate* argument is I also want ech and public key pinning and this gives us those too

  69. moparisthebest

    And critically drops the number of lookups to 1, instead of the current... 6, 7 if you add quic and 8 if you add webtransport

  70. singpolyma

    > There is no scenario where we interop with off the shelf web proxies and can pretend path doesn't matter I don't know why we care about web proxies, but obviously you technically have a path. It's probably / but if we really want something "detectable" then there's the option to spec it as /.well-known/xmpp/s2s

  71. singpolyma

    quic and WebTransport should be the same thing. I would hate to see them be looked up differently

  72. pep.

    moparisthebest, so.. replicating DNS over HTTPS?

  73. moparisthebest

    pep.: No, as introduction states this carries more info than DNS can

  74. pep.

    Maybe that's missing a Rationale section that's partly included in the introduction

  75. pep.

    As to why some of the things are mandatory and all

  76. pep.

    Why is SNI mandatory for example? In the example it's all the same

  77. moparisthebest

    Because it's mandatory for TLS/quic, so why not include it?

  78. singpolyma

    Is it?

  79. singpolyma

    Shouldn't SNI always be set to the service name, as we do now?

  80. moparisthebest

    You are right I should switch up the example a bit, it's a gap in 156 (which maybe pre-dated SNI lol)

  81. moparisthebest

    No, in fact often not for websocket (and soon webtransport)

  82. singpolyma

    What else would you set it to? Sounds like a bad precedent

  83. moparisthebest

    The situation now with 156 & Bosh/websocket is you have to guess

  84. moparisthebest

    Try one, if it errors, try the other

  85. pep.

    Re rationale, you also mention stuff above about ech which doesn't appear in the document (That yo want key pinning etc.), or does it?

  86. moparisthebest

    Setting it seems much safer no?

  87. singpolyma

    Bosh and websocket are hacks. But even then sni should always be the service name

  88. moparisthebest

    Oh that's the situation with DNSSEC too btw

  89. moparisthebest

    No it shouldn't always be the service name for sure

  90. moparisthebest

    This is secure delegation, like DNSSEC

  91. pep.

    singpolyma, conversations.im hosting your.name or sth?

  92. singpolyma

    You mean the broken dane srv thing which specifies to do it wrong?

  93. singpolyma

    Pretty sure we've decided to ignore that for xmpp land

  94. moparisthebest

    I should write down there the reason for SNI, because 156 and DNSSEC don't provide this, thanks

  95. singpolyma

    Using SNI of anything but service name is always wrong, IMO. I've never seen an example of anything else

  96. singpolyma

    pep.: right, that's a great example of a case where you definitely need sni to be service name

  97. moparisthebest

    singpolyma: what pep. said, someone else hosting your server and you don't give them a cert

  98. singpolyma

    And they want to use a generic cert for the whole service. Sure, if they use dane and people actually supported that then they can do that. Doesn't change the SNi string

  99. singpolyma

    And they want to use a generic cert for the whole service. Sure, if they use dane and people actually supported that then they can do that. Doesn't change the SNI string

  100. moparisthebest

    > pep.: right, that's a great example of a case where you definitely need sni to be service name No... They have 1 cert valid for hoster.example.org, they don't have one for bob.com, you ask for that in SNI you'll have a bad time

  101. singpolyma

    It can only work if they use dane anyway, in which case you won't have a bad time it'll be fine

  102. singpolyma

    Since dane spec says to ignore the name field in certs

  103. moparisthebest

    Dane or host meta 2 ;)

  104. pep.

    In any case I'm not really down for more JSON and HTTP stuff in XMPP land.. I'm sad that it has to come to this

  105. moparisthebest

    Or POSH which is what they are using now

  106. singpolyma

    Posh doesn't work for s2s

  107. moparisthebest

    POSH is already json over https, but I feel your pain

  108. pep.

    "it could", right?

  109. pep.

    (posh s2s)

  110. singpolyma

    Could, but doesn't and I doubt anyone wants to go down that road

  111. pep.

    moparisthebest, I mean the whole host-meta-2. You're not just replacing posh there

  112. pep.

    You're hoping to replace the whole connection method discovery there riht?

  113. pep.

    You're hoping to replace the whole connection method discovery there right?

  114. pep.

    "Hey use my JSON over HTTP over DNS-discovered domain over moar HTTP connection discovery things maybe someday to discover which XMPP method you should connect with" :P

  115. moparisthebest

    Posh does s2s https://datatracker.ietf.org/doc/html/rfc7711#section-8

  116. pep.

    I was quite happy when this was confined to BOSH/SW fwiw.

  117. pep.

    I was quite happy when this was confined to BOSH/WS fwiw.

  118. moparisthebest

    pretty sure xmpp-proxy does posh s2s too

  119. pep.

    (That is, HTTP things)

  120. singpolyma

    And with WT we can in principle get rid of all http things entirely if we do DNS discovery for it

  121. moparisthebest

    pep.: I agree with you but I don't think it's a fight we can win, at least right now

  122. singpolyma

    Even for web clients

  123. moparisthebest

    I put all this in my introduction, other ways to do them, and why they won't work

  124. moparisthebest

    Webtransport is http3

  125. singpolyma

    Nah

  126. singpolyma

    It's quic

  127. singpolyma

    The handshake just looks like http3

  128. moparisthebest

    You can squint and pretend the handshake at the beginning isn't lol, but it is

  129. singpolyma

    You don't need a web server or anything do hrndle it

  130. singpolyma

    Just a thing to recognize the handshake

  131. moparisthebest

    So tl;dr we can't get all this info over DNS, might as well use https since we already do

  132. singpolyma

    I'm still unconvinced that's true. Just need host and port why can't we get that from DNS?

  133. moparisthebest

    Extra bonus that all hosting platforms support https and you can then host an XMPP server on them all

  134. pep.

    We don't "already do". We use HTTPS for HTTP stuff

  135. pep.

    Not for the day to day XMPP

  136. moparisthebest

    Your clients and servers don't do POSH? Shame shame!!!! :P

  137. singpolyma

    I removed it from mine for today's release 🙂

  138. singpolyma

    Good riddance

  139. singpolyma

    I don't think ay severs do

  140. singpolyma

    I don't think any severs do

  141. moparisthebest

    Also http upload is the only way to share files in a muc or multi client setup

  142. moparisthebest

    singpolyma: conversations hosting at minimum does

  143. singpolyma

    moparisthebest: not for s2s

  144. moparisthebest

    And chat.moparisthe.best does

  145. moparisthebest

    And we use webrtc heavily

  146. singpolyma

    webrtc isn't http related :P

  147. moparisthebest

    Face it, XMPP is already an http application >:)

  148. singpolyma

    Lots of things have web in the name, that doernt make them wib things

  149. singpolyma

    Lots of things have web in the name, that doernt make them web things

  150. moparisthebest

    And some things don't have web in the name but still rely on it, like XMPP :P