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:

Objectives

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

Accomplishments

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:

Conversations

  • 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

Converse.js

Dino

Packaging

Poezio

Prosody

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.

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 2018. Licensed under CC-BY-SA 4.0 unless specified.

Powered by Hugo & Kiss.