Planet Jabber

July 30, 2015

Ignite Realtime Blog

A new WebSocket plugin for Openfire

While there has long been support in Openfire for early versions of XMPP over WebSocket (per Dele's fine original plugin, and also via OfMeet), the final specification (RFC 7395) had not yet been implemented ... until now! We have just released a new Openfire plugin that is compliant with the latest specs, extending the core BOSH component with a WebSocket upgrade capability where supported. Older browsers that do not support WebSocket may continue to use BOSH (HTTP long polling) as a fallback connection protocol.


The new Openfire WebSocket plugin has been tested using the library and is ready for immediate use. It is available for download via the Openfire plugins page or directly via the "Available Plugins" page within your local admin console. Feel free to leave feedback here in the comments or post questions to the Ignite Realtime Community site.

by Ignite Realtime Blog ( at July 30, 2015 16:31


Adding a Security Policy to M-Link

We have two small changes to our evaluation guide series to announce (with many more coming soon).

Our core XMPP Messaging Evaluation Guide, using our M-Link XMPP server and M-Vault LDAP directory, now includes a section on adding a Security Policy to your XMPP service. In this new section we show you how to add a the policy to your service and clearances to your users. You can additionally apply label based controls to multi-user chat, domains and peer services (all of which and more is covered in the M-Link Admin Guide).

The Security Policy we use in the evaluation guide is one of the demonstration policies we ship with M-Link but, if you want to create your own, you can now get started with the new SPIF Editor Evaluation Guide. A SPIF (Security Policy Information File) is a file representation of a Security Policy, in other words the definition of which labels are valid and how to check them against clearances. This new evaluation guide will show you how to create your own basic SPIF using the Isode SPIF editor tool.

by Hannah Gibbs at July 30, 2015 15:50

Jérôme Poisson

Let's talk XMPP - episode 2 - core and extensions

This article was initially published in French, and it got some interest, so we started to translate the whole series in English. If you can read French, you can follow the whole series there:

The translation to English was done thanks to: Poulet, Éfrit, Paco and mbarbarosa and Weyfonk. The whole series is under CC By-SA, and any help would be appreciated to help with the translation of next articles.

Now that we know what we’re talking about, let’s see what the core of the protocol looks like.
Originally, XMPP is defined by 3 (previously 2) RFCs: RFC 6120, RFC 6121, and RFC 6122 (there are others, but these 3 are the main ones). They explain the core of the system, such as sending messages, presence information, statuses and so on.
Without getting too much into details related to developers, we can quickly explain that XMPP is based on 3 element types, or “stanzas”:
  • <presence/> to primarily indicate… our presence information (sometimes, we also add other things like our avatars, our capabilities, but let’s stay focused). The presence is broadcast by the server to all the people that you have given permission to (see below).
    We can associate a state and a message to our presence. The state can be one of the following (names can change depending on the client):
    • available (default): you’re online.
    • away: you’re away for a short period
    • chat: you want to talk
    • dnd (do not disturb): you’re occupied (often called “busy” in clients)
    • xa (eXtended Away): you’re away for a long while.
    The status messages allow you to specify your availability in a clear language (for example: “I’m watching a movie, do not disturb”), even though, in practice, it is used for any kind of message (a lot of people use a quote, for example).
  • <message/> A message’s sending of type “send and forget”. There are 5 types of messages::
    • chat: the most well-known message, used for simple instant messaging;
    • error: this one is usually managed directly by client software. It is often shown by means of a notification window in your client, indicating that something wrong occurred;
    • groupchat: as “chat”, but for discussion with multiple people. In practice the difference concerns only developers and it should be transparent in the client;
    • headline: an important message, an announcement. Normally, these messages aren’t kept offline, so if you aren’t connected while the message is sent, you shouldn’t receive it. These messages don’t expect answers. A typical example is an announcement for an imminent server maintenance;
    • normal: a little known yet interesting type. It is a message which generally has a subject, but outside of an instant conversation. Yes, exactly like an email! It is more or less its XMPP equivalent.
    Conversation threads are managed as well, but we’ll talk about it another time.
  • <IQ/> (Info/Query): used for everything that works on a question/answer pattern (it is mandatory to provide an answer to an request, even if you need to reply with an error). This is used mainly by developers, as it serves as a basis for most of the features you need. Using it is like saying "I need to know or edit this information".
I don't want to delve into technical details, but it seems essential for a user to know different message and presence types to understand their client.
One should note that there is an excellent feature that is largely underused in XMPP: it natively knows how to handle different languages because of its inheritance from XML (xml:lang). In other words, you can specify a normal or status message in French, German and Slovak at the same time. This is a major asset that we intend to use in Libervia.
Now let's talk about another essential part: the contact list.
It is called "roster" in the XMPP world. You can assign 0, 1 or several groups ("family", "friends", etc.), a name (which is an alias chosen by yourself, not by your contact), and subscription information to every contact you add to your roster.
Subscription lets you know whether you have allowed your contact to see your presence information and whether you are allowed to see theirs. Therefore, every time someone adds you to their contact list, your client (e.g. Gajim) asks you whether you wish to grant them access to your presence information. Note that these permissions don't need to be symmetrical: a contact may have been allowed to see your contact information without enabling you to see theirs, and vice versa. It might even be possible that neither of you can see each other's presence information (but I think most clients remove the contact from the roster in that case).
Groups are dependent on contacts, not the other way around (it's not a list of groups which contains the contacts): this explains why having an empty group (i.e. without any contact) isn't possible. In my opinion, groups too are underused in the XMPP world, but we'll get back to this.
That's it for today. I opted to keep the part on extensions for the next post to keep this one lighter.

by Goffi at July 30, 2015 12:29

July 29, 2015

Fanout Blog

Runscope JWT authentication

Monday evening we had a particularly nasty outage: JWT authentication was broken, preventing anyone from using our HTTP API to publish data. The reason we didn't catch this early on is because our manual test scripts turned out to be broken (reporting auth success when auth had failed.. yeesh!), and there was no authentication coverage in our external monitoring to fall back on.

In a perfect world, our external monitoring would test authentication. I'm happy to report that we are now doing this with Runscope! Getting this to work right was a little tricky since we use JWT, but it was made possible thanks to Runscope's scripting feature.


by justin at July 29, 2015 22:24

Daniel Baczynski (GSoC 2015)

Roster model proxy

It's time for roster. We want to show multiple accounts in one window. Hence we decided to make every active account being a top level element of roster and thereby downgrade group elements.

I have implemented proxy model that makes use of current RosterModel. It contains collection of <RosterModel, Account> pairs. For now, we can show one account contacts but code is more prepared to jump into multiple view.

by DanielB ( at July 29, 2015 15:13

Tarun Gupta (GSoC 2015)

Week - 10

Hello everyone,

This week I completed some incomplete bits of SASL ( Simple Authentication and Security Layer ) , TLS ( Transport Layer Security ) , Session, Presence and Client.

XMPP includes a method for authenticating a stream by means of an XMPP-specific profile of the SASL protocol. SASL specification defines the core authentication method for XMPP: an application profile of the Simple Authentication and Security Layer (SASL) protocol that enables a client to authenticate with a server or for one server to authenticate with a peer server. This profile may be used for both client-to-server and server-to-server connections. For client connections, the service name used is "jabber-client". For server connections, the service name used is "jabber-server". The following XML namespaces are used in the context of the Simple Authentication and Security Layer protocol: urn:ietf:params:xml:ns:xmpp-sasl. I added DIGESTMD5ClientAuthenticator, DIGESTMD5Properties and tests for these as well as the existing authenticators. More information available here.

TLS specification defines the core channel encryption method for XMPP: an application profile of Transport Layer Security (TLS) that enables a client to encrypt its XML streams with a server or for one server to encrypt its XML streams with a peer server. By its nature as a TLS profile, XMPP channel encryption also includes the ability to compress XML streams. The following XML namespaces are used in the context of the Transport Layer Security protocol : urn:ietf:params:xml:ns:xmpp-tls. I added TLSError, TLSOptions, SimpleCertificate and also made sure that all other features are in line with Swiften. Session only needed updates for the signal definition and some other minor changes.

In Presence, I just added three tests i.e. DirectedPresenceSenderTest, PayloadAddingPresenceSenderTest and PresenceOracleTest. In Client, I updated existing files and also added Client Block List Manager, Client XML Tracer, XML Beautifier along with their tests.

Next Up, I'll do Network which needs a lot to port including proxies and then Jingle and FileTransfer.

by TARUN GUPTA ( at July 29, 2015 11:30

Jérôme Poisson

Let's talk XMPP - episode 1 - the basics

This article was initially published in French, and it got some interest, so we started to translate the whole series in English. If you can read French, you can follow the whole series there:

The translation to English was done thanks to: Poulet, Éfrit, Paco and mbarbarosa. The whole series is under CC By-SA, and any help would be appreciated to help with the translation of next articles.

Well, as it’s a shame that XMPP is not well known or understood, I decided to start a series of articles to explain what it is.
These articles are for a technical audience, but not necessarily for developers, and I hope it will help you to understand the advantages of this protocol and to use your software in a better way.
Being a developer of the “Salut à Toi” project, I’ll probably give examples with it quite often.
So let’s start with basis.
What’s XMPP? It’s a standard message and presence protocol, and extensible (XMPP means « eXtensible Message and Presence Protocol », that is it’s documented and used as a reference (validated by standards organization: the IETF). It allows all software which use it to speak the same language, and so to be interoperable. It’s a libre protocol, that is you can get the documentation and use it for free, without any legal or technical restrictions, and you can improve or modify it (but if you divert and don’t suggest your modifications, you risk to lose the compatibility with other software).
XMPP is decentralized and federated, that is you can have servers anywhere, they could (if they don’t forbid it explicitly in their configuration) communicate with each other.
It’s a popular protocol, many software allow to use it: for servers, there are Prosody, Ejabberd, Openfire, Tigase, Mongooselm, Metronome, etc. For clients: Gajim, Poezio, Pidgin, Psi, Swift, Jappix, Movim and of course Libervia/Salut à Toi (I let you find the official websites by yourself). A complete list (servers, clients and libraries) is available here:
If you cannot install your server at home, many public ones are available: in France one can cite those of APINC ((,, etc), of the Quadrature du Net, etc. A small list (it’s not up-to-date, don’t hesitate to contribute) is available here in French,, if not you can check on or (yes, there are a lot!). But I strongly suggest you to install your own server or to go meet a local organization that you can contact easily: on the one hand if you install it by yourself you’ll have a better control on your own data and on the other hand if you want a specific feature you’ll be able to ask admins for an update.
Knowing all that, let’s try to install an account.
Once the server installed or a public server chosen, you can create an account. You’ll have then an address, a “JID” (Jabber ID, “Jabber” is the former name of the protocol, this name is now owned by a private company and is kept here for historical reasons).
This address is on the form of local_name@domain.tld/resource, or in canonical form (or what is called “bare JID”) local_name@domain.tld. For example, mine is Does it sound familiar? Yes, it really looks like email addresses!
So what is this resource? The resource is linked with the client software that you use to connect: XMPP has been designed from the beginning to allow several clients to connect at once (10 years ago, a few messaging protocols were able to do that, and connecting again from a different place was often resulting in the disconnection of the first client) and this resource is used to identify them. In other words, you have a resource only once connected, and it will be a different one for each client that you are using: if I connect with Libervia, Gajim and Movim, I’ll have 3 different resources.
It used to be several strategies to name the resource, sometimes it was used to show the connection location (“home”, “work”), clients often used their names as default value (“gajim”, “psi”). Today, it’s well accepted that it’s better to have a resource that we cannot guess, as somebody can know if you are online or not (even if you don’t want this information to be public) by doing a request to this resource. The best way is to let the server choose the resource for you.
Finally, the resource is linked with a priority: it allows to indicate, if several resources are available, which one will get the message. But we’ll see that later.
In the next episode, I'll talk about extensions an features discovery
That’s it. Let me know if you are interested in this series, if it seems too technical for you, or if you have any comment or fix to suggest. Everything is under the license CC By-SA, so don't hesitate to re-use, share or modify !

by Goffi at July 29, 2015 10:14


ejabberd 15.07 released: Summer Progress

This month’s ejabberd release contains many fixes and a few improvements. This is a consolidation release that help us pave the way to exciting new features coming at end of the summer.

Since we released our Message Archive Management support in ejabberd 15.06, we have been impressed by how quickly our users did adopt this features. It helps us make the implementation more robust and more complete, thanks to your feedback. This release thus improves ejabberd mod_mam.

We have also been very happy by the feedback received on our brand new installer for Windows, and for the .deb and .rpm packages. They are still beta, but thanks to your feedback, we could improve them tremendously. So, keep the feedback coming !

And of course, all this work on installers help us improve our tool to deploy and build ejabberd contributed modules. Contributed modules can now include their own configuration snippet, which are dynamically loaded by ejabberd.

Overall, this version should be easier and even more enjoyable to run and we all hope you will like the progress.


Message Archive Management (XEP-0313)

  • Add “complete” attribute to MAM final response
  • Fix mod_mam compatibility with RSM
  • Changed mam iq get to set as specified by XEP-0313 v0.3

Modules management

  • Ensure config snippet is loaded at module installation
  • Allow contribution to include .yml or .yaml config file
  • Allow include of simple dependencies

Multi User Chat

  • New API hook: muc_filter_packet
  • Send notifications on MUC configuration changes
  • Omit warning message regarding non-anonymous room
  • During halt only shutdown MUC rooms on local node


  • Allow migration of old pubsub items with old xmlelement structure in body
  • Trigger PEP notifications on CAPS updates
  • Check for node subscription of bare JID
  • Flat is now the default plugin

Stream Management (XEP-0198)

  • Increase timeout during resumption
  • Increase default “max_ack_queue” value

ejabberd Client connection

  • API change: user_send_packet is now a run_fold hook and pass the c2s State as a parameter. It was already the case in ejabberd 15.06, but it was not mentioned in the changelog, by mistake. So, now, you know :)


  • Do not rely on behaviour info when doing config validation, so that it can work with ejabberd binary installers
  • When passwords are scrammed, report check_password_hash cannot work
  • Fix problem with merging values from multiple config files
  • If local guide.html file not found, redirect to the online guide
  • Support RTL page direction in WebAdmin for Hebrew
  • add AC_CONFIG_MACRO_DIR and static AC_INIT


  • Don’t crash web admin when displaying info about websocket using users


  • Both RPM and DEB now are using the improved post-install script which creates ejabberd user when installing as root. This let ejabberd running as user without any manual setup.

  • Windows installer now uses %USERPROFILE% to get path of user writable directory. We made numerous other fixes to that version, thanks to your feedback.


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.

by Christophe Romain at July 29, 2015 09:40

Adhish Singla (GSoC 2015)

Week 9


VCard, CSS Changes and Read Implementation for Mobile Application


VCard stores the information of a User which is retrieved at the time when the roster is recieved. And Implement Read for Sensor Devices.


  • We use the NickName and Image from the VCard for the Contacts View.
  • Bug Fix for Login Form Removal after the connection has been established.
  • CSS Changes for the Views.
  • Add Dynamic Event Listener for Tap on Contacts to send a Read Request.
  • Display Read Values as a Dropdown to the Device in the Contacts View.

Problems Faced

  • (Solved) Dynamic Event Handler was not working when using jQuery on(‘tap’) function. The problem was with the older version of jQuery, replacing it with the latest version solved the problem.

Final Output

Login View Retrieved Contacts VCard Display Read Values of a Device

Road Ahead

  • Implement Write and History using a Graph Library.
  • CSS changes for Read Values.
  • Some functionality changes for adding contacts to Contacts View.

by Joachim Lindborg ( at July 29, 2015 08:13

July 28, 2015


Building a simple chat client using XMPPFrameWork and Cocoapods

Capture d’écran 2015-07-27 à 15.10.11
When it comes to building an XMPP client on iOS, one will immediately struggle with the lack of documentation and a complex setup involving tweaking files and laborious try’n fail attempts.

Suffer no more !

Enter the world of cocoapod: you are just 2 words away of your next iso chat client.

See more and download example here

by Paul Lemaire at July 28, 2015 13:15

July 23, 2015


Advanced Erlang Initiative

We are proud to be launching the Advanced Erlang Initiative, a new group of companies that use Erlang as a strategic technology to craft great products. Erlang ecosystems rely on those publishers that are producing person/years worth of code to build excellent products.


The Advanced Erlang Initiative recognises that those products in turn contribute to the fame of the Erlang platform. They help pushing the limits and contribute to the fame of our beloved programming language. Most of all, the Advanced Erlang Initiative acknowledges peoples energy and effort put in those great products to the good of every Erlang developer. We have created a forum for developers working with and contributing to those tools to meet and discuss their work.

The Advanced Erlang Initiative welcomes all developers that share our passion for Erlang, Elixir, the beam environment and our vision of technical excellence.

Our initiative is primarily centered around inexpensive highly technical workshops given around the world and educational videos on our Erlang products.

The first two members are:

  • ProcessOne, maker of the world class messaging server ejabberd, since 2002.
  • Quviq, maker of the Quickcheck property-based testing tool, innovation in quality assurance.

We are happy to meet you on the newly launched website Advanced-Erlang

We are already taking registration for the first two workshops:

More to come soon !

Enjoy and see you there after the summer break !

Thomas Arts, Quviq
Mickaël Rémond, ProcessOne

by Mickaël Rémond at July 23, 2015 16:29

Swift Blog

Swift 3.0-beta2 Released

We have just released the second Swift 3.0 beta. Apart from several bugfixes, highlights include an emoticons menu in chat dialogs, bookmark for rooms can now be edited directly from the ‘Recent Chats’ list and rooms entered while offline will now get entered on reconnect.

Have a look at the changelog for a list of all the new features since 2.0.

We encourage everyone to get the new build and try it out, and tell us about any bugs they should come across.

July 23, 2015 00:00

July 22, 2015

Tarun Gupta (GSoC 2015)

Week - 9

This week I have completed the remaining bit of serializers, completed StreamStack, Components, AdHoc, Compress and EventLoop. I'll give a brief description about each and what I changed.

In serializers, I just updated all the Non-payload serializers to return a SafeByteArray instead of a string.

There are two types of server-side components. Internal and External Components.
External Components use internal API of a server while the external components communicate to a server over a wire protocol and therefore not tied to any particular implementation. An external component is called trusted because it authenticates with a server using authentication credentials that include a shared secret. This secret is commonly specified in the configuration files used by the server and component, but could be provided at runtime on the command line or extracted from a database. An external component is commonly trusted to do things that clients cannot, such as write 'from' addresses for the server's domain(s).
External components do not use the obsolete NON-SASL Authentication nor they use SASL Authentication (yet), but use a special <handshake/> element whose XML character data specifies credentials for the component's session with the server. A simple getHandShake function takes a streamID and secret, concatenates them and replace some characters (like '&' with "&amp;", etc) and then generate a SHA1Hash and return the hexified value.

For example, ComponentHandshakeGenerator.getHandshake("myid", "mysecret") generates the hash "4011cd31f9b99ac089a0cd7ce297da7323fa2525". 

More information can be found here. This patch is under review now and I have ported all of component along with tests. However Component Connector test can still not be implemented because it needs certain bits of Network which aren't available now.

I have made a very minor change to AdHoc, allowing the connection to disconnect. Information about AdHoc can be read here.

We are using a third party library jzlib to accomplish the compresssion of XML Streams, in which ZLIB compression method is used. Here is the XEP for the same.

The EventLoop is a seemingly infinite loop that waits for XMPP events to occur (incoming messages, notification about connection errors, etc.). Whenever an event occurs, the eventloop calls the event handler method that is associated with the event. I just added simple eventloop tests and checked whether functionality is in parity with Swiften.
Next up, I am covering SASL (Simple Authentication and Security Layer). Thanks.

by TARUN GUPTA ( at July 22, 2015 14:44

Andreas Straub (GSoC 2015)

Week 08 - Trust

Hey, welcome back!

A lot of exciting stuff has happened. The focus of work this week was the trust system. It was extended to encompass two additional states: INACTIVE and COMPROMISED. Along with some UI improvements, this got us to a stage where the protocol is starting to become usable for day to day communications.

In designig the logic driving these changes, we were faced with some tough problems. Recall that, so far, we have had three trust states: UNDECIDED, UNTRUSTED, and TRUSTED. UNDECIDED served as a default initialization for keys on which the user hasn't made a trust decision yet. The idea was that, if there are new keys available when the user sends a message, we'd drop them into a TrustKeysActivity. Here, the user would have to decide which of the UNDECIDED keys they want to trust before the message is sent. 

This activity was implemented this week, and it is triggered under two condition. Either if, as previously described, there are UNDECIDED keys for the current conversation (meaning for either the contact or the own account), or if there are no TRUSTED keys for the contact (as in that case, the message couldn't actually be sent). In the former case, only UNDECIDED keys are displayed. In the latter case, UNTRUSTED keys are displayed as well, as there may not necessarily be any UNDECIDED keys. The activity sets all pending keys to UNTRUSTED by default and lets the user pick which ones they want to trust. This way, no key can remain UNDECIDED, preventing the activity from reappearing every time a user tries to send a message. The activity is in a "locked" state until it is done fetching all keys in the background, and until, after commiting the selected changes, there will be at least one TRUSTED key. The user can of course revise these decisions in the ContactDetailsActivity (as before) and EditAccountAcitivity  (new this week). The TrustKeysActivity reuses the key display UI introduced for the ContactDetailsActivity and EditAccountActivity, which also got an overhaul this week. Take a look:

You'll notice we replaced the buttons with a slider and got rid of the trust state text, as this was now redundant. TRUSTED and UNTRUSTED keys obviously have an enabled/disabled slider respectively. UNDECIDED keys have a greyed-out slider that gets enabled (and initialized to UNTRUSTED) when the user clicks on it. 

You may also have noticed an entirely greyed-out key in the above screenshots. This represents an INACTIVE key. The INACTIVE state was introduced to deal with the problem of stale keys. Stale keys not only clog up the UI unnecessarily, they also create overhead. Because the device doesn't know that a key may not be needed anymore, it will still have to encrypt sent messages for that device. This creates computational as well as bandwidth overhead.

Let's say one of your contacts buys a new phone. They wipe their old one, and sell it. On their new phone, a new IdentityKey will be generated, that their contacts will have to trust. While your contact can use the "Clear devices" function to remove the announcement of that stale key from the PEP devicelist, this will only prevent new sessions from being established with that stale key. Contacts that already have a session with that device will still keep them around. Those contacts will notice that the device that key belongs to was removed from the announcement, but they can't use that as a trigger to delete the key and session from their database. The reason for this is that the "Clear devices" function has no way of knowing which devices it should actually clear, so it just removes all devices except for the current one. This is not a problem, because the other active devices will notice they were removed, and they will just immediately readd themselves. But at that point, we would have already deleted the session and key, if we simply used the event that a device was removed from PEP as a trigger to delete it. 

This is where the INACTIVE state comes in. When a device that was initially TRUSTED is removed from PEP, we now set it to INACTIVE rather than deleting it outright. While a device is considered INACTIVE, no messages are encrypted for it. INACTIVE devices are automatically reactivated and set back to TRUSTED if they either reappear in PEP or we receive a message from them. As a result, the "Clear devices" function works as expected, with active devices remaining in their TRUSTED state, while unused devices are set to INACTIVE automatically and not used for sending anymore. A side effect of this design is that after using "Clear devices", the user has to ensure all their devices come online so they can reannounce themselves. Until they do so, messages will not be encrypted for them, so the user might lose some of the history on some of their devices. We warn about this in a popup. 

Note that there is still no way for a device to ever get deleted. So while old devices will now end up INACTIVE, they will still clog up out UI. The same goes for devices that are explicitly not to be trusted because they don't match our contact's fingerprint(s). This problem is resolved by the second new state that was added, COMPROMISED. By long-pressing on a key, the user can purge them. The effects of this are twofold: the key is not displayed in the UI or used for message processing anymore but it is kept around in the database. The COMPROMISED keys effectively constitute a blacklist of keys that can never be used again. Once a key is set COMPROMISED by the user, there's no way back, as they are hidden from the user forever (or at least until they remove and readd their account to the app). This protects the user from accidentally re-trusting a key they shouldn't. This functionality is also intended to be used for the aforementioned stale keys. If one of your contact's keys has been INACTIVE for a while, you can now simply remove it. It not only makes sense to treat both of these cases -- keys that are not needed anymore, and keys that were never trusted at all -- identically to get a more streamlined UX, but they are in fact very similar semantically, as an old key no longer in use should be considered COMPROMISED anyway.

I have to give huge thanks to my mentor Daniel here for taking the time to sit down with me and talk this thing through. While this design may seem simple and intuitive in hindsight, we had to play through many different options in order to arrive at this point where these different choices mate to make a coherent whole. To my knowledge, no one has built anything quite like what we're working on before, so we're kind of flying by the seat of our pants here. It was our big goal to come up with a design that unburdens the user as much as possible, in order to yield a streamlined experience.  I think we've built something that is very simple to use and understand by automating wherver possible, yet letting the user make the important choices in order to ensure sufficient control over this crucial component. Daniel was also really helpful in debugging the UI code for this overhauled trust system. He took a lot of time for me and helped me find some really nasty bugs. :)

In other news, this week also marked an overhaul of the payload message encryption. We switched from our prototype implementation (plain AES-CTR, no HMAC) to AES-GCM, which provides encryption and integrity protection in one neat package. Less to implement means less sources for bugs. I also fixed some bugs relating to file transfers while in axolotl sessions amongst others, and I improved the "Clear devices" UI. And finally, my code has been merged into the development branch of Conversations! While it's not done yet, this will make it easier for interested users to help test it.

As you can tell, I've been pretty busy, and we've made a lot of progress recently. I will probably spend the next week on code quality improvements and bug fixes. Right now the code accesses the database way more than it should, which leads to performance problems and (in some cases) unresponsive UI. 

If you have any comments or suggestions, please let me know. Until next week!

by Andreas Straub ( at July 22, 2015 11:11

Adhish Singla (GSoC 2015)

Week 8


Login and Contact Retrieval using Strophe for Mobile Application


Implementation of Mobile Application (Login, Roster and Presence).


  • Related Info :
  • Tested Strophe Login using a hardcoded Script to connect to the BOSH Server with fixed Login Details.
  • Made a View for Login to enter Username and Password.
  • Problem : Login Form does not remove after Login is Successful.
  • Contacts Retrieved are displayed as Jid under the login Form.

Problems Faced and Bugs

  • Bug : Login Form not removing.
  • Presence only received for one Device (Solved) : Occupied with this problem for quiet some time. Realized later that Handler needs to return true, otherwise they work only once.

Final Output

Login View Retrieved Contacts Display

Road Ahead

  • Retrieve VCard, Bug Fixes, Implement Read, CSS Changes.

by Joachim Lindborg ( at July 22, 2015 08:13

Marvin Wißfeld (GSoC 2015)

Status Update - Finished yet?

It was some work, but finally we reached a state, where DNSSEC in minidns is fully usable*.

What happened?

Summarizing everything done as part of the Google Summer of Code so far gives us a pretty long list of features:

  • A full recursive resolver (not only stub resolving)
  • TCP and EDNS(0) usage
  • Support of a total of 9 new record types: DS, RRSIG, DNSKEY, OPT, NSEC, NSEC3(PARAM), TLSANEW, OPENPGPKEYNEW
  • Verification of DNSKEY entries using DS
  • Verification of RSA signatures using RRSIG
  • Verification of negative responses using NSEC and NSEC3NEW
  • RFC compatible output format (like dig)

What is to be done?

Testing. Yes that’s a main thing to do. As announced in this blogs first post, we want our DNSSEC implementation to be fully tested. Until now our test coverage is still less than 60%.

Another feature that is missing in the current implementation of minidns-dnssec, is verification signatures made using DSA or ECDSA keys. Currently this is done by a small number of DNSSEC systems and the feature is marked as optional, none the less it is an interesting feature.

Google Summer of Code is still a month to go, so I am certain these problems can be tackled in time and we can see DNSSEC used in smack and OpenKeychain until then.

July 22, 2015 00:00

July 20, 2015

Ishan Khanna (GSoC 2015)

GSOC Week – 08

With great help from Florian, my mentor and some research I was able to get the XMPPLLConnection and XMPPLLConfiguration work together.  So a user can now create an XMPPLLConfiguration that takes some basic information about the presence and it can passed to the XMPPLLConnection’s constructor to establish a new link-local connection.

User can then call XMPPLLConnection#announcePresence() to broadcast the presence info on the network so that other clients listening to it can get it.

Here is a small demo of what is currently happening. Youtube – Announce Presence Test

What am I planning next?
Add sockets to the XMPPLLConnection and start listening for connections on them. As I am new to socket programming, I have been given a small task by my mentor to Learn basics of Socket Programming that I have completed and now waiting for his review. I am also looking into the java.nio package tutorials online.

by Ishan at July 20, 2015 11:24

July 17, 2015

Ishan Khanna (GSoC 2015)

GSOC Week – 07

Got JmDNS Working in the code and tested it with Gajim on a Ubuntu VM. Written and tested POC implementations for announcing presence, discovering presences and concealing presences on the link local network.

Currently working on the implementation of the XMPPLLConnection and XMPPLLConnectionConfiguration to enable developers to use this API in Smack to initiate Link-Local connections.

by Ishan at July 17, 2015 11:20

July 16, 2015


Securing ejabberd against logjam attacks … and future threats

As a default, ejabberd is secured and resistant to logjam attacks. However, ejabberd 15.06 adds improvements that makes ejabberd even more resistant to future attacks.

We hope you will find valuable information there, even from a general XMPP security standpoint.

What is logjam security issue ?

In may 2015, a team of researchers (Henninger et. al) published a paper explain two possible weakness in client / server communication encryption (“Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice”) .

The paper covers two issues the team uncovered:

  • discrete logs attack on a 512-bit Diffie-Hellman (DH) group
  • protocol downgrade attack against TLS connections

TLS protocol vulnerability

The TLS protocol vulnerability can allow to downgrade security to 512-bit DHE_EXPORT keys with a man-in-the-middle attack. It requires the attacker to be in the same network and have access to network routing to perform the attack. This is condition that are difficult to reproduce, except on public wifi for example or mobile connections.

However, ejabberd default configuration forbids a set a weak ciphers. The default configuration in ejabberd bans export weak ciphers and a few others: "DEFAULT:!EXPORT:!LOW:!RC4:!SSLv2"

It means that using ejabberd with default setting is safe.

In case you are using custom cipher list in your ejabberd configuration, please, make sure you do not explicitly allow EXPORT ciphers in you configuration file.

Attack on small Diffie-Hellman groups

The researchers have shown that small 512-bit or 1024-bit Diffie-Helman prime groups are vulnerable to attack under the following circumstances: Many server comes preconfigured with 512 or 1024-bit prime group. Precomputing an attack against very common small groups mean that someone with access to the network could eavedrop on connections. Even if cost to precompute attack on a single 1024-bit prime are extremely expensive, it is recommended to be on the safe side (and future proof) to generate your own DH parameters.

At the moment, as ejabberd does not allow as default ‘export’ cipher, you are still safe. However, we recommend in our best practices to set your own DH parameters, as allowed in ejabberd Community Edition 15.06.

Using your own Diffie-Helman parameters with ejabberd

To generate your own parameters DH you can generate a .pem file with:

openssl dhparam -out dhparams.pem 2048

Then, simply tell ejabberd to use your own 2048-bit prime DH group by adding the following entries in your listener configuration file and global parameters for outgoing s2s connections:

    port: 5222
    module: ejabberd_c2s
    access: c2s
    shaper: c2s_shaper
    starttls: true
    certfile: "/etc/ejabberd/server.pem"
    dhfile: "/etc/ejabberd/dhparams.pem"
    max_stanza_size: 65536
    port: 5223
    module: ejabberd_c2s
    access: c2s
    shaper: c2s_shaper
    tls: true
    max_stanza_size: 65536
    port: 5269
    ip: "::"
    module: ejabberd_s2s_in
    shaper: s2s_shaper
    max_stanza_size: 131072

# For s2s connection, you need a global parameter:
s2s_certfile: "/etc/ejabberd/server.pem"
s2s_dhfile: "/etc/ejabberd/dhparams.pem"


ejabberd team always work hard to make ejabberd highly secure and follow the state of the art practices in term of security. As security is highly depend on computing power available at any given time, we do our best to anticipate to make sure you will stay on the safe side for the years to come.

However, there is no emergency in implementing our recommendations. These are the best practice that you should look forward implementing as your time allows.

by Mickaël Rémond at July 16, 2015 09:56

Daniel Baczynski (GSoC 2015)

Account serialization

We wanted profile settings to be stored using boost::serialization. It's done now for Account class (including ClientOptions serialization and other) that remember profile details. Saving and loading objects is realized in AccountsManager.

Previously, account details were stored using ProfileSettingsProvider. Now, for backward compatibility reason, they're stored in both settings provider and serialized string. When no serialization string is detected in settings, Swift obtain details using current settings provider and stores them serialized also.

Places in code using settings provider were replaced to make use of Account serialization. In future, we are probably going to avoid using ProfileSettingsProvider at all.

by DanielB ( at July 16, 2015 07:50

July 15, 2015

Tarun Gupta (GSoC 2015)

Week - 8

This week was a little less of work, and I completed VCards and MUC.

The basic functionality of VCards is for a user to store and retrieve an XML representation of his or her vCard using the data storage capabilities. This is done by by sending an <iq/> of type "set" (storage) or "get" (retrieval) to one's Jabber server containing a <vCard/> child scoped by the 'vcard-temp' namespace, with the <vCard/> element containing the actual vCard-XML elements as defined by the vCard-XML DTD. Other users may then view one's vCard information. The various use cases available are: retrieving and updating own VCard and accessing other's VCard too. More information can be read here.

I just had to make minor changes to VCard to have feature parity with Swiften. Although I had to add the whole test file from Swiften and check for any inconsistencies.

Next on, I completed MUC (Multi User Chat). In MUC, each room is identified as a "room JID" <room@service> (e.g., <>), where "room" is the name of the room and "service" is the hostname at which the multi-user chat service is running. Each occupant has an occupant JID. User enters a room by sending a directed presence to <room@service/nick>. Messages sent within multi-user chat rooms are of a special type "groupchat" and are addressed to the room itself (room@service), then reflected to all occupants. More information can be read here.

In this I changed MUC to be an abstract class and implemented MUCImpl. Also updated a little bit of MUCBookmark and MUCManager. The difficult part was to port the tests, as those were failing with some reasons. I had to debug all the way, and finally corrected the mistakes. Next on, I am doing Components (might take longer). Also we are trying to find out the unexpected behavior of ant which is not updating the required class files and tests are giving error i.e. NoSuchMethodError.

That's all. Thanks for reading.

by TARUN GUPTA ( at July 15, 2015 19:02

Andreas Straub (GSoC 2015)

Week 07 - Alpha

Hey everyone!

The majority of this week was spent on getting the code ready for alpha. This meant refactoring the logging, so that we would better be able to diagnose potential problems from the logs people would send in, along with some more random code cleanup.

I encountered some tricky issues with my in-memory SessionCache being out of sync with the database, due to the roster not having been present when the cache is initially populated. This took quite a bit of fiddling around to figure out, and a few iterations to completely fix, because there are several non-obvious, distinct failure modes here.

I also worked on a bunch of little UI tweaks, mainly relating to session trust. If you recall from week 2, we had originally planned to decide trust on a per-session basis. The idea back then was that you would only ever build one session per contact, which would never be ended, so it seemed superfluous to trust the IdentityKey. After some deliberation, it turned out to be much more complicated to achieve this in a robust way, so we decided instead to implement trust on an IdentityKey basis. This meant shifting around some of the code, as well as changing the database schema.

All this work was needed so that message locks now show whether they originate from a trusted session. If the session is untrusted, the lock is colored red. The ContactDetailsActiviy now shows per-IdentityKey trust, along with a trust toggle button for every key.

In addition to TRUSTED and UNTRUSTED, I internally keep track of a third state, UNDECIDED, which all keys are set to initially. So far, this third state is treated the same as UNTRUSTED, but in a future update, if there are UNDECIDED keys, the send message button in axolotl-enabled conversations will spawn a new activity, prompting the user to either accept or reject the individual UNDECIDED keys, before sending the message.

My goals for the next week are implementing this TrustKeysActivity, fixing message delay tagging for axolotl messages, and a slight overhaul of the crypto code, which is still missing an HMAC.

by Andreas Straub ( at July 15, 2015 13:42

Ignite Realtime Blog

Smack 4.1.3 released

I've just released Smack 4.1.3 to Maven Central. This is a bugfix release which can act as drop-in replacement for any Smack 4.1 version. Users are encouraged to update since Smack 4.1.2 introduced a memory leak in the Roster API which was fixed in 4.1.3.

by Ignite Realtime Blog ( at July 15, 2015 13:37


Boxcar Android Developer SDK updated with GCM 3 support

Boxcar Developer Push service was recently updated to support Google Cloud Messaging 3.0 (GCM 3).

Google changed the semantic of the identifier. They replaced the ad-hoc RegistrationID with a new Universal Identifier. Android Developer will need need our new Boxcar Android SDK 3.0 to support it.

You can find more details on Boxcar Developer Blog: New Boxcar Android SDK 3.0.0 and SDK 2.0.4 released

by Mickaël Rémond at July 15, 2015 10:24

Adhish Singla (GSoC 2015)

Week 7


Learning Cordova with Examples


Apache Cordova is a platform for building cross-platform applications using HTML, CSS and JavaScript.

This week I have tried various examples in order to have a better understanding of Cordova for the purpose of making an IoT Client application for Android and Apple iOS.


  • Made a starting application that shows a alert message on starting.
  • Directory Application that stores the information locally and implement search on it.
  • Learn View Routing on Cordova.
  • Understand how to use Location, Contacts and Camera APIs using Cordova.

Images from Example Application

Directory Employee View

Road Ahead

  • Start with implementation of Application(Login, Strophe Connection, Retrieve Contacts).

by Joachim Lindborg ( at July 15, 2015 06:56