XMPP server hands-on comparison: ejabberd vs. Prosody

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.

ejabberd

Pros

  • 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 ejabberdctl and 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.

Cons

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

Prosody

Pros

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

Cons

  • 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.[1]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!

More…

Are you aware of additional differences? (An earlier version of this post also appeared on StackExchange, so there might be additional comments.)

Footnotes   [ + ]

1. Update: I did know about mod_reload_modules, which would have avoided some or these restarts. Thanks, drs!

2 Gedanken zu „XMPP server hands-on comparison: ejabberd vs. Prosody

  1. rick

    Excellent summary!
    This post seems like a good place to keep information up-to-date. For example I’ll be selecting one of these two servers for my personal XMPP server and was wondering what are the differences.
    ejabberd claims to support ACME (Let’s Encrypt) in future versions ( source: https://blog.process-one.net/ejabberd-17-06/ ) so it’ll be a strong point for them.

    • Marcel Waldvogel Autor des Beitrages

      Thanks for the pointer, Rick. Yes, with the built-in HTTP server, adding this might be easy to add (and userfriendly, lowering the bar to entry further, which is one of my goals as well).

      Using acme.sh is not too shabby, either (I use it because of the DNS verification support). However, *ejabberd* still requires that extra step of `cat private.key fullchain.pem > combo.key` and then specifying the latter to the `certfile:` option).

Schreibe einen Kommentar