XSF Discussion - 2021-01-12


  1. Neustradamus

    Can you look and maybe comment here? - https://www.reddit.com/r/xmpp/comments/kvbn0l/can_xmpp_be_used_as_a_replacement_technology_for/

  2. Paganini

    Hi people! How many users can a Private Group Chat support? And how many users can a Public Channel support. I know that Telegram rooms support a maximum of 200000 users.

  3. Ge0rG

    Paganini: on regular servers, rooms start to get impractical around 1000 users. It's possible to work around that on the server, to some degree

  4. Paganini

    > Paganini: on regular servers, rooms start to get impractical around 1000 users. It's possible to work around that on the server, to some degree Thanks for your response! Nobody wants to create things without knowing what those things can or cannot support. Telegram is transparent about this. They explicitly say that their rooms can support a maximum of 200000 users... As a matter of fact I'm trying to move/migrate the users of some large Telegram rooms to XMPP, so I do need to get this kind of information.

  5. Ge0rG

    Paganini: there is no *technical* limit, but when you join a room, you'll receive a list of all current users, one by one. And many xmpp clients and servers will misbehave if you send 10000+ messages to a user

  6. Paganini

    > Paganini: there is no *technical* limit, but when you join a room, you'll receive a list of all current users, one by one. And many xmpp clients and servers will misbehave if you send 10000+ messages to a user I see...So what do you think the pratical limit will normally be? Just 1000 users? 5000?

  7. Paganini

    People are trying to leave Facebook and even Telegram for political (censorship) and security reasons (Telegram server is not opensource).

  8. Ge0rG

    Paganini: you can probably change the server code to not send this long list of users; everybody will appear as offline, but then you'll be able to have many more users in a room

  9. flow

    Paganini, the practical limit depends on the use-case and used software implementations

  10. goffi

    Paganini: for public large groups, you should have a look a pubsub instead of chat (chat is really hard to follow with so many people). As far as I know there a 2 clients supporting this (Movim, and Salut à Toi/Libervia on which I'm working). There is no end-to-end encryption in this case though. Also MIX (future of chat) should fix this, but it's barely implemented at the time (have a look at Tigase software, I think they start to support it).

  11. Paganini

    > Paganini: you can probably change the server code to not send this long list of users; everybody will appear as offline, but then you'll be able to have many more users in a room Ge0rG: Thanks, it's a solution, although not without inconvenient consequences. But for now I'm not thinking about installing my own XMPP server.

  12. Paganini

    > Paganini, the practical limit depends on the use-case and used software implementations That's why every server should made that information public.

  13. Paganini

    goffi: End-to-end encryption is required. One good think about XMPP is that we can create a public encrypted chatroom.

  14. flow

    Paganini, not easy, because it depends also on the use-case

  15. flow

    (and, of course, potentially also on the used hardware)

  16. Paganini

    Here on XMPP we just need to choose the option "Create private group chat"' and we'll get an encrypted chatroom.

  17. Arne

    is it possible to create one with a password set?

  18. Arne

    is it possible to create one with a password set? (sorry just seen it's actually on the wrong room here...)

  19. Paganini

    flow: I understand. But it will be nice if we could know in advance what is the approximate number of maximum users.

  20. flow

    Paganini, typically, if you have such extreme scaling demands, then you should probably reach out to the vendor and ask for paid support

  21. Paganini

    flow: Are there payed XMPP servers?

  22. Ge0rG

    Paganini: end-to-end encrypted rooms will probably have a much smaller practical limit

  23. Ge0rG

    I don't think anybody tested that beyond 1000 people

  24. mathieui

    Paganini, as it was already said, there is no *theoretical* limit, but there is a practical one, as XMPP chatroom users are *active* participants, currently connected, and we receive the whole list on join

  25. mathieui

    modern systems should be fine with a few thousands+ connected users, but that is not generally the standard use case (and as it was also already said, there are optimizations that can be put in place to help with that)

  26. deuill

    Do MUCs send through participants that are inactive as per CSI? That is, do servers typically treat inactivity as being offline, for the purposes of MUC interactions?

  27. Paganini

    > Paganini: end-to-end encrypted rooms will probably have a much smaller practical limit > I don't think anybody tested that beyond 1000 people That's bad news... Very bad news...

  28. Paganini

    mathieui: Thanks for throwing more light into the subject!

  29. mathieui

    Paganini, also, having thousands of people in an end-to-end encrypted room kind of defeats the purpose, considering how easy it is to leak information when there is that many participants

  30. mathieui

    It makes sense in a centralized protocol, but using XMPP you can just roll your own server without logs or data retention instead

  31. Paganini

    > Paganini, also, having thousands of people in an end-to-end encrypted room kind of defeats the purpose, considering how easy it is to leak information when there is that many participants Good point... Perhaps the best solution is to set and run our own XMPP server, on an encrypted system...

  32. mathieui

    And unless it’s terribly insecure, I don’t see proprietary protocols having much better perf than XMPP in big, encrypted chatrooms, to be honest, at some point you need to encrypt your message to everyone you know of

  33. mathieui

    But I haven’t tried either with many participants so I can’t really speak from experience here

  34. mathieui

    (apart from the overhead when connecting or reconnecting due to MUC, that we already talked about)

  35. Paganini

    > And unless it’s terribly insecure, I don’t see proprietary protocols having much better perf than XMPP in big, encrypted chatrooms, to be honest, at some point you need to encrypt your message to everyone you know of Hum... I see...

  36. Paganini

    If we ignore the issue of encryption, what advantages does XMPP have over Telegram and Signal that can be presented to users in order to be able to convince them to migrate from Telegram or Signal to XMPP?

  37. Paganini

    If we ignore the issue of encryption, what advantages does XMPP has over Telegram and Signal that can be presented to users in order to be able to convince them to migrate from Telegram or Signal to XMPP?

  38. deuill

    As a user (not directly involved with XMPP development): - Wider support for devices, especially older devices. iOS is still somewhat rough, but workable, and Telegram/Signal have long since left older iOS versions unsupported. - Desktop clients that work independently from mobile clients, but provide equivalent or greater security guarantees. - Control over identity and data, especially if using a custom domain (some public servers support this).

  39. deuill

    Basically, it works now, I know it will continue to work, and that I won't be forced to migrate or lose my data if I need to move to a different server (or stop using chat entirely, in any case).

  40. mathieui

    Paganini, from my point of view, the advantages of XMPP in the current messaging kerfluffle are (as an XMPP user and developer for more than a decade, I am obviously not objective though): - it’s enduring (20 years and counting of existence, it’s here to stay) - adaptative (the protocol is always evolving to adapt, e.g. the issues with the impracticality of big rooms are being worked on) - Federated (you don’t have to give up everything if the admin becomes rogue, as it happens in centralized systems such as telegram or signal, worst case is you find another server) - Provides state of the art encryption for those who desire it - Plenty of clients if you’re not satisfied with one (but of course that’s also a downside because UX may not be consistent)

  41. goffi

    from a dev point of view, it's also very hackable, meaning that you can extend it the way you want with a proper namespace system (i.e. it won't conflict with others)

  42. mathieui

    (but e.g. at work I’m forced to use teams, which only has one client which provides a truly awful experience for anyone not using their electron app or chrome, that’s not the case with XMPP)

  43. purplebeetroot

    Something signal gets better: sealed sender How signal makes that feature in practice a bit useless: exposing phone numbers to participants of a chat (they do or? Haven't used it since long)

  44. mathieui

    purplebeetroot, so looking at sealed senders (didn’t know about it) and uh: “To prevent spoofing, clients periodically retrieve a short-lived sender certificate from the service attesting to their identity. The certificate contains the client’s phone number, public identity key, and an expiration timestamp. Clients can include the sender certificate when a message is sent, and receiving clients can easily check its validity.”

  45. MattJ

    1. IP address A requests a sender certificate 2. IP address A sends a sealed-sender message to user B Perfect secrecy!

  46. purplebeetroot

    > purplebeetroot, so looking at sealed senders (didn’t know about it) and uh: > “The certificate contains the client’s phone number, public identity key, and an expiration timestamp.” Yes. But afaik it is e2ee. "...the “envelope” containing the sender certificate as well as the message ciphertext is then also encrypted using the sender and recipient identity keys:"

  47. Paganini

    deuill: Thanks for your explanation. Unfortunately Telegram group chats have more features than XMPP group chats: the possibility of creating polls, for example.

  48. purplebeetroot

    > 1. IP address A requests a sender certificate > 2. IP address A sends a sealed-sender message to user B > Perfect secrecy! Thought it does the job of sealing the ID (don't know how good) of a user. In xmpp it is known that JID A writes JID B. In signal it is promoted to not know this. You can't change IP unless using a proxy. Vpn and Tor do that.

  49. Paganini

    > Paganini, from my point of view, the advantages of XMPP in the current messaging kerfluffle are: > - Federated (you don’t have to give up everything if the admin becomes rogue, as it happens in centralized systems such as telegram or signal, worst case is you find another server) > - Provides state of the art encryption for those who desire it > - Plenty of clients if you’re not satisfied with one (but of course that’s also a downside because UX may not be consistent) Thanks so much mathieui! In my opinion the advantages I quoted above are very important!

  50. Paganini

    > from a dev point of view, it's also very hackable, meaning that you can extend it the way you want with a proper namespace system (i.e. it won't conflict with others) goffi: That's great too, but it's not an advantage a normal user would understand 😃

  51. Paganini

    > (but e.g. at work I’m forced to use teams, which only has one client which provides a truly awful experience for anyone not using their electron app or chrome, that’s not the case with XMPP) Microsoft Teams?? Oh my God! Why don't you use Nextcloud instead?? Isn't Nextcloud technically superior to Microsoft Teams (even if we ignore issues like the proprietary code)?

  52. Zash

    Enterprise? Enterprise.

  53. mathieui

    Paganini, I don’t make the decisions (also non-tech people get office online & sharepoint integration which important to them)

  54. SamWhited

    Nextcloud doesn't scale and you can't get support for it. I haven't used teams in particular, but businesses use the big chat things and not random open source projects for good reason.

  55. mathieui

    SamWhited, tbh the microsoft suite suffers more often from (short) failures than some random self-hosted chat, but that means the blame can be placed on microsfoft and not IT

  56. mathieui

    SamWhited, tbh the microsoft suite suffers more often from (short) failures than some random self-hosted chat, but that means the blame can be placed on microsoft and not IT

  57. Paganini

    Nextcloud now offers office online... Collabora office or OnlyOffice.

  58. jonas’

    which are binary blobs

  59. mathieui

    also teams actually provides a viable solution for 100+ videoconferencing integrated with a lot of tools and everything

  60. jonas’

    onlyoffice is anyway

  61. mathieui

    I don’t like it but it still works in an efficient manner

  62. Paganini

    > Nextcloud doesn't scale and you can't get support for it. I haven't used teams in particular, but businesses use the big chat things and not random open source projects for good reason. That's not the case in several countries, like Germany and Switzerland...

  63. SamWhited

    mathieui: yah, I don't know how good or bad the microsoft thing is compared to other stuff, but they have a phone number you can call which is why I'd use it over something I have to run myself if I just wanted to make my product and not have to think about it.

  64. Paganini

    > also teams actually provides a viable solution for 100+ videoconferencing integrated with a lot of tools and everything I think Nextcloud Talk can support that number of participants on a video conferencing.

  65. SamWhited

    (or maybe not a phone number, you know what I mean though, point is that there is someone to fix things when they break that you don't have to pay a salary to, someone else is doing it)

  66. Paganini

    > (or maybe not a phone number, you know what I mean though, point is that there is someone to fix things when they break that you don't have to pay a salary to, someone else is doing it) Are you honestly expecting Microsoft to fix things?? 😁

  67. SamWhited

    :)

  68. Paganini

    They didn't even manage to fix Window after more than 35 years, and they let things get to the point that now the only way to fix Window is to rewrite the code from scratch!

  69. Paganini

    They didn't even manage to fix Windows after more than 35 years, and they let things get to the point that now the only way to fix Windows is to rewrite the code from scratch!

  70. SamWhited

    I assumed you were joking. By "fix" I meant, "when there's an outage, it goes away after a bit and the business doesn't have to take time away from their actual product to try and fix chat"

  71. emus

    Paganini: I think you are heading offtopic

  72. SamWhited

    Point is: random open source projects aren't practical for most people. We have to make them practical.

  73. deuill

    With regard to features such as polls: these are generally implemented via bots and the like (at least on Slack etc.), so it's not impossible to add this functionality in where needed.

  74. deuill

    That said, I'm not sure what state general-purpose XMPP bots are these days...

  75. Zash

    XMPP is eXtensible, you could write a XEP on how to do polls

  76. mathieui

    deuill, not great, tbh

  77. mathieui

    Zash, the quickresponse XEP is actually an easy way to do polls

  78. mathieui

    without having to define things in a very precise manner

  79. Zash

    Yeah

  80. Zash

    Reactions is another

  81. Zash

    So many options!

  82. deuill

    I assume the timeline for defining and implementing an XEP is slightly longer than one for implementing a bot :)

  83. deuill

    Poll bots on Slack, GChat etc. collect votes via reactions -- probably the only viable use of these I've seen!

  84. Paganini

    > With regard to features such as polls: these are generally implemented via bots and the like (at least on Slack etc.), so it's not impossible to add this functionality in where needed. Right, but the truth is that those functions are not implemented on XMPP, for the time being.

  85. mathieui

    Paganini, we have been using poll bots for as long XMPP has existed, approximately

  86. SamWhited

    mathieui: are you suggesting that a normal user can turn on a client and create a poll? Because there's a big obvious difference between using a service like telegram or whatever Paganini is talking about and trying to create a poll on XMPP.

  87. Paganini

    How a regular user could create a poll here on XMPP?

  88. mathieui

    SamWhited, I haven’t used telegram at all, so I don’t know, but e.g. looking at discord, matrix, etc, they appear to also go the bot route

  89. SamWhited

    Implementation doesn't matter. Same question: if on matrix I can log in and hit create poll, are you suggesting XMPP does the same thing? The answer is "no, you can't create a poll on the public jabber network easily" right now.

  90. mathieui

    SamWhited, agreed

  91. SamWhited

    I dunno if that specific feature is actually a thing we want or not, but just pretending because a bot or an XEP is out there somewhere means we have the same feature as Matrix (or whatever) is probably not helpful to Paganini trying to move his users over.

  92. Paganini

    SamWhited: That's right.

  93. SamWhited

    I keep thinking that we need some organization aside from the XSF whos job it is to do things like this. Some org to sort of act like a product manager for the public network.

  94. SamWhited

    I mean, obviously they can't force clients to comply, but just keeping a compatibility suite that's more specifically geared to the public network, lists of clients and services that support it, etc. might be nice.

  95. mathieui

    SamWhited, you mean something like modernxmpp?

  96. SamWhited

    mathieui: I dunno, maybe? I should look into that again.

  97. MattJ

    ModernXMPP was my attempt to solve this problem

  98. Zash

    Past tense? 🙁

  99. MattJ

    and I think it's far from irrelevant, at least as a documentation project

  100. MattJ

    When I started it I was more optimistic about it than I am today

  101. MattJ

    As a documentation resource, I think it's fine, but it isn't a vehicle for change

  102. SamWhited

    That's too bad, the idea looks nice

  103. SamWhited

    I vaguely remember this launching, and apparently I joined the chatroom at some point, but I haven't seen it in a while

  104. MattJ

    Documenting stuff doesn't get people to implement it

  105. MattJ

    So I consider Snikket as an implementation of Modern XMPP, and I'm hoping that will be the vehicle for change instead

  106. MattJ

    It's also way harder to secure resources and funding for a documentation project, vs. something normal people can actually use

  107. SamWhited

    I kind of wonder if it doesn't need a whole service (ie. the way Matrix does it) to make it work, but I'm not sure

  108. MattJ

    Lessons learned from Snikket will go into Modern XMPP docs, and I encourage anyone who feels there is stuff not documented or suitable for documenting under the XSF to PR there

  109. SamWhited

    I never really understood what Snicket was and didn't realize it had any relation to Modern XMPP too, so it may be a messaging problem

  110. MattJ

    It has no formal connection with Modern XMPP other than in my head and actions

  111. SamWhited

    (although the Snikket website looks really good)

  112. MattJ

    Modern XMPP was about defining a blueprint for everyone to follow, but... hard to make that blueprint a reality :)

  113. SamWhited

    Oh snickket does hosting too? That will be nice

  114. MattJ

    Snikket has real users, real feedback, and implementation experience. Which all beats a pure documentation project.

  115. SamWhited

    yah, nice; the website sort of made me think it was just a docker container and a rebranded conversations and I didn't understand the point at first and just pointed people at it if they were struggling to run prosody and just needed a container they could run easily, but it looks like it's a lot more

  116. jonas’

    especially since I hear there’ll be iOS support soon

  117. MattJ

    Few people understood the point, but my focus isn't the XMPP community so I didn't care too much

  118. SamWhited

    Fair enough

  119. SamWhited

    well I love the idea anyways now that I understand a little better; good luck

  120. MattJ

    Hopefully it will all become clear to everyone as it matures

  121. SamWhited

    Let me know how I can help (other than writing code), etc.

  122. MattJ

    Thanks :)

  123. MattJ

    I spent a chunk of last year trying to secure funding, but my attempts failed (partly because others also didn't see the purpose and I guess I'm still learning how to communicate it better)

  124. MattJ

    Hence my focus on hosting, despite the irony at a project aiming to improve decentralization

  125. Ge0rG

    > Some org to sort of act like a product manager for the public network. The Jabber Software Foundation!1!

  126. Zash

    Ge0rG, not the JoinXMPP foundation?

  127. Ge0rG

    Zash: the public network is Jabber™

  128. Neustradamus

    Ge0rG: XMPP network!

  129. MattJ

    You only make me want to jabber about the Jabber network more

  130. Neustradamus

    First sentence: https://www.jabber.org/

  131. Ge0rG

    Neustradamus: I have written about that distinction on the SMTP network before. Read it up!

  132. Neustradamus

    http://jabber.org/ and https://jabber.org/ do not work.

  133. Ge0rG

    > http://jabber.org/ and https://jabber.org/ do not work. Jabber is down.

  134. MattJ

    Since 2006

  135. marc

    Wouldn't it be nice to have at least a single post on xmpp twitter about the whatsapp policy changes and advertisement for xmpp?

  136. Zash

    Sure would.

  137. Zash

    But something something neutrality? 😀

  138. Ge0rG

    I suggested a text some days ago. Nothing happened.

  139. MattJ

    Sorry, it wasn't clear to me at the time that you were asking for someone to post something

  140. MattJ

    I don't know who is active on Twitter but ping someone directly and avoid the bystander effect

  141. Ge0rG

    Well, it was a suggestion to tweet as @xmpp, made in the commteam MUC. Not sure how much more explicit I should have made it, not knowing who personally has write access to that account

  142. Paganini

    > Wouldn't it be nice to have at least a single post on xmpp twitter about the whatsapp policy changes and advertisement for xmpp? Yes, it would!!! Due to inaction, XMPP is missing a great opportunity to gain many new users. XMPP is letting itself be overtaken by Telegram and Signal.

  143. Paganini

    Facebook posts would be important too...

  144. Guus

    Kindly start drafting texts.

  145. Ge0rG

    Guus: see my suggestion in commteam@, four days ago

  146. Zash

    Who knows who has access to twitter / other social media accounts?

  147. Ge0rG

    Board does?

  148. Guus

    Didn't we grant commteam access not to long ago?

  149. Guus

    I might have the ability to post tweets, but not to grand other access. IIRC, Kev does.

  150. Paganini

    We need a propaganda team, with local groups (on every country).

  151. Ge0rG

    Paganini: you volunteer?

  152. mathieui

    we have one, everyone is just stretched quite thin as far as I’m aware

  153. Paganini

    > Paganini: you volunteer? Yes, why not?

  154. Link Mauve

    Paganini, their room is xmpp:commteam@muc.xmpp.org?join

  155. marc

    Paganini: awesome, thanks!

  156. Link Mauve

    Or should I say, your room now. :)

  157. wurstsalat

    Ge0rG, since you talked to gov officials regarding XMPP, this might be of interest as well https://www.bundeskartellamt.de/SharedDocs/Meldung/DE/Pressemitteilungen/2020/12_11_2020_SU_Messenger_Dienste.html the admin of xmpp:conversations@conference.jabber.de?join is already in contact, sending some contact infos for a survey

  158. Paganini

    > Paganini: awesome, thanks! My pleasure.

  159. emus

    I plan to write at least a tweet, but let me pass an interview on thursday first

  160. marc

    emus: wow, what interview?

  161. Paganini

    I think that when advertising XMPP we have to put the target audience on the path to choosing good service providers... One thing I've noticed is that for most people it is very important to be able to send/receive all types of files, including large files (about 100Mb or more). But it turns out that many XMPP service providers only allow the transmission of files up to a maximum of about 3Mb... So I think it would be important to route people to service providers which allow the transmission of large files (even if encrypted), namely through end-to-end transmission.

  162. emus

    Job interview, but unrelated

  163. emus

    marc:

  164. marc

    Ah :D

  165. marc

    Paganini: +1

  166. jonas’

    Paganini, end-to-end transmission is always possible and modern clients will fall back to that if the file size is restricted on the server side

  167. jonas’

    but it doesn’t work with 1:n scenarios

  168. emus

    @board & @council as not offered from anyone else located in DE, I am offering my contact to the cartell office approach one in the XMPP community is thriving

  169. emus

    @board & @council if not offered from anyone else located in DE, I am offering my contact to the cartell office approach one in the XMPP community is thriving

  170. jonas’

    emus, as council chair, I’d be happy to, but I think this is more of a board matter.

  171. emus

    Yes ok, I dont need to do it alone, so happy if there are at least supporters and people in the background I can talk to

  172. Paganini

    > Paganini, end-to-end transmission is always possible and modern clients will fall back to that if the file size is restricted on the server side > but it doesn’t work with 1:n scenarios I'm currently using Movim service provider and I'm not able to transfer files over 3Mb...

  173. jonas’

    emus, you cannot represent the XSF without an official statement from board, mind

  174. emus

    No interest to do so.

  175. emus

    Just saying that want to support this from a general perspective

  176. marc

    > Paganini, end-to-end transmission is always possible and modern clients will fall back to that if the file size is restricted on the server side > but it doesn’t work with 1:n scenarios e2e transmission is really bad in most use cases IMO

  177. Zash

    Harder to have reliable, but less taxing on the servers.

  178. jonas’

    thanks to the spread of TURN, it should also be more realistically achieveable ;)

  179. Zash

    Wasn't Proxy65 wide-spread enough already?

  180. emus

    Just saying that I want to support this from a general perspective

  181. marc

    Still not multi device and painful when on mobile

  182. marc

    Should be avoided whenever possible IMO

  183. Paganini

    Well, it seems 404.city supports file transmission up to 2Gb!!!

  184. Zash

    There you have it.