July 17, 2019

New Sprint, new goodies

Une traduction française est disponible sur le blog de JabberFR.

On this weekend of Bastille day some of us gathered and worked around some interesting new features in XMPP implementations. Wisolv – tailor-made software development company – generously sponsored the venue and provided us with their office in Villeurbanne (next to Lyon).

I think most of us are happy with this sprint, we managed to get quite some work done. On the agenda were DOAP, Message Reactions, Occupant-id, various fixes and discussions, also including work on a Jabber client for Haiku!

Bastille day fireworks by olek_impek.

DOAP - Description Of A Project

Lists of XMPP software are not machine readable and the information contained within them varies in quality. The DOAP project provides a way for each project to host a semantic description of itself, which can then be used by anyone to display information about XMPP software.

A few years ago, Link Mauve submitted a proposal to extend DOAP with information most of these lists want to expose, but it didn’t get much interest… until this sprint! PulkoMandy wrote a bunch of XSLT stylesheets to render such tables, Link Mauve wrote a schema and a JavaScript integration into the XEP pages (an example can be seen here for Bookmarks), and all client authors present at the sprint wrote a DOAP file for their client.


Some time ago Movim implemented reactions using the Message Attaching specification. Dino developers felt that the situation could be improved, especially some issues with non-supporting clients, and started working on a new specification a few weeks ago. The protoXEP has been sent to the inbox this weekend!

Edhelas reworked the Movim implementation using this new specification, mathieui worked on an implementation in Poezio (not yet merged, but the Slixmpp bits are), and fiaxh and larma started an implementation in Dino.


Occupant-id is a protoXEP that was also submitted by larma this weekend.

It mandates that MUC components provide a stable and unique id that is attributed per room per user (bare real JID). This is especially useful in semi-anonymous rooms where it is usually not possible to ensure messages are coming from the same participant between rejoins.

Some clients are talking about requiring occupant-id for features like Last Message Correction or Reactions in semi-anonymous rooms.

A prosody module is now available and is usable with the current release (0.11) or trunk.

And more

PulkoMandy started porting Jabber4Haiku – now renamed Renga – to gloox. Fiaxh worked on stable and unique IDs in Dino. Slixmpp finally uses non-predictable ids. Mathieui and I worked around issues with asynchronous APIs in Poezio and Slixmpp. xmpp-parsers got a new release, fixing documentation on the way!

What’s next

I’d like to thank Wisolv again for hosting us this weekend.

Next month members of the community will be present at FrosCon at the XMPP booth, and at CCCamp2019. See our events page for more information about future events!

February 25, 2019

Slixmpp gets OMEMO support

TL;DR: Developers can already experiment with the slixmpp-omemo plugin.
Please give us feedback on the tracker or in the channel!

After almost a year since I started working on the OMEMO encryption mechanism support for Slixmpp, I am happy to finally announce a first release. I would like to get feedback. I am sure there are still plenty of things to improve, and so I encourage developers to bring out their inner vandal, break it and report their findings.

This library provides an interface to python-omemo.

You can find the code at https://lab.louiz.org/poezio/slixmpp-omemo.
Documentation is available in the README, and there is also an echo bot, with lots of comments.

Thanks to Syndace and Daniel for the help with the OMEMO implementation, and mathieui and Link Mauve for the help on Slixmpp and moral support.

Separate repository

As you may have noticed, this plugin is served via a separate repository. This is for licensing purposes. As much as I like GPL and copyleft, Slixmpp is licensed under the MIT license, and this is probably not going to change. Fortunately for Slixmpp this split should not last forever.

The python-omemo library that is used – developed by Syndace – is a complete reimplementation of the Signal Protocol unlike python-axolotl, which is a port of the original library implemented in Signal.

There are bits that prevent him from releasing his library under MIT at the moment, I am not entirely sure to grasp all the details but this is being worked on.


There are still lots of things to be improved in the OMEMO specification.

I would personally like to see what is usually called Full Stanza Encryption added to the spec. Today, an OMEMO implementation will only encrypt the plaintext (<body/>) part of messages you send, and either leak everything else (e.g., chatstates, receipts, corrections, xhtml-im), or effectively disable them, for privacy-conscious implementations.

I would also like to drop Forward Secrecy, in the context of Instant Messaging. And I would like to have a better way to manage all these device keys, fortunately there are people working on this already.

Not having all these options (or having them, in the case of Forward Secrecy) heavily degrades user experience in my opinion, and that is my main concern.

Not having OMEMO though, is also not great either for user experience, many implementations nowadays provide it, and some even enable it by default. This makes it impossible for us Slixmpp users to communicate without having to ask the sender to turn it off first.

While I would prefer to see other alternatives, this library should help with the current situation, and we can go back to work on fixing the world.

What’s next?

Apart from the tons of bugs that I’ll have to fix in the following days/weeks, now that we have the foundations next step is to implement OMEMO in Poezio.

Any help is welcome!

EDIT 2019-03-02: A small but important precision on Full Stanza Encryption. I did write “what is usually called”, because it does not actually consist in encrypting the full stanza. The server still needs to see routing information, as well messages hints (e.g., <no-copy/> or <no-store/>) designed for the server rather than the final recipient. A better name might be “Arbitrary Extension Element Encryption” (thanks Flow.)

August 30, 2018

Cambridge XMPP Sprint

This month, on August 18-19th, was held the first developer event in the XMPP community for a long time.

The idea came up at the Gulaschprogrammiernacht, in Karlsruhe earlier this year, talking with Daniel Gultsch, and JC Brand. We gathered there to work on an implementation of the OMEMO encryption mechanism for Converse.js, and Poezio. Converse.js is currently seeing the changes merged. It’s taking a bit more time for Poezio, but we’ll get there.

JC mentioned sprints organised by the Plone community, and I felt that was something we were missing for XMPP. While the XMPP summit is held every year before FOSDEM, it is often more oriented towards protocol discussions. Developer events are scarce.

I set a goal for myself to start a movement in the community, gather interested people, and work together to improve the ecosystem.

The first event – of this hopefully long series of events – was held this month, sponsored by my employer, Collabora, in their UK offices in Cambridge!

Who attended

And remotely:


We started the sprint with a short standup, to discuss ideas gathered during the previous weeks online, and to narrow the focus to a few feasible items. At this point it became clear that User Experience (UX) would be an important topic during the weekend, as it is also within the XMPP community of late.

Here is roughly what was mentioned, and what we planned to work on:

  1. Bookmarks: Sync Private XML bookmarks with PEP ones.
    XMPP has different standard places to store bookmarks, and this has often proven to be a painful experience to the user, when using different clients for example. The objective here was to transparently synchronize both stores, so that the user gets an overall nicer experience.
  2. Message Attaching and Reactions.
    Message Attaching defines a way by which one can indicate that a message is semantically related, “attached”, to an earlier message in the discussion. This can be useful for reactions, for example, or even for previews of links.
  3. In-Band Registration in clients that don’t support it, namely Dino and Poezio.
    In-Band Registration is a mechanism that allows clients to provide an interface to create accounts on servers that allow it. This way the user doesn’t have to go through multiple hops to start chatting with their friends.
  4. Consistent color generation.
    This specification aims at providing algorithms that will be used to generate deterministic colors, so that they stay consistent across clients, and thus help with recognition, for nicknames in groupchats, for example.
  5. Hats.
    Hats allow for customised roles and affiliations in chatrooms, an extension of the usual roles and affiliations. They can be used as regular “titles” that are displayed to other users, (e.g., “Teacher”, “Student”, “Developer of XYZ”), but can also carry permission information. The current specification needed reworking as it has been left with lots of TODOs, and was not really finished nor implementable.

Hard working developers


Not everything that was mentioned on the saturday morning was worked on, but we did manage to get quite a few things done. This was also the opportunity to discuss about various topics.

As this is also something I would like to encourage, I am happy to say that first-time XMPP users were able to contribute on projects, by providing feedback as well as patches.

Here is a non-exhaustive list of issues/topics we worked on:


  • Use PEP Bookmarks if urn:xmpp:bookmarks-conversion:0 is announced. commit
  • Experiments with Consistent Color Generation:
    Disabled by default variant that uses HSLUV instead of YCbCr. HSLUV provides more uniform colors and also ‘nicer’ colors by default. commit
  • Updated Conversations Compliance Checker help for Prosody: pull/6






XEPs (specifications)

  • Synchronisation between vCard-based and PEP avatars: pull/700
  • Started XEP for synchronisation between Private XML and PEP bookmarks
  • Message attachments XEP updated: pull/696
  • Started writing of a counter-proposal XEP for Hats.

Original information about the event is now listed in the wiki.

I would like to thank everybody who participated, helped organise the event, and made all this possible. Thanks Collabora again for sponsoring the event and providing the venue.

What’s Next

Talks of organising a next sprint this year in Düsseldorf, or Paris, are already happening. I would also like to encourage anybody who wants to organize similar events in their region. If you are interested and want to help organize, or participate, please join the chatroom for more information.

July 13, 2018

Hello World

Grump Grump.

New start.
Let’s hope this blog engine is able to generate content by itself. Empty blog is sad blog.


June 13, 2015

Best IM of the world

This is a translation of this article in French.

Although Instant Messaging (also known as IM) has been in our everyday life for a while now, I am under the impression that we limit ourselves to old habits or features that we could update to offer our users innovative and modern services they all dream about.

Here I will share some groundbreaking ideas of mine that flourished as I have worked for a few years in this field. You are free to do whatever you want with them. Maybe they could be a base for some next generation application and revolutionize our communication process.

Fasten your seatbelt and let’s go!

1. Redesign Authentication!

Let’s be honest, credentials are crap, registering an account is counterintuitive and annoying. The first thing I would suggest is to rethink the whole registration process. This little form you know, that every user must fill in on each service, website or platform he wants to log in for the first time.

To tell the truth, when the user face this registration form, he hesitates, it’s always a burden to have to fill in these fields. Why not just remove this step? The first time a user logs in, we attribute him a unique identifier (a number). We would then invite him to fill in his profile, since he would already be logged he would much easily give in information needed to complete this step.

The point is to manage to correctly uniquely identify the user before getting any input. Impossible? It depends what your target platform is. Say we want to build an IM service for mobile phone, we can use the IMEI, or just the phone number currently in use. Smart isn’t it?

2. Federate the network?

The previous idea comes with some limitation. Since we want to make the registration process execute automatically, we can’t ask the user where he wants to register his account. We don’t want to make the user choose, that will lead him to hesitate, and would increase the chances that he would leave.

The best solution is certainly to skip this step as well. We would have a unique server where every account is created. This way we would have one user, one cell phone, one unique account, one service.

Better, don’t you think?

3. Add new contacts

Once again, users are lazy, and once the account is created they always have to add in or invite people they want to talk to. This long and tedious process can discourage even the most brave. It would be nice to already have a contact list ready for use, with whom the user could talk right away.

Where can we find such a list? There must be something on the phone that we can use, like a phonebook. Bingo! Let’s take the whole list of contacts, send it to our server, match it to phone numbers that are already registered and link the accounts. This supports our idea of the phone number being the unique identifier.

Nobody will have any problems with the fact that we keep their phonebook on our server in exchange for the great service we provide, right?

4. Respect the users

The previous idea is quite appealing, but it can scare users who are concerned about their privacy, and their contacts that wouldn’t like their numbers to be sent to a server that they don’t know about. What can we do to reassure them about handling their personal data?

There is one word that can calm everyone down: encryption. If communications are encrypted it shows that we do care about their privacy, right? We can guarantee them that communications between our users and the server will be encrypted. A bit of SSL/TLS here and there and we’re done!

We can go a step further in this direction to prove our good faith and show that we want a modern and innovative service, and encrypt every single message! It doesn’t really matter since we already have:

  • the user’s phone number,
  • his profile,
  • his complete phonebook with all the attached data (email, address, etc.),
  • and also the entirety of his exchanges (sender, receiver, sending time, receiving time, reading time, answering time, weight of the content, etc.).

And as we know, metadata is by far more important than the data so end-to-end encryption is a good compensation for all this generosity.

5. Bonus idea: Open the platform

In order for us to maintain the users’ trust, we can play the openness card, believe me it works every single time. We need two killer arguments for this:

Provide an API

Of course! Some reworking of the communication protocol, a bit of documentation in our Wiki and here it is! Openness. Users can now talk to the world and write libraries in any language they want. Don’t forget to have some authorization protocol so you can strike off those who would try to look too close.

Open our client applications

Open sourcing our clients would definitely guarantee transparency. Just do it. We can then prove that encryption is applied correctly without any flaw. We can keep a few backdoors in apps we compile and distribute while keeping the codebase opened.

A nice ripple effect that we will gain from opening the codebase is contributions, bugfixes and new features from the community. We keep a hand on the API so we can monitor what comes in and goes out. Be careful of not being too chatty, though.

That’s it!

Here are some ideas that will definitely help you in building the new IM application on mobile, you can even try porting it to other platforms with a few changes.

With the third idea, I can guarantee you exponential growth since you get an entire phonebook each time a new user subscribes.

Playing the card of openness can be done later, in case problems concerning privacy surface, so you can claim transparency. It will depend on how open you want to be concerning your users’ privacy.

Nobody told me?

It seems there are already such apps:

Q: Who can I write to?

You can write to people, who are in your phone contacts and have Telegram.

For more ideas:

And for those who are not lazy, there is real Instant Messaging, there is XMPP.

Thanks to liori and lool0 for the help and corrections.

© Maxime “pep.” Buquet 2019. Licensed under CC-BY-SA 4.0 unless specified.

Powered by Hugo & Kiss.