XMPP: The secure communication protocol that respects privacy

I said "my server", but the exact same code could be pointed at a different server by simply changing the username/password. Compare this to having to port a codebase from Signal to WhatsApp/Slack/whatever.

I'm also just using a standard ejabberd-based deployment, nothing highly-customized about it. Have you tried a Signal server deployment? I have, and THAT is the definition of highly-customized.

> This was discussed numerous times various platforms and proven wrong.

Alternative clients exist, but they are heavily frowned upon by the community - as a lot of the functionality they add (disappearing messages, view once media) depend on people using the official clients and not custom ones that could simply ignore this functionality.

> As discussed before on this page, most XMPP users don't run their own XMPP server but use a public XMPP server on the internet. Nobody can check whether this public XMPP server tracks its users without accessing the server itself.

That's fine, same thing applies to Matrix/Signal/WhatsApp/pretty much any messaging service out there.

> So, do you assume the Signal network infrastructure consists of a single server?

Functionally - although it is clustered - it is a single server, run by a single team - and it has gone down multiple times in the past few years.

And when it does go down: good luck using that Signal client to talk to anyone over it (SMS doesn't count as it has zero security on Signal and isn't even available on the iOS client). At least with XMPP, I can point the same client to some other server and potentially continue a conversation with someone somewhere else, with the exact same OMEMO/PGP encryption.

That is why decentralized/federated is better than "all your eggs in one basket" centralized. Centralization provides one with convenience, right up until it stops working and then it becomes a massive inconvenience.

> At least Quicksy (from the Conversations developer who bragged in a public video about copying WhatsApp/Signal) and Kontalk require a phone number.

The whole point of Quicksy is to allow people to try XMPP and find contacts easily with their number before they then move on to using actual JID-based accounts.

And he's more than free to brag about what he does - he's the one that spent the time; writing code and extensions and then released the thing to the public as free and open-source code.

> Signal does. You wrote, you use Signal. Did you ever join a Signal group? There is a dialog when entering a group the first time.

This is your Signal PROFILE name, not a username. You can quite clearly see this described in Settings -> tap the top bit with your number and read the text at the bottom.

People can still see your phone number by simply clicking on your user in the group member list. Signal, at the current time[0], has zero username functionality.

[0]: https://twitter.com/moxie/status/1480643863970816001

> At least with XMPP, I can point the same client to some other server and potentially continue a conversation with someone somewhere else, with the exact same OMEMO/PGP encryption.

How do you just "continue a conversation with someone somewhere else" when your XMPP server goes down?

Typically, you register an XMPP account on an XMPP server. If this server is offline, your account is unreachable as the account is managed by the XMPP server not by your client. Therefore, you can't use this account anymore. So you need to go to another XMPP server, register a new XMPP account, and then try to find your contacts again (which may be cached by your client or not). Finally, you have to convince "someone" that this is just you with another account on another server. There is also no verified E2EE anymore. If "someone" uses the same now-offline XMPP server, "someone" also needs to find another XMPP server.

How is this different from "when Signal goes down one uses a completely different instant messaging system", apart from using another client?

> That is why decentralized/federated is better

And we already explained (also several times) that XMPP is de-facto centralized as the vast majority of users only use a tiny number of XMPP servers hosted by an even smaller number of hosting companies. Which means: If one of these hosting companies blocks XMPP traffic (e.g., if a rogue state starts censoring) or one of these XMPP servers goes down, a huge part of XMPP users is affected.

At this time there are 9 room versions. Once the room version had to be incremented because of a bug in the consensus algorithm, which required a new algorithm, i.e. room version.

That's it. Bugs happen when you create new tech...

> Except of course for censorship-resilient public rooms where it shines, which goes back to my point that "decentralized rooms" as an XMPP extension would have made sense.

There are many more reasons for wanting decentralized rooms, e.g. autonomy, reliability, availability, anti-takeover - and it works for private rooms as well. Prospectively, it enables things like P2P and multi homing

I would never want to go back to the XMPP like it is today. And XMPP today is not Matrix, even if you could turn it to Matrix, but what is the point of doing that? Matrix is already there!

If you want Matrix to be an XMPP extension, I suggest creating a new XEP pointing to spec.matrix.org and call it XMPP v2. No idea what you would gain from it though.