Planet Jabber

Distribuir contenido
Planet Jabber -
Actualizado: hace 5 horas 42 mins

Tigase Blog: Tigase XMPP Server v7.1.3 Released!

1 February, 2018 - 01:31

Tigase XMPP Server v7.1.3 has been released! Please review the change notes below to see what has changed since our last release.

Daniel Pocock: Imagine the world's biggest Kanban / Scrumboard

30 January, 2018 - 18:52

Imagine a Kanban board that could aggregate issues from multiple backends, including your CalDAV task list, Bugzilla systems (Fedora, Mozilla, GNOME communities), Github issue lists and the Debian Bug Tracking System, visualize them together and coordinate your upstream fixes and packaging fixes in a single sprint.

It is not so farfetched - all of those systems already provide read access using iCalendar URLs as described in my earlier blog. There are REST APIs to manipulate most of them too. Why not write a front end to poll them and merge the content into a Kanban board view?

We've added this as a potential GSoC project using Python and PyQt.

If you'd like to see this or any of the other proposed projects go ahead, you don't need to be a Debian Developer to suggest ideas, refer a student or be a co-mentor. Many of our projects have relevance in multiple communities. Feel free to get in touch with us through the debian-outreach mailing list.

Christian Schudt: Babbler 0.7.5 released

27 January, 2018 - 20:16
I am pleased to announce a new bugfx release 0.7.5 for the XMPP Java client library. It only contains non-security related bug fixes.

Here's what got fixed:

  • Add stream ID to ConsoleDebugger output (Issue #105).
  • Improve CustomIQ example and documentation (Issue #112).
  • PingManager: Make exception for feature-not-implemented (Issue #113).
  • Allow configuration of custom name server for DNS SRV resolution.
  • MUC service discovery should handle items with non-room JIDs (Issue #106).
  • Connecting to stream hosts should not exceed configured response timeout (Issue #111).
  • Fixed DataForm.getReportedFields() to work when null.
  • Fix NullPointerException in RPC Value class (Issue #117).
  • Fix memory leak on WebSocket connection failure (Issue #122)
  • Ensure WebSocket session is closed, if server does not respond with <close/> element.
  • Store avatar image using correct hash code.

Peter Saint-Andre: Privacy FTW

27 January, 2018 - 00:00
Tomorrow (January 28th) is Data Privacy Day. Why not join in the celebration? Here are some suggestions to prevent absolutely everything you do online from being tracked:...

Jérôme Poisson: Build a decentralized internet with Libervia (Salut à Toi) !

25 January, 2018 - 19:53

Among many novelties of Salut à Toi in the next release (0.7), one has specially big potential: Libervia (the web frontend) is now a web framework.
"Yeah but there already so many of them!" I 've heard you saying… That is true, but this one is decentralized.

Building on standards, having tools for decentralization Using existing accounts

So, Libervia is based on SàT and XMPP in order to help you to build or rebuild the web. But why? Well, first the authentication, which is used on most websites nowadays, use the account you alread have. No, I'm not talking about the account on the big blue stuff or the noisy bird, but about your XMPP account, the one you are using with SàT, Movim, Gajim, Conversations or Pidgin, the one, in which your data can be located in your living room, and the one in which you can use any name you choose; the one that does not tract your activity.

The developer doesn't have to worry about this, and the users don't have to create yet another account on each website, or to use an account from a big central website (and then tell to web data hoovers where, when and to what you did connect).

Other advantage: we take profit for existing software. If you want to integrate other authentication ways (for instance if you want to use your GNU/Linux accounts), you just have to activate the suitable thing on your server (check this prosody list for instance, you'll surely find similar lists for other servers).

Pubsub, the decentralized database

XMPP is not a single technology, but rather a basis for a variety of coherent technologies, and pubsub is one of them. As a reminder, with it you can store data (or "items") in "nodes" (which can been seen as tables or collections in other databases), on "services".

A service can be anywhere on the network : in the same location as your web server, on the other side of the Earth, on the intranet or on a .onion in Tor network. Of course it's possible to keep data locally if needed, in particular for caching.

Let’s talk about cache, pubsub has a really nice property: we can subscribe to a node to be notified when there are changes on it (new data, data update or deletion). Taking benefit from this gives Libervia an automatic cache system: a page can be automatically put in cache, and later can be invalidated as soon as a modification happen. That is an other thing to simplify developer's life, and to improve the speed for the user.

Simplify life

Libervia has been thought to make things easy :

Appearance change

The framework is entirely based on template engine (jinja2). It is really straightforward to create new themes (from doing simple CSS change to major changes in pages structure). You just have to create a new directory with theme name, and to modify what you want, and only what you want: pages from default theme will be used if needed.

Integration between server and client

A bunch of tools are there to facilitate integration between client (in the browser) and the HTTP server. For instance, you just have to set "dynamic = True" in your Libervia page on server side to automatically activate a bidirectionnal dynamic communication system with the browser (based on websockets). A method can be used to send data at any time to the page, and an other one is called when data are emited from the browser.

This will go deeper in the 0.8 release, with the planed integration of Python to Javascript transpileur/interpreters. Libervia is using so far Pyjamas, a project which is not maintained anymore and which is transpiling an obsolete Python 2. To avoid future blocking on a single option, developers will have the choice to use a Python transpiler/interpreter (Brython and Transcript are planed), Simple Javascript ("vanilla"), or if they really like pain, any currenly popular Javascript framework.

Handling common tasks

A translation system is natively integrated (using Babel), and also filters for dates, backend UI templates rendering, or forms creation.

Templates are built to be reusables, so it's easy to include, for instance, comments in page.

A symbiotic ecosystem

I'll stop here for features, though the list is not finished (it's for instance possible to generate static website à la Pelican or Hugo).

This new tool has already been used in severals features in the incoming release, notably with the tickets or merge requests handlers that I have announced recently.

Next release of Salut à Toi will be an achievement, the first version ready for production, and is now a whole ecosystem to communicate, create, or do collaborative work, compatible with the rest of XMPP family.

If you want to stay up to date, follow my blog (which is using Libervia), or join us on our room

If you want to support us, you can either join the association, or help us on Liberapay.

Other news to come soon…

Erlang Solutions: MongooseIM 2.1.1 - More than a patch!

25 January, 2018 - 14:28

About 3 months have passed since the final MongooseIM 2.1.0 release.

Over that time we’ve gathered feedback from community and picked out improvements we really wanted to include in 2.1.0 (but the schedule is merciless!). The outcome is a release that closes the 2.x series.

This is the last stop before the leap into 3.0.0, when you may expect significant changes and features.

You might ask, “why do they call it >>More than a patch<<?“ as there are many catchier titles we could have used.

The reason for that title is honesty, and us admitting our miscalculation. What started as a small revision, sort of closure after 2.1.0, turned into quite an impressive set on changes.

What are these? Keep reading! Oh, and by the way: welcome to MongooseIM 2.1.1!

Secure connections to databases

Security and connection encryption have always been important topics, not only in chat applications.

To always stay ahead of the game, we’ve ensured that you can integrate MongooseIM with external (i.e.: not Mnesia) databases with TLS enabled.

We’ve updated our dependencies where it was necessary and made sure everything is well-documented. With 2.1.1 you may add extra hardening to your platform, no matter if your MySQL/Postgres/etc. is running in the same local network, or in a separate location. For example, you could have a MongooseIM cluster running on bare metal in your data center, while calling MySQL deployed in a cloud (for extra flexibility).

Obviously, it does not apply to Mnesia, which runs alongside MongooseIM and uses Erlang distribution for data exchange.

If you’d like to add a similar level of security to it, you may enable TLS for Erlang distribution protocol. This improvement also does not apply to Redis, as there is no official support for connection encryption in this database yet. We may add some recommendations on enabling it in an unofficial way in the future.


A word of explanation: Deumbrellification is a process of transforming an umbrella structure (an application that contains more applications) into a flat one. It makes developers’ life easier, as it means more intuitive code hierarchy and better integration with certain build systems.

How does it apply to MongooseIM?

For a large part of its lifetime, MongooseIM has been bundled with MySQL and PostgreSQL client libraries. It required a nested structure - the main application was placed in apps/ directory alongside these drivers. In the meantime, two events took place: we’ve begun fetching these drivers as dependencies and we’ve switched from Rebar 2 to Rebar 3.

The former change has left us with more up-to-date libraries downloaded by Rebar, and with a somewhat awkward project structure with only one application remaining in apps/ directory. While we were certain that we want to improve it at some point, it had a low priority because it simply kept working. In order to make MongooseIM usable as a dependency, there was a separate src/ folder with a file inside. It means that, while we had MongooseIM’s application file in src/, the rest of the code was in apps/ejabberd/. Again - not the prettiest solution, but it did its job.

The latter improvement required us to temporarily disable MongooseIM’s application file, because Rebar 3 no longer accepted such a structure. With the release of 2.1.0, community feedback strengthened our resolve to keep going and complete the journey. The full transition to OTP-compliance had to be done sooner rather than later; 2.1.1 is what we aimed for. All of the code is in src/ now, and all dependencies are fetched from other repositories. And, what is important, MongooseIM can be used as a dependency in other Rebar projects again!

For those who forked MongooseIM and modified it for their projects, we’ve prepared a comprehensive guide to what has been changed and how you should migrate your repository in order to sync with the current master.

Event Pusher

At some point a requirement arose for MongooseIM to be able to “publish” data to external endpoints. A fine example of such an event is sending a push notification request with message content to MongoosePush. Over time, it turned out that we need to deliver notifications not only to mobile devices, but also to other channels like Amazon SNS or a chosen HTTP endpoint. These three extensions were developed independently and existed as separate modules in MongooseIM.

In order to reduce maintenance costs and make the development of additional channels easier, we’ve introduced Event Pusher - a unified framework that combines the aforementioned extensions.

It’s an important change for everyone using mod_push, mod_http_notification and mod_aws_sns - these are now deprecated. Please check mod_event_pusher’s documentation to see how you can migrate.

Warning! Highly experimental!

2.1.1 includes a very important extension, which will be a subject of intensive development in upcoming version: the Global Distribution module.

Classic cluster intercommunitation in XMPP involves using distinct domains, and message routing between them requires interlocutors to be aware of the other party’s domain. While being a stable and well-tested solution, it is not very intuitive for many users and not so convenient for modern applications.

Global Distribution extension allows deploying multiple clusters that share a global routing table. It’s a solution for massive-scale projects that need MongooseIM instances in multiple data centers, while remaining transparent to the clients.

GD is highly experimental and verified mostly for 1-1 messaging. We haven’t ensured its proper interaction with other MongooseIM extensions yet. If you consider it a good fit for your use case - by all means try it and give us your feedback. Nevertheless, GD’s main “job” in 2.1.1 is to start maturing with the master branch.

Miscellaneous technical improvements & changes

Warning! Highly technical details ahead! Non-geeks may keep reading at their own risk!

Message Archive Management - moving forward

MAM is a commonly used extension in XMPP community. It has been published in 2012 (when 0.1 version was published) and undergone several important changes since then. First MAM implementation in MongooseIM was based on v0.2 of the XEP-0313. Subsequent updates to this XEP brought more or less significant modifications to the protocol (which involved XML namespace changes). MongooseIM’s mod_mam is compatible with multiple versions by default.

In 2.1.1 it is time to face the fact that v0.2 will soon be 5 years old and most (or perhaps all of them by now) of the client libraries are using v0.3 or newer protocol. From now on, v0.2 support is considered deprecated and will be removed in MongooseIM 3.0.0.

MySQL & UTF8 support

UTF8 support in MySQL has its surprises. One of them is the range of characters that utf8 encoding offers. It turns out that it doesn’t cover the full set. For example, it can’t store 4-byte emojis. In order to fix it, we’ve decided to set utf8mb4 encoding for all tables in our MySQL schema.

But it has created another issue - we’ve hit a limit for index key size because some of the varchar columns used in indices are pretty large. Changing their encoding from utf8 to utf8mb4 added an extra byte to every character, so indices based on them suddenly exceeded the 767-byte limit. We’ve decided to avoid extensive modification of column sizes in all affected tables, so the team has chosen to drop the official support for MySQL versions that do not have the “large prefixes” option implemented. As a part of this step, ROW_TYPE is now set to DYNAMIC.

In 2.1.1 the oldest supported MySQL version is 5.5.14. What is more, all servers of version 5.7.8 or earlier require additional configuration.

Important: No action is required for existing deployments, as we’ve modified only the schema file. All SQL backends in 2.1.1 are still 100% compatible with schema from 2.1.0 but obviously won’t benefit from this improvement, unless migrated.

Build fixes

MongooseIM 2.1.0 introduced an improved Message Archive ID generation method but it actually turned out that new C++ module could not be built on 32-bit systems. This issue has been resolved in 2.1.1 and the server can now be compiled both on 32 and 64-bit architectures.

The second fix helps developers using macOS High Sierra, which uses BoringSSL as default library for secure connections. MongooseIM’s dependency, fast_tls, relies on OpenSSL. Since it was compiled with a flat namespace, it resulted in mysterious runtime errors. 2.1.1 depends on a recent fast_tls version, which is not affected by this problem.


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


Special thanks to our contributors: @andrewvmail @igors!

What’s next?

MongooseIM 3.0.0 will feature several important changes and novelties. One of them will be a standard implementation of Inbox, which should cover most (or hopefully - all) of our community’s needs. Second is further improvements to Global Distribution. We are going to ensure that it is compatible with other MongooseIM extensions. The third goal is restructuring the documentation - we want to significantly improve usability and to introduce a more intuitive hierarchy of topics.

You may expect MongooseIM 3.0.0 release on April 17th!

Test our work on MongooseIM 2.1.1 and share your feedback

Help us improve the MongooseIM platform:

Star our repo: esl/MongooseIM

Report issues: esl/MongooseIM/issues

Share your thoughts via Twitter:

Download: Docker image with new release

Sign up to our dedicated mailing list to stay up to date about MongooseIM, messaging innovations and industry news.

Check out our MongooseIM product page for more information on the MongooseIM platform.

Monal IM: What on earth is iPhoneOSNano?

23 January, 2018 - 05:29

I was looking at the XNU source code today (don’t ask) and stumbled upon this line in a particular file (

SUPPORTED_PLATFORMS = macosx iphoneos iphoneosnano tvos appletvos watchos bridgeos

I can tell you what all of those are including the new Bridge OS that powers the Arm chips on the new Macs. I have never heard of iPhoneOSNano before. There are several references to it as a supported platform if you search for it✓&q=iphoneosnano&type=

Does anyone have any idea what this is?

/* Platform: iPhoneOSNano */ #define __DARWIN_ONLY_64_BIT_INO_T 1 #define __DARWIN_ONLY_UNIX_CONFORMANCE 1 #define __DARWIN_ONLY_VERS_1050 1 #endif /* PLATFORM_iPhoneOSNano */ #ifdef PLATFORM_iPhoneNanoSimulator /* Platform: iPhoneNanoSimulator */ #define __DARWIN_ONLY_64_BIT_INO_T 1 #define __DARWIN_ONLY_UNIX_CONFORMANCE 1 #define __DARWIN_ONLY_VERS_1050 1 #endif /* PLATFORM_iPhoneNanoSimulator */ Update: Its been there since 2014. No idea what it is though

ProcessOne: Using TLS Authentication for your Go Kafka Client

22 January, 2018 - 14:49

If you want to access a Kafka server that have enabled TLS, you will need to be able to use certificate to connect from your Sarama / Go client. This article outlines the needed steps to configure it properly.

Configuring your Kafka server to support authentication

If you are managing your own Kafka service and would like to enable authentication, you should read this article from Confluent documentation site: Encryption and Authentication using SSL.

Converting Java keystore and truststore

The first steps to easily handle your certificates from Go is to convert them to a set of PEM files.

Here are the commands to extract the Certificate Authority (CA) certificate:

$ keytool -importkeystore -srckeystore kafka.server.truststore.jks -destkeystore server.p12 -deststoretype PKCS12 $ openssl pkcs12 -in server.p12 -nokeys -out server.cer.pem

You can then convert your client keystore to be usable from Go, with similar commands:

$ keytool -importkeystore -srckeystore kafka.server.keystore.jks -destkeystore client.p12 -deststoretype PKCS12 $ openssl pkcs12 -in client.p12 -nokeys -out client.cer.pem $ openssl pkcs12 -in client.p12 -nodes -nocerts -out client.key.pem Go Kafka client supporting TLS authentication

To connect to the server and authenticate with TLS, you just need to generate the proper TLSConfig. Here is the relevant code:

func NewTLSConfig(clientCertFile, clientKeyFile, caCertFile string) (*tls.Config, error) { tlsConfig := tls.Config{} // Load client cert cert, err := tls.LoadX509KeyPair(clientCertFile, clientKeyFile) if err != nil { return &tlsConfig, err } tlsConfig.Certificates = []tls.Certificate{cert} // Load CA cert caCert, err := ioutil.ReadFile(caCertFile) if err != nil { return &tlsConfig, err } caCertPool := x509.NewCertPool() caCertPool.AppendCertsFromPEM(caCert) tlsConfig.RootCAs = caCertPool tlsConfig.BuildNameToCertificate() return &tlsConfig, err }

The code is then extremely simple to connect:

func main() { tlsConfig, err := NewTLSConfig("bundle/client.cer.pem", "bundle/client.key.pem", "bundle/server.cer.pem") if err != nil { log.Fatal(err) } // This can be used on test server if domain does not match cert: // tlsConfig.InsecureSkipVerify = true consumerConfig := sarama.NewConfig() consumerConfig.Net.TLS.Enable = true consumerConfig.Net.TLS.Config = tlsConfig client, err := sarama.NewClient([]string{"localhost:9093"}, consumerConfig) if err != nil { log.Fatalf("unable to create kafka client: %q", err) } consumer, err := sarama.NewConsumerFromClient(client) if err != nil { log.Fatal(err) } defer consumer.Close() consumerLoop(consumer, "mytopic") }

The consumerLoop has nothing special regarding TLS authentication. You can just use your standard Sarama code. You can read the full code on Github: base-client.go.

Monal IM: Next Mac Beta is up

18 January, 2018 - 15:00

Another Mac beta is up.  I have fixed all the crashes that came in on the last beta.

JC Brand: Converse 3.3 has been released

18 January, 2018 - 14:30

Last night I released version 3.3.0 of Converse.js, and as often happens with big releases, I made a quick bugfix release (3.3.1) today.

The bugfix release turns off some CSS3 animations for new messages which caused degraded performance on Firefox. On Chrome the animations render smoothly, so if you'd like you can still turn them on with the show_message_load_animation config option.

What's in the release?

Maintaining a long-term open source front-end JavaScript library almost feels like a Sisyphean task sometimes. As soon as you've rolled the big stone up the hill, the whole JS ecosystem, best practices and tooling changes and you find yourself at the bottom of the hill again.

This release is therefore heavy on changes under the hood, with the aim of modernizing and improving the quality of the code.

Besides that, I also spent time squashing lots of small usability bugs and on improving performance.

Converse.js now uses a Virtual DOM

Various views, such as the registration form, are now rendered by means of a Virtual DOM. I wrote a new Backbone view called Backbone.VDOMView for this, and blogged about it here:

No more jQuery

Looking at the git log, I started rewriting code to not use jQuery in January 2017.

So this change has been a year in the works. I often asked myself whether I should spend time on this and not rather do something else, like adding new features, especially since removing jQuery has taken a lot of time.

However, there were some good reasons, or perhaps motivations, for me to remove jQuery.

Before ES6 promises were available, I used $.Deferred. However, jQuery's deferreds weren't compatible with Promises, so when ES6 Promises came around, I had to rewrite lots of code to use Promises.

I used $.show and $.hide quite a bit, and then it turned out that the way jQuery was doing it (by adding/removing display: none to the DOM element) is not good practice and also very slow.

So I started writing my own utility functions to replace jQuery's.

The last straw for me was when jQuery 3 came out, and half of Converse.js's ~240 tests failed once I plugged it in.

After spending some time trying to figure out what backward incompatible changes they made and how I should update the code, I decided to instead rip jQuery out entirely.

It's still used in the tests, but it's no longer included in any build.

Since removing it, I've noticed a remarkable reduction in time to run the tests.

By looking at how quickly the tests run now, the code seems to run much faster without jQuery.

Less weight

Besides removing jQuery, I also updated Converse.js to load translations at runtime, and only the exact translation JSON file that's needed.

Due to these changes, the unminified built has shrunk from 3.38MB to 2.8MB, and the minified build from 1.66MB to 1.2MB.

And this is while adding the virtual DOM code.

Route to a specific chat room via the URL

It's now possible to directly link to a specific chat room, or to the registration page (instead of the login page) via the URL.

For example, the URL will take you immediately to the Converse.js "Discuss" chat room, once you've logged in.

What else?

Lots of other bugfixes and improvements have been added in this release. For more details, check the changelog.

Notable absent from this release are some desired features, such as file sharing, message corrections, message receipts and the like.

I would love to add some of these often requested features, however I had to get the house in order so to speak, by modernizing the code and squashing lots and lots of little usability and performance bugs.

That said, Converse.js takes up a LOT of my free time and not a single line of code in this release was paid for.

If you or your company make use of converse.js, please consider sponsoring it on Patreon or Liberapay.


Thanks goes out to everyone who's made pull requests and bug reports over the last months.

And thanks also to the folks who hang out in the Converse.js Discusss chat room and who have there provided valuable feedback.

Monal IM: New Mac beta up

16 January, 2018 - 19:50

There is a new beta of the Mac client with all of the recent  fixes and addition of group messaging.  I know there are still a few issues, for example it doesn’t save the password for auto joining a bookmarked group. Im curious to see what other issues people encounter. Its been working ok for me the last couple of days as I’ve been using it to lurk on the XMPP developers group chats.

Paul Schaub: Smack: Some busy nights

16 January, 2018 - 13:11

Hello everyone!

This weekend I stayed up late almost every evening. Thus I decided that I wanted to code something, but I wasn’t sure what, so I took a look at the list of published XEPs to maybe find something that is easy to implement, but missing from Smack.

I found that XEP-0394: Message Markup was missing from Smacks list of supported extensions, so I began to code. The next day I finished my work and created Smack#194. One or two nights later I again stayed up late and decided to take another look for an unimplemented XEP. I settled on XEP-0382: Spoiler Messages  this time, which was really easy to implement (apart from the one little attribute, which for whatever reason I struggled to parse until I found a solution). The result of that night is Smack#195.

So if you find yourself laying awake one night with no chance to sleep, just look out for an easy to do task on your favourite free software project. I’m sure this will help you sleep better once the task is done.

Happy Hacking!

Monal IM: The new group chat UI

16 January, 2018 - 05:29

I’m getting closer to the UI that I would like for group chats. It might not be the greatest thing for power users but I suspect it will work well for most people. Especially those familiar with iMessage or other chat clients already.   Things to note in the picture below, proper nick name support and subjects. I’ve decided to treat the subject like the group name.  I’ve observed that in other chat clients people like to change the group name on a whim mid conversation.  This is not something the muc spec supports as far as I can tell. People  can however change the subject, so subject it shall be.

Monal IM: Mac has group chat

12 January, 2018 - 19:52

The Mac client has always had group chat but didn’t have a UI surfacing the functionality. I am adding that now.  I know favorites and auto join have long been asked for. I hope to have that in the iOS client as well. 

ProcessOne: ejabberd 18.01

12 January, 2018 - 11:29

ejabberd 18.01 is a bugfix release. This version of ejabberd Community Server is a good candidate for Linux distributions packaging as it concludes a year of development and stabilised all recent changes for production use.

  • Fix TLS driver memory management
  • Fix privacy_set command
  • Report ‘fs’ support as unavailable on SunOS
  • Let mod_block_strangers bounce an error when a message is rejected

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.

Paul Schaub: Reworking smack-omemo

10 January, 2018 - 16:36

A bit over a year ago I started working on smack-omemo as part of my bachelor thesis. Looking back at the past year, I can say there could have hardly been a better topic for my thesis. Working with Smack brought me deep into the XMPP world, got me in contact with a lot of cool people and taught me a lot. Especially the past Google Summer of Code improved my skills substantially. During said event, I took a break from working on smack-omemo, while focussing on a Jingle implementation instead. After the 3 months were over, I dedicated my time to smack-omemo again and realized, that there were some points that needed improvements.

One major issue was, that my “OmemoStore” class, which is responsible for storing keys, sessions, etc. was not having access to the users data before the user logged in. The reason for that is, that my implementation allows multiple OMEMO instances to be running on the same connection. That requires the OmemoStore to store keys for multiple instances (devices), which I distinguished based on the Jid and deviceId of the user. The problem here is, that the Jid is unknown before the user logged in (they might use a burner jid for example, or use an authentication system with username and password which differ from the jid).

While this is an edgecase, it lead to issues. I implemented a workaround for that problem (using the username instead of BareJid in case the connection is not authenticated), which caused numerous problems.

I thought about replacing the Jid as an identifier with something else, but nothing was suitable, so I started a major rework of the implementation as a whole. One important aspect I wanted to preserve is that smack-omemo should still be somewhat usable even when the connection is not authenticated (ie. the user should still be able to scan qr codes and make trust decisions).

The result of my work (so far) is a diff of “+6,300 −5,361″, and a modified API (sorry to all those who already use smack-omemo :O). One major change is, that the OmemoStore no longer stores trust decisions. Instead those decisions are now made by the client itself, who must implement a OmemoTrustCallback. That way trust decisions can be made while the OmemoManager is offline. Everything else what remained in the OmemoStore is only needed when the connection is authenticated and messages are received.

Furthermore I got rid of the OmemoSession class. Session handling is done in libsignal already, so why would I want to have a session related class as well (especially since libsignal doesn’t give you any feedback about what happens with the session, so you have to keep sessions in sync manually)? I recommend everyone who wants to implement OMEMO themselves not to create a “OmemoSession” class and instead rely on libsignals session management.

OMEMO sessions are somewhat brittle. You can never know, whether a recipient received your message, or if it failed to decrypt for some reason. There is no signalling to provide feedback about the sessions state. Because of the fact that even message encryption can go wrong, the old API was very ugly. Originally I first checked, whether there are devices which still need a trust decision to be made and threw an exception if that was the case. Then I tried to build sessions for devices without session and threw an exception when session negotiation failed. Then I tried to encrypt the message for all recipients and threw an exception if something went wrong… Oh and the exception I threw when sessions could not be negotiated contained a list of all devices with intact sessions, so the user could retry to encrypt the message, only for all devices which had a session.


The new API is much cleaner. I still throw an exception when there are undecided devices, but otherwise I always return an OmemoMessage object. That object has a map of OmemoDevices for which message encryption failed, alongside the respective exceptions, so the client can check if and what went wrong.

Also sessions are now “completed” whenever a preKeyMessage arrives.
Prior to this change it could happen, that two senders chose the same PreKey from a bundle in order to create a session. That could cause on of both session to break which lead to message loss. Now whenever smack-omemo receives a preKeyMessage, it instantly responds with an empty message to make the session stable.
This was proposed by Philipp Hörist.

Other changes include a new OmemoStore implementation, the CachingOmemoStore, which can either wrap other OmemoStores to provide a caching layer, or can be used standalone as an ephemeral store for testing purposes.

Also the integration tests were improved and are much simpler and more readable now.

All in all the code got much cleaner now and I hope that at some point it will be audited to find all the bugs I oversaw (everyone who wants to take a look for themselves, the code can currently be found at Smacks Repository. I’m always thankful for any types of feedback)

I hope this changes will make it to Smack 4.2.3, even though here are still some things I have to do, but all in all I’m already pretty satisfied with how smack-omemo turned out so far.

Happy Hacking!

Monal IM: Monal OSX 2 beta 7 out

10 January, 2018 - 00:19

OSX Beta 7 has been pushed  out. This version support making and receiving Jingle calls.  I have also added Monal to brew. You can now do this:

brew cask install monal


ProcessOne: ejabberd 2017 year in review

9 January, 2018 - 11:56

This was an amazing year for ejabberd! With almost regular monthly updates, tons of new features and improvements, we worked hard to make ejabberd the best XMPP server available. Let’s take a look at the past year, and let us wish you a Happy New Year!

January – 17.01

We started last year with a cleanup. Most notably, we introduced SSL in PostgreSQL connections and improved database migration.

March – 17.03

This release introduced dynamic configuration reload, to ease ejabberd administration and management. To ease end users’ life, we created mod_block_strangers to significantly reduce XMPP spam.

April – 17.04

One of the most significant features of 2017 was introduced in April: Redis and SQL backends can now be used to store RAM tables, just like Mnesia.

May – GSoC

In May, ejabberd was yet again accepted to Google Summer of Code ’17. With two projects, Support for “Let’s Encrypt” ACME protocol and Server-to-Server stream management support it was looking like a super-interesting summer.

June – 17.06

Another significant ejabberd update happend in the middle of 2017. This time, we introduced a handy Certificate Manager, new caching system and the highly demanded Riak support.

August – 17.08

At the end of summer we produced another ejabberd release that improved the XEP-0357: Push Notifications support, as well as made it easier to configure a cluster backend – although only for Mnesia, for now.

September – 17.09

This was a busy month for ProcessOne. The result of the two ejabberd GSoC projects was very satisfying, both for us and the participants. Additionally, this month’s ejabberd release introduced a new, much better avatar module, implemented XEP-0368, and updated OpenSSL libraries in our installer.

November – 17.11

Happy Birthday ejabberd! It’s been 15 years :) Apart from the celebrations, this month we introduced “Let’s Encrypt” ACME support created during ejabberd GSoC, and implemented much demanded PubSub improvements.

December – 17.12

With the end of this amazing year for ejabberd, we were happy to announce a major XMPP/PubSub project migration to ejabberd server. And with another successful ejabberd release, we introduced SNI for inbound connections, and improved support for PubSub v1.14 and OMEMO.


2017 was an amazing year for ejabberd, but we are not stopping there! Looking forward, we are happy to announce that ejabberd is compatible with XEP-0387: XMPP Compliance Suites 2018 as well as passes the Conversations Compliance Suite.

We have many new features and improvements lined up for this year. Look forward to our next release! To stay tuned, be sure to follow us on Twitter, Facebook, or subscribe to ejabberd newsletter.

Monal IM: Mac Jingle Voice Calls Work

9 January, 2018 - 01:30

Tested out jingle voice calls on the Mac today.  There is a call button on the toolbar but you can’t initiate calls quite yet. You can however, accept a call, talk and hang up.  Monal is the bare bones ui with the hang up button :).  Try it out with the beta that is currently available. 

Monal IM: Revisiting Muc

8 January, 2018 - 17:00

Muc aka Group Chat has been something that’s been in Monal since the beginning.   I’ve decided to throw out all the old  UI for this and remake it.   The old version was something I wrote before I had very many users and based on my experience using pidgin/adium/gaim. It doesn’t work anywhere near as nice as I would like it to. Also given the greater importance of group conversations these days, I have decided make it a top level item.   There isn’t a lot of room for things on the tab bar at the bottom.  I think this is what the current four will be.