XSF Discussion - 2021-01-12

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

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.

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

> 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.

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

> 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?

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

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

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

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).

> 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.

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

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

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

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

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

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

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

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

flow: Are there payed XMPP servers?

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

I don't think anybody tested that beyond 1000 people

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

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)

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?

> 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...

mathieui: Thanks for throwing more light into the subject!

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

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

> 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...

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

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

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

> 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...

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? ✏

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).

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).

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)

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)

(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)

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)

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.”

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

> 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:"

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

> 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.

> 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!

> 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 😃

> (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)?

Enterprise? Enterprise.

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

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.

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 ✏

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

which are binary blobs

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

onlyoffice is anyway

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

> 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...

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.

> 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.

(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)

> (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?? 😁

:)

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! ✏

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"

Paganini: I think you are heading offtopic

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

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.

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

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

deuill, not great, tbh

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

without having to define things in a very precise manner

Yeah

Reactions is another

So many options!

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

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

> 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.

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

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.

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

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

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.

SamWhited, agreed

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.

SamWhited: That's right.

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.

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.

SamWhited, you mean something like modernxmpp?

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

ModernXMPP was my attempt to solve this problem

Past tense? 🙁

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

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

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

That's too bad, the idea looks nice

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

Documenting stuff doesn't get people to implement it

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

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

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

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

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

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

(although the Snikket website looks really good)

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

Oh snickket does hosting too? That will be nice

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

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

especially since I hear there’ll be iOS support soon

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

Fair enough

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

Hopefully it will all become clear to everyone as it matures

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

Thanks :)

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)

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

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

Ge0rG, not the JoinXMPP foundation?

Zash: the public network is Jabber™

Ge0rG: XMPP network!

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

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

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

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

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

Since 2006

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

Sure would.

But something something neutrality? 😀

I suggested a text some days ago. Nothing happened.

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

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

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

> 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.

Facebook posts would be important too...

Kindly start drafting texts.

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

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

Board does?

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

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

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

Paganini: you volunteer?

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

> Paganini: you volunteer? Yes, why not?

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

Paganini: awesome, thanks!

Or should I say, your room now. :)

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

> Paganini: awesome, thanks! My pleasure.

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

emus: wow, what interview?

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.

Job interview, but unrelated

marc:

Ah :D

Paganini: +1

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

@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 ✏

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

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

> 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...

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

No interest to do so.

> 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

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

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

Wasn't Proxy65 wide-spread enough already?

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

Still not multi device and painful when on mobile

Should be avoided whenever possible IMO

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

There you have it.