Release Highlights:

• Matrix Gateway Gets Room Support
• Multiple Simultaneous Password Types
• Execute API Commands Using XMPP Client

If you are upgrading from a previous version, please check the changes in SQL schemas ; but there aren&apost changes in the configuration, API commands or hooks.

Other contents:

• Macros and Keywords Improvements
• ejabberdctl : new option CTL_OVER_HTTP
• mod_configure : new option access
• Container images: reduce friction, use macros, webadmin port
• ejabberd container image: admin account
• Unix Domain Socket: relative path
• Privileged Entity Bugfixes
• mod_muc_occupantid enabled by default
• mod_http_api : return sorted list elements
• create_room_with_opts API command separators
• New API commands to change Mnesia table storage
• Erlang/OTP and Elixir versions support
• Acknowledgments
• Improvements in ejabberd Business Edition
• ChangeLog
• ejabberd 25.03 download & feedback

Below is a detailed breakdown of the improvements and enhancements:

Matrix Gateway with Room Support

ejabberd can bridge communications to Matrix servers since version 24.02 thanks to mod_matrix_gw , but until now only one-to-one conversations were supported.

Starting with ejabberd 25.03, now you can receive invitations to Matrix rooms and join public Matrix rooms by yourself. The Matrix bridge will be seen a multi-user chat service, as default matrix.yourdomain.net .

For example, once you have enabled the Matrix bridge, if you wish to join the room #ejabberd-matrix-bridge:matrix.org , you can use XMPP MUC protocol to enter the XMPP room: #ejabberd-matrix-bridge%matrix.org@matrix.yourdomain.net

Caveats for this release:

1. Older room protocol version are not supported yet for this release. We only support room protocol version 9, 10 and 11 for now but are planning to add support for older rooms.
2. One to one conversation will need to be restarted empty after server restart as the persistence is not yet implemented.
3. matrix room members are those who kind of subscribed to the room, not necessarily online, and mod_matrix_gw sends a presence for each of them, it depends on whether the xmpp client can handle thousands of muc members.

Note that matrix.org server has also declared an XMPP service in its DNS entries. To communicate with the real Matrix server, you need to block it and add this rule in your firewall on your ejabberd instance:

iptables -A OUTPUT -d lethe.matrix.org -j REJECT

As a reminder, as encrypted payloads are different in Matrix and XMPP, Matrix payload cannot be end-to-end encrypted. In the future, it could be possible to join Matrix encrypted room, with the decryption happening on the server in the bridge, but it will not be end-to-end encrypted anymore. It would just be a convenience for those trusting their XMPP server. Please, let us know if this is an option you would like to see in the future.

Support Multiple Simultaneous Password Types

Faithful to our commitment to help gradually ramp up messaging security, we added the ability to store passwords in multiple formats per account. This feature should help with migration to newer, more secure authentication methods. Using the option auth_stored_password_types , you can specify in what formats the password will be stored in the database. And the stored passwords will be updated each time user changes the password or when the user&aposs client provides the password in a new format using SASL Upgrade Tasks XEP specification.

This option takes a list of values, currently recognized ones are plain , scram_sha1 , scram_sha256 , scram_sha512 . When this options is set, it overrides old options that allowed to specify password storage - auth_scream_hash and auth_password_format .

Update SQL Schema

This release requires SQL database schema update to allow storage of multiple passwords per user. This task can be performed automatically by ejabberd, if your config has enabled update_sql_schema toplevel option.

If you prefer to perform the SQL schema update manually yourself, check the corresponding instructions, depending if your config has enabled new_sql_schema :

• MySQL default schema:

ALTER TABLE users ADD COLUMN type smallint NOT NULL DEFAULT 0;
ALTER TABLE users ALTER COLUMN type DROP DEFAULT;
ALTER TABLE users DROP PRIMARY KEY, ADD PRIMARY KEY (username(191), type);

• MySQL new schema:

ALTER TABLE users ADD COLUMN type smallint NOT NULL DEFAULT 0;
ALTER TABLE users ALTER COLUMN type DROP DEFAULT;
ALTER TABLE users DROP PRIMARY KEY, ADD PRIMARY KEY (server_host(191), username(191), type);

• PostgreSQL default schema:

ALTER TABLE users ADD COLUMN "type" smallint NOT NULL DEFAULT 0;
ALTER TABLE users ALTER COLUMN type DROP DEFAULT;
ALTER TABLE users DROP CONSTRAINT users_pkey, ADD PRIMARY KEY (username, type);

• PostgreSQL new schema:

ALTER TABLE users ADD COLUMN "type" smallint NOT NULL DEFAULT 0;
ALTER TABLE users ALTER COLUMN type DROP DEFAULT;
ALTER TABLE users DROP CONSTRAINT users_pkey, ADD PRIMARY KEY (server_host, username, type);

• SQLite default schema:

ALTER TABLE users ADD COLUMN type smallint NOT NULL DEFAULT 0;
CREATE TABLE new_users (
    username text NOT NULL,
    type smallint NOT NULL,
    password text NOT NULL,
    serverkey text NOT NULL DEFAULT &apos&apos,
    salt text NOT NULL DEFAULT &apos&apos,
    iterationcount integer NOT NULL DEFAULT 0,
    created_at timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY (username, type)
);
INSERT INTO new_users SELECT * FROM users;
DROP TABLE users;
ALTER TABLE new_users RENAME TO users;

• SQLite new schema:

ALTER TABLE users ADD COLUMN type smallint NOT NULL DEFAULT 0;
CREATE TABLE new_users (
    username text NOT NULL,
    server_host text NOT NULL,
    type smallint NOT NULL,
    password text NOT NULL,
    serverkey text NOT NULL DEFAULT &apos&apos,
    salt text NOT NULL DEFAULT &apos&apos,
    iterationcount integer NOT NULL DEFAULT 0,
    created_at timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY (server_host, username, type)
);
INSERT INTO new_users SELECT * FROM users;
DROP TABLE users;
ALTER TABLE new_users RENAME TO users;

New mod_adhoc_api module

You may remember this paragraph from the ejabberd 24.06 release notes :

ejabberd already has around 200 commands to perform many administrative tasks, both to get information about the server and its status, and also to perform operations with side-effects. Those commands have its input and output parameters clearly described, and also documented.

Almost a year ago, ejabberd WebAdmin got support to execute all those 200 API commands ... and now your XMPP client can execute them too!

The new mod_adhoc_api ejabberd module allows to execute all the ejabberd API commands using a XMPP client that supports XEP-0050 Ad-Hoc Commands and XEP-0030 Service Discovery .

Simply add this module to modules , setup api_permissions to grant some account permission to execute some command, or tags of commands, or all commands. Reload the ejabberd configuration and login with your client to that account.

Example configuration:

acl:
  admin:
    user: jan@localhost

api_permissions:
  "adhoc commands":
    from: mod_adhoc_api
    who: admin
    what:
      - "[tag:roster]"
      - "[tag:session]"
      - stats
      - status

modules:
  mod_adhoc_api:
    default_version: 2

Now you can execute the same commands in the command line, using ReST, in the WebAdmin, and in your XMPP client!

This feature has been tested with Gajim, Psi, Psi+ and Tkabber. Conversejs allows to list and execute the commands, but doesn&apost show the result to the user.

Macros and Keyword improvements

Some options in ejabberd supported the possibility to use hard-coded keywords. For example, many modules like mod_vcard could used HOST in their hosts option. Other example is the captcha_cmd toplevel option: it could use VERSION and SEMVER keywords. All this was implemented for each individual option.

Now those keywords are predefined and can be used by any option, and this is implemented in ejabberd core, no need to implement the keyword substitution in each option. The predefined keywords are: HOST , HOME , VERSION and SEMVER .

For example, this configuration is now possible without requiring any specific implementation in the option source code:

ext_api_url: "http://example.org/@VERSION@/api"

Additionally, now you can define your own keywords, similarly to how macros are defined:

define_keyword:
  SCRIPT: "captcha.sh"

captcha_cmd: "tools/@SCRIPT@"

And finally, now macros can be used inside string options, similarly to how keywords can be used:

define_macro:
  SCRIPT: "captcha.sh"

captcha_cmd: "tools/@SCRIPT@"

In summary, now macros and keywords can be defined and used very similarly, so you may be wondering what are their differences. That is explained in detail in the new section Macros and Keywords :

• Macros are implemented by the yconf library: macros cannot be defined inside host_config .

• Keywords are implemented by ejabberd itself: keywords can be defined inside host_config but only for usage in module options. And cannot be used in those toplevel options: hosts , loglevel , version .

ejabberdctl: New option CTL_OVER_HTTP

The ejabberdctl script is useful not only to start and stop ejabberd, it can also execute the ~200 ejabberd API commands inside the running ejabberd node. For this, the script starts another erlang virtual machine and connects it to the already existing one that is running ejabberd.

This connection method is acceptable for performing a few administrative tasks (reload configuration, register an account, etc). However, ejabberdctl is noticeably slow for performing multiple calls, for example to register 1000 accounts. In that case, it is preferable to use other API frontend like mod_http_api or ejabberd_xmlrpc.

And now ejabberdctl can do exactly this! ejabberdctl can be configured to use an HTTP connection to execute the command, which is way faster than starting an erlang node, around 20 times faster.

To enable this feature, first configure in ejabberd.yml :

listen:
  -
    port: "unix:sockets/ctl_over_http.sock"
    module: ejabberd_http
    unix_socket:
      mode: &apos0600&apos
    request_handlers:
      /ctl: ejabberd_ctl

Then enable the CTL_OVER_HTTP option in ejabberdctl.cfg :

CTL_OVER_HTTP=sockets/ctl_over_http.sock

Let&aposs register 100 accounts using the standard method and later using CTL_OVER_HTTP:

$ time for (( i=100 ; i ; i=i-1 )) ; do ejabberdctl register user-standard-$i localhost pass; done
...
real    0m43,929s
user    0m41,878s
sys     0m10,558s

$ time for (( i=100 ; i  ; i=i-1 )) ; do CTL_OVER_HTTP=sockets/ctl_over_http.sock ejabberdctl register user-http-$i localhost pass; done
...
real    0m2,144s
user    0m1,377s
sys     0m0,566s

This feature is enabled by default in the ejabberd container image.

mod_configure: New option access

mod_configure always had support to configure what accounts can access its features: using the configure access rule . The name of that access rule was hard-coded. Now, thanks to the new access option, that can be configured.

Container images: Reduce friction, use macros, WebAdmin port

Several improvements are added in the ejabberd and ecs container images to allow easier migration from one to the other. This also allows to use the same documentation file for both container images, as now there are very few usability differences between both images. Also, a new comparison table in that documentation describes all the differences between both images. The improvements are:

• Adds support for paths from ecs into ejabberd container image, and viceversa: /opt/ linked to /home/ and /usr/local/bin/ linked to /opt/ejabberd/bin/
• Include the ejabberdapi binary also in the ejabberd container image, as does ecs
• Copy captcha scripts to immutable path /usr/local/bin/ for easy calling, and it&aposs included in $PATH
• Copy sql files to /opt/ejabberd/database/sql/
• Copy sql also to /opt/ejabberd/database/ for backwards compatibility with ecs
• Link path to Mnesia spool dir for backwards compatibility
• CONTAINER.md now documents both images, as there are few differences. Also includes a comparison table

Macros are used in the default ejabberd.yml configuration files to define host, admin account and port numbers. This way you can overwrite any of them at starttime using environment variables :

     env:
     - name: PORT_HTTP_TLS
       value: 5444

If you use the podman-desktop or docker-desktop applications, you may have noticed they show a button named "Open Browser". When you click that button, it opens a web browser with / URL and the lowest exposed port number. Now the default ejabberd.yml configuration file listens in port number 1880, the lowest of all, so the "Open Browser" button will open directly the ejabberd WebAdmin page.

ejabberd container image: admin account

In the ejabberd container image, you can grant admin rights to an account using the EJABBERD_MACRO_ADMIN environment variable. Additionally, if you set the REGISTER_ADMIN_PASSWORD environment variable, that account is automatically registered.

Example kubernetes yaml file in podman:

     env:
     - name: EJABBERD_MACRO_ADMIN
       value: administrator@example.org
     - name: REGISTER_ADMIN_PASSWORD
       value: somePass0rd

When those environment variables are not set, admin rights are granted to a random account name in the default ejabberd.yml .

Alternatively, this can be done with the existing CTL_ON_CREATE variable, and then you would need to modify ejabberd.yml accordingly:

     env:
     - name: CTL_ON_CREATE
       value: register administrator example.org somePass0rd

Unix Domain Socket: Relative path

There are several minor improvements in the Unix Domain Socket support, the most notable being support for socket relative path: if the port option is set to "unix:directory/filename" without absolute path, then the directory and file are created in the Mnesia spool directory.

Privileged Entity Bugfixes

Two bugs related to XEP-0356: Privileged Entity have been solved:

Don&apost rewrite "self-addressed" privileged IQs as results

process_privilege_iq is meant to rewrite the result of a privileged IQ into the forwarded form required by XEP-0356 so it can be routed back to the original privileged requester. It checks whether the impersonated JID ( ReplacedJid ) of the original request matches the recipient of the IQ being processed to determine if this is a response to a privileged IQ (assuming it has privileged-IQ metadata attached).

Unfortunately, it doesn&apost check the packet type, and this check will also match a privileged-IQ request that is being sent to the same user that&aposs being impersonated. This results in the request itself being rewritten and forwarded back to the sending component, instead of being processed and having the result send back.

Instead, just check for IQ results (either a regular result or an error), and as long as it is marked as being a response to a privileged-IQ, always rewrite it and forward it to the sending component. There&aposs no circumstance under which we shouldn&apost forward a privileged-IQ response, so we don&apost need to be tricky about checking whether impersonated-user and recipient match.

Accept non-privileged IQs from privileged components

mod_privilege current drops any non-privileged IQ received from a component with an error about it not being properly wrapped. While this might represent a mistake on the part of the component, it means that well- behaved components can no longer send non-privileged IQs (something they normally can do if mod_privilege isn&apost enabled).

Since mod_privilege is intended to grant additional permissions, and not remove existing ones, route non-privileged IQs received from the component normally.

This also removes the special-case for roster-query IQ stanzas, since those are also non-privileged and will be routed along with any other non-privileged IQ packet. This mirrors the privileged-IQ/everything-else structure of the XEP, which defined the handling of privileged IQ stanzas and leaves all other IQ stanzas as defined in their own specs.

To make this clearer, the predicate function now returns distinct results indicating privileged IQs, non-privileged IQs, and error conditions, rather than treating non-privilege IQs as an error that gets handled by routing the packet normally.

mod_muc_occupantid: Enable in the default configuration

mod_muc_occupantid was added to the list of modules enabled in the sample configuration file ejabberd.yml.example .

It&aposs not necessarily obvious that it&aposs required for using certain modern features in group chat, and there&aposs no downside in activating this module.

mod_http_api returns sorted list elements

When mod_http_api returns a list of elements, now those elements are sorted alphabetically. If it is a list of tuples, the tuples are sorted alphabetically by the first element in that tuple.

Notice that the new module mod_adhoc_api uses internally mod_http_api to format the API command arguments and result, this means that mod_adhoc_api benefits from this feature too.

create_room_with_opts API command separators

One of the arguments accepted by the create_room_with_opts API command is a list of room options, expressed as tuples of option name and option value. And some room option values are also list of tuples! This is the case of affiliations and subscribers .

That is not a problem for API frontends that accept structured arguments like mod_http_api and ejabberd_xmlrpc . But this is a problem in ejabberdctl , mod_adhoc_api and WebAdmin, because they don&apost use structured arguments, and instead separate list elements with , and tuple elements with : . In that case, a list of tuples of list of tuples cannot be parsed correctly if all them use the same separators.

Solution: when using the create_room_with_opts command to set affiliations and subscribers options:

• list elements were separated with , and now should be with ;
• tuple elements were separated with : and now should be with =

All the previous separators are still supported for backwards compatibility, but please use the new recommended separators, specially if using ejabberdctl , mod_adhoc_api and WebAdmin.

Let&aposs see side by side the old and the new recommended syntax:

affiliations:owner:user1@localhost,member:user2@localhost
affiliations:owner=user1@localhost;member=user2@localhost

In a practical example, instead of this (which didn&apost work at all):

ejabberdctl \
  create_room_with_opts \
  room_old_separators \
  conference.localhost \
  localhost \
  "persistent:true,affiliations:owner:user1@localhost,member:user2@localhost"

please use:

ejabberdctl \
  create_room_with_opts \
  room_new_separators \
  conference.localhost \
  localhost \
  "persistent:true,affiliations:owner=user1@localhost;member=user2@localhost"

Notice that both the old and new separators are supported by create_room_with_opts . For example, let&aposs use curl to query mod_http_api :

curl -k -X POST -H "Content-type: application/json" \
     "http://localhost:5280/api/create_room_with_opts" \
     -d &apos{"name": "room_old_separators",
          "service": "conference.localhost",
          "host": "localhost",
          "options": [
           {"name": "persistent",
            "value": "true"},
           {"name": "affiliations",
            "value": "owner:user1@localhost,member:user2@localhost"}
          ]
         }&apos

curl -k -X POST -H "Content-type: application/json" \
     "http://localhost:5280/api/create_room_with_opts" \
     -d &apos{"name": "room_new_separators",
          "service": "conference.localhost",
          "host": "localhost",
          "options": [
           {"name": "persistent",
            "value": "true"},
           {"name": "affiliations",
            "value": "owner=user1@localhost;member=user2@localhost"}
          ]
         }&apos

New API commands to change Mnesia table storage

There are two new API commands: mnesia_list_tables and mnesia_table_change_storage .

In fact those commands were already implemented since ejabberd 24.06, but they were tagged as internal as they were only used by WebAdmin. Now they are available for any API frontend, including mod_adhoc_api .

Erlang/OTP and Elixir versions support

Let&aposs review the supported Erlang/OTP versions:

• Erlang/OTP 20.0 up to 24.3 are discouraged: ejabberd 25.03 is the last ejabberd release that fully supports those old erlang versions. If you are still using any of them, please upgrade it before the next ejabberd release.

• Erlang/OTP 25.0 up to 27.3 are the recommended versions. For example Erlang/OTP 27.3 is used in the ejabberd binary installers and ejabberd container image.

• Erlang/OTP 28.0-rc2 is mostly supported, but not yet recommended for production deployments.

Regarding Elixir supported versions:

• Elixir 1.10.3 up to 1.12.3 are discouraged: ejabberd compilation is not tested with those old Elixir versions.

• Elixir 1.13.4 up to 1.18.3 are the recommended versions; for instance Elixir 1.18.3 is used in the ejabberd binary installers and container images.

Acknowledgments

We would like to thank the contributions to the source code, documentation, and translation provided for this release by:

• Dmitriy Bogdanov for fixing documentation typos
• Holger Weiß for improving xmpp , mod_private , installers
• Linus Jahn for fixing mix pam
• Matthew Stickney for fixing mod_privilege
• Pouriya Jahanbakhsh for adding c2s_handle_bind event
• Saarko for ejabberdapi compilation in containers
• Stefan Strigler for ext_mod fixes and other
• Tamil Neram , added and completed a new Tamil translation
• Sketch6580 , updated the Chinese translation
• Максим Горпиніч , updated the Ukrainian translation

And also to all the people contributing in the ejabberd chatroom, issue tracker...

Improvements in ejabberd Business Edition

Customers of the ejabberd Business Edition , in addition to all those improvements and bugfixes, also get the floowing fixes

• Fix mod_unread with s2s messages
• Fix logic detecting duplicate pushes to not trigger pushes on other backends
• Fix issue with connection to Apple push servers for APNS delivery
• Fix server_info commands when a cluster node is not available

ChangeLog

This is a more detailed list of changes in this ejabberd release:

Commands API

• ejabberdctl : New option CTL_OVER_HTTP ( #4340 )
• ejabberd_web_admin : Support commands with tuple arguments
• mod_adhoc_api : New module to execute API Commands using Ad-Hoc Commands ( #4357 )
• mod_http_api : Sort list elements in a command result
• Show warning when registering command with an existing name
• Fix commands unregistration
• change_room_option : Add forgotten support to set enable_hats room option
• change_room_option : Verify room option value before setting it ( #4337 )
• create_room_with_opts : Recommend using ; and = separators
• list_cluster_detailed : Fix crash when a node is down
• mnesia_list_tables : Allow using this internal command
• mnesia_table_change_storage : Allow using this internal command
• status : Separate command result with newline
• update_sql : Fix updating tables created by ejabberd internally
• update_sql : Fix MySQL support

Configuration

• acl : Fix bug matching the acl shared_group: NAME
• define_keyword : New option to define keywords ( #4350 )
• define_macro : Add option to globals() because it&aposs useless inside host_config
• ejabberd.yml.example : Enable mod_muc_occupantid by default
• Add support to use keywords in toplevel, listener and modules
• Show warning also when deprecated listener option is set as disabled ( #4345 )

Container

• Bump versions to Erlang/OTP 27.3 and Elixir 1.18.3
• Add ERL_FLAGS to compile elixir on qemu cross-platform
• Copy files to stable path, add ecs backwards compatibility
• Fix warning about relative workdir
• Improve entrypoint script: register account, or set random
• Link path to Mnesia spool dir for backwards compatibility
• Place sockets/ outside database/
• Use again direct METHOD, qemu got fixed ( #4280 )
• ejabberd.yml.example : Copy main example configuration file
• ejabberd.yml.example : Define and use macros in the default configuration file
• ejabberd.yml.example : Enable CTL_OVER_HTTP by default
• ejabberd.yml.example : Listen for webadmin in a port number lower than any other
• ejabberdapi : Compile during build
• CONTAINER.md : Include documentation for ecs container image

Core and Modules

• ejabberd_auth : Add support for auth_stored_password_types
• ejabberd_router : Don&apost rewrite "self-addressed" privileged IQs as results ( #4348 )
• misc : Fix json version of json_encode_with_kv_list for nested kv lists ( #4338 )
• OAuth: Fix crashes when oauth is feed with invalid jid ( #4355 )
• PubSub: Bubble up db errors in nodetree_tree_sql:set_node
• mod_configure : Add option access to let configure the access name
• mod_mix_pam : Remove Channels roster group of mix channels ( #4297 )
• mod_muc : Document MUC room option vcard_xupdate
• mod_privilege : Accept non-privileged IQs from privileged components ( #4341 )
• mod_private : Improve exception handling
• mod_private : Don&apost warn on conversion errors
• mod_private : Handle invalid PEP-native bookmarks
• mod_private : Don&apost crash on invalid bookmarks
• mod_s2s_bidi : Stop processing other handlers in s2s_in_handle_info ( #4344 )
• mod_s2s_bidi : Fix issue with wrong namespace

Dependencies

• ex_doc : Bump to 0.37.2
• stringprep : Bump to 1.0.31
• provider_asn1 : Bump to 0.4.1
• xmpp Bump to bring fix for ssdp hash calculation
• xmpp Bump to get support for webchat_url ( #3041 )
• xmpp Bump to get XEP-0317 Hats namespaces version 0.2.0
• xmpp Bump to bring SSDP to XEP version 0.4
• yconf Bump to support macro inside string

Development and Testing

• mix.exs : Keep debug info when building dev release
• mix.exs : The ex_doc dependency is only relevant for the edoc Mix environment
• ext_mod : add $libdir/include to include path
• ext_mod : fix greedy include path ( #4359 )
• gen_mod : Support registering commands and hook_subscribe in start/2 result
• c2s_handle_bind : New event in ejabberd_c2s ( #4356 )
• muc_disco_info_extras : New event mod_muc_room useful for mod_muc_webchat_url ( #3041 )
• VSCode: Fix compiling support
• Add tests for config features define_macro and define_keyword
• Allow test to run using ct_run
• Fixes to handle re-running test after update_sql
• Uninstall mod_example when the tests has finished

Documentation

• Add XEPs that are indirectly supported and required by XEP-0479
• Document that XEP-0474 0.4.0 was recently upgraded
• Don&apost use backtick quotes for ejabberd name
• Fix values allowed in db_type of mod_auth_fast documentation
• Reword explanation about ACL names and definitions
• Update moved or broken URLs in documentation

Installers

• Bump Erlang/OTP 27.3 and Elixir 1.18.3
• Bump OpenSSL 3.4.1
• Bump crosstool-NG 1.27.0
• Fix building Termcap and Linux-PAM

Matrix Gateway

• Preserve XMPP message IDs in Matrix rooms
• Better Matrix room topic and room roles to MUC conversion, support room aliases in invites
• Add muc#user element to presences and an initial empty subject
• Fix gen_iq_handler:remove_iq_handler call
• Properly handle IQ requests
• Support Matrix room aliases
• Fix handling of 3PI events

Unix Domain Socket

• Add support for socket relative path
• Use /tmp for temporary socket, as path is restricted to 107 chars
• Handle unix socket when logging remote client
• When stopping listener, delete Unix Domain Socket file
• get_auto_url option: Don&apost build auto URL if port is unix domain socket ( #4345 )

Full Changelog

https://github.com/processone/ejabberd/compare/24.12...25.03

ejabberd 25.03 download & feedback

As usual, the release is tagged in the Git source code repository on GitHub .

The source package and installers are available in ejabberd Downloads page. To check the *.asc signature files, see How to verify ProcessOne downloads integrity .

For convenience, there are alternative download locations like the ejabberd DEB/RPM Packages Repository and the GitHub Release / Tags .

The ecs container image is available in docker.io/ejabberd/ecs and ghcr.io/processone/ecs . The alternative ejabberd container image is available in ghcr.io/processone/ejabberd .

If you consider that you&aposve found a bug, please search or fill a bug report on GitHub Issues .

When I explain to others what I do for a living, I often ask why it is that we are not surprised that one can use a Gmail account to send an email to someone who uses an Outlook account, yet many people fully accept that you can’t send a message to someone using WhatsApp from a Telegram account. We’re not surprised that we can use our phone to set up a call with someone who uses a different brand of phone (or is subscribed to a different provider), yet, for instant messaging, we find ourselves in a world of walled gardens.

Walled gardens refer to ecosystems where companies control access to their platforms and restrict users’ ability to freely interact with other services, creating barriers that prevent open communication and fair competition.

Recognizing this, legislation is slowly being put in place to improve things. The Digital Markets Act (DMA) is a regulatory framework established aimed at ensuring fair competition and improving the functioning of the digital economy. One of its primary objectives is to dismantle these walled gardens and promote messaging interoperability . The DMA seeks to break down barriers and ensure that users have more freedom to engage with different platforms and services, while also enabling interoperability between messaging services.

Meta (of WhatsApp and Facebook fame) is designated as a “gatekeeper” under the DMA. This means that Meta holds a dominant position in the market, controlling key access points that can potentially limit competition or consumer choice. The act outlines various obligations that Meta must comply with to ensure a fairer and more open digital environment.

The XMPP Standards Foundation is now publishing an Open Letter to Meta , to advocate for the adoption of XMPP for messaging interoperability. It argues that Meta’s proposal falls short: Meta’s current approach to interoperability, which relies on restrictive NDAs, proprietary APIs, and centralized control, is not true interoperability.

The XSF argues that Meta should adopt XMPP (eXtensible Messaging and Presence Protocol), a proven, open standard that allows for true federation, decentralization, enhanced privacy, and scalability. XMPP enables seamless communication between different services, akin to email or phone networks. Meta has previously utilized XMPP for WhatsApp and Messenger and has embraced federation for other services, showing that adoption and implementation are not only achievable, but has already been proven to work.

The XSF urges Meta to adopt XMPP for messaging interoperability to comply with the DMA and build a competitive, open messaging ecosystem. The XSF is ready to collaborate and evolve the protocol as needed.

The Ignite Realtime community is based on the strength and flexibility offered by XMPP. Projects like Openfire, Smack, Pade and Spark are direct implementations of the XMPP protocol. We have firsthand witnessed the flexibility, reliability and maturity of the protocol, and have been successfully applying it for years, if not decades. We should therefore fully endorse the XSF’s call to action!

It is time for real interoperability. Let’s make it happen!

You can find the Open Letter of the XSF here: XMPP | Open Letter to Meta: Support True Messaging Interoperability with XMPP

A accompanying technical briefing is also published: XMPP | Detailed technical briefing: The Case for XMPP – Why Meta Must Embrace True Messaging Interoperability

For other release announcements and news follow us on Mastodon or X

1 post - 1 participant

Read full topic

The XMPP Standards Foundation (XSF) has published an open letter to Meta, asking them to support true messaging interoperability using the XMPP protocol.

Meta had previously integrated this protocol, and WhatsApp was actually built on an XMPP-based server , and Meta has previously supported XMPP in Facebook Messenger, as explained in XSF&aposs technical briefing :

A Call to Meta: Build Your Interoperability Stack on XMPP

We at the XMPP Standards Foundation (XSF) urge Meta to build its interoperability framework on top of XMPP federation.

If Threads can implement the Fediverse protocol, there is no reason why Meta cannot do the same with XMPP for Facebook Messenger and WhatsApp—especially since WhatsApp itself was originally built on XMPP.

Why This Matters

We support this initiative as it represents the best approach for genuine interoperability. The European Digital Markets Act (DMA) is specifically designed to break down walled gardens and enforce messaging interoperability across platforms.

XMPP has played a crucial role in shaping the modern messaging landscape , and its success demonstrates that true interoperability is achievable across different platforms and services. It remains the most viable and battle-tested solution to meet interoperability requirements.

As a free and open standard for building and deploying instant messaging systems , XMPP represents the ideal foundation for true messaging interoperability.

Take Action to #FederateTheWorld

Federation is the way to go! Learn more by reading the announcement on the XSF website , where they provide both the open letter and a detailed technical briefing explaining the reasoning behind this call to action.

The XSF, as well as ProcessOne as a long time supporter, is ready to collaborate with Meta and continue to evolve the protocol to meet modern messaging needs.

Why I Looked Beyond Ruby

For years, Ruby was my go-to language for building everything from small prototypes to full-fledged production apps. I fell in love with its elegance and expressiveness and how Ruby on Rails could turn an idea into a working web app in record time. The community—with its focus on kindness and collaboration—only deepened my appreciation. In short, Ruby felt like home.

But as my projects grew in complexity, I started running into bottlenecks. I had apps requiring real-time features, massive concurrency, and high availability. Scaling them with Ruby often meant juggling multiple processes, external services, or creative threading approaches—all of which worked but never felt truly seamless. That’s when I stumbled upon Elixir.

At first glance, Elixir’s syntax reminded me of Ruby. It looked approachable and developer-friendly. But beneath the surface lies a fundamentally different philosophy, heavily influenced by Erlang’s functional model and the concurrency power of the BEAM. Moving from Ruby’s object-oriented approach to Elixir’s functional core was eye-opening. Here’s how I made that transition and why I think it’s worth considering if you’re a fellow Rubyist.

The Mindset Shift: From Objects to Functions

Life Before: Classes and Objects

In Ruby, I approached problems by modeling them as classes, bundling data and behavior together. It was second nature to create an @name instance variable in an initializer, mutate it, and rely on inheritance or modules to share behavior. This style allowed me to write expressive code, but it also hid state changes behind class boundaries.

A New Paradigm in Elixir

Elixir flips that script. Data is immutable, and functions are the stars of the show. Instead of objects, I have modules that hold pure functions. Instead of inheritance, I rely on composition and pattern matching. This required me to unlearn some habits.

• No more hidden state : Every function receives data as input and returns a new copy of that data, so you always know where transformations happen.

No more deep class hierarchies : In Elixir, code sharing happens via modules and function imports rather than extending base classes.

Example: Refactoring a Class into a Module

Ruby

class Greeter
  def initialize(name)
    @name = name
  end

  def greet
    "Hello, #{@name}!"
  end
end

greeter = Greeter.new("Ruby")
puts greeter.greet  # => "Hello, Ruby!"

Elixir

defmodule Greeter do

  def greet(name), do: "Hello, #{name}!"

end
IO.puts Greeter.greet("Elixir")  # => "Hello, Elixir!"

At first, I missed the idea of storing state inside an object, but soon realized how clean and predictable code can be when data and functions are separated. Immutability drastically cut down on side effects, which in turn cut down on surprises.

Concurrency: Learning to Trust Processes

Ruby’s approach

Ruby concurrency typically means spinning up multiple processes or using multi-threading for IO-bound tasks. If you need to queue background jobs, gems like Sidekiq step in. Sidekiq runs in its own OS processes, separate from the main web server, and these processes can run on multiple cores for true parallelism. This approach is straightforward but often demands more memory and additional infrastructure for scaling.

On the plus side, Ruby can handle many simultaneous web requests if they’re primarily IO-bound (such as database queries). Even with the Global Interpreter Lock (GIL) limiting the parallel execution of pure Ruby code, IO tasks can still interleave, allowing a single OS process to serve multiple requests concurrently.

Elixir and the BEAM

Elixir, on the other hand, was built for concurrency from the ground up, thanks to the BEAM virtual machine. It uses lightweight processes (not OS processes or threads) that are cheap to create and easy to isolate. These processes don’t share memory but communicate via message passing—meaning a crash in one process won’t cascade.

This design was a game-changer for me: I no longer needed to layer so many external tools just to achieve scalable concurrency. When the language itself embraces concurrency, writing fault-tolerant, parallel code becomes second nature.

Example: Background Jobs

Ruby ( Sidekiq )

class UserSyncJob
  include Sidekiq::Worker

  # This job fetches user data from an external API
  # and updates the local database.
  def perform(user_id)
    begin
      # 1. Fetch data from external service
      external_data = ExternalApi.get_user_data(user_id)

      # 2. Update local DB (pseudo-code)
      user = User.find(user_id)
      user.update(
        name: external_data[:name],
        email: external_data[:email]
      )

      puts "Successfully synced user #{user_id}"
    rescue => e
      # If something goes wrong, Sidekiq can retry
      # automatically, or we can log the error.
      puts "Error syncing user #{user_id}: #{e.message}"
    end
  end
end

# Trigger the job asynchronously:
UserSyncJob.perform_async(42)

Elixir ( GenServer )

defmodule UserSyncServer do
  use GenServer

  # We'll store a simple state map for demonstration.
  def start_link(_opts) do
    GenServer.start_link(__MODULE__, %{}, name: __MODULE__)
  end

  @impl true
  def init(state), do: {:ok, state}

  # Public API to sync a user:
  def sync_user(user_id) do
    GenServer.call(__MODULE__, {:sync, user_id})
  end

  @impl true
  def handle_call({:sync, user_id}, _from, state) do
    # 1. Fetch data from external API
    case ExternalApi.get_user_data(user_id) do
      {:ok, external_data} ->
        # 2. Update local DB
        user = MyApp.Repo.get(User, user_id)
        MyApp.Repo.update!(User.changeset(user, %{
          name: external_data.name,
          email: external_data.email
        }))
        IO.puts("Successfully synced user #{user_id}")

      {:error, reason} ->
        IO.puts("Error syncing user #{user_id}: #{reason}")
    end

    {:reply, :ok, state}
  end
end

# Start the GenServer somewhere in your supervision tree:
{:ok, _pid} = UserSyncServer.start_link(%{})

# Call the sync_user function to process the job:
UserSyncServer.sync_user(42)

No extra dependencies or external queue systems are needed; Elixir’s native process model just handles it.

Debugging and Fault Tolerance: A New Perspective

Catching Exceptions in Ruby

Error handling in Ruby typically involves begin/rescue blocks. If a critical background job crashes, I might rely on Sidekiq’s retry logic or external monitoring. It worked, but I always worried about a missed exception bringing down crucial parts of the app.

Supervision Trees in Elixir

Elixir uses a concept called a supervision tree , inherited from Erlang’s OTP. Supervisors watch over processes, restarting them automatically if they crash. At first, I found it odd to let a process crash on purpose instead of rescuing the error. But once I saw how quickly the supervisor restarted a failed process, I was hooked.

defmodule Worker do
  use GenServer

  def start_link(_) do
	GenServer.start_link(__MODULE__, %{}, name: __MODULE__)
  end

  def init(_), do: {:ok, %{}}

  def handle_call(:risky, _from, state) do
    raise "Something went wrong"
    {:reply, :ok, state}
  end
end

defmodule SupervisorTree do
  use Supervisor

  def start_link(_) do
    Supervisor.start_link(__MODULE__, :ok, name: __MODULE__)
  end

  def init(:ok) do
    children = [
      {Worker, []}
    ]
    Supervisor.init(children, strategy: :one_for_one)
  end
end

Now, if Worker crashes, the supervisor restarts it automatically. No manual intervention, no separate monitoring service, and no global meltdown.

LiveView: A Game-Changer for Web Development

Why I Loved Rails

Rails made it trivial to spin up CRUD apps, handle migrations, and integrate with robust testing tools like RSpec. But building real-time interactions (like chat or real-time dashboards) could be tricky without relying heavily on JavaScript frameworks or ActionCable .

Phoenix + LiveView

Elixir’s Phoenix framework parallels Rails in many ways: fast bootstrapping, a clear folder structure, and strong conventions. But Phoenix Channels and LiveView push it even further. With LiveView, I can build highly interactive, real-time features that update the DOM via websockets—all without a dedicated front-end framework.

Elixir (Phoenix LiveView)

defmodule ChatLive do
  use Phoenix.LiveView

  def mount(_params, _session, socket) do
    {:ok, assign(socket, :messages, [])}
  end

  def handle_event("send", %{"message" => msg}, socket) do
    {:noreply, update(socket, :messages, fn msgs -> msgs ++ [msg] end)}
  end

  def render(assigns) do
    ~H"""
    <h1>Chat</h1>
    <ul>
      <%= for msg <- @messages do %>
        <li><%= msg %></li>
      <% end %>
    </ul>

    <form phx-submit="send">
      <input type="text" name="message" placeholder="Type something"/>
      <button type="submit">Send</button>
    </form>
    """
  end
end

This simple LiveView code handles real-time chat updates directly from the server, minimising the JavaScript I need to write. The reactive UI is all done through server-rendered updates.

My Takeaways

Embracing Immutability

At first, it was tough to break free from the habit of mutating data in place. But once I got comfortable returning new data structures, my code became far more predictable. I stopped chasing side effects and race conditions.

Let It Crash

Ruby taught me to rescue and recover from every possible error. Elixir taught me to trust the supervisor process. This “let it crash” philosophy took some getting used to, but it simplifies error handling significantly.

Less JavaScript, More Productivity

LiveView drastically cut down my front-end overhead. I don’t need a full client framework for real-time updates. Seeing how quickly I could build a proof-of-concept live chat convinced me that Elixir was onto something big.

Still Love Ruby

None of this means I dislike Ruby. I still think Rails is fantastic for many use cases, especially when you need to prototype something quickly or build a classic CRUD app. Ruby fosters a developer-friendly environment that many languages can only aspire to. I simply reached a point where concurrency and fault tolerance became a top priority—and that’s where Elixir really shines.

Final Advice for Rubyists Curious About Elixir

1. Start Small : Experiment with a tiny service or background job. Don’t rewrite your entire monolith on day one.
2. Get Comfortable with Functional Concepts : Embrace immutability and pattern matching. The mental shift is real, but it pays off.
3. Check Out Phoenix and LiveView : If you’re doing web dev, see how your typical Rails flow translates in Phoenix. And definitely try LiveView.
4. Utilise Existing Ruby Skills : Your understanding of test-driven development, domain modeling, and code readability all carry over—you’ll just write them differently.

Ultimately, if you’re running into the same scaling or concurrency issues I did, Elixir might just be the upgrade you need. It brings a breath of fresh air to large-scale, real-time, and fault-tolerant applications while keeping developer happiness front and center. For me, it was worth the leap, and I haven’t looked back since. If you’re looking for a detailed comparison of Elixir and Ruby, our comprehensive Elixir vs. Ruby guide has you covered.

The post My Journey from Ruby to Elixir: Lessons from a Developer appeared first on Erlang Solutions .

This new version does not have many new features, but it has quite a few breaking changes, which should not impact many people, as well as one important security fix.

Thanks to everyone who contributed with code, issues, suggestions, and reviews!

Welcome to a new major release of the Prosody XMPP server! While the 0.12 branch has served us well for a while now, this release brings a bunch of new features we’ve been busy polishing.

If you’re unfamiliar with Prosody, it’s an open-source project that implements XMPP , an open standard protocol for online communication. Prosody is widely used to power everything from small self-hosted messaging servers to worldwide real-time applications such as Jitsi Meet. It’s part of a large ecosystem of compatible software that you can use for realtime online communication.

Before we begin…

The first thing anyone who has been following the project for a while will notice about this release is the version number.

Long adherents of the cult of 0ver , we finally decided it was time to break away. While, as Shakespeare wrote, “That which we call a rose, by any other name would smell as sweet”, such is true of version numbers. Prosody has been stable and used in production deployments for many years, however the ‘0.x’ version number occasionally misled people to believe otherwise. Apart from shifting the middle component leftwards, nothing has changed.

If you’re really curious, you can read full details in our versioning and support policy .

Our version numbers have also been in step with Debian’s for several versions now. Could this become a thing? Maybe!

Overview of changes

This release brings a wide range of improvements that make Prosody more secure, performant, and easier to manage than ever before. Let’s review the most significant changes that administrators and users can look forward to across a range of different topics.

Security and authentication

Security takes centre stage in this release with several notable improvements. Building on DNSSEC, the addition of full DANE support for server-to-server connections strengthens the trust between federating XMPP servers.

We’ve enhanced our support for channel binding, which is now compatible with TLS 1.3, and we’ve added support for XEP-0440 which helps clients know which channel binding methods the server supports. Channel binding protects your connection from certain machine-in-the-middle attacks, even if the server’s TLS certificate is compromised.

Account management

Administrators now have more granular control over user accounts with the ability to disable and enable them as needed. This can be particularly useful for public servers, where disabling an account can act as a reversible alternative to deletion.

In fact, we now have the ability to set a grace period for deleted accounts to allow restoring an account (within the grace period) in case of accidental deletion.

Roles and permissions

A new role and permissions framework provides more flexible access control. Prosody supplies several built-in roles:

• prosody:operator - for operators of the whole Prosody instance. By default, accounts with this role have full access, including to operations that affect the whole server.
• prosody:admin - the usual role for admins of a specific virtual host (or component). Accounts with this role have permission to manage user accounts and various other aspects of the domain.
• prosody:member - this role is for “normal” user accounts, but specifically those ones which are trusted to some extent by the administrators. Typically accounts that are created through an invitation or through manual provisioning by the admin have this role.
• prosody:registered - this role is also for general user accounts, but is used by default for accounts which registered themselves, e.g. if the server has in-band registration enabled.
• prosody:guest - finally, the “guest” role is used for temporary/anonymous accounts and is also the default for remote JIDs interacting with the server.

For more details about how to use these roles, customize permissions, and more, read our new roles and permissions documentation . You will also find the link there for the development documentation, so module developers can make use of the new system.

Shell commands

Since the earliest releases, the prosodyctl command has been the admin’s primary way of managing and interacting with Prosody. In 0.12 we introduced the prosodyctl shell interface to send administrative commands to Prosody at runtime via a local connection. It has been a big success, and this release significantly extends its capabilities.

• prosodyctl adduser/passwd/deluser commands now use the admin connection to create users, which improves compatibility with various storage and authentication plugins. It also ensures Prosody can instantly respond to changes, such as immediately disconnecting users when their account is deleted.
• Pubsub management commands have been added, to create/configure/delete nodes and items on pubsub and PEP services without needing an XMPP client.
• One of our own favourites as Prosody developers is the new prosodyctl shell watch log command, which lets you stream debug logs in real-time without needing to store them on the filesystem.
• Similarly, there is now prosodyctl shell watch stanzas which lets you monitor stanzas to/from arbitrary JIDs, which is incredibly helpful for developers trying to diagnose various client issues.
• Server-wide announcements can now be sent via the shell, optionally limiting the recipients by online status or role.
• MUC has gained a few new commands for interacting with MUC rooms.

Improved Multi-User Chat (MUC) Management

The MUC system has received a significant overhaul focusing on security and administrative control. By default, room creation is now restricted to local users, providing better control over who can create persistent and public rooms.

Server administrators get new shell commands to inspect room occupants and affiliations, making day-to-day operations more straightforward.

One notable change is that component admins are no longer automatically owners. This can be reverted to the old behaviour with component_admins_as_room_owners = true in the config, but this has known incompatibilities with some clients. Instead, admins can use the shell or ad-hoc commands to gain ownership of rooms when it’s necessary.

Better Network Performance

Network connectivity sees substantial improvements with the implementation of RFC 8305’s “Happy Eyeballs” algorithm, which enhances IPv4/IPv6 dual-stack performance and increases the chance of a successful connection.

Support for TCP Fast Open and deferred accept capabilities (in the server_epoll backend) can potentially reduce connection latency.

The server now also better handles SRV record selection by respecting the ‘weight’ parameter, leading to more efficient connection distribution.

Storage and Performance Improvements

Under the hood, Prosody now offers better query performance with its internal archive stores by generating indexes.

SQLite users now have the option to use LuaSQLite3 instead of LuaDBI, potentially offering better performance and easier deployment.

We’ve also added compatibility with SQLCipher , a fork of SQLite that adds support for encrypted databases.

Configuration Improvements

The configuration system has been modernized to support referencing and appending to previously set options, making complex configurations more manageable.

While direct Lua API usage in the config file is now deprecated, it remains accessible through the new Lua.* namespace for those who need it.

Also new in this release is the ability to reference credentials or other secrets in the configuration file, without storing them in the file itself. It is compatible with the credentials mechanisms supported by systemd , podman and more.

Developer/API changes

The development experience has always been an important part of our project - we set out to make an XMPP server that was very easy to extend and customize. Our developer API has improved with every release. We’ve even had first-time coders write Prosody plugins!

There are too many improvements to list here, but some notable ones:

• Storage access from modules has been simplified with a new ‘keyval+’ store type, which combines the old ‘keyval’ (default) and ‘map’ stores into a single interface. Before this change, many modules had to open the store twice to utilize the two APIs.
• Any module can now replace custom permission handling with Prosody’s own permission framework via the simple module:may() API call.
• Providing new commands for prosodyctl shell is now much easier for module developers.

Backwards compatibility is of course generally preserved, although is_admin() has been deprecated in favour of module:may() . Modules that want to remain compatible with older versions can use mod_compat_roles to enable (limited) permission functionality.

Important Notes for Upgrading

A few breaking changes are worth noting:

• Lua 5.1 support has been removed (this also breaks compatibility with LuaJIT, which is based primarily on Lua 5.1).
• Some MUC default behaviors have changed regarding room creation and admin permissions (see above).

Conclusion

We’re very excited about this release, which represents a significant step forward for Prosody, and contains improvements for virtually every aspect of the server. From enhanced security to better performance and more flexible administration tools, there has never been a better time to deploy Prosody and take control of your realtime communications.

As always, if you have any problems or questions with Prosody or the new release, drop by our community chat !

In our final “Meet the Team” of 2024, we’d like to introduce you to Erik Schön, Managing Director at Erlang Solutions.

Erik shares his journey with Erlang, Elixir, and the BEAM ecosystem, from his work at Ericsson to joining Erlang Solutions in 2019. He also reflects on a key professional highlight in 2024 and looks ahead to his goals for 2025. Erik also reveals his festive traditions, including a Swedish-Japanese twist.

About Erik

So tell us about yourself and your role at Erlang Solutions .

Hello, I’m Erik! I’ve been a big fan of all things Erlang/Elixir/BEAM since the 90s, having seen many successful applications of it when working at Ericsson as an R&D manager for many years.

Since 2019, I’ve been part of the Erlang Solutions Nordic Fjällrävens (“Arctic Foxes”) team based in Stockholm, Sweden. I love helping our customers succeed by delivering faster, safer, and more efficient solutions.

What has been a professional highlight of yours in 2024?

The highlight of 2024 for me was our successful collaboration with BoardClic, a startup that helps its customers with digital board and C-suite level performance evaluations.

We started our collaboration with a comprehensive code-/architecture review of their Elixir codebase, using our 25 years of experience in delivering software for societal infrastructure, including all the do’s and don’ts for future-proof, secure, resilient, and scalable solutions.

Based on this, we boosted their development of new functionality for a strategically important customer—from idea to live, commercial operation. Two of our curious, competent collaborators, with 10+ years of practical, hands-on Elixir/Erlang/BEAM expertise, worked closely with BoardClic on-site to deliver on time and with quality.

What professional and personal achievements are you looking forward to achieving in 2025?

Professionally, I look forward to continued success with our customers. This includes strengthening our long-standing partnerships with TV4, Telia, Ericsson, and Cisco . I’m also excited about the start of new partnerships, both inside and outside the BEAM community where we will continue to deliver more team-based, full-stack, end-to-end solutions.

Personally, I look forward to continuing to talk about my trilogy of books – The Art of Change, The Art of Leadership and The Art of Strategy – in podcasts, meetups and conferences.

Do you have any festive traditions that you’re looking forward to this holiday season?

In Sweden, “ julbord “ (a buffet-style table of small dishes including different kinds of marinated fish like herring and salmon, meatballs, ham, porridge, etc)  is a very important tradition to look forward to. Since my wife is from Japan, we always try to spice things up a bit by including suitable dishes from the Japanese kitchen, like different kinds of sushi.

Final thoughts

As we wrap up our 2024 meet-the-team series, a big thank you to Erik and all the incredible team members we’ve highlighted this year. Their passion, expertise, and dedication continue to drive our success.

Stay tuned for more insights and profiles in the new year as we introduce even more of the talented people who make Erlang Solutions what it is! if you’d like to speak more with our team, please get in touch .

The post Meet the team: Erik Schön appeared first on Erlang Solutions .

Elixir and Haskell are two very powerful, very popular programming languages. However, each has its strengths and weaknesses. Whilst they are similar in a few ways, it’s their differences that make them more suitable for certain tasks.

Here’s an Elixir vs Haskell comparison.

Elixir vs Haskell: a comparison

Core philosophy and design goals

Starting at a top-level view of both languages, the first difference we see is in their fundamental philosophies. Both are functional languages. However, their design choices reflect very different priorities.

Elixir is designed for the real world. It runs on the Erlang VM (BEAM), which was built to handle massive concurrency, distributed systems, and applications that can’t afford downtime, like telecoms, messaging platforms, and web apps.

Elixir prioritises:

• Concurrency-first – It uses lightweight processes and message passing to make scalability easier.
• Fault tolerance – It follows a “Let it crash” philosophy to ensure failures don’t take down the whole system.
• Developer-friendly – Its Ruby-like syntax makes functional programming approachable and readable.

Elixir is not designed for theoretic rigidness—it’s practical. It gives you the tools you need to build robust, scalable systems quickly, even if that means allowing some flexibility in functional integrity.

Haskell, on the other hand, is all about mathematical precision. It enforces a pure programming model. As a result, functions don’t have side effects, and data is immutable by default. This makes it incredibly powerful for provably correct, type-safe programs, but it also comes with a steeper learning curve.

We would like to clarify that Elixir’s data is also immutable, but it does a great job of hiding that fact. You can “reassign” variables and ostensibly change values, but the data underneath remains unchanged. It’s just that Haskell doesn’t allow that at all.

Haskell offers:

• Pure functions – No surprises; given the same input, a function will always return the same output.
• Static typing with strong guarantees – The type system (with Hindley-Milner inference, monads, and algebraic data types) helps catch errors at compile time instead of run time.
• Lazy evaluation – Expressions aren’t evaluated until they’re needed, optimising performance but adding complexity.

Haskell is a language for those who prioritise correctness, mathematical rigour, and abstraction over quick iterations and real-world flexibility. That does not mean it’s slower and inflexible. In fact, experienced Haskellers will use its strong type guarantees to iterate faster, relying on its compiler to catch any mistakes. However, it does contrast with Elixir’s gradual tightening approach. Here, interaction between processes is prioritised, and initial development is quick and flexible, becoming more and more precise as the system evolves.

Typing: dynamic vs static

The next significant difference between Elixir and Haskell is how they handle types.

Elixir is dynamically typed. It doesn’t require explicitly declared variable types; it will infer them at run time. As a result, it’s fast to write and easy to prototype. It allows you to focus on functionality rather than defining types up front.

Of course, there’s a cost attached to this flexibility. If variables are computed at run time, any errors are also only detected then. Mistakes that could have been caught earlier come up when the code is executed. In a large project, this can make debugging a nightmare.

For example:

def add(a, b), do: a + b  

IO.puts add(2, 3)      # Works fine
IO.puts add(2, "three") # Causes a runtime error

In this example, “three” is a string but should’ve been a number and is going to return an error. Since it doesn’t type check at compile time, the error will only be caught when the function runs.

Meanwhile, Haskell uses static typing, which means all variable types are checked at compile time. If there’s a mismatch, the code won’t compile. This is very helpful in preventing many classes of bugs before the code execution.

For example:

add :: Int -> Int -> Int
add a b = a + b

main = print (add 2 3)    -- Works fine
main = print (add 2 "three")  -- Compile-time error

Here, the compiler will immediately catch the type mismatch and prevent runtime errors.

Elixir’s dynamic typing gives you faster iteration and more flexible development. However, it doesn’t rely only on dynamic typing for its robustness. Instead, it follows Erlang’s “Golden Trinity” philosophy, which is:

• Fail fast instead of trying to prevent all possible errors.
• Maintain system stability with supervision trees, which automatically restart failed processes.
• Use the BEAM VM to isolate failures so they don’t crash the system.

Haskell’s static typing, on the other hand, gives you long-term maintainability and correctness up front. It’s particularly useful in high-assurance software projects, where errors must be kept to a minimum before execution.

In comparison, Elixir is a popular choice for high-availability systems. Both are highly reliable, but the former is okay with failure and relies on recovery at runtime, whilst the latter enforces correctness at compile-time.

Concurrency vs parallelism

When considering Haskell vs Elixir, concurrency is one of the biggest differentiators. Both Elixir and Haskell are highly concurrent but take different approaches to it. Elixir is built for carrying out a massive number of processes simultaneously. In contrast, Haskell gives you powerful—but more manual—tools for parallel execution.

Elixir manages effortless concurrency with BEAM. The Erlang VM is designed to handle millions of lightweight processes at the same time with high fault tolerance. These lightweight processes follow the actor model principles and are informally called “actors”, although Elixir doesn’t officially use this term.

Unlike traditional OS threads, these processes are isolated and communicate through message-passing. That means that if one process crashes, BEAM uses supervision trees to restart it automatically while making sure it doesn’t affect the others. This is typical of the ‘let it crash’ philosophy, where failures are expected and handled. There is no expectation to eliminate them entirely.

As a result, concurrency in Elixir is quite straightforward. You don’t need to manage locks, threads, or shared memory. Load balancing is managed efficiently by the BEAM scheduler across CPU cores, with no manual tuning required.

Haskell also supports parallelism and concurrency but it requires more explicit management. To achieve this, it uses several concurrency models, including software transactional memory (STM), lazy evaluations, and explicit parallelism to efficiently utilise multicore processors.

As a result, even though managing parallelism is more hands-on in Haskell, it also leads to some pretty significant performance advantages. For certain workloads, it can be several orders of magnitude faster than Elixir.

Additionally, Cloud Haskell extends Haskell’s concurrency model beyond a single machine. Inspired by Erlang’s message-passing approach, it allows distributed concurrency across multiple nodes, making Haskell viable for large-scale concurrent systems—not just parallel computations.

Scaling and parallelism continue to be one of the headaches of distributed programming. Find out what the others are.
[ Read more ]

Best-fit workloads

Both Haskell and Elixir are highly capable, but the kinds of workloads for which they’re suitable are different. We’ve seen how running on the Erlang VM allows Elixir to be more fault-tolerant and support massive concurrency. It can also run processes along multiple nodes for seamless communication.

Since Elixir can scale horizontally very easily—across multiple machines—it works really well for real-time applications like chat applications, IoT platforms, and financial transaction processing.

Haskell optimises performance with parallel execution and smart use of system resources.  It doesn’t have BEAM’s actor-based concurrency model but its powerful programming features that allow you to make fine-grained use of multi-core processors more than make up for it.

It’s perfect for applications where you need heavy numerical computations, granular control over multi-core execution, and deterministic performance.

So, where Elixir excels at processing high volumes of real-time transactions, Haskell works better for modelling, risk analysis, and regulatory compliance.

Ecosystem and tooling

Both Elixir and Haskell have strong ecosystems, but you must have noticed the theme running through our narrative. Yes, both are designed for different industries and development styles.

Elixir’s ecosystem is practical and industry-focused, with a strong emphasis on web development and real-time applications. It has a growing community and a well-documented standard library, supplemented with production-ready libraries.

Meanwhile, Haskell has a highly dedicated community in academia, finance, human therapeutics, wireless communications and networking, and compiler development. It offers powerful libraries for mathematical modelling, type safety, and parallel computing. However, tooling can sometimes feel less user-friendly compared to mainstream languages.

For web development, Elixir offers the Phoenix framework: a high-performance web framework designed for real-time applications, which comes with built-in support for WebSockets and scalability. It follows Elixir’s functional programming principles but keeps development accessible with a syntax inspired by Ruby on Rails.

Haskell’s Servant framework is a type-safe web framework that leverages the language’s static typing to ensure API correctness. While powerful, it comes with a steeper learning curve due to Haskell’s strict functional nature.

Which one you should choose depends on your project’s requirements. If you’re looking for general web and backend development, Elixir’s Phoenix is the more practical choice. For research-heavy or high-assurance software, Haskell’s ecosystem provides formal guarantees.

Maintainability and refactoring

It’s important to manage technical debt while keeping software maintainable. Part of this is improving quality and future-proofing the code. Elixir’s syntax is clean and intuitive. It offers dynamic typing, meaning you can write code quickly without specifying types. This can make runtime errors harder to track sometimes, but debugging tools like IEx (Interactive Elixir) and Logger make troubleshooting straightforward.

It’s also easier to refactor because of its dynamic nature and process isolation. Since BEAM isolates processes, refactoring can often be done incrementally without disrupting the rest of the system. This is particularly handy in long-running, real-time applications where uptime is crucial.

Haskell, on the other hand, enforces strict type safety and a pure functional model, which makes debugging less frequent but more complex. As we mentioned earlier, the compiler catches most issues before runtime, reducing unexpected behaviour.

However, this strictness means that refactoring in Haskell must be done carefully to maintain type compatibility, module integrity, and scope resolution. Unlike dynamically typed languages, where refactoring is often lightweight, Haskell’s strong type system and module dependencies can make certain refactorings more involved, especially when they affect function signatures or module structures.

Research on Haskell refactoring highlights challenges like name capture, type signature compatibility, and module-level dependency management, which require careful handling to preserve correctness.

Then, there’s pattern matching, which both languages use, but do it differently.

Elixir’s pattern matching is flexible and widely used in function definitions and control flow, making code more readable and expressive.

Haskell’s pattern matching is type-driven and enforced by the compiler, ensuring exhaustiveness but requiring a more upfront design.

So, which of the two is easier to maintain?

Elixir is better suited for fast-moving projects where codebases evolve frequently, thanks to its fault-tolerant design and incremental refactoring capabilities.

Haskell provides stronger guarantees of correctness, making it a better choice for mission-critical applications where stability outweighs development speed.

Compilation speed

One often overlooked difference between Elixir and Haskell is how they handle compilation and code updates.

Elixir benefits from BEAM’s hot code swapping, where updates can be applied without stopping a running system. Additionally, Elixir compiles faster than Haskell because it doesn’t perform extensive type checking at compile time.

This speeds up development cycles, which is what makes Elixir well-suited for projects requiring frequent updates and rapid iteration. However, since BEAM uses Just-In-Time (JIT) compilation, some optimisations happen at runtime rather than during compilation.

Haskell, on the other hand, has a much stricter compilation process. The compiler performs heavy type inference and optimisation, which increases compilation time but results in highly efficient, predictable code.

Learning curve

Elixir is often considered easier to learn than Haskell. Its syntax is clean and approachable, especially if you’re coming from Ruby, Python, or JavaScript. The dynamic typing and friendly error messages make it easy to experiment without getting caught up in strict type constraints.

Haskell, on the other hand, has a notoriously steep learning curve. It requires a shift in mindset, especially for those unfamiliar with pure functional programming, monads, lazy evaluation, and advanced type systems. While it rewards those who stick with it, the initial learning experience can be challenging, even if you’re an experienced developer.

Metaprogramming

Both Elixir and Haskell allow you to write highly flexible code, but they take different approaches.

Elixir provides macros, which you can modify and extend the language at compile time. This makes it easy to generate boilerplate code, create domain-specific languages (DSLs), and build reusable abstractions. However, improper use of macros can make code harder to debug and maintain.

Haskell doesn’t have macros but compensates with powerful type-level programming. Features like type families and higher-kinded types allow you to enforce complex rules at the type level. This enables incredible flexibility, but it also makes the language even harder to learn.

Choosing between the two

As you’ve seen, both Elixir and Haskell can be great, if used correctly in the right circumstances.

If you do choose Elixir, we’ve got a great resource that discusses how Elixir and Erlang—the language that forms its foundation—can help in future-proofing legacy systems. Find out how their reliability and scalability make them great for modernising infrastructures.

[ Read more ]

Want to learn more? Drop the Erlang Solutions team a message.

The post Elixir vs Haskell: What’s the Difference? appeared first on Erlang Solutions .

This is mostly a bugfix release over version 1.9.0 .

The main fix is the rust JID implementation that would behave incorrectly when hashed if the JID contained non-ascii characters. This is an important issue as using a non-ascii JID was mostly broken, and interacting with one failed in interesting ways.