Agregador de noticias

ProcessOne: Securing ejabberd with TLS encryption

Planet Jabber - 8 April, 2016 - 12:49

In recent years security and privacy become central focus of users and system administrators. Here is brief guide on securing ejabberd connections and keep them private.

ejabberd have number of options that control security:

certfile: Full path to a file containing the default SSL certificate
ciphers: OpenSSL ciphers list in the same format accepted by ‘openssl ciphers’ command
protocol_options: List of supported SSL protocols
dhfile: Full path to a file containing custom parameters for Diffie-Hellman key exchange
starttls: This option specifies that STARTTLS encryption is available on connections to the port
starttls_required: This option specifies that STARTTLS encryption is required on connections to the port.
tls: This option specifies that traffic on the port will be encrypted using SSL immediately after connecting. This method is nowadays deprecated and not recommended
tls_compression: Whether to enable or disable TLS compression.
s2s_use_starttls: This option defines if s2s connections are encrypted
s2s_certfile: Full path to a file containing a SSL certificate
s2s_dhfile: Full path to a file containing custom DH parameters
s2s_ciphers: OpenSSL ciphers list in the same format accepted by ‘openssl ciphers’ command
s2s_protocol_options: List of supported SSL protocols
s2s_tls_compression: Whether to enable or disable TLS compression

For more configuration options and description refer to ejabberd documentation.

Settings: Recommended vs Compatibility

For many years security was something that was not primary concern in many cases in internet standards. ProcessOne team stands on the point that security is one of the primary factors thus we will recommend strong settings but also provide compatibility for reference only for those who want and need to retain support for insecure, legacy clients and servers but understand that this settings may jeopardize security and privacy. In below table you can find defaults for legacy and recommended settings:

Option Legacy Recommended certfile path: /etc/ssl/ejabberd/domain.pem path: /etc/ssl/ejabberd/domain.pem ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 protocol_options no_sslv2, no_sslv3 no_sslv2, no_sslv3, no_tlsv1,no_tlsv1_1 dhfile path: /etc/ssl/ejabberd/dh1024.pem path: /etc/ssl/ejabberd/dh2048.pem starttls TRUE TRUE starttls_required FALSE TRUE tls FALSE FALSE tls_compression FALSE FALSE s2s_use_starttls OPTIONAL REQUIRED s2s_certfile path: /etc/ssl/ejabberd/domain.pem path: /etc/ssl/ejabberd/domain.pem s2s_dhfile path: /etc/ssl/ejabberd/dh1024.pem path: /etc/ssl/ejabberd/dh2048.pem s2s_ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 s2s_protocol_options no_sslv2, no_sslv3 no_sslv2, no_sslv3, no_tlsv1,no_tlsv1_1 s2s_tls_compression FALSE FALSE

Configuration examples

Example 1 – Strong settings for c2s settings

This config disables protocols from SSLv2 up to TLSv1.1 and allows only “modern” (as of 2016) protocol TLSv1.2 and related ciphers.

listen: - port: 5222 module: ejabberd_c2s protocol_options: - "no_sslv2" - "no_sslv3" - "no_tlsv1" - "no_tlsv1_1" ciphers: "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256" shaper: c2s_shaper access: c2s certfile: "/etc/ssl/ejabberd/domain.pem" starttls: true starttls_required: true tls_compression: false dhfile: "/etc/ssl/ejabberd/dh2048.pem"

Note: Clients that do not support TLS1.2 will not be allowed to connect to c2s port.

Example 2 – Compatible settings for c2s

listen: - port: 5222 module: ejabberd_c2s protocol_options: - "no_sslv2" - "no_sslv3" ciphers: "ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS" shaper: c2s_shaper access: c2s certfile: "/etc/ssl/ejabberd/domain.pem" starttls: true starttls_required: false tls_compression: false dhfile: "/etc/ssl/ejabberd/dh1024.pem"

Note: Clients that can connect to c2s ports need support at last TLS1.0. SSLv2 and SSLv3 have serious security flaws and have to be disabled. Also DH parameter is lowered here to 1024 bit as some older Java do not support higher grades.

Server-to-Server connections

s2s connections are more complex then client connections. If we want to federate with broad spectrum of XMPP servers, we have to allow unencrypted connections to that port. There are still lot of servers that do not support encryption. On the other hand, we have 2016 and it is hard to believe that there are still servers that sends data using plain-text. Choice is always up to server administrators, but ProcessOne strongly recommend to allow only secure, encrypted connections to port s2s:

Example 1 – Strong settings for s2s connections

Global section:

s2s_use_starttls: required s2s_certfile: /etc/ssl/ejabberd/domain.pem s2s_dhfile: /etc/ssl/ejabberd/dh2048.pem s2s_ciphers: "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256"

Listening ports:

listen: - port: 5269 module: ejabberd_s2s_in protocol_options: - "no_sslv2" - "no_sslv3" - "no_tlsv1" - "no_tlsv1_1"

Note: Only TLSv1.2 connections are allowed and all s2s connections are required to be encrypted

Example 2 – Legacy and unsafe s2s settings

Global section:


Listening ports:

listen: - port: 5269 module: ejabberd_s2s_in protocol_options: - "no_sslv2" - "no_sslv3"

Note: Allow unencrypted connections for servers that do not require it. If connections are encrypted – allow only protocol up from TLSv1. Also DH is lowered to 1024 bits.

Appendix: Create PEM files and DH paramerers

ejabberd supports certificates in PEM format. Certificate should also contain certificate-chain that comes from certificate provider. Here is how certificates in PEM file should stack-up:

——— Main Certificate ( ——— ——— Intermediate certificate, chain certs ——— ——— Private Key for Main Certificate ———

PEM file should be only readable by process running ejabberd.

ejabberd configuration allow to use custom DH parameters, this is important as recent research revealed weakness of widely and common used DH files (see We are recommending to use at last 2048-bit DH parameters. To generate DH use openssl command, for example:

openssl dhparam -out /etc/ssl/ejabberd/dh2048.pem 2048

and add proper ejabberd config option (see previous section). If you need to support some old software like Java7, set DH size to 1024.

Appendix: Generating Private Key and Certificate Requests

You can generate self-signed certificates for your connections, however nowadays we strongly recommend that anyone use signed certificates by trusted and known Certificate Authority (CA). You can easily find commercial CA with pricing starting as low as $15 per year. There is also option of using free certificates from – see their docs for automated process of issuing certificates.

Generate Private Key (PK):

openssl genrsa -out xmpp_example_com.key 2048

this will generate PK – keep it safe, do not share. It is 2048 bit long, if you need bigger key, go for 4096 bits. Now you need to generate Certificate Signing Request (CSR) – that need to be send (usually copy&paste) to CA to generate certificate for you:

openssl req -out xmpp_example_com.csr -key xmpp_example_com.key -new -sha256

you will have to answer range of questions, and most important is: “Common Name (e.g. server FQDN or YOUR name)” this is where you place your domain name, like: , you can use wildcard names as well if you use certificate for other sub-domains.
After submitting CSR to CA you will get CRT – file that is actually public part of your key pair. Usually with your CRT, CA also provides certificate chain that need to be included in PEM file (see appendix about creating PEM files).

If you want to generate a self-signed certificate and not yet ask a certificate to a CA, you can use the following command. It is not recommended for production, but can be helpful for testing:

openssl x509 -req -days 365 -in xmpp_example_com.csr -signkey xmpp_example_com.key -out xmpp_example_com.crt

Then, all what you need to do is to combine files into single PEM file. Using names from above examples, that can be done using cat command (step-by-step):

Let’s assume that CA sent you xmpp_example_com.crt and ca_intermediate_certificate.crt:

cat xmpp_example_com.crt > xmpp_example_com.pem (create PEM file with certificate)
cat ca_intermediate_certificate.crt >> xmpp_example_com.pem (add intermediate CA certificate to PEM)
cat xmpp_example_com.key >> xmpp_example_com.pem (finally add private key to file)

ensure that PEM file do not have any garbage, it should be nice and smooth text file like:

-----BEGIN CERTIFICATE----- MIIHEjCCBfqgAwIBAgIQCI9arD288vK6p24B8dArzjANBgkqhkiG9w0BAQUFADBm MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3 .... .... XJqV43tRs8oaymPzU9NVbLutjva+ln/ml2IcEoE7a8x0UbdcYfQKpFI9cjr9yIki sn5Y+o5sMjse8gXZtFMttmE3yypBt5BR4yLoQB2BSocmZkhWGjQ= -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIGWDCCBUCgAwIBAgIQCl8RTQNbF5EX0u/UA4w/OzANBgkqhkiG9w0BAQUFADBs .... .... Ib4p1I5eFdZCSucyb6Sxa1GDWL4/bcf72gMhy2oWGU4K8K2Eyl2Us1p292E= -----END CERTIFICATE----- -----BEGIN RSA PRIVATE KEY----- MIIEpQIyyiKCA35wtuube64IQM5hYnSzNL8HLJLYVfEl5vSrDO5KwLZ/P71BPrhx .... .... hddA/p+zRteyTvBJaXAJwrreSjeJL4HGyf0E9z4TLE5qNMF81bXFso0+2FGDrh0t -----END RSA PRIVATE KEY-----

Tigase Blog: Connection Watchdog

Planet Jabber - 8 April, 2016 - 00:11

A common problem that can occur with any server is stale connections tying up available bandwidth. Whether it is due to a connection timeout, poor quality connection, or system errors, stale connections can bog down a system from operating at peak efficiency and post security risks. Operating systems and network settings can be configured to attempt to solve this problem, but that solution can cause problems. We at Tigase thought if we can monitor connections internally, we can enable users can fine-tune settings to exactly fit their needs.

ProcessOne: ejabberd ARM64 support

Planet Jabber - 4 April, 2016 - 12:41

ARMv8 represents a fundamental change to the ARM architecture. It adds a 64-bit architecture instruction set, named “AArch64”, or ARM64.

ProcessOne has been playing with ARM64 ejabberd servers for few months already, but with recent availability of many low cost 64-bit ARM development platforms, we decided to announce official ARM64 support for ejabberd.

ejabberd Community Server 16.03 is the first public version available with an ARM64 installer.

You will need a 64-bit ARM Linux installation, with glibc >= 2.17 to use our official installer.
Give it a try and Send us feedback !

Fanout Blog: Migrated to Jekyll

Planet Jabber - 2 April, 2016 - 19:43

We recently migrated the Fanout Blog from WordPress to Jekyll, and we updated the blog theme to match the newer Fanout website design.

The blog content is all the same, and Livefyre commenting is still here as well as RSS/Atom feeds and the SubToMe buttons. The reason for the migration (and thus the differences) are mostly internal:


ProcessOne: ejabberd 16.03: Experimental MIX support, LDAP, SQL and Riak improvements

Planet Jabber - 30 March, 2016 - 16:20

ejabberd development keeps on its steady pace and we are energized by the growing momentum. Thank you all for your feedback and contributions for that release.

This new ejabberd release contains many many bugfixes, internal improvements, but also, as usual, some new features.

We are very excited by the experimental support for Mediated Information eXchange (MIX) we have added in ejabberd 16.03. This is the future of Multi User Chat for XMPP. While still rough, you can already give it a try and help improve the specification. You can learn more from our previous blog post: Experimental MIX Support for Group Conversations added to ejabberd

We have also started improvements of various third-party backends such a Microsoft SQL Server and LDAP. This is the beginning of a process to improve support of those backend, so please, bare with us and keep us posted on your results.

Changes Protocols
  • mod_mix: Experimental support for MIX (XEP-0369)
  • mod_http_upload: Add support for XEP-0363 v0.2
  • Use SASL PLAIN authzid as client identity if auth module permits it
  • Make auto generated resources shorter
  • Start ezlib only if required, as it’s optional
  • Make it possible to get virtual host of a registered route
LDAP improvements
  • Fix issue getting shared roster
  • Do not call to deprected/undefined functions from mod_shared_roster_ldap
  • Proper naming for LDAP test function for shared roster
SQL databases support
  • New parse transform for SQL queries, use prepare/execute calls with Postgres
  • Support for run-time SQL queries selection depending on DBMS version
  • In SQL files create Users table with SCRAM support by default
  • Do not auto append IP suffix to usernames
  • Fix some LIMIT related problems with MSSQL
  • Update Microsoft SQL Server schema
  • Add support for Riak authentication
  • Fix is_connected/0 function
  • Keep alive Riak connections by default
API and Commands
  • Add support for ReST admin commands that are only restricted by source IP. This is key for easy integration with other backend using ReST API.
  • Fix add_commands and remove_commands options
  • Pass noauth when auth isn’t provided
  • Improve ban_account command to work with other DBs than Mnesia
  • Escape quoting node name for ejabberdctl ping
  • Bare JID in ‘from’ of Roster Push (RFC 6121 section 2.1.6) in mod_admin_extra
  • Fix result type of “connected_users_info” command
  • New command delete_mnesia deletes all tables that can be exported. This is useful after you have migrated to another backend, like SQL.
  • Unregister route at the very end
  • Define PubSub node configuration per route/host explicitly
  • Fix config fetch and pubsub disco after host/serverhost cleanup
Admin and build chain
  • Update OTP release to use R17.5 and drop release 17.1
  • Compile ejabberd_config early to stop undefined behaviour warnings
  • Fix start via systemd
  • Fixed type specifications for ‘rebar doc’
  • Specify lacking nodename in ejabberdctl
  • Update p1_pgsql to 1.1.0: This add support for prepared statements.
  • Uptate fast_yaml to 1.0.3: This improves the error reporting on syntax errors in Yaml configuration file.
  • Use the v0.2 release of luerl instead of a commit.
Test framework
  • Add Coveralls support
  • Add ability to run the ejabberd test suite in a modular way. You can now run the test suite, even if you only have a a single backend locally.
  • mod_mam: Don’t store watchdog notifications in MAM archives
  • mod_multicast: Fix Addresses element which lacked others local destinations
  • mod_offline: Mark get_queue_length obsolete, and use count_offline_messages
  • Update Gallician translation

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

The source package and binary installers are available at ProcessOne.

If you suspect that you’ve found a bug, please search or fill a bug report on Github.

Tigase Blog: DBSchemaLoader Utility

Planet Jabber - 26 March, 2016 - 02:24

Tigase is programmed to work with a plethora of databases, however not all users will want to learn (or purchase) an SQL editor to maintain those databases. We at Tigase have decided to provide a utility, built into our XMPP server, that can perform many functions of database utilities. This utility has been included with Tigase for some time now, but it's possible many of our users never noticed it's existence. DBSchemaLoader runs as a java program, so it is independent of operating system, and can run on any machine that can also run Tigase XMPP Server.

Daniel Pocock: With Facebook, everybody can betray Jesus

Planet Jabber - 25 March, 2016 - 17:43

It's Easter time again and many of those who are Christian will be familiar with the story of the Last Supper and the subsequent betrayal of Jesus by his friend Judas.

If Jesus was around today and didn't immediately die from a heart attack after hearing about the Bishop of Bling (who spent $500,000 just renovating his closet and flew first class to visit the poor in India), how many more of his disciples would betray him and each other by tagging him in selfies on Facebook? Why do people put the short term indulgence of social media ahead of protecting privacy in the long term? Is this how you treat your friends?

Daniel Pocock: GSoC 2016 opportunities for Voice, Video and Chat Communication

Planet Jabber - 23 March, 2016 - 03:55

I've advertised a GSoC project under Debian for improving voice, video and chat communication with free software.

Replacing Skype, Viber and WhatsApp is a big task, however, it is quite achievable by breaking it down into small chunks of work. I've been cataloguing many of the key improvements needed to make Free RTC products work together. Many of these chunks are within the scope of a GSoC project.

If you can refer any students, if you would like to help as a mentor or if you are a student, please come and introduce yourself on the FreeRTC mailing list. If additional mentors volunteer, there is a good chance we can have more than one student funded to work on this topic.

The deadline is Friday, 25 March 2016

The student application deadline is 25 March 2016 19:00 UTC. This is a hard deadline for students. Mentors can still join after the deadline, during the phase where student applications are evaluated.

The Google site can be very busy in the hours before the deadline so it is recommended to try and complete the application at least 8 hours before the final deadline.

Action items for students:

  • Register yourself on the Google Site and submit an application. You can submit applications to multiple organizations. For example, if you wish to focus on the DruCall module for Drupal, you can apply to both Debian and Drupal.
  • Join the FreeRTC mailing list and send a message introducing yourself. Tell us which topics you are interested in, which programming languages your are most confident with and which organizations you applied to through the Google site.
  • Create an application wiki page on the Debian wiki. You are permitted to edit the page after the 25 March deadline, so if you are applying at the last minute, just create a basic list of things you will work on and expand it over the following 2-3 days
Introducing yourself and making a strong application

When completing the application form for Google, the wiki page and writing the email to introduce yourself, consider including the following details:

  • Link to any public profile you have on sites like Github or bug trackers
  • Tell us about your programming language skills, list the top three programming languages you are comfortable with and tell us how many years you have used each
  • other skills you have or courses you have completed
  • any talks you have given at conferences
  • any papers you have had published
  • any conferences you have attended or would like to attend
  • where you are located and where you study, including timezone
  • any work experience you already have
  • any courses, exams or employment commitments you have between 22 May and 24 August
  • anybody from your local free software community or university who may be willing to help as an additional mentor
Further reading

Please also see my other project idea, for ham radio / SDR projects and my blog Want to be selected for Google Summer of Code 2016?.

If you are not selected in 2016

We try to make contact with all students who apply and give some feedback, in particular, we will try to let you know what to do to increase your chances of selection in the next year, 2017. Applying for GSoC and being interviewed by mentors is a great way to practice for applying for other internships and jobs.

Monal IM: Monal OSX 1.4 is out

Planet Jabber - 22 March, 2016 - 14:01

Quick update to fix some of the issues people saw with 1.3 . Also, some UI updates that didn’t make it to the last release.

Erlang Solutions: MongooseIM 1.6.2 is out. Time to upgrade!

Planet Jabber - 22 March, 2016 - 10:10
MongooseIM 1.6.2 is out. Time to upgrade!

by Michał Piotrowski and Rafał Studnicki

We are pleased to announce the release of MongooseIM 1.6.2. This is last release in the 1.6.x family. Please read below to find out more about our demo, load tests and all the significant changes. We encourage everyone to upgrade.

MongooseIM 1.6.2 is about "stability": finished Riak for all major modules, docker-based demo, load test, improved tests, new enhancements.


We finished our work on implementing missing Riak backends. Now all major functionalities like:

  • authentication
  • last_activity
  • message archive for one-to-one and MUC conversation (MUC archive was added in this release)
  • private
  • privacy (added in this release)
  • offline messages (added in this release)
  • rosters
  • vcard

Can be configured to store data in Riak database.

Docker-based demo The use case

In this demo we wanted to show, that cluster of MongooseIM nodes can handle node failures gracefully and users will be able to reconnect to remaining nodes in the cluster.

Set up

During Lambda Days we showed a MongooseIM demo built with docker containers. The set up was very simple:

  • DNS server
  • 5 nodes cluster of MongooseIM 1.6.2
  • HAProxy in front of all the nodes
  • MySQL as the database backend
  • Graphite/Grafana to collect all metrics

From the MongooseIM/XMPP standpoint, this setup can be depicted by the following diagram:

The code is on GitHub studzien/mongooseim-docker. Please follow the very quick start guide if you want to setup a similar infrastructure.


We prepared Amoc's scenario where every single session is trying to reconnect after node failure. The scenario can be found here.


The dashboard for interactive starting or stopping nodes and adding or removing XMPP users during an example run looked as follows:

You can check out the snapshot of this run to see how MongooseIM nodes reacted for nodes going up or down here.

Load test

To proof that we didn't break anything in the 1.6.x road, we ran load tests comparing 1.6.2 with 1.6.0. These load tests proved that we in fact improved memory footprint since 1.6.0. All other parameters stayed the same.

Exported Grafana dashboards can be found here:


As usual we are increasing test coverage and improving tests quality. The most important changes are:

  • extended privacy tests
  • improved ejabberd_c2s tests
  • added tests for MAM preference
Enhancements and fixes

We finally added support for new MAM XEP-0313 versions. Now MongooseIM understands MAM version from 0.2 to 0.5! Also we implemented Dialback Key Generation and Validation (XEP-0185) which is important to have trusted S2S connections.

Since 1.6.2, MongooseIM no longer supports Erlang/OTP versions older than R16B03-1. Thanks to that we simplified our codebase by removing some workarounds for older Erlang versions.

Join us!

As we finished our work on 1.6.x release we are now starting work on 1.7.x, please suggest features on our tracker.

Special thanks to our contributors @gbour, @bartekgorny and @jfjalburquerque. We encourage everybody to code and do a Pull Request!

Read the MongooseIM Product page on Erlang Solutions website. Or read on GitHub the detailed changelog, and check out the MongooseIM repository.

Get the news! Subscribe to the announcements mailing-list.

Ignite Realtime Blog: Openfire 4.0.2 Released

Planet Jabber - 21 March, 2016 - 18:41

The Ignite Realtime Community is pleased to announce the 4.0.2 release of Openfire.  This release signifies our ongoing effort to produce a stable 4.0 series release while continuing to work toward a 4.1 release.  A changelog of issues fixed indicates 9 issues resolved with hopefully the issue of stale/ghost client sessions being resolved.


As always, please report issues in the Community Forums and you can download this release from our website.  Here are the sha1sum's for the downloads available.


Platformsha1sumFilenameLinux RPMcc675aad91ae28ed8e4dd5f86ff1bd0bed8a6000openfire-4.0.2-1.i386.rpmDebianbcbd2f48f39b59b7d445ee46a42b1a576507af41openfire_4.0.2_all.debMac369cbdc069bfabcc9a1fc906026fb21c7ab85905openfire_4_0_2.dmgWindows7c910a8136347f2b35576886dc883b4173ea598copenfire_4_0_2.exeBinary (tar.gz)b21b0087a19c5ae043c66d1b60a6e1070336d15dopenfire_4_0_2.tar.gzBinary (zip)1820004f927900ec8a8de4f0ce869a60529aa91dopenfire_4_0_2.zipSource (tar.gz)7ce3f9e727582ce6fb05fc82984f87eec160ed6bopenfire_src_4_0_2.tar.gzSource (zip)


As a reminder, Openfire's source code and development can be found on Github and an active developer discussion occurs within our groupchat.  Please consider helping out with Openfire's development!

Tigase Blog: Spam Account Protection

Planet Jabber - 18 March, 2016 - 17:37

Tigase XMPP server is built from the ground up to be secure, however, some installation use cases may render themselves vulnerable. For example, if you are running a public chat server, and allow users to register for usernames. Public registration could allow for somebody to register many bogus accounts and force a DDOS attack on the server, slowing down traffic, database, and software performance. Although servers can have their own levels of protection, Tigase has some settings that may help on its own.

Tigase Blog: Editing Server Settings via XMPP

Planet Jabber - 16 March, 2016 - 02:47
Almost every application written has some way you can change how it behaves. Some are more difficult to change than others, being locked behind options and run commands. Others, like Tigase, offer a number of ways you can configure the software allowing the user to choose the most convenient way to change settings

ProcessOne: IoT Studio #1 Video and Slides

Planet Jabber - 14 March, 2016 - 11:07

This is the video recording of ProcessOne IoT Studio session #1.

At the core of the discussion is an introduction to Internet of Things protocols.

Here are the topics / questions that we covered during that session:

  • What are the main classes of protocols for the Internet of Things ?
  • What are the strengths of XMPP for the Internet of things ?
  • What are the main XMPP Extensions for building the Internet of Things ?
  • How can I leverage XMPP to build a real device / appliance ?

As such, the session ends with a hands-on demonstration of a Soundcloud connected Jukebox built with:
– Raspberry Pi 2
– Connected to ejabberd
– Client is developed in Go using Go XMPP library Gox.

Example code for the XMPP jukebox is available on Github: xmpp_jukebox.go

The full video recording of that session is now online and available for everyone to enjoy.

Please, send us your IoT questions for the next event !

For those who just need access to the slides, they are on Slideshare:

Tigase Blog: Windows Integration Improved

Planet Jabber - 11 March, 2016 - 21:17

Recently, we've added a number of fixes to the version 7.0.3 of Tigase XMPP server which includes a number of fixes that improves operation of the software. These fixes include an easier time when setting up and operating Tigase in a Windows operating environment. When it comes to operating an XMPP server, a Windows environment might not be the first place you think of, however, Tigase can run in many Windows environments just fine! With the new maintenance version, we've improved the ease and operation of Tigase XMPP Server in this popular operating system.

ProcessOne: Experimental MIX Support for Group Conversations added to ejabberd

Planet Jabber - 11 March, 2016 - 17:43

MIX stands for Mediated Information eXchange and is defined in draft of XEP-0369.

It is a work in progress extension for the XMPP protocol to build a group messaging protocol that does not rely on the presence mechanism. It is designed to overcome the limitation of XEP-0045 Multi-User Chat, in a context where most clients are mobile clients.

To do so, MIX is built on top of PubSub (XEP-0060) and use different nodes per channel to separate event types. There is five nodes to support five different types of event for each MIX conversation:

  • Messages
  • Presence
  • Participant list changes
  • Subject update
  • Conversion configuration changes

This is a work in progress, but this is a very important task and we are happy to provide the very first server implementation of the Mix protocol to get up to speed on that specification.

Here is a short walk through what can already be done.

Please, note that this is a work in progress and that the specification can (and will) change significantly before it becomes stable. This blog post is based on XEP-0369 v0.1.


Configuration is simple:

  • You need to build ejabberd from source, latest master version.
  • You need to add mod_mix in ejabberd configuration, modules section:

    modules: mod_mix: {}
  • Make sure you have pubsub enabled. Default configuration is fine:

    modules: mod_pubsub: access_createnode: pubsub_createnode ignore_pep_from_offline: true last_item_cache: false plugins: - "flat" - "hometree" - "pep"

There is no client supporting MIX yet so here is how it works directly at XMPP stream level.

Here are real-life examples from playing with our MIX implementation:

Joining a MIX conversation

You can join a MIX conversation if you know its jid (id@mixservice):

You can send a join IQ:

<iq type='set' to='hellomix@mix.localhost' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> <join xmlns='urn:xmpp:mix:0'> <subscribe node='urn:xmpp:mix:nodes:messages'></subscribe> <subscribe node='urn:xmpp:mix:nodes:presence'></subscribe> <subscribe node='urn:xmpp:mix:nodes:participants'></subscribe> <subscribe node='urn:xmpp:mix:nodes:subject'></subscribe> <subscribe node='urn:xmpp:mix:nodes:config'></subscribe> </join> </iq>

You receive IQ that confirms success:

<iq from="HelloMix@mix.localhost" type="result" to="admin@localhost/MacBook-Pro-de-Mickael" id="E6E10350-76CF-40C6-B91B-1EA08C332FC7"> <join xmlns="urn:xmpp:mix:0" jid="admin@localhost"> <subscribe node="urn:xmpp:mix:nodes:messages"></subscribe> <subscribe node="urn:xmpp:mix:nodes:presence"></subscribe> <subscribe node="urn:xmpp:mix:nodes:participants"></subscribe> <subscribe node="urn:xmpp:mix:nodes:subject"></subscribe> <subscribe node="urn:xmpp:mix:nodes:config"></subscribe> </join> </iq>

Subscribers on the participants node for that channel will also receive the new list of participants (so, including ourselves in that case):

<message from="hellomix@mix.localhost" type="headline" to="admin@localhost/MacBook-Pro-de-Mickael"> <event xmlns=""> <items node="urn:xmpp:mix:nodes:participants"> <item id="3d1766e2bd1b02167104f350f84b0668f850ef92"> <participant xmlns="urn:xmpp:mix:0" jid="admin@localhost"></participant> </item> </items> </event> </message>

Note: Nickname registration support is not yet implemented in our code.

Sending and receiving messages

You can now start chatting with your peers, by publishing on the message node:

<iq type='set' to='HelloMix@mix.localhost' id='mix2'> <pubsub xmlns=''> <publish node='urn:xmpp:mix:nodes:messages'> <item> <body xmlns='jabber:client'>Hi, there !</body> </item> </publish> </pubsub> </iq>

Server confirms publishing:

<iq from="HelloMix@mix.localhost" type="result" to="admin@localhost/MacBook-Pro-de-Mickael" id="mix2"> <pubsub xmlns=""> <publish node="urn:xmpp:mix:nodes:messages"> <item id="5B1AB7F432DA5"></item> </publish> </pubsub> </iq>

Message is received by all subscribers on the message node on that MIX conversation:

<message from="hellomix@mix.localhost" type="headline" to="admin@localhost/MacBook-Pro-de-Mickael"> <event xmlns=""> <items node="urn:xmpp:mix:nodes:messages"> <item id="5B1AB7F432DA5"> <body xmlns="jabber:client">Hi, there !</body> </item> </items> </event> </message> Sending and receiving presence

The presence in MIX conversation is conceptually independent from presence stanzas in standard XMPP protocol. In MIX, the presence is simply a state you want to broadcast to the subscribers of the presence node in the conversation.

The presence is broadcast through the Mix conversion, in a similar way to message:

<iq type='set' to='HelloMix@mix.localhost' id='mix3'> <pubsub xmlns=''> <publish node='urn:xmpp:mix:nodes:presence'> <item> <presence xmlns='jabber:client'> <c xmlns='' hash='sha-1' node='' ver='QgayPKawpkPSDYmwT/WM94uAlu0='></c> </presence> </item> </publish> </pubsub> </iq>

As you can see, presence is model on XMPP presence specification. In that case, we included caps info for example in our broadcast.

Server confirms presence broadcast to sender:

<iq from="HelloMix@mix.localhost" type="result" to="admin@localhost/MacBook-Pro-de-Mickael" id="mix3"> <pubsub xmlns=""> <publish node="urn:xmpp:mix:nodes:presence"> <item id="5B1ACB064CE"></item> </publish> </pubsub> </iq>

And finally, participants to conversation subscribe to presence will receive presence update:

<message from="hellomix@mix.localhost" type="headline" to="admin@localhost/MacBook-Pro-de-Mickael"> <event xmlns=""> <items node="urn:xmpp:mix:nodes:presence"> <item id="5B1ACB064CE"> <presence xmlns="jabber:client"> <c xmlns="" node="" ver="QgayPKawpkPSDYmwT/WM94uAlu0=" hash="sha-1"></c> </presence> </item> </items> </event> </message>

The presence at the moment is somewhat in between in current state of the XEP. To retract the presence you send a standard XMPP presence of type unavailable:

<presence type='unavailable' to='HelloMix@mix.localhost'></presence>

Server confirms retracting the presence item:

<message from="hellomix@mix.localhost" type="headline" to="test@localhost/MacBook-Pro-de-Mickael"> <event xmlns=""> <items node="urn:xmpp:mix:nodes:presence"> <retract id="5B1ACB064CE"></retract> </items> </event> </message>

This part is still unfortunate as it still makes it difficult to manage presence on mobiles were the status, that is the ability to receive messages, is somewhat disconnected from the session state. This is likely an area that will change significantly in the future.

Another thing to note is that for the moment, all your presence publications are kept as items, but going offline retract them all.

Querying participants list

A participant can always get list of participants with a Pubsub query on node items for the conversation:

<iq type='get' to='HelloMix@mix.localhost' id='mix4'> <pubsub xmlns=''> <items node='urn:xmpp:mix:nodes:participants'></items> </pubsub> </iq>

The conversation will reply with list of participants:

<iq from="HelloMix@mix.localhost" type="result" to="admin@localhost/MacBook-Pro-de-Mickael" id="mix4"> <pubsub xmlns=""> <items node="urn:xmpp:mix:nodes:participants"> <item id="1a3b7690ea2608d13988aca8339acf759daa8483"> <participant xmlns="urn:xmpp:mix:0" jid="test@localhost"></participant> </item> <item id="3d1766e2bd1b02167104f350f84b0668f850ef92"> <participant xmlns="urn:xmpp:mix:0" jid="admin@localhost"></participant> </item> </items> </pubsub> </iq> Querying the presence

You can query the presence as well:

<iq type='get' to='HelloMix@mix.localhost' id='mix5'> <pubsub xmlns=''> <items node='urn:xmpp:mix:nodes:presence'></items> </pubsub> </iq>

and you get a list of “available” users:

<iq from="HelloMix@mix.localhost" type="result" to="admin@localhost/MacBook-Pro-de-Mickael" id="mix5"> <pubsub xmlns=""> <items node="urn:xmpp:mix:nodes:presence"> <item id="5B1ADB972CEC"> <presence xmlns="jabber:client"> <c xmlns="" node="" ver="QgayPKawpkPSDYmwT/WM94uAlu0=" hash="sha-1"></c> </presence> </item> </items> </pubsub> </iq> Getting the list of messages

With a similar pubsub query, you can retrieve the list of messages:

<iq type='get' to='HelloMix@mix.localhost' id='mix5'> <pubsub xmlns=''> <items node='urn:xmpp:mix:nodes:messages'></items> </pubsub> </iq>

Server replies with list of messages:

<iq from="HelloMix@mix.localhost" type="result" to="admin@localhost/MacBook-Pro-de-Mickael" id="mix5"> <pubsub xmlns=""> <items node="urn:xmpp:mix:nodes:messages"> <item id="5B1ABD0BD973D"> <body xmlns="jabber:client">Hi, there is is test !</body> </item> <item id="5B1AB7F432DA5"> <body xmlns="jabber:client">Hi, there !</body> </item> </items> </pubsub> </iq>

As you can see there, there is need for improvement to rely on this list for history of messages. First, you do not have message attribution (see Caveats section), but this can be worked out.
Also, you do not have timestamp on the messages.

This part will likely change a lot in the future. I expect that a link with Message Archive Management support will be a more efficient and more consistent way to deal with message history.


At the moment it is unclear from XEP-0369 example how you match a message you receive to a participant. We are going to improve our implementation in the following way:

  1. Add a participant id on the item tag when broadcasting new participant.
  2. Add the participant id on the published items.
  3. Add the participant id in participants list on the publisher

Another issue is that the current specification and implementation will have trouble scaling and offer plenty of opportunities for “Denial of Service” attacks. This is something that will change in the future as the specification matures. However, currently, do not deploy or rely on this implementation for large-scale production services. The work is still an experiment to progress on the specifications by offering client developers to give real life feedback on a reference implementation of the current specification.


We are only at the beginning of MIX. However, we are excited to have reached a point where it is already usable in some cases.

It is still missing on administrative tasks, right management, user invitations, relationship with MAM archiving and probably a lot more. And we need consolidations on participants message attribution. However, we want to iterate fast with client developers to prototype implementation changes and have meaningful and real life feedback to improve XEP-0359.

Send us your feedback !

Distribuir contenido