Having been involved in testing an open-source XMPP web client (JSXC) against ejabberd and Prosody, I have noticed the following differences that I would like to share, to make it easier for you to decide. Please note that I have done more with ejabberd, so there will naturally be more nitpicking there, but also more praise.
- The mechanisms that have been implemented are typically rock-solid, probably due to the fact that a company is behind it, offering services which require this quality.
- With the
ejabberdctland the admin web interface, it is possible to configure many things while the process is running. Even if you need to touch the config files heavily, reloading them does the right thing without an interruption.
- ejabberd can easily be turned into a cluster for reliability or performance
- Comes with a built-in STUN/TURN server
- Shared roster groups are very powerful, but also need getting used to.
- The documentation is mostly option-based, i.e. options are described, similar to a manual page. There are few examples and even fewer descriptions of how the options interact, what would be the best practice usage, or actually where you would put the option, especially in a virtual hosting environment.
- If you want to extend ejabberd, you need to be able to grasp Erlang, a very powerful language, but with quite a few differences to the programming languages most beginners learn.
- Message Archive Management is currently not supported in the final version (
mam:2), only an intermediary version.
- External Service Discovery (
extdisco) is not (yet) supported either.
- Has a lot of community modules, due to the easier accessibility of the Lua programming language.
- As a pure community project, if you want to invest time, you really can shape the project.
- Does support
extdisco(requires less client configuration) and
mam:2(better supported by clients)
- Can map some of the services, e.g. HTTP Upload, to the same DNS name (and thus certificate entry) [Updated 2018-09-02]
- Some modules (for me, the most notable was the external authentication mechanism) are unreliable.
- Has to be restarted for more configuration updates, i.e., clients will be disconnected and have to reconnect, typically causing has gone offline/come online notifications to the users.Update: I did know about
mod_reload_modules, which would have avoided some or these restarts. Thanks, drs!
- No persistence for PEP/PubSub (Personal Eventing Protocol; Publish-Subscribe) data. This makes it unusable for both bookmarking (e.g., multi-user chats) and XMPP-based social networks such as Movim
You want it? Now?
Great! Setting up your own XMPP server is easy, if you have some experience administering a Linux server. For some additional guidance, we created some how-to documents. They are dedicated to setting up an XMPP server for a Nextcloud+JSXC combo, which frees you from some configuration tasks, including the user management. However, they provide a good starting point for setting up any XMPP server, or any server which is supposed to support encrypted connection, for that matter.
Security is easy and cheap these days. There is no excuse anymore for not having encryption built-in!
Are you aware of additional differences? (An earlier version of this post also appeared on StackExchange, so there might be additional comments.)