// the find
processone/ejabberd
Robust, Ubiquitous and Massively Scalable Messaging Platform (XMPP, MQTT, SIP Server)
ejabberd is a 20+ year old XMPP/MQTT/SIP server written in Erlang, maintained by ProcessOne and running in production at WhatsApp scale (they forked it). It handles millions of concurrent connections through Erlang's actor model and OTP supervision trees. If you need a battle-tested messaging server you don't have to build yourself, this is the serious option.
The OTP supervision tree means individual connection failures don't cascade — a crashing process gets restarted in isolation, which is the right model for a system handling thousands of concurrent sessions. The backend abstraction (Mnesia/Redis/SQL/PostgreSQL all interchangeable per module) means you can start with Mnesia for dev and switch to PostgreSQL without rewriting anything. The module system is genuinely extensible — `gen_mod` lets you hot-load modules without restarting the server, and the hook system means you can intercept nearly any event without patching core. Protocol breadth is real: XMPP, MQTT, SIP, WebSocket, BOSH, Matrix gateway — these aren't stubs, they're production-tested.
The config format is YAML but the validation logic is spread across generated Erlang (econf.erl, ejabberd_option.erl) in ways that make error messages cryptic — you'll spend time on IRC decoding 'invalid_option' failures. The mixed Erlang/Elixir codebase (lib/ is Elixir, src/ is Erlang) is an ongoing half-migration that adds cognitive overhead without clear benefit yet. Clustering works but the Mnesia-based clustering has known split-brain edge cases that the docs understate; Redis-based session storage is the right call for anything beyond a single node, but you have to know to ask. The web admin UI is functional but dated — monitoring and diagnostics lean heavily on ejabberdctl commands rather than observable metrics, so integrating with modern observability stacks requires extra work.