ProcessOne Blog

> self-hosting an XMPP server isn't something you can just install and have it work

For basic needs ala IRC it should just work out of the box by defining a virtualhost. For respect of advanced features as defined in the XMPP Compliance Suites, it'll need a few more settings but there's good guides:

prosody: https://homebrewserver.club/configuring-a-modern-xmpp-server.html

ejabberd: https://www.process-one.net/blog/ejabberd-xmpp-server-useful-configuration-steps/

All in all it should take a novice (who has some experience of sysadmin, can deal with DNS records, firewall, etc) a few hours to setup to their taste... Or you could go with Snikket, a XMPP distribution, to have everything pre-configured in a docker container.

> XMPP clients on iOS were unusable

Sorry I don't know about iOS mostly because my acquaintances can't afford Apple devices and/or are not interested in a walled garden where a private company owns all your computations. Though i heard similar stories as yours, but there is progress with Siskin, with some development (eg. OMEMO groupchats) being funded by the Snikket project.

> notifications sometimes don't work

This may have to do with your OS settings. I don't know how iOS handles low power mode but i know for sure some Android distros restrict network queries (apart from the privileged, centralized push notifications service) and there's settings to uncheck for that.

> in a business situation

In a business situation you might find the resources…

> I'm still hopeful for matrix to become easier to deploy and easier to use, as it has real potential.

I mean, I'm admittedly biased here, but the "easy to deploy, $10 shared host IM" already exists and is XMPP. Matrix is doomed to be inefficient, and that's baked at the protocol level. It won't ever get easy and cheap to deploy and run, judging from the recent year's trajectory, with more and more components being added to the mix.

> somebody get matrix to run via one click with softalicious / fantistico like abilities please!

https://www.process-one.net/download/ejabberd/ ← Docker, RPM, DEB, binary, pick your poison. It really doesn't have to be that hard.

> I also think Matrix would be better as a no federated self hosted install and connect some sort of bridge on a different server if someone wants to connect the federated stuff

You just described federation. Anyhow, do you know what's the world's largest non-federated ejabberd instance? It's WhatsApp. Yes, that WhatsApp: https://www.process-one.net/blog/whatsapp-facebook-erlang-and-realtime-messaging-it-all-started-with-ejabberd/

Another software delivering a slack-lite experience geared towards corporations is prose: https://prose.org/ it's also XMPP, their client can be used with ejabberd but they have an easy-deployment bundle that ships Prosody instead (yeah, unlike the Matrix ecosystem, XMPP has multiple completely viable and compatible implementations, ejabberd and prosody being only the two most popular).

Here's a blog post on scalability from the front page (well, sort of, see last paragraph): https://www.process-one.net/blog/ejabberd-massive-scalability-1node-2-million-concurrent-users/ This includes not just textual claims about scalability but a lot of hooks you can use to followup on, like a reference to the Tsung benchmarking tool you can use. If you're asking about this for serious reasons, at this scale you're obviously running your own tests anyhow. You may also want to speak directly to Process One about this because it sounds like you're at a scale where you should probably be looking at paid support anyhow.

I'm not necessarily endorsing this, just giving it to you as some first stabs at answers and some ways to follow up.

If there's anyone reading this from the ejabberd project, note that the link to this on your front page under "Massively Scalable" is completely broken; that links to "blog.process-one.net" but that domain is completely dead, so it doesn't redirect to the link I gave above. (It's also part of why I posted this; my post here is not a "just read these docs" because I had to do non-trivial work to find them.) I had to pull that out of archive.org. Should probably check for any other links to that domain too.

This isn't necessarily an endorsement of one protocol/ecosystem over the other, nor do I have direct experience with integrating Matrix or XMPP (though I run the latter on my home-server for family), but XMPP has seen a few large deployments, including in healthcare (in the UK)[0][1] and in Germany[2].

The consumer-facing client ecosystem for XMPP has indeed seen less rapid development than Matrix (the latter probably benefits from a more cohesive approach), but the server ecosystem for XMPP is very mature, and servers such as Ejabberd are known to scale to hundreds of thousands of connections on a single, modest host[3]. Obviously, that's only one part of the puzzle, hence why Matrix was chosen here.

Still, it'd be interesting to see how the two evolve and compare down the line.

[0]: https://www.erlang-solutions.com/case-studies/pando-health-case-study/
[1]: https://medium.com/miquido/successful-migration-to-a-custom-xmpp-solution-76fcdecb0928
[2]: https://twitter.com/iNPUTmice/status/1203611711967813633
[3]: https://www.process-one.net/blog/ejabberd-nintendo-switch-npns/

Actually, from talking with the OneSocialWeb [1] and BuddyCloud [2] guys, I understood that Android phones have a really sophisticated "always connected" philosophy. The main CPU can go into deep sleep and the phone still maintains a persistent data connection, waking up the CPU on incoming data. That's for the low-level IP stuff. TCP-over-GSM really sucks your battery.

XMPP doesn't (yet) have a standardized way of filtering data. Using Privacy Lists is a workable hack. Google implemented their own thing (using Protocol Buffers [3] to replace XML-on-the-wire, instead of gzipping as the XSF recommends). Process One has their own system as well for OneTeam [4].

The future ideal is to use SIFT [5], but it is still experimental and as far as I know, only Prosody [6] has partially implemented it.

[1] http://onesocialweb.org/
[2] http://buddycloud.com/
[3] http://code.google.com/p/protobuf/
[4] http://www.process-one.net/en/solutions/oneteam_iphone/
[5] http://xmpp.org/extensions/xep-0273.html
[6] http://prosody.im/
(dammit, how do I embed URLs in the reply?)

I get it the numbers are irrelevant, but just wanted to share where those came from.

http://www.process-one.net/en/imtrends/article/usage_estimation_of_public_xmpp_servers_per_domain/ - "that study relies on a panel of 7292 XMPP domains as discovered by the IMtrends engine"

So, I'd guess, if there's was least 7k public servers in 2008, it won't be wrong to say "thousands."

http://xmpp.org/xsf/press/2003-09-22.shtml - this one is old, much before the popularity peak, when XMPP was still called Jabber, and yet: "the JSF's estimate includes more than 4 million paying customers of Jabber, Inc.'s commercial software as well as an estimated 6 million users of open source and other commercial implementations of the Jabber/XMPP protocol"

So, I guess, "millions" isn't a wrong estimate, too.