• Pl chevron_right

      Erlang Solutions: Healthcare Blog Round-Up

      news.movim.eu / PlanetJabber • 29 August 2025 • 3 minutes

    Healthcare is moving quickly, and technology is playing a big part in that shift. The way information is collected, the way patients are cared for, and the way hospitals run are all changing.

    Over the past year, our team has written about some of the most important trends shaping the future of healthcare. In this round-up, we bring together three of those articles: remote patient monitoring, big data, and generative AI.

    Maybe you have been following along, or maybe one or two of these slipped past you. Either way, this is a chance to catch up on the ideas that are influencing healthcare right now.

    What is Remote Patient Monitoring?

    Remote Patient Monitoring (RPM) is already changing everyday care. With the help of connected devices, clinicians can see what’s happening with patients at home, step in earlier when something changes, and prevent unnecessary hospital stays.

    What is Remote Patient Monitoring?

    What is Remote Patient Monitoring? sets out how RPM works, the devices that make it possible (from blood pressure monitors to smart inhalers), and why it is now a priority for healthcare leaders. The article shows how RPM is transforming chronic disease management, post-operative recovery, elderly care, and clinical trials, while driving down system costs by up to 40 per cent.

    Digital care models like virtual wards are no longer experiments. They are reshaping the NHS and health systems worldwide, and this guide explains why.

    Understanding Big Data in Healthcare

    Healthcare produces enormous amounts of information every day. Patient records, medical scans, wearables, and research all add to the mix, and the real challenge is turning it into something useful. Done well, big data can improve care, reduce costs, and even speed up medical breakthroughs.

    Big Data in Healthcare

    Understanding Big Data in Healthcare” breaks down the fundamentals, including the three V’s that define it: volume, velocity, and variety. You’ll see how providers are already using data to personalise treatments, predict health trends, and cut readmissions by up to 20 per cent. The article also shows how it can shorten clinical trial times by 30 per cent and reduce costs by as much as 50 per cent.

    But with opportunity comes risk. The average cost of a healthcare data breach now stands at $9.77 million, making security a top priority for every provider. The article looks at the biggest threats, the regulations shaping data use, and how technologies like Erlang, Elixir, and SAFE can help keep information secure and systems reliable.

    How Generative AI is Transforming Healthcare

    With adoption already valued at more than $1.6 billion, generative AI is fast becoming one of the biggest drivers of change in healthcare. The global AI in healthcare market is projected to hit $45.2 billion by 2026, reflecting the scale of its potential to improve patient outcomes, support clinicians, and make systems more efficient.

    How Generative AI is Transforming Healthcare

    In “How Generative AI is Transforming Healthcare” , we look at how it differs from traditional AI and why its flexibility makes it such a powerful tool for the industry. The article explores real-world applications such as personalised treatment plans, predictive analytics, enhanced diagnostics, virtual health assistants, and even accelerating drug discovery.

    It also considers the future of AI in healthcare, including the need to address challenges around privacy, regulation, and patient trust. With the right planning and technologies like Elixir supporting scalable and reliable systems, generative AI could help shape a new era of patient-centred care.

    To conclude

    That wraps up our latest healthcare round-up. We hope this guide helps you cut through the noise and get a clear picture of the trends that matter most right now.

    If something here has sparked your interest, whether it’s the possibilities of remote monitoring, the power of data, or the promise of generative AI, we would love to keep the conversation going. So get in touch .

    Here’s to smarter systems, healthier outcomes, and more confident decision-making in healthcare.

    The post Healthcare Blog Round-Up appeared first on Erlang Solutions .

    • Pl chevron_right

      Erlang Solutions: Healthcare Blog Round-Up

      news.movim.eu / PlanetJabber • 29 August 2025 • 3 minutes

    Healthcare is moving quickly, and technology is playing a big part in that shift. The way information is collected, the way patients are cared for, and the way hospitals run are all changing.

    Over the past year, our team has written about some of the most important trends shaping the future of healthcare. In this round-up, we bring together three of those articles: remote patient monitoring, big data, and generative AI.

    Maybe you have been following along, or maybe one or two of these slipped past you. Either way, this is a chance to catch up on the ideas that are influencing healthcare right now.

    What is Remote Patient Monitoring?

    Remote Patient Monitoring (RPM) is already changing everyday care. With the help of connected devices, clinicians can see what’s happening with patients at home, step in earlier when something changes, and prevent unnecessary hospital stays.

    What is Remote Patient Monitoring?

    What is Remote Patient Monitoring? sets out how RPM works, the devices that make it possible (from blood pressure monitors to smart inhalers), and why it is now a priority for healthcare leaders. The article shows how RPM is transforming chronic disease management, post-operative recovery, elderly care, and clinical trials, while driving down system costs by up to 40 per cent.

    Digital care models like virtual wards are no longer experiments. They are reshaping the NHS and health systems worldwide, and this guide explains why.

    Understanding Big Data in Healthcare

    Healthcare produces enormous amounts of information every day. Patient records, medical scans, wearables, and research all add to the mix, and the real challenge is turning it into something useful. Done well, big data can improve care, reduce costs, and even speed up medical breakthroughs.

    Big Data in Healthcare

    Understanding Big Data in Healthcare” breaks down the fundamentals, including the three V’s that define it: volume, velocity, and variety. You’ll see how providers are already using data to personalise treatments, predict health trends, and cut readmissions by up to 20 per cent. The article also shows how it can shorten clinical trial times by 30 per cent and reduce costs by as much as 50 per cent.

    But with opportunity comes risk. The average cost of a healthcare data breach now stands at $9.77 million, making security a top priority for every provider. The article looks at the biggest threats, the regulations shaping data use, and how technologies like Erlang, Elixir, and SAFE can help keep information secure and systems reliable.

    How Generative AI is Transforming Healthcare

    With adoption already valued at more than $1.6 billion, generative AI is fast becoming one of the biggest drivers of change in healthcare. The global AI in healthcare market is projected to hit $45.2 billion by 2026, reflecting the scale of its potential to improve patient outcomes, support clinicians, and make systems more efficient.

    How Generative AI is Transforming Healthcare

    In “How Generative AI is Transforming Healthcare” , we look at how it differs from traditional AI and why its flexibility makes it such a powerful tool for the industry. The article explores real-world applications such as personalised treatment plans, predictive analytics, enhanced diagnostics, virtual health assistants, and even accelerating drug discovery.

    It also considers the future of AI in healthcare, including the need to address challenges around privacy, regulation, and patient trust. With the right planning and technologies like Elixir supporting scalable and reliable systems, generative AI could help shape a new era of patient-centred care.

    To conclude

    That wraps up our latest healthcare round-up. We hope this guide helps you cut through the noise and get a clear picture of the trends that matter most right now.

    If something here has sparked your interest, whether it’s the possibilities of remote monitoring, the power of data, or the promise of generative AI, we would love to keep the conversation going. So get in touch .

    Here’s to smarter systems, healthier outcomes, and more confident decision-making in healthcare.

    The post Healthcare Blog Round-Up appeared first on Erlang Solutions .

    • Pl chevron_right

      Erlang Solutions: Healthcare Blog Round-Up

      news.movim.eu / PlanetJabber • 29 August 2025 • 3 minutes

    Healthcare is moving quickly, and technology is playing a big part in that shift. The way information is collected, the way patients are cared for, and the way hospitals run are all changing.

    Over the past year, our team has written about some of the most important trends shaping the future of healthcare. In this round-up, we bring together three of those articles: remote patient monitoring, big data, and generative AI.

    Maybe you have been following along, or maybe one or two of these slipped past you. Either way, this is a chance to catch up on the ideas that are influencing healthcare right now.

    What is Remote Patient Monitoring?

    Remote Patient Monitoring (RPM) is already changing everyday care. With the help of connected devices, clinicians can see what’s happening with patients at home, step in earlier when something changes, and prevent unnecessary hospital stays.

    What is Remote Patient Monitoring?

    What is Remote Patient Monitoring? sets out how RPM works, the devices that make it possible (from blood pressure monitors to smart inhalers), and why it is now a priority for healthcare leaders. The article shows how RPM is transforming chronic disease management, post-operative recovery, elderly care, and clinical trials, while driving down system costs by up to 40 per cent.

    Digital care models like virtual wards are no longer experiments. They are reshaping the NHS and health systems worldwide, and this guide explains why.

    Understanding Big Data in Healthcare

    Healthcare produces enormous amounts of information every day. Patient records, medical scans, wearables, and research all add to the mix, and the real challenge is turning it into something useful. Done well, big data can improve care, reduce costs, and even speed up medical breakthroughs.

    Big Data in Healthcare

    Understanding Big Data in Healthcare” breaks down the fundamentals, including the three V’s that define it: volume, velocity, and variety. You’ll see how providers are already using data to personalise treatments, predict health trends, and cut readmissions by up to 20 per cent. The article also shows how it can shorten clinical trial times by 30 per cent and reduce costs by as much as 50 per cent.

    But with opportunity comes risk. The average cost of a healthcare data breach now stands at $9.77 million, making security a top priority for every provider. The article looks at the biggest threats, the regulations shaping data use, and how technologies like Erlang, Elixir, and SAFE can help keep information secure and systems reliable.

    How Generative AI is Transforming Healthcare

    With adoption already valued at more than $1.6 billion, generative AI is fast becoming one of the biggest drivers of change in healthcare. The global AI in healthcare market is projected to hit $45.2 billion by 2026, reflecting the scale of its potential to improve patient outcomes, support clinicians, and make systems more efficient.

    How Generative AI is Transforming Healthcare

    In “How Generative AI is Transforming Healthcare” , we look at how it differs from traditional AI and why its flexibility makes it such a powerful tool for the industry. The article explores real-world applications such as personalised treatment plans, predictive analytics, enhanced diagnostics, virtual health assistants, and even accelerating drug discovery.

    It also considers the future of AI in healthcare, including the need to address challenges around privacy, regulation, and patient trust. With the right planning and technologies like Elixir supporting scalable and reliable systems, generative AI could help shape a new era of patient-centred care.

    To conclude

    That wraps up our latest healthcare round-up. We hope this guide helps you cut through the noise and get a clear picture of the trends that matter most right now.

    If something here has sparked your interest, whether it’s the possibilities of remote monitoring, the power of data, or the promise of generative AI, we would love to keep the conversation going. So get in touch .

    Here’s to smarter systems, healthier outcomes, and more confident decision-making in healthcare.

    The post Healthcare Blog Round-Up appeared first on Erlang Solutions .

    • Pl chevron_right

      ProcessOne: rocket ejabberd 25.08

      news.movim.eu / PlanetJabber • 22 August 2025 • 8 minutes

    🚀 ejabberd 25.08

    Release Highlights:

    This release includes the support for Hydra rooms in our Matrix gateway, which fixes high severity protocol vulnerabilities.

    If you are upgrading from a previous version, there are no changes in SQL schemas, configuration, API commands or hooks.

    Other contents:

    Below is a detailed breakdown of the improvements and enhancements:

    Improvements in Matrix gateway

    The ejabberd Matrix gateway now supports Hydra rooms (Matrix room version 12). This fix some high severity protocol vulnerabilities . The state resolution has been partially rewritten in our gateway.

    A double colon is used for separating a matrix server from a room ID in JID with Hydra rooms.

    Other changes to the matrix gateway:

    • The new option notary_servers of mod_matrix_gw can now be used to set a list of notary servers.
    • Add leave_timeout option to mod_matrix_gw (#4386)
    • Don&apost send empty direct Matrix messages (thanks to snoopcatt) (#4420)

    Fixed ACME in Erlang/OTP 28.0.2

    The ejabberd 25.07 release notes mentioned that Erlang/OTP 28.0.1 was not yet fully supported because there was a problem with ACME support.

    Good news! this problem with ACME is fixed and tested to work when using Erlang/OTP 28.0.2, the latest p1_acme library, and ejabberd 25.08.

    If you are playing with ejabberd and Erlang/OTP 28, please report any problem you find. If you are running ejabberd in production, better stick with Erlang/OTP 27.3, this is the one used in installers and container images.

    New mod_providers to serve XMPP Providers file

    mod_providers is a new module to serve easily XMPP Providers files.

    The standard way to perform this task is to first generate the Provider File , store in the disk with the proper name, and then serve the file using an HTTP server or mod_http_fileserver . And repeat this for each vhost.

    Now this can be replaced with mod_providers, which automatically sets some values according to your configuration. Try configuring ejabberd like:

    listen:
      -
        port: 443
        module: ejabberd_http
        tls: true
        request_handlers:
          /.well-known/xmpp-provider-v2.json: mod_providers
    
    modules:
      mod_providers: {}
    

    Check the URL https://localhost:443/.well-known/xmpp-provider-v2.json , and finetune it by setting a few mod_providers options.

    Improved Unicode support in configuration

    When using non-latin characters in a vhost served by ejabberd, you can write it in the configuration file as unicode, or using the IDNA/punycode. For example:

    hosts:
      - localhost1
      - locälhost2
      - xn--loclhost4-x2a
      - 日本語
    
    host_config:
      "locälhost2":
        modules:
          mod_disco: {}
          mod_muc:
            host: "conference3.@HOST@"
      "xn--loclhost4-x2a":
        modules:
          mod_disco: {}
          mod_muc:
            host: "conference4.@HOST@"
    

    This raises a problem in mod_http_upload if the option put_url contains the @HOST@ keyword. In that case, please use the new predefined keyword HOST_URL_ENCODE .

    This change was also applied to ejabberd.yml.example .

    New option conversejs_plugins to enable OMEMO

    mod_conversejs gets a new option conversejs_plugins that points to additional local files to include as scripts in the homepage.

    Right now this is useful to enable OMEMO encryption .

    Please make sure those files are available in the path specified in conversejs_resources option, in subdirectory plugins/ . For example, copy a file to path /home/ejabberd/conversejs-x.y.z/package/dist/plugins/libsignal-protocol.min.js and then configure like:

    modules:
      mod_conversejs:
        conversejs_resources: "/home/ejabberd/conversejs-x.y.z/package/dist"
        conversejs_plugins: ["libsignal-protocol.min.js"]
    

    If you are using the public Converse client, then you can set \"libsignal\" , which gets replaced with the URL of the public library. For example:

    modules:
      mod_conversejs:
        conversejs_plugins: ["libsignal"]
        websocket_url: "ws://@HOST@:5280/websocket"
    

    Easier erlang node name change with mnesia_change

    ejabberd uses by default the distributed Mnesia database. Being distributed, Mnesia enforces consistency of its file, so it stores the Erlang node name, which may include the hostname of the computer.

    When the erlang node name changes (which may happen when changing the computer name, or moving ejabberd to another computer), then mnesia refused to start with an error message like this:

    2025-08-21 11:06:31.831594+02:00 [critical]
      Erlang node name mismatch:
      I&aposm running in node [ejabberd2@localhost],
      but the mnesia database is owned by [ejabberd@localhost]
    2025-08-21 11:06:31.831782+02:00 [critical]
      Either set ERLANG_NODE in ejabberdctl.cfg
      or change node name in Mnesia
    

    To change the computer hostname in the mnesia database, it was required to follow a tutorial with 10 steps that starts ejabberd a pair of times and runs the mnesia_change_nodename API command.

    Well, now all this tutorial is implemented in one single command for the ejabberdctl command line script. When mnesia refuses to start due to an erlang node name change, it mentions that new solution:

    $ echo "ERLANG_NODE=ejabberd2@localhost" >>_build/relive/conf/ejabberdctl.cfg
    
    $ ejabberdctl live
    2025-08-21 11:06:31.831594+02:00 [critical]
      Erlang node name mismatch:
      I&aposm running in node [ejabberd2@localhost],
      but the mnesia database is owned by [ejabberd@localhost]
    2025-08-21 11:06:31.831782+02:00 [critical]
      Either set ERLANG_NODE in ejabberdctl.cfg
      or change node name in Mnesia by running:
      ejabberdctl mnesia_change ejabberd@localhost
    

    Let&aposs use the new command to change the erlang node name stored in the mnesia database:

    $ ejabberdctl mnesia_change ejabberd@localhost
    
    ==> This changes your mnesia database from node name &aposejabberd@localhost&apos to &aposejabberd2@localhost&apos
    
    ...
    
    ==> Finished, now you can start ejabberd normally
    

    Great! Now ejabberd can start correctly:

    $ ejabberdctl live
    ...
    2025-08-21 11:18:52.154718+02:00 [info]
      ejabberd 25.07.51 is started in the node ejabberd2@localhost in 1.77s
    

    Notice that the command mnesia_change must start and stop ejabberd a pair of times. For that reason, it cannot be implemented as an API command . Instead, it is implemented as an ejabberdctl command directly in the ejabberdctl command line script.

    Colorized interactive log

    When ejabberd starts with an erlang shell using Mix, it prints error lines in a remarkable color: orange for warnings and red for errors. This helps to detect those lines when reading the log interactively.

    Now this is also supported when using Rebar3. To test it, start ejabberd either:

    • ejabberdctl live : to start interactive mode with erlang shell
    • ejabberdctl foreground : to start in server mode with attached log output

    You will see log lines colorized with:

    • green+white for informative log messages
    • grey for debug
    • yellow for warnings
    • red for errors
    • magenta for messages coming from other Erlang libraries (xmpp, OTP library), not ejabberd itself

    Document API Tags in modules

    Many ejabberd modules implement their own API commands , and now the documentation of those modules mention which tags contain their commands.

    See for example at the end of modules mod_muc_admin , mod_private or mod_antispam .

    Unfortunately, many early API commands were implemented in mod_admin_extra , which includes commands related to account management, vcard, roster, private, ... and consequently those are not mentioned in their corresponding modules documentation.

    Acknowledgments

    We would like to thank the contributions to the source code provided for this release by:

    • mod_matrix_gw: Don&apost send empty direct Matrix messages (thanks to snoopcatt) (#4420)
    • Holger Weiß for improvements in the installers, HTTP file upload and mod_register
    • marc0s for the improvement in MUC

    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 following changes:

    New module mod_dedup

    This module removes duplicates of read receipts sent by concurrent sessions of single user, this will prevent both delivery and storage in archive of duplicates.

    Limits in mod_unread queries

    Queries issued to mod_unread can now declare maximum number and age of returned results. This can also be tweaked with new options of that module.

    ChangeLog

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

    API Commands

    • ban_account : Run sm_kick_user event when kicking account ( #4415 )
    • ban_account : No need to change password ( #4415 )
    • mnesia_change : New command in ejabberdctl script that helps changing the mnesia node name

    Configuration

    • Rename auth_password_types_hidden_in_scram1 option to auth_password_types_hidden_in_sasl1
    • econf : If a host in configuration is encoded IDNA, decode it ( #3519 )
    • ejabberd_config : New predefined keyword HOST_URL_ENCODE
    • ejabberd.yml.example : Use HOST_URL_ENCODE to handle case when vhost is non-latin1
    • mod_conversejs : Add option conversejs_plugins ( #4413 )
    • mod_matrix_gw : Add leave_timeout option ( #4386 )

    Documentation and Tests

    • COMPILE.md : Mention dependencies and add link to Docs ( #4431 )
    • ejabberd_doc : Document commands tags for modules
    • CI: bump XMPP-Interop-Testing/xmpp-interop-tests-action ( #4425 )
    • Runtime: Raise the minimum Erlang tested to Erlang/OTP 24

    Installers and Container

    • Bump Erlang/OTP version to 27.3.4.2
    • Bump OpenSSL version to 3.5.2
    • make-binaries : Disable Linux-PAM&aposs logind support

    Core and Modules

    • Bump p1_acme to fix &aposAttributePKCS-10&apos and OTP 28 ( processone/p1_acme#4 )
    • Prevent loops in xml_compress:decode with corrupted data
    • ejabberd_auth_mnesia : Fix issue with filtering duplicates in get_users()
    • ejabberd_listener : Add secret in temporary unix domain socket path ( #4422 )
    • ejabberd_listener : Log error when cannot set definitive unix socket ( #4422 )
    • ejabberd_listener : Try to create provisional socket in final directory ( #4422 )
    • ejabberd_logger : Print log lines colorized in console when using rebar3
    • mod_conversejs : Ensure assets_path ends in / as required by Converse ( #4414 )
    • mod_conversejs : Ensure plugins URL is separated with / ( #4413 )
    • mod_http_upload : Encode URLs into IDNA when showing to XMPP client ( #3519 )
    • mod_matrix_gw : Add support for null values in is_canonical_json ( #4421 )
    • mod_matrix_gw : Don&apost send empty direct Matrix messages ( #4420 )
    • mod_matrix_gw : Matrix gateway updates
    • mod_muc : Report db failures when restoring rooms
    • mod_muc : Unsubscribe users from members-only rooms when expelled ( #4412 )
    • mod_providers : New module to serve easily XMPP Providers files
    • mod_register : Don&apost duplicate welcome subject and message
    • mod_scram_upgrade : Fix format of passwords updates
    • mod_scram_upgrade : Only offer upgrades to methods that aren&apost already stored

    Full Changelog

    https://github.com/processone/ejabberd/compare/25.07...25.08

    ejabberd 25.08 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 .

    • Pl chevron_right

      ProcessOne: rocket ejabberd 25.08

      news.movim.eu / PlanetJabber • 22 August 2025 • 8 minutes

    🚀 ejabberd 25.08

    Release Highlights:

    This release includes the support for Hydra rooms in our Matrix gateway, which fixes high severity protocol vulnerabilities.

    If you are upgrading from a previous version, there are no changes in SQL schemas, configuration, API commands or hooks.

    Other contents:

    Below is a detailed breakdown of the improvements and enhancements:

    Improvements in Matrix gateway

    The ejabberd Matrix gateway now supports Hydra rooms (Matrix room version 12). This fix some high severity protocol vulnerabilities . The state resolution has been partially rewritten in our gateway.

    A double colon is used for separating a matrix server from a room ID in JID with Hydra rooms.

    Other changes to the matrix gateway:

    • The new option notary_servers of mod_matrix_gw can now be used to set a list of notary servers.
    • Add leave_timeout option to mod_matrix_gw (#4386)
    • Don&apost send empty direct Matrix messages (thanks to snoopcatt) (#4420)

    Fixed ACME in Erlang/OTP 28.0.2

    The ejabberd 25.07 release notes mentioned that Erlang/OTP 28.0.1 was not yet fully supported because there was a problem with ACME support.

    Good news! this problem with ACME is fixed and tested to work when using Erlang/OTP 28.0.2, the latest p1_acme library, and ejabberd 25.08.

    If you are playing with ejabberd and Erlang/OTP 28, please report any problem you find. If you are running ejabberd in production, better stick with Erlang/OTP 27.3, this is the one used in installers and container images.

    New mod_providers to serve XMPP Providers file

    mod_providers is a new module to serve easily XMPP Providers files.

    The standard way to perform this task is to first generate the Provider File , store in the disk with the proper name, and then serve the file using an HTTP server or mod_http_fileserver . And repeat this for each vhost.

    Now this can be replaced with mod_providers, which automatically sets some values according to your configuration. Try configuring ejabberd like:

    listen:
      -
        port: 443
        module: ejabberd_http
        tls: true
        request_handlers:
          /.well-known/xmpp-provider-v2.json: mod_providers
    
    modules:
      mod_providers: {}
    

    Check the URL https://localhost:443/.well-known/xmpp-provider-v2.json , and finetune it by setting a few mod_providers options.

    Improved Unicode support in configuration

    When using non-latin characters in a vhost served by ejabberd, you can write it in the configuration file as unicode, or using the IDNA/punycode. For example:

    hosts:
      - localhost1
      - locälhost2
      - xn--loclhost4-x2a
      - 日本語
    
    host_config:
      "locälhost2":
        modules:
          mod_disco: {}
          mod_muc:
            host: "conference3.@HOST@"
      "xn--loclhost4-x2a":
        modules:
          mod_disco: {}
          mod_muc:
            host: "conference4.@HOST@"
    

    This raises a problem in mod_http_upload if the option put_url contains the @HOST@ keyword. In that case, please use the new predefined keyword HOST_URL_ENCODE .

    This change was also applied to ejabberd.yml.example .

    New option conversejs_plugins to enable OMEMO

    mod_conversejs gets a new option conversejs_plugins that points to additional local files to include as scripts in the homepage.

    Right now this is useful to enable OMEMO encryption .

    Please make sure those files are available in the path specified in conversejs_resources option, in subdirectory plugins/ . For example, copy a file to path /home/ejabberd/conversejs-x.y.z/package/dist/plugins/libsignal-protocol.min.js and then configure like:

    modules:
      mod_conversejs:
        conversejs_resources: "/home/ejabberd/conversejs-x.y.z/package/dist"
        conversejs_plugins: ["libsignal-protocol.min.js"]
    

    If you are using the public Converse client, then you can set \"libsignal\" , which gets replaced with the URL of the public library. For example:

    modules:
      mod_conversejs:
        conversejs_plugins: ["libsignal"]
        websocket_url: "ws://@HOST@:5280/websocket"
    

    Easier erlang node name change with mnesia_change

    ejabberd uses by default the distributed Mnesia database. Being distributed, Mnesia enforces consistency of its file, so it stores the Erlang node name, which may include the hostname of the computer.

    When the erlang node name changes (which may happen when changing the computer name, or moving ejabberd to another computer), then mnesia refused to start with an error message like this:

    2025-08-21 11:06:31.831594+02:00 [critical]
      Erlang node name mismatch:
      I&aposm running in node [ejabberd2@localhost],
      but the mnesia database is owned by [ejabberd@localhost]
    2025-08-21 11:06:31.831782+02:00 [critical]
      Either set ERLANG_NODE in ejabberdctl.cfg
      or change node name in Mnesia
    

    To change the computer hostname in the mnesia database, it was required to follow a tutorial with 10 steps that starts ejabberd a pair of times and runs the mnesia_change_nodename API command.

    Well, now all this tutorial is implemented in one single command for the ejabberdctl command line script. When mnesia refuses to start due to an erlang node name change, it mentions that new solution:

    $ echo "ERLANG_NODE=ejabberd2@localhost" >>_build/relive/conf/ejabberdctl.cfg
    
    $ ejabberdctl live
    2025-08-21 11:06:31.831594+02:00 [critical]
      Erlang node name mismatch:
      I&aposm running in node [ejabberd2@localhost],
      but the mnesia database is owned by [ejabberd@localhost]
    2025-08-21 11:06:31.831782+02:00 [critical]
      Either set ERLANG_NODE in ejabberdctl.cfg
      or change node name in Mnesia by running:
      ejabberdctl mnesia_change ejabberd@localhost
    

    Let&aposs use the new command to change the erlang node name stored in the mnesia database:

    $ ejabberdctl mnesia_change ejabberd@localhost
    
    ==> This changes your mnesia database from node name &aposejabberd@localhost&apos to &aposejabberd2@localhost&apos
    
    ...
    
    ==> Finished, now you can start ejabberd normally
    

    Great! Now ejabberd can start correctly:

    $ ejabberdctl live
    ...
    2025-08-21 11:18:52.154718+02:00 [info]
      ejabberd 25.07.51 is started in the node ejabberd2@localhost in 1.77s
    

    Notice that the command mnesia_change must start and stop ejabberd a pair of times. For that reason, it cannot be implemented as an API command . Instead, it is implemented as an ejabberdctl command directly in the ejabberdctl command line script.

    Colorized interactive log

    When ejabberd starts with an erlang shell using Mix, it prints error lines in a remarkable color: orange for warnings and red for errors. This helps to detect those lines when reading the log interactively.

    Now this is also supported when using Rebar3. To test it, start ejabberd either:

    • ejabberdctl live : to start interactive mode with erlang shell
    • ejabberdctl foreground : to start in server mode with attached log output

    You will see log lines colorized with:

    • green+white for informative log messages
    • grey for debug
    • yellow for warnings
    • red for errors
    • magenta for messages coming from other Erlang libraries (xmpp, OTP library), not ejabberd itself

    Document API Tags in modules

    Many ejabberd modules implement their own API commands , and now the documentation of those modules mention which tags contain their commands.

    See for example at the end of modules mod_muc_admin , mod_private or mod_antispam .

    Unfortunately, many early API commands were implemented in mod_admin_extra , which includes commands related to account management, vcard, roster, private, ... and consequently those are not mentioned in their corresponding modules documentation.

    Acknowledgments

    We would like to thank the contributions to the source code provided for this release by:

    • mod_matrix_gw: Don&apost send empty direct Matrix messages (thanks to snoopcatt) (#4420)
    • Holger Weiß for improvements in the installers, HTTP file upload and mod_register
    • marc0s for the improvement in MUC

    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 following changes:

    New module mod_dedup

    This module removes duplicates of read receipts sent by concurrent sessions of single user, this will prevent both delivery and storage in archive of duplicates.

    Limits in mod_unread queries

    Queries issued to mod_unread can now declare maximum number and age of returned results. This can also be tweaked with new options of that module.

    ChangeLog

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

    API Commands

    • ban_account : Run sm_kick_user event when kicking account ( #4415 )
    • ban_account : No need to change password ( #4415 )
    • mnesia_change : New command in ejabberdctl script that helps changing the mnesia node name

    Configuration

    • Rename auth_password_types_hidden_in_scram1 option to auth_password_types_hidden_in_sasl1
    • econf : If a host in configuration is encoded IDNA, decode it ( #3519 )
    • ejabberd_config : New predefined keyword HOST_URL_ENCODE
    • ejabberd.yml.example : Use HOST_URL_ENCODE to handle case when vhost is non-latin1
    • mod_conversejs : Add option conversejs_plugins ( #4413 )
    • mod_matrix_gw : Add leave_timeout option ( #4386 )

    Documentation and Tests

    • COMPILE.md : Mention dependencies and add link to Docs ( #4431 )
    • ejabberd_doc : Document commands tags for modules
    • CI: bump XMPP-Interop-Testing/xmpp-interop-tests-action ( #4425 )
    • Runtime: Raise the minimum Erlang tested to Erlang/OTP 24

    Installers and Container

    • Bump Erlang/OTP version to 27.3.4.2
    • Bump OpenSSL version to 3.5.2
    • make-binaries : Disable Linux-PAM&aposs logind support

    Core and Modules

    • Bump p1_acme to fix &aposAttributePKCS-10&apos and OTP 28 ( processone/p1_acme#4 )
    • Prevent loops in xml_compress:decode with corrupted data
    • ejabberd_auth_mnesia : Fix issue with filtering duplicates in get_users()
    • ejabberd_listener : Add secret in temporary unix domain socket path ( #4422 )
    • ejabberd_listener : Log error when cannot set definitive unix socket ( #4422 )
    • ejabberd_listener : Try to create provisional socket in final directory ( #4422 )
    • ejabberd_logger : Print log lines colorized in console when using rebar3
    • mod_conversejs : Ensure assets_path ends in / as required by Converse ( #4414 )
    • mod_conversejs : Ensure plugins URL is separated with / ( #4413 )
    • mod_http_upload : Encode URLs into IDNA when showing to XMPP client ( #3519 )
    • mod_matrix_gw : Add support for null values in is_canonical_json ( #4421 )
    • mod_matrix_gw : Don&apost send empty direct Matrix messages ( #4420 )
    • mod_matrix_gw : Matrix gateway updates
    • mod_muc : Report db failures when restoring rooms
    • mod_muc : Unsubscribe users from members-only rooms when expelled ( #4412 )
    • mod_providers : New module to serve easily XMPP Providers files
    • mod_register : Don&apost duplicate welcome subject and message
    • mod_scram_upgrade : Fix format of passwords updates
    • mod_scram_upgrade : Only offer upgrades to methods that aren&apost already stored

    Full Changelog

    https://github.com/processone/ejabberd/compare/25.07...25.08

    ejabberd 25.08 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 .

    • Pl chevron_right

      ProcessOne: rocket ejabberd 25.08

      news.movim.eu / PlanetJabber • 22 August 2025 • 8 minutes

    🚀 ejabberd 25.08

    Release Highlights:

    This release includes the support for Hydra rooms in our Matrix gateway, which fixes high severity protocol vulnerabilities.

    If you are upgrading from a previous version, there are no changes in SQL schemas, configuration, API commands or hooks.

    Other contents:

    Below is a detailed breakdown of the improvements and enhancements:

    Improvements in Matrix gateway

    The ejabberd Matrix gateway now supports Hydra rooms (Matrix room version 12). This fix some high severity protocol vulnerabilities . The state resolution has been partially rewritten in our gateway.

    A double colon is used for separating a matrix server from a room ID in JID with Hydra rooms.

    Other changes to the matrix gateway:

    • The new option notary_servers of mod_matrix_gw can now be used to set a list of notary servers.
    • Add leave_timeout option to mod_matrix_gw (#4386)
    • Don&apost send empty direct Matrix messages (thanks to snoopcatt) (#4420)

    Fixed ACME in Erlang/OTP 28.0.2

    The ejabberd 25.07 release notes mentioned that Erlang/OTP 28.0.1 was not yet fully supported because there was a problem with ACME support.

    Good news! this problem with ACME is fixed and tested to work when using Erlang/OTP 28.0.2, the latest p1_acme library, and ejabberd 25.08.

    If you are playing with ejabberd and Erlang/OTP 28, please report any problem you find. If you are running ejabberd in production, better stick with Erlang/OTP 27.3, this is the one used in installers and container images.

    New mod_providers to serve XMPP Providers file

    mod_providers is a new module to serve easily XMPP Providers files.

    The standard way to perform this task is to first generate the Provider File , store in the disk with the proper name, and then serve the file using an HTTP server or mod_http_fileserver . And repeat this for each vhost.

    Now this can be replaced with mod_providers, which automatically sets some values according to your configuration. Try configuring ejabberd like:

    listen:
      -
        port: 443
        module: ejabberd_http
        tls: true
        request_handlers:
          /.well-known/xmpp-provider-v2.json: mod_providers
    
    modules:
      mod_providers: {}
    

    Check the URL https://localhost:443/.well-known/xmpp-provider-v2.json , and finetune it by setting a few mod_providers options.

    Improved Unicode support in configuration

    When using non-latin characters in a vhost served by ejabberd, you can write it in the configuration file as unicode, or using the IDNA/punycode. For example:

    hosts:
      - localhost1
      - locälhost2
      - xn--loclhost4-x2a
      - 日本語
    
    host_config:
      "locälhost2":
        modules:
          mod_disco: {}
          mod_muc:
            host: "conference3.@HOST@"
      "xn--loclhost4-x2a":
        modules:
          mod_disco: {}
          mod_muc:
            host: "conference4.@HOST@"
    

    This raises a problem in mod_http_upload if the option put_url contains the @HOST@ keyword. In that case, please use the new predefined keyword HOST_URL_ENCODE .

    This change was also applied to ejabberd.yml.example .

    New option conversejs_plugins to enable OMEMO

    mod_conversejs gets a new option conversejs_plugins that points to additional local files to include as scripts in the homepage.

    Right now this is useful to enable OMEMO encryption .

    Please make sure those files are available in the path specified in conversejs_resources option, in subdirectory plugins/ . For example, copy a file to path /home/ejabberd/conversejs-x.y.z/package/dist/plugins/libsignal-protocol.min.js and then configure like:

    modules:
      mod_conversejs:
        conversejs_resources: "/home/ejabberd/conversejs-x.y.z/package/dist"
        conversejs_plugins: ["libsignal-protocol.min.js"]
    

    If you are using the public Converse client, then you can set \"libsignal\" , which gets replaced with the URL of the public library. For example:

    modules:
      mod_conversejs:
        conversejs_plugins: ["libsignal"]
        websocket_url: "ws://@HOST@:5280/websocket"
    

    Easier erlang node name change with mnesia_change

    ejabberd uses by default the distributed Mnesia database. Being distributed, Mnesia enforces consistency of its file, so it stores the Erlang node name, which may include the hostname of the computer.

    When the erlang node name changes (which may happen when changing the computer name, or moving ejabberd to another computer), then mnesia refused to start with an error message like this:

    2025-08-21 11:06:31.831594+02:00 [critical]
      Erlang node name mismatch:
      I&aposm running in node [ejabberd2@localhost],
      but the mnesia database is owned by [ejabberd@localhost]
    2025-08-21 11:06:31.831782+02:00 [critical]
      Either set ERLANG_NODE in ejabberdctl.cfg
      or change node name in Mnesia
    

    To change the computer hostname in the mnesia database, it was required to follow a tutorial with 10 steps that starts ejabberd a pair of times and runs the mnesia_change_nodename API command.

    Well, now all this tutorial is implemented in one single command for the ejabberdctl command line script. When mnesia refuses to start due to an erlang node name change, it mentions that new solution:

    $ echo "ERLANG_NODE=ejabberd2@localhost" >>_build/relive/conf/ejabberdctl.cfg
    
    $ ejabberdctl live
    2025-08-21 11:06:31.831594+02:00 [critical]
      Erlang node name mismatch:
      I&aposm running in node [ejabberd2@localhost],
      but the mnesia database is owned by [ejabberd@localhost]
    2025-08-21 11:06:31.831782+02:00 [critical]
      Either set ERLANG_NODE in ejabberdctl.cfg
      or change node name in Mnesia by running:
      ejabberdctl mnesia_change ejabberd@localhost
    

    Let&aposs use the new command to change the erlang node name stored in the mnesia database:

    $ ejabberdctl mnesia_change ejabberd@localhost
    
    ==> This changes your mnesia database from node name &aposejabberd@localhost&apos to &aposejabberd2@localhost&apos
    
    ...
    
    ==> Finished, now you can start ejabberd normally
    

    Great! Now ejabberd can start correctly:

    $ ejabberdctl live
    ...
    2025-08-21 11:18:52.154718+02:00 [info]
      ejabberd 25.07.51 is started in the node ejabberd2@localhost in 1.77s
    

    Notice that the command mnesia_change must start and stop ejabberd a pair of times. For that reason, it cannot be implemented as an API command . Instead, it is implemented as an ejabberdctl command directly in the ejabberdctl command line script.

    Colorized interactive log

    When ejabberd starts with an erlang shell using Mix, it prints error lines in a remarkable color: orange for warnings and red for errors. This helps to detect those lines when reading the log interactively.

    Now this is also supported when using Rebar3. To test it, start ejabberd either:

    • ejabberdctl live : to start interactive mode with erlang shell
    • ejabberdctl foreground : to start in server mode with attached log output

    You will see log lines colorized with:

    • green+white for informative log messages
    • grey for debug
    • yellow for warnings
    • red for errors
    • magenta for messages coming from other Erlang libraries (xmpp, OTP library), not ejabberd itself

    Document API Tags in modules

    Many ejabberd modules implement their own API commands , and now the documentation of those modules mention which tags contain their commands.

    See for example at the end of modules mod_muc_admin , mod_private or mod_antispam .

    Unfortunately, many early API commands were implemented in mod_admin_extra , which includes commands related to account management, vcard, roster, private, ... and consequently those are not mentioned in their corresponding modules documentation.

    Acknowledgments

    We would like to thank the contributions to the source code provided for this release by:

    • mod_matrix_gw: Don&apost send empty direct Matrix messages (thanks to snoopcatt) (#4420)
    • Holger Weiß for improvements in the installers, HTTP file upload and mod_register
    • marc0s for the improvement in MUC

    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 following changes:

    New module mod_dedup

    This module removes duplicates of read receipts sent by concurrent sessions of single user, this will prevent both delivery and storage in archive of duplicates.

    Limits in mod_unread queries

    Queries issued to mod_unread can now declare maximum number and age of returned results. This can also be tweaked with new options of that module.

    ChangeLog

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

    API Commands

    • ban_account : Run sm_kick_user event when kicking account ( #4415 )
    • ban_account : No need to change password ( #4415 )
    • mnesia_change : New command in ejabberdctl script that helps changing the mnesia node name

    Configuration

    • Rename auth_password_types_hidden_in_scram1 option to auth_password_types_hidden_in_sasl1
    • econf : If a host in configuration is encoded IDNA, decode it ( #3519 )
    • ejabberd_config : New predefined keyword HOST_URL_ENCODE
    • ejabberd.yml.example : Use HOST_URL_ENCODE to handle case when vhost is non-latin1
    • mod_conversejs : Add option conversejs_plugins ( #4413 )
    • mod_matrix_gw : Add leave_timeout option ( #4386 )

    Documentation and Tests

    • COMPILE.md : Mention dependencies and add link to Docs ( #4431 )
    • ejabberd_doc : Document commands tags for modules
    • CI: bump XMPP-Interop-Testing/xmpp-interop-tests-action ( #4425 )
    • Runtime: Raise the minimum Erlang tested to Erlang/OTP 24

    Installers and Container

    • Bump Erlang/OTP version to 27.3.4.2
    • Bump OpenSSL version to 3.5.2
    • make-binaries : Disable Linux-PAM&aposs logind support

    Core and Modules

    • Bump p1_acme to fix &aposAttributePKCS-10&apos and OTP 28 ( processone/p1_acme#4 )
    • Prevent loops in xml_compress:decode with corrupted data
    • ejabberd_auth_mnesia : Fix issue with filtering duplicates in get_users()
    • ejabberd_listener : Add secret in temporary unix domain socket path ( #4422 )
    • ejabberd_listener : Log error when cannot set definitive unix socket ( #4422 )
    • ejabberd_listener : Try to create provisional socket in final directory ( #4422 )
    • ejabberd_logger : Print log lines colorized in console when using rebar3
    • mod_conversejs : Ensure assets_path ends in / as required by Converse ( #4414 )
    • mod_conversejs : Ensure plugins URL is separated with / ( #4413 )
    • mod_http_upload : Encode URLs into IDNA when showing to XMPP client ( #3519 )
    • mod_matrix_gw : Add support for null values in is_canonical_json ( #4421 )
    • mod_matrix_gw : Don&apost send empty direct Matrix messages ( #4420 )
    • mod_matrix_gw : Matrix gateway updates
    • mod_muc : Report db failures when restoring rooms
    • mod_muc : Unsubscribe users from members-only rooms when expelled ( #4412 )
    • mod_providers : New module to serve easily XMPP Providers files
    • mod_register : Don&apost duplicate welcome subject and message
    • mod_scram_upgrade : Fix format of passwords updates
    • mod_scram_upgrade : Only offer upgrades to methods that aren&apost already stored

    Full Changelog

    https://github.com/processone/ejabberd/compare/25.07...25.08

    ejabberd 25.08 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 .

    • Pl chevron_right

      Erlang Solutions: MongooseIM 6.4: Simplified and Unified

      news.movim.eu / PlanetJabber • 21 August 2025 • 7 minutes

    MongooseIM is a scalable and efficient instant messaging server. With the latest release 6.4.0, it has become more powerful yet easier to use and maintain. Thanks to the internal unification of listeners and connection handling, the configuration is easier and more intuitive, while numerous new options are supported.

    New features include support for TLS 1.3 with optional channel binding for improved security, single round-trip authentication with FAST (which can be even faster with 0-RTT or more secure with channel binding), reduced start-up time and many other improvements and bug fixes. Let’s take a deeper look at some of the most important improvements.

    Reworked XMPP interfaces

    MongooseIM uses the open, proven, extensible and constantly evolving XMPP protocol, which is an excellent choice when it comes to instant messaging. To communicate with other XMPP entities, the server uses three main types of interfaces, listed in the table below.

    XMPP Interface Purpose Connection type Reworked in version
    C2S (client-to-server) Accept connections from XMPP clients inbound 6.1.0 – 6.4.0
    S2S (server-to-server) Federate with other XMPP servers inbound/outbound 6.4.0 (latest)
    Component Accept connections from external components inbound

    The C2S interface was reworked and improved already in version 6.1.0 (see the blog post ), making it more modern, organised and extensible. In version 6.4.0, this trend is continued by reworking the S2S and component interfaces while unifying the whole connection handling logic.

    Simplified, unified and more complete

    Connection accepting and handling was simplified and unified in multiple ways, allowing the addition of new features along the way. All connections are now accepted by ranch , a state-of-the-art socket acceptor pool for Erlang. Modern gen_statem behaviour is then used to handle open connections using state machines. These changes allowed for improved handling of various corner cases, removing unexpected limitations and mishandled error conditions. There is also improved separation of concerns, resulting in easier extensibility and configurability.

    Another unified and improved system aspect is the TLS encryption . The legacy fast_tls library is now fully replaced with the Erlang implementation, resulting in much more straightforward configuration and implementation without a drop in performance (as evidenced by rigorous load tests). This change made it possible to fill in some gaps in functionality, such as the support for channel binding as required for TLS 1.3 (see RFC 9266 for details). Additionally, TLS is now supported for component connections. Moreover, CA certificates can be provided by the OS, reducing the need for manual certificate provisioning. As a result of these changes, your MongooseIM installation will be more secure and robust.

    All these changes are reflected in the TOML configuration file. As an example, the following snippet presents the configuration of S2S and component connections:

    [[listen.component]]
      port = 8190
      shaper = "fast"
      ip_address = "127.0.0.1"
      password = "secret"
      tls.certfile = "priv/ssl/cert.pem"
      tls.keyfile = "priv/ssl/key.pem"
    
    
    [[listen.s2s]]
      port = 5269
      shaper = "fast"
      tls.certfile = "priv/ssl/cert.pem"
      tls.keyfile = "priv/ssl/key.pem"
    
    
    [s2s]
      default_policy = "allow"
    
      [s2s.outgoing]
        port = 5269
        shaper = "fast"
        tls.certfile = "priv/ssl/cert.pem"
        tls.keyfile = "priv/ssl/key.pem"
    
    

    When compared with the previous version of MongooseIM, there are the following improvements:

    • Components can benefit from TLS connections.
    • S2S options are separate for the incoming ( listen.s2s ) and outgoing ( s2s.outgoing ) connections. Common options are placed directly in the s2s section (e.g. default_policy ).
    • Traffic shapers are configured the same way for all types of connections, and are always referenced by their names.
    • S2S outgoing connections can have traffic shaping enabled.
    • All TLS options follow the same pattern throughout the configuration file. This also affects multiple options that were omitted from this example for simplicity.

    Another improved layer is the instrumentation . Most changes affect XMPP traffic events – they are summarised in the table below:

    Events in version 6.3.* Events in version 6.4.0 Measurements
    Names Labels
    c2s_element_inc
    2s_element_out
    xmpp_element_in
    xmpp_element_out
    connection_type
    (c2s, s2s, component)
    host_type
    (if known)
    count
    stanza_count
    message_count
    iq_count(...)
    c2s_xmpp_element_size_in
    c2s_xmpp_element_size_out
    s2s_xmpp_element_size_in
    s2s_xmpp_element_size_out
    component_xmpp_element_size_in
    component_xmpp_element_size_out
    byte_size
    c2s_tcp_data_in
    c2s_tcp_data_out
    s2s_tcp_data_in
    s2s_tcp_data_out
    component_tcp_data_in component_tcp_data_out
    tcp_data_in
    tcp_data_out
    connection_type
    (c2s, s2s, component)
    c2s_tls_data_in
    c2s_tls_data_out
    s2s_tls_data_in
    s2s_tls_data_out
    component_tls_data_in component_tls_data_out
    tls_data_in
    tls_data_out

    We can see that there are fewer event names now, and they are more concise, making them easier to remember and reason about. This was possible due to the use of labels like connection_type and host_type , and actually, the event coverage got improved – see the element_in and element_out events, which now cover s2s and component connections. Also, the events are emitted more consistently. For incoming data, there is always one event emitted as soon as an XML element (most often a stanza) is parsed. For outgoing data, there is always one event emitted just before sending an XML element out. As a result, the metrics are consistent with actual network traffic.

    Another addition is the auth_failed event for s2s and component connections. For more information, such as the translation of event names and measurements to actual metric names, see the documentation on metrics . Our blog post about release 6.3.0 can also give you more details about the instrumentation layer and its integration with Prometheus.

    SASL 2, Bind 2, FAST

    Over the past few releases, we have been implementing extensions, speeding up the XMPP stream negotiation and authentication:

    • XEP-0388 : Extensible SASL Profile (SASL2) allows a client to authenticate, resume its session and more in one round-trip.
    • XEP-0386 : Bind 2 allows a client to bind the resource and enable selected extensions (SM, carbons, CSI) as part of SASL2.
    • XEP-0484 : FAST allows a client to authenticate with a token as a part of SASL2. According to the specification, this is a token-based method for streamlining authentication in XMPP, enabling fully authenticated stream establishment within a single round-trip.

    As an example, let’s assume that a user with the JID alice@localhost already has a FAST token obtained during previous authentication. When opening a new connection, the client sends the following:

    <authenticate mechanism='HT-SHA-256-NONE' xmlns='urn:xmpp:sasl:2'>
      <initial-response>YWxpY0VfY2xpZW50X2F1dGhlbnRpY2F0ZXNfdXNpbmdfZmFzdF80MDYA5u2CpST(...)</initial-response>
      <bind xmlns='urn:xmpp:bind:0'/>
      <user-agent id='d4565fa7-4d72-4749-b3d3-740edbf87770'/>
    </authenticate>
    
    

    As a response, it receives:

    <success xmlns='urn:xmpp:sasl:2'>
      <authorization-identifier>alice@localhost/1750-684128-573793-695021f052e299fe</authorization-identifier>
      <bound xmlns='urn:xmpp:bind:0'/>
    </success>
    
    

    This way, the whole connection and authentication process is performed in a single round-trip.

    FAST features supported in MongooseIM

    In version 6.4, additional advanced features of FAST are supported. One of them is token rotation : the server invalidates tokens after a configurable period, and provides a new token on reconnection if the current one is close to expiry (this period is also configurable). Additionally, a client can request immediate token invalidation – with or without requesting a new one.

    Another addition is the support for 0-RTT (zero round-trip time) data in TLS 1.3 (see RFC 8446, section 2.3 ). The FAST token can be provided by the client during a subsequent handshake after reconnection, meaning that there is no additional round-trip needed after the handshake – hence the name “0-RTT”. A different extension is the tls-exporter channel binding in TLS 1.3 (see RFC 9266 for details) – it can be used with FAST, resulting in the channel binding data being passed with the FAST token, increasing the security. Note that currently it cannot be used with 0-RTT data. See the documentation for mod_fast_auth_token and the Hashed Token SASL Mechanism specification for more information.

    Summary

    MongooseIM 6.4.0 offers numerous improvements in various areas – from configuration to instrumentation. New features such as FAST tokens make it easier for your clients and services to connect, while TLS 1.3 makes it more protected against malicious attacks. You can discover much more in the release notes .

    Don’t hesitate to visit our product page , try it online and contact us if you are considering using it in your business – we will be happy to help you install, configure, maintain, and, if necessary, customise it to fit your particular needs

    The post MongooseIM 6.4: Simplified and Unified appeared first on Erlang Solutions .

    • Pl chevron_right

      Erlang Solutions: MongooseIM 6.4: Simplified and Unified

      news.movim.eu / PlanetJabber • 21 August 2025 • 7 minutes

    MongooseIM is a scalable and efficient instant messaging server. With the latest release 6.4.0, it has become more powerful yet easier to use and maintain. Thanks to the internal unification of listeners and connection handling, the configuration is easier and more intuitive, while numerous new options are supported.

    New features include support for TLS 1.3 with optional channel binding for improved security, single round-trip authentication with FAST (which can be even faster with 0-RTT or more secure with channel binding), reduced start-up time and many other improvements and bug fixes. Let’s take a deeper look at some of the most important improvements.

    Reworked XMPP interfaces

    MongooseIM uses the open, proven, extensible and constantly evolving XMPP protocol, which is an excellent choice when it comes to instant messaging. To communicate with other XMPP entities, the server uses three main types of interfaces, listed in the table below.

    XMPP Interface Purpose Connection type Reworked in version
    C2S (client-to-server) Accept connections from XMPP clients inbound 6.1.0 – 6.4.0
    S2S (server-to-server) Federate with other XMPP servers inbound/outbound 6.4.0 (latest)
    Component Accept connections from external components inbound

    The C2S interface was reworked and improved already in version 6.1.0 (see the blog post ), making it more modern, organised and extensible. In version 6.4.0, this trend is continued by reworking the S2S and component interfaces while unifying the whole connection handling logic.

    Simplified, unified and more complete

    Connection accepting and handling was simplified and unified in multiple ways, allowing the addition of new features along the way. All connections are now accepted by ranch , a state-of-the-art socket acceptor pool for Erlang. Modern gen_statem behaviour is then used to handle open connections using state machines. These changes allowed for improved handling of various corner cases, removing unexpected limitations and mishandled error conditions. There is also improved separation of concerns, resulting in easier extensibility and configurability.

    Another unified and improved system aspect is the TLS encryption . The legacy fast_tls library is now fully replaced with the Erlang implementation, resulting in much more straightforward configuration and implementation without a drop in performance (as evidenced by rigorous load tests). This change made it possible to fill in some gaps in functionality, such as the support for channel binding as required for TLS 1.3 (see RFC 9266 for details). Additionally, TLS is now supported for component connections. Moreover, CA certificates can be provided by the OS, reducing the need for manual certificate provisioning. As a result of these changes, your MongooseIM installation will be more secure and robust.

    All these changes are reflected in the TOML configuration file. As an example, the following snippet presents the configuration of S2S and component connections:

    [[listen.component]]
      port = 8190
      shaper = "fast"
      ip_address = "127.0.0.1"
      password = "secret"
      tls.certfile = "priv/ssl/cert.pem"
      tls.keyfile = "priv/ssl/key.pem"
    
    
    [[listen.s2s]]
      port = 5269
      shaper = "fast"
      tls.certfile = "priv/ssl/cert.pem"
      tls.keyfile = "priv/ssl/key.pem"
    
    
    [s2s]
      default_policy = "allow"
    
      [s2s.outgoing]
        port = 5269
        shaper = "fast"
        tls.certfile = "priv/ssl/cert.pem"
        tls.keyfile = "priv/ssl/key.pem"
    
    

    When compared with the previous version of MongooseIM, there are the following improvements:

    • Components can benefit from TLS connections.
    • S2S options are separate for the incoming ( listen.s2s ) and outgoing ( s2s.outgoing ) connections. Common options are placed directly in the s2s section (e.g. default_policy ).
    • Traffic shapers are configured the same way for all types of connections, and are always referenced by their names.
    • S2S outgoing connections can have traffic shaping enabled.
    • All TLS options follow the same pattern throughout the configuration file. This also affects multiple options that were omitted from this example for simplicity.

    Another improved layer is the instrumentation . Most changes affect XMPP traffic events – they are summarised in the table below:

    Events in version 6.3.* Events in version 6.4.0 Measurements
    Names Labels
    c2s_element_inc
    2s_element_out
    xmpp_element_in
    xmpp_element_out
    connection_type
    (c2s, s2s, component)
    host_type
    (if known)
    count
    stanza_count
    message_count
    iq_count(...)
    c2s_xmpp_element_size_in
    c2s_xmpp_element_size_out
    s2s_xmpp_element_size_in
    s2s_xmpp_element_size_out
    component_xmpp_element_size_in
    component_xmpp_element_size_out
    byte_size
    c2s_tcp_data_in
    c2s_tcp_data_out
    s2s_tcp_data_in
    s2s_tcp_data_out
    component_tcp_data_in component_tcp_data_out
    tcp_data_in
    tcp_data_out
    connection_type
    (c2s, s2s, component)
    c2s_tls_data_in
    c2s_tls_data_out
    s2s_tls_data_in
    s2s_tls_data_out
    component_tls_data_in component_tls_data_out
    tls_data_in
    tls_data_out

    We can see that there are fewer event names now, and they are more concise, making them easier to remember and reason about. This was possible due to the use of labels like connection_type and host_type , and actually, the event coverage got improved – see the element_in and element_out events, which now cover s2s and component connections. Also, the events are emitted more consistently. For incoming data, there is always one event emitted as soon as an XML element (most often a stanza) is parsed. For outgoing data, there is always one event emitted just before sending an XML element out. As a result, the metrics are consistent with actual network traffic.

    Another addition is the auth_failed event for s2s and component connections. For more information, such as the translation of event names and measurements to actual metric names, see the documentation on metrics . Our blog post about release 6.3.0 can also give you more details about the instrumentation layer and its integration with Prometheus.

    SASL 2, Bind 2, FAST

    Over the past few releases, we have been implementing extensions, speeding up the XMPP stream negotiation and authentication:

    • XEP-0388 : Extensible SASL Profile (SASL2) allows a client to authenticate, resume its session and more in one round-trip.
    • XEP-0386 : Bind 2 allows a client to bind the resource and enable selected extensions (SM, carbons, CSI) as part of SASL2.
    • XEP-0484 : FAST allows a client to authenticate with a token as a part of SASL2. According to the specification, this is a token-based method for streamlining authentication in XMPP, enabling fully authenticated stream establishment within a single round-trip.

    As an example, let’s assume that a user with the JID alice@localhost already has a FAST token obtained during previous authentication. When opening a new connection, the client sends the following:

    <authenticate mechanism='HT-SHA-256-NONE' xmlns='urn:xmpp:sasl:2'>
      <initial-response>YWxpY0VfY2xpZW50X2F1dGhlbnRpY2F0ZXNfdXNpbmdfZmFzdF80MDYA5u2CpST(...)</initial-response>
      <bind xmlns='urn:xmpp:bind:0'/>
      <user-agent id='d4565fa7-4d72-4749-b3d3-740edbf87770'/>
    </authenticate>
    
    

    As a response, it receives:

    <success xmlns='urn:xmpp:sasl:2'>
      <authorization-identifier>alice@localhost/1750-684128-573793-695021f052e299fe</authorization-identifier>
      <bound xmlns='urn:xmpp:bind:0'/>
    </success>
    
    

    This way, the whole connection and authentication process is performed in a single round-trip.

    FAST features supported in MongooseIM

    In version 6.4, additional advanced features of FAST are supported. One of them is token rotation : the server invalidates tokens after a configurable period, and provides a new token on reconnection if the current one is close to expiry (this period is also configurable). Additionally, a client can request immediate token invalidation – with or without requesting a new one.

    Another addition is the support for 0-RTT (zero round-trip time) data in TLS 1.3 (see RFC 8446, section 2.3 ). The FAST token can be provided by the client during a subsequent handshake after reconnection, meaning that there is no additional round-trip needed after the handshake – hence the name “0-RTT”. A different extension is the tls-exporter channel binding in TLS 1.3 (see RFC 9266 for details) – it can be used with FAST, resulting in the channel binding data being passed with the FAST token, increasing the security. Note that currently it cannot be used with 0-RTT data. See the documentation for mod_fast_auth_token and the Hashed Token SASL Mechanism specification for more information.

    Summary

    MongooseIM 6.4.0 offers numerous improvements in various areas – from configuration to instrumentation. New features such as FAST tokens make it easier for your clients and services to connect, while TLS 1.3 makes it more protected against malicious attacks. You can discover much more in the release notes .

    Don’t hesitate to visit our product page , try it online and contact us if you are considering using it in your business – we will be happy to help you install, configure, maintain, and, if necessary, customise it to fit your particular needs

    The post MongooseIM 6.4: Simplified and Unified appeared first on Erlang Solutions .

    • Pl chevron_right

      Erlang Solutions: MongooseIM 6.4: Simplified and Unified

      news.movim.eu / PlanetJabber • 21 August 2025 • 7 minutes

    MongooseIM is a scalable and efficient instant messaging server. With the latest release 6.4.0, it has become more powerful yet easier to use and maintain. Thanks to the internal unification of listeners and connection handling, the configuration is easier and more intuitive, while numerous new options are supported.

    New features include support for TLS 1.3 with optional channel binding for improved security, single round-trip authentication with FAST (which can be even faster with 0-RTT or more secure with channel binding), reduced start-up time and many other improvements and bug fixes. Let’s take a deeper look at some of the most important improvements.

    Reworked XMPP interfaces

    MongooseIM uses the open, proven, extensible and constantly evolving XMPP protocol, which is an excellent choice when it comes to instant messaging. To communicate with other XMPP entities, the server uses three main types of interfaces, listed in the table below.

    XMPP Interface Purpose Connection type Reworked in version
    C2S (client-to-server) Accept connections from XMPP clients inbound 6.1.0 – 6.4.0
    S2S (server-to-server) Federate with other XMPP servers inbound/outbound 6.4.0 (latest)
    Component Accept connections from external components inbound

    The C2S interface was reworked and improved already in version 6.1.0 (see the blog post ), making it more modern, organised and extensible. In version 6.4.0, this trend is continued by reworking the S2S and component interfaces while unifying the whole connection handling logic.

    Simplified, unified and more complete

    Connection accepting and handling was simplified and unified in multiple ways, allowing the addition of new features along the way. All connections are now accepted by ranch , a state-of-the-art socket acceptor pool for Erlang. Modern gen_statem behaviour is then used to handle open connections using state machines. These changes allowed for improved handling of various corner cases, removing unexpected limitations and mishandled error conditions. There is also improved separation of concerns, resulting in easier extensibility and configurability.

    Another unified and improved system aspect is the TLS encryption . The legacy fast_tls library is now fully replaced with the Erlang implementation, resulting in much more straightforward configuration and implementation without a drop in performance (as evidenced by rigorous load tests). This change made it possible to fill in some gaps in functionality, such as the support for channel binding as required for TLS 1.3 (see RFC 9266 for details). Additionally, TLS is now supported for component connections. Moreover, CA certificates can be provided by the OS, reducing the need for manual certificate provisioning. As a result of these changes, your MongooseIM installation will be more secure and robust.

    All these changes are reflected in the TOML configuration file. As an example, the following snippet presents the configuration of S2S and component connections:

    [[listen.component]]
      port = 8190
      shaper = "fast"
      ip_address = "127.0.0.1"
      password = "secret"
      tls.certfile = "priv/ssl/cert.pem"
      tls.keyfile = "priv/ssl/key.pem"
    
    
    [[listen.s2s]]
      port = 5269
      shaper = "fast"
      tls.certfile = "priv/ssl/cert.pem"
      tls.keyfile = "priv/ssl/key.pem"
    
    
    [s2s]
      default_policy = "allow"
    
      [s2s.outgoing]
        port = 5269
        shaper = "fast"
        tls.certfile = "priv/ssl/cert.pem"
        tls.keyfile = "priv/ssl/key.pem"
    
    

    When compared with the previous version of MongooseIM, there are the following improvements:

    • Components can benefit from TLS connections.
    • S2S options are separate for the incoming ( listen.s2s ) and outgoing ( s2s.outgoing ) connections. Common options are placed directly in the s2s section (e.g. default_policy ).
    • Traffic shapers are configured the same way for all types of connections, and are always referenced by their names.
    • S2S outgoing connections can have traffic shaping enabled.
    • All TLS options follow the same pattern throughout the configuration file. This also affects multiple options that were omitted from this example for simplicity.

    Another improved layer is the instrumentation . Most changes affect XMPP traffic events – they are summarised in the table below:

    Events in version 6.3.* Events in version 6.4.0 Measurements
    Names Labels
    c2s_element_inc
    2s_element_out
    xmpp_element_in
    xmpp_element_out
    connection_type
    (c2s, s2s, component)
    host_type
    (if known)
    count
    stanza_count
    message_count
    iq_count(...)
    c2s_xmpp_element_size_in
    c2s_xmpp_element_size_out
    s2s_xmpp_element_size_in
    s2s_xmpp_element_size_out
    component_xmpp_element_size_in
    component_xmpp_element_size_out
    byte_size
    c2s_tcp_data_in
    c2s_tcp_data_out
    s2s_tcp_data_in
    s2s_tcp_data_out
    component_tcp_data_in component_tcp_data_out
    tcp_data_in
    tcp_data_out
    connection_type
    (c2s, s2s, component)
    c2s_tls_data_in
    c2s_tls_data_out
    s2s_tls_data_in
    s2s_tls_data_out
    component_tls_data_in component_tls_data_out
    tls_data_in
    tls_data_out

    We can see that there are fewer event names now, and they are more concise, making them easier to remember and reason about. This was possible due to the use of labels like connection_type and host_type , and actually, the event coverage got improved – see the element_in and element_out events, which now cover s2s and component connections. Also, the events are emitted more consistently. For incoming data, there is always one event emitted as soon as an XML element (most often a stanza) is parsed. For outgoing data, there is always one event emitted just before sending an XML element out. As a result, the metrics are consistent with actual network traffic.

    Another addition is the auth_failed event for s2s and component connections. For more information, such as the translation of event names and measurements to actual metric names, see the documentation on metrics . Our blog post about release 6.3.0 can also give you more details about the instrumentation layer and its integration with Prometheus.

    SASL 2, Bind 2, FAST

    Over the past few releases, we have been implementing extensions, speeding up the XMPP stream negotiation and authentication:

    • XEP-0388 : Extensible SASL Profile (SASL2) allows a client to authenticate, resume its session and more in one round-trip.
    • XEP-0386 : Bind 2 allows a client to bind the resource and enable selected extensions (SM, carbons, CSI) as part of SASL2.
    • XEP-0484 : FAST allows a client to authenticate with a token as a part of SASL2. According to the specification, this is a token-based method for streamlining authentication in XMPP, enabling fully authenticated stream establishment within a single round-trip.

    As an example, let’s assume that a user with the JID alice@localhost already has a FAST token obtained during previous authentication. When opening a new connection, the client sends the following:

    <authenticate mechanism='HT-SHA-256-NONE' xmlns='urn:xmpp:sasl:2'>
      <initial-response>YWxpY0VfY2xpZW50X2F1dGhlbnRpY2F0ZXNfdXNpbmdfZmFzdF80MDYA5u2CpST(...)</initial-response>
      <bind xmlns='urn:xmpp:bind:0'/>
      <user-agent id='d4565fa7-4d72-4749-b3d3-740edbf87770'/>
    </authenticate>
    
    

    As a response, it receives:

    <success xmlns='urn:xmpp:sasl:2'>
      <authorization-identifier>alice@localhost/1750-684128-573793-695021f052e299fe</authorization-identifier>
      <bound xmlns='urn:xmpp:bind:0'/>
    </success>
    
    

    This way, the whole connection and authentication process is performed in a single round-trip.

    FAST features supported in MongooseIM

    In version 6.4, additional advanced features of FAST are supported. One of them is token rotation : the server invalidates tokens after a configurable period, and provides a new token on reconnection if the current one is close to expiry (this period is also configurable). Additionally, a client can request immediate token invalidation – with or without requesting a new one.

    Another addition is the support for 0-RTT (zero round-trip time) data in TLS 1.3 (see RFC 8446, section 2.3 ). The FAST token can be provided by the client during a subsequent handshake after reconnection, meaning that there is no additional round-trip needed after the handshake – hence the name “0-RTT”. A different extension is the tls-exporter channel binding in TLS 1.3 (see RFC 9266 for details) – it can be used with FAST, resulting in the channel binding data being passed with the FAST token, increasing the security. Note that currently it cannot be used with 0-RTT data. See the documentation for mod_fast_auth_token and the Hashed Token SASL Mechanism specification for more information.

    Summary

    MongooseIM 6.4.0 offers numerous improvements in various areas – from configuration to instrumentation. New features such as FAST tokens make it easier for your clients and services to connect, while TLS 1.3 makes it more protected against malicious attacks. You can discover much more in the release notes .

    Don’t hesitate to visit our product page , try it online and contact us if you are considering using it in your business – we will be happy to help you install, configure, maintain, and, if necessary, customise it to fit your particular needs

    The post MongooseIM 6.4: Simplified and Unified appeared first on Erlang Solutions .