MongooseIM 3.2 - Meet our Inbox

by Piotr Nosek

Since the last release of our enterprise-ready, highly scalable IM platform: MongooseIM 3.1, the team has been working at full speed on the expanded set of features and improvements aimed to bring MongooseIM to the next level. What comes as a result is MongooseIM 3.2. With its highlights such as full-featured Inbox, worker pool unification, PKI for BOSH and Websockets and multi-aspect TLS integration, this release becomes a big step in the evolution of our server!

What we love about MongooseIM 3.2 ?!

The latest iteration of MongooseIM not only introduces exclusive and uncommon solutions, such as the advanced inbox or multi-aspect TLS integration, it also becomes more and more open to new angles in providing a full-fledged messaging solution, that responds to global market demands.

Among the highlights of the 3.2 release, there is another bundle of Inbox improvements. The most significant one is the possibility to attach unread messages count to push notifications so application badge may be updated appropriately. Our full-featured Inbox now gets more and more mature, becoming a complete extension for virtually every chat application!

We also added PKI for BOSH and Websockets, allowing web XMPP clients to authenticate with TLS certificate.

This version certainly makes devops’ life easier. Unified worker pools, provided in 3.2, enable much more convenient and consistent configuration of outgoing connections (e.g. to databases). They also grant better stability, predictability, and inspection of their behavior.

Meet our Inbox

Inbox in MongooseIM 3.2 received a couple of nice improvements but one of them is particularly important: integration with the Event Pusher. Among other things, this component is responsible for delivering push notifications data to MongoosePush and other services, and using it with inbox opens up some new possibilities. One example would be simplifying incrementing the unread count (the “badge”) which up until now was hardcoded to “1” and required extra effort from the frontend team when trying to display the real number of notifications. Push notifications implementation was unable to access this information at the moment of event delivery and the client application had to work around this and risk being inaccurate.

With the new update, a valid number is always attached to push notifications so the applications may display it in a simple, natural and precise manner. MongooseIM 3.2 introduces a number of updates that should make your client development team much happier. All inbox query results include total unread messages count and the number of “active” (with at least one unread message) conversations. A client may also filter explicitly for active conversations only.

We would like to present our new Inbox demo, showcasing three of the newly added features:

  1. Unread messages counter implemented for push notifications
  2. New filtering option - a user may choose to query for conversations with unread messages only
  3. Extended error description - error messages readability is improved.

Examples in the demo are prepared with the Forward application.

Worker pools - unite!

When you take a look at MongooseIM 3.1 - Inbox got better, testing got easier you may notice an inconspicuous paragraph “Worker pool unification”. This small internal improvement expanded into one of the most satisfying cleanups in MongooseIM in recent history. It affects not only the server’s inner workings but also changes the way pools are configured.

Until 3.1.x (included) the config schema varied between multiple connection types:

  1. For RDBMS there was an odbc_server key (misleading, right?) with several unlabeled elements (you had to remember their order or use docs). Pool size was defined under separate key. Oh, right, there was yet another key to define the pool names alone. And you couldn’t define common pool for all XMPP domains.
  2. For HTTP, we had an http_connections key. Pool size was provided as one of key-value pairs.
  3. For Cassandra you could specify the pool size as well. As one of cassandra_servers tuple elements. And so on…

You can clearly see that various aspects of configuration (how pool size was provided, was the pool global or per-host) were inconsistent and could lead to confusion.

In 3.2 these connections are governed by a dedicated server logic, which in future will allow us to expose generic metrics or implement extra debugging tools. Configuration-wise, all of these tuples have been replaced with outgoing_pools list, where every element follow simple convention: {Type, Host, Tag, PoolOpts, ConnectionOpts}. Type resolves to one of implemented pool specifications, such as rdbms, riak or http. Host indicates if there should be only one pool for all XMPP domains, separate pools for every XMPP domain or just one pool for one of the domains. Tag is a name that can be referenced in specific extensions. It allows to e.g. have separate RDBMS pools for write and read operations. PoolOpts are pool-centric options, such as worker count or worker selection strategy. ConnectionOpts are items specific to the chosen connection driver.

Our work here is still not finished. We would like to leverage the common logic even further. It is possible to create more interesting metrics. We also plan to make existing extensions more flexible, as currently many of them use hardcoded pool tags or even hosts. It is a temporary state so you may expect it to improve in future releases!

Certificates everywhere

Security is paramount whether we are talking enterprise or not. SASL EXTERNAL authentication mechanism was introduced in MongooseIM 2.2. As a reminder: it allows XMPP clients to authenticate with TLS certificates (without extra password). It was originally implemented only for raw TCP connections so web clients could not benefit from this feature. MongooseIM 3.2 extends this method’s capabilities and now it may be used with Websocket (wss://) and BOSH (https://) connections.

PKI authentication is the current industry standard in terms of secure authentication, so MongooseIM 3.2 brings this feature to a whole new audience.

Other improvements

MongooseIM 3.2, just like previous releases, includes many (non-)technical improvements. A large part of them is purely internal or developer-focused. See the changelog to read about all of them. Here are some highlights!

Migration guide

We all know that it’s a good idea to always keep your software up to date. One exception is a certain OS which may suddenly remove all of your data after the automatic upgrade. In our effort to steadily improve MongooseIM’s quality, intuitiveness and feature set, sometimes bold changes have to be made. We are aware that sometimes adjusting config file or custom code base may not be that straightforward.

For all of these users, who always stick to the most recent release of MongooseIM, we’ve created a Migration Guide section in our documentation. Each page will describe what needs to be changed to migrate between subsequent versions. The current chapter is “3.1.1 to 3.2” and it may be found here:


As a part of our effort to improve consistency in our source code and the repository, we have changed the name of MongooseIM’s main config file from ejabberd.cfg to mongooseim.cfg. It is definitely more intuitive. However, existing projects, which deploy MongooseIM releases with custom scripts, may need to have their pipelines updated.


Please feel free to read the detailed changelog. Here, you can find a full list of source code changes and useful links.


Special thanks to our contributors: @getong @igors @justinba1010

Test our work on MongooseIM 3.2 and share your feedback

Help us improve the MongooseIM platform:

  1. Star our repo: esl/MongooseIM
  2. Report issues: esl/MongooseIM/issues
  3. Share your thoughts via Twitter: @MongooseIM
  4. Download Docker image with new release
  5. Sign up to our dedicated mailing list to stay up to date about MongooseIM, messaging innovations and industry news.
  6. Check out our MongooseIM product page for more information on the MongooseIM platform.
Go back to the blog


Thank you for your message

We sent you a confirmation email to let you know we received it. One of our colleagues will get in touch shortly.
Have a nice day!