ProcessOne Blog

(EU-based freelancer and SaaS builder here). I can warmly recommend https://www.recurly.com, which I use to handle recurring billing on a number of projects (my own SaaS https://www.wisecashhq.com, but also client projects such as https://www.boxcar.io/developer and https://www.process-one.net/en/ejabberd/saas/). It can be used together with Stripe as a gateway (much recommended, the setup is much faster than on other gateways), and provides a full-featured setup with PCI SAQ A, VAT handling, PDF invoices, coupons, dunning etc.

They shouldn't, though, because pretty much every XMPP server I've seen has user-offline message storage for later delivery eg [1], [2], and the "best practices" have been documented for years, e.g. [3]. Unless you actually mean "receive messages [to your device] when you're offline" and how the hell would that work? [1] https://prosody.im/doc/modules/mod_offline [2] http://www.process-one.net/docs/ejabberd/guide_en.html#htoc48 [3] http://xmpp.org/extensions/xep-0160.html

We have the needed software stack at ProcessOne: http://www.process-one.net/ Contact us if you are interested.

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

How is ejabberd or XMPP in general doing these days? I remember Nintendo adopted it for their push platform [1] but it was old news. Are there any interesting development and/or adoption stories in recent years? [1] https://www.process-one.net/blog/ejabberd-nintendo-switch-npns/

Any run down of the xmpp extensions it supports compared to something like ejabberd or openfire? Edit: Found it: https://github.com/ortuman/jackal#supported-specifications Ejabberd in comparison: https://www.process-one.net/en/ejabberd/protocols/ It’s crazy how much stuff a mature xmpp server can do out of the box.

I know that Fortnite [1] and League of Legends both use XMPP. Eve just moved to XMPP [2] somewhat recently. There is a Hackernews thread that talks about the Eve article already too. [3] [1] https://www.epicgames.com/fortnite/en-US/news/postmortem-of-service-ou… [2] https://blog.process-one.net/eve-online-chat-is-moving-to-ejabberd/ [3] https://news.ycombinator.com/item?id=16445365

I just read something that makes me rather angry. For ejabberd, message reliability is a premium feature that is not supported in the free version. The fuck? https://www.process-one.net/en/ejabberd/protocols/

Original source: https://blog.process-one.net/eve-online-chat-is-moving-to-ejabberd/

This post [1] seems to indicate that ejabberd's support of MAM is complete. Note that you also (obviously) need support from the client, which most but not all clients do. Conversations [2], on mobile, does. [1] https://blog.process-one.net/ejabberd-15-06/ [2] https://play.google.com/store/apps/details?id=eu.siacs.conversations

My understanding is that it is not the clients that are the problem but rather there is patchy support in open source XMPP servers to utilize the new mobile friendly features. [1] - https://www.process-one.net/en/ejabberd/protocols/ [2] - https://prosody.im/doc/xeplist [3] - https://github.com/esl/MongooseIM#features-and-supported-standards

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_pub… - "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.

Be careful with traditional Diffie-Hellman, which in practice also has problems: if your server software doesn't let you specify your own parameters, it's probably using 1024 bit parameters. All versions of Apache are guilty of this[1], as are (at least the versions I checked) Dovecot and Postfix. I would not trust 1024 bit DH in the face of an adversary like the NSA. It would be interesting to check how XMPP server software handles DH parameters. [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=49559 Edit to add: Prosody allows you to specify dhparams, though the documentation is vague[2]. Don't see anything in the ejabberd docs for this[3]. [2] http://prosody.im/doc/advanced_ssl_config [3] http://www.process-one.net/docs/ejabberd/guide_en.html

They already did for some time, I am not sure if they've done in the scope of this rebrand, it is surely an welcome addition. [1] Don't expect that it just works with any XMPP client as it uses a proprietary authentication mechanism "very similar to Facebook" OAUTH2.[1] More popular clients have already integrated it. That's why Windows devs drink. [1] http://blog.process-one.net/details_on_msns_xmpp_server/

They use a proprietary authentication mechanism, so you can't just use any XMPP client... The client-to-server authentication used is SASL, with a specific and proprietary mechanism called X_MESSENGER_OAUTH2. ... Which means that all current XMPP clients are NOT able to connect to messenger.live.com. http://www.process-one.net/en/blogs/article/details_on_msns_xmpp_serve…

Process One (developers of ejabberd) are working on an independent implementation: http://www.process-one.net/en/blogs/article/processone_wave_server_eja… http://www.process-one.net/en/blogs/article/proof_of_concept_wave_clie… I wouldnt be surprised if they eventually offered corporate hosting.

This means everyone can use AIM and ICQ via the Jabber gateways: http://www.process-one.net/en/blogs/article/openaim_aol_is_opening_its…

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

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-solut… [2]: https://twitter.com/iNPUTmice/status/1203611711967813633 [3]: https://www.process-one.net/blog/ejabberd-nintendo-switch-npns/

> 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-configura… 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…

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