Planet Jabber

July 02, 2015


Growing programming languages, June 2015

Steve O’Grady published another edition of his great popularity study on programming languages: RedMonk Programming Language Rankings: June 2015.

As usual, it is a very valuable piece. There are many take-away from this research. I will not go over Steve O’Grady findings, but what I found interesting is:

  • Open Source and license matters. For two of the hot languages, Erlang and Swift, we have seen important changes in licensing that may have an impact in the coming months.

    • Erlang changed its license from its Erlang Public License to a more widely accepted Apache V2. Steve O’Grady notes that it will not change language popularity but will remove friction for adoption and will make the language more attractive for large contributors. It is worth noting that Erlang is still growing and is now in the top 25, thanks to the amazing projects build with it.
    • Apple announced that Swift will be open source by end of the year, with a Linux version coming at the same time. This was a much needed change that will expand the community and accelerate the adoption of one of the fastest growing programming languages.
  • There are 4 booming programming languages: Go, Swift, Rust and Julia. Go and Rust are competing for the same type of projects and developers. In a sense, with an open sourced Swift, it could reach the same target of system programming, even if it will be difficult to overshadow its mobile development roots. It will be interesting to see how those three languages evolves comparatively in the next research. Julia is a scientific language and evolves in its own niche space.

  • My current favorite, Elixir, is not progressing as fast as Rust, despite reaching version 1 and being developed at an incredible page under Jose Valim’s vision. My feeling is that it is still in developer projet inception phase and that it is winning the heart of Erlang developers first, and many Ruby developers. I expect it to grow slowly in the coming months, as Phoenix Web Framework matures.

The programming language space is still extremely interesting to see evolve and I am looking forward seeing what the developer community is doing with them. Actual projects are the language king makers. For example ejabberd has been critical for Erlang popularity. Docker project is boosting Go adoption. Let’s watch other big project to understand programming languages future.

by Mickaël Rémond at July 02, 2015 09:26

July 01, 2015

Remko Tronçon

Flattening Callback Chains with Monad Do-Notation

A few unrelated topics on my reading list made me want to randomly experiment with a few things. I wanted to understand monads a bit better, see how they applied to callback-based asynchronous programming, and play around with macro programming in a Lisp dialect. This is a partial log of the theoretical-and-probably-not-directly-applicable-but-nevertheless-fun rabbit hole I dived into.

Continue reading post

July 01, 2015 22:00

Tarun Gupta (GSoC 2015)

Week - 6

Hello Everyone,

I have completed International Domain Name (IDN) features, all JID features and couple of bugs this week, along with tests.

Well, International domain name is an internet domain name that contains at least one character in a language specific script (can be any language). Internationalized domain names can use characters from the entire range of Unicode, while traditional domain names are restricted to ASCII characters. The conversions between ASCII and non-ASCII forms of a domain name are accomplished by algorithms called ToASCII and ToUnicode. The algorithms are applied after breaking the domain into different labels such as: "" is composed of three labels: "www", "example", and "com". ToASCII will apply the Nameprep algorithm, which converts the label to lowercase and performs other normalization, and will then translate the result to ASCII using Punycode before prepending the four-character string "xn--". The ToASCII algorithm can also fail if the final string exceed the 63-character limit of a DNS name. A label for which ToASCII fails, cannot be used in an internationalized domain name. More details can be found in RFC 3490. For example,

"транспорт.com" gets converted to "".

I have used a third party library ICU - International Components for Unicode, which provides functionalities for such conversions.

Next, I have completed JID which required a bit of refactoring and addition of two important methods providing functionalities of getting escaped and unescaped node. getEscapedNode takes a string node and then checks for each character. If character is one of the allowed esacpe characters, then it is replaced with the Hex of that character. I have also added tests for checking all the functionalities inside JID.

Lastly, as a substitute for boost::ptime::not_a_date_time, I have allowed null values for Date type variables to some elements.

Next Up, I will be implementing Disco, Queries. And I am working quite in alignment with the proposal.


by TARUN GUPTA ( at July 01, 2015 17:20

June 30, 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 June 30, 2015 16:25

ejabberd 15.06: Message archive, configuration checker and new packages

ejabberd 15.06 includes over 100 changes since the last release two months ago. Among those changes it includes several major new features.

New features

The focus of this release is archiving and easier configuration.

Message Archive Management support

Message Archive Management (aka MAM, defined in XEP-313) is now the de facto standard for message archiving in XMPP world.

ejabberd now comes with its own full feature message archiving implementation:
– It support both version 0.2 and the more recent version 0.3 of the protocol.
– It support Mnesia internal storage and relational database backend (aka odbc, but actually use native drivers).

To enable it, simply add mod_mam in ejabberd modules configuration section, telling it to use your configured relational database.

    db_type: odbc

Please, also check the sql directory to find about the table to add to your relational database. MAM relational storage is supported for MySQL, Postgres and SQLite.

Configuration checking on launch

ejabberd is sometime difficult to configure, especially when you want to define complex setup. After having changed the configuration file to support YAML format, we now introduce a new feature to help you get your configuration right.

On ejabberd launch, you will now see report about possible misconfiguration, with explicit error message.

For example, suppose there is a typo on the registration_timeout option, you’ll get the following error in the log file:

16:15:20.487 [error] unknown option 'registrtion_timeout' will be likely ignored

This can be of great help when trying to understand why an option is not taken into account.

Windows installer

The Microsoft Windows installer is back, as a beta version. Windows is not a good platform to run a production ejabberd server, for various reasons. However, many users are developing on Windows or want to try ejabberd from their Windows Desktop. Building ejabberd on Windows is very complex, so we decided to finally update our packaging to bring latest ejabberd to Windows users. The installer is 64 bits only, it supports Windows 7 and Windows 8.

The installer is still considered experimental. For example, we did not yet sign the installer with Windows developer account to become a trusted developer. This may come depending on the feedback we get regarding our Windows version.

Please, send us your feedback and contributions!

RPM and DEB packages

We have been providing for years a binary installer that includes everything you need to run ejabberd. It includes all the dependencies and a minimal version of Erlang, independently from the one installed on your system.

We now provide the same binary packaging as RPM and DEB for 64bit Linux. This is generated from the same source so it includes its own minimal version of Erlang and doesn’t have any dependencies on other packages. This is still a work in progress, it means that your feedback is welcome. The packages can be downloaded from ProcessOne ejabberd download page.

We hope that this is another step in making ejabberd simpler to deal with and even more ubiquitous. It should also help you stay up to date and always be able to run the latest ejabberd version.


We now have an installer for contributed modules since ejabberd 15.04. In that new release, we’ve improved automatic compilation of external modules, it’s now more robust and able to handle more complex modules.

Documentation now includes supported protocols with versions by parsing directly modules source code.

Changelog overview

Here is a complete changelog. We’ll detail some of these changes in the coming days with follow up blog posts.

Message archiving

  • Add support for message archiving in Mnesia or relational databases.


  • Document protocol support and version inside each module and use that info in documentation
  • Remove deprecated XEP-0090 Entity Time and XEP-0091 Delayed Delivery
  • Don’t add body element to MUC subject messages
  • Do not bounce normal messages sent to unavailable resource

Admin command-line tool

  • Fixed several ejabberd commands
  • Allow password with ‘;’ passed in ejabberdctl
  • Improve ejabberdctl external module install code, allows better error checking
  • New ping ejabberdctl command to check if the node is up and running
  • New commands for Multi-User chat management: get_room_options and get_user_rooms


  • Add config validation at startup
  • Fix include of non yaml config files
  • New option hide_sensitive_log_data to hide client IP address in log
  • New option net_ticktime, to fine tune Erlang cluster networking
  • New option max_users_presence in mod_muc, to avoid broadcasting presence packet from users after a chat room has reached a given size


  • Add correct package version for mix


  • New options to configure your own custom Diffie-Helman parameters: dhfile and s2s_dhfile


  • Enforce definition of pubsub node max_items
  • Fix pubsub/odbc crash on remote user unsubscribe
  • Fix use of publish_only affiliation with odbc backend


  • Pick first local multicast service, otherwise remote


  • Fix anonymous user login, it wasn’t stored in anonymous mnesia table
  • Fixed some string/binary issues in ejabberd_odbc
  • PostgreSQL storage: added missing sm (session manager) table


  • Microsoft Windows 64 bits installer
  • Provide RPM and DEB binary packages for linux 64 bits.

Clean up

  • Remove obsolete doc and win32 files


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 June 30, 2015 14:27

June 24, 2015

Andreas Straub (GSoC 2015)

Week 04 - PEP

Welcome to this week's progress update! 

As you may recall, I spent the last two weeks trying to get a basic OTR-style end to end encryption setup working. I encountered a lot of problems, as I had written all of the supporting code with the ultimate goal of PreKeyBundle-initiated multi-end to multi-end sessions in mind. After realizing I would have to rewrite large chunks of the code in order for this OTR-like behavior to work, and after discussing these problems with my mentor, we decided to drop work on this. Rather, I decided to progress immediately to working on the PEP code that would be needed to house the PreKeyBundles. The only reason we had decided initially to work on this was because it was thought to be less complicated, and so would get us to a testable state sooner. As this turned out to be a dead end, it was time to cut our losses and move on. This was definitely the right decision, as I was able to get a very basic PreKeyBundle-based implementation working this week:

As you can see from the above screenshots, I was able to demonstrate the ability to send an encrypted message that reaches multiple devices of the same account. This is of course still very fragile code, missing most error handling, but I'm now able to test on real hardware, which makes iterating on the design a much quicker (and more enjoyable) process. I'm hopeful that, within a few weeks, I will be able to distribute a test build on the Conversations beta channel, which will be very useful in getting bug reports as well as early user feedback.

So with the progress update out of the way, let's talk about PEP. The asynchronous model of axolotl necessitates some kind of central storage where users can publish PreKeyBundles, which can be used by their contacts to establish sessions with them asynchronously. We chose to implement this using PEP, as it's a standardized XMPP extension that is in wide use (e.g. for Avatars). PEP is needed by my protocol for two tasks:
  1. Publishing a user's list of deviceIds
  2. For every device, publish a list of PreKeyBundles
For these purposes, I introduced two types of PEP nodes:  eu.siacs.conversations.axolotl.devicelist and eu.siacs.conversations.axolotl.bundles. These are, of course, preliminary names that will be changed to something more neutral once this protocol is standardized properly. Here are some examples of what these nodes look like:

<!-- Node: eu.siacs.conversations.axolotl.devicelist -->
<list xmlns="eu.siacs.conversations.axolotl">
<device id="1337"/>
<device id="2342"/>
<!-- ... -->

<!-- Node: eu.siacs.conversations.axolotl.bundles:DEVICE_ID -->
<bundle xmlns="eu.siacs.conversations.axolotl">
<signedPreKeyPublic signedPreKeyId="FOO">
<prekeys xmlns="eu.siacs.conversations.axolotl">
<preKeyPublic preKeyId="1">
<preKeyPublic preKeyId="2">
<!-- ... -->

Notice that there are actually several copies of the bundles node, one per deviceId. The idea behind this scheme is that device will subscribe to the devicelist node, so that they are notified whenever their contacts (or their own account) adds another device. Separating out the bundles list into a separate node has several advantages.
  • It reduces contention on PEP, as the deviceIds are generally updated less frequently
  • It reduces network load, as subscribers receive PEP updates not only when the node is changed, but also whenever they come online. The bundles node is pretty big, as it houses 100 preKeyRecords.
These PEP nodes are used as follows:
  • Whenever a user comes online, they will check that their own deviceId and PreKeyBundles are present in PEP. If not, they are published.
  • Whenever a user receives devicelists for one of their contacts (or themself), the deviceIds are cached and used later when establishing sessions.
  • Whenever a user wants to send a message to one of their contacts, they first check whether they have active sessions for each of the contact's (and their own) deviceIds. If there are missing sessions, they will fetch corresponding PreKeyBundles from PEP and use these to build sessions.

Because PEP is a general purpose pubsub key-value-store, there are some issues that have to be dealt with when using it for our purposes. In traditional axolotl setups (i.e. as used by TextSecure), the key server will 
  1. only hand out a PreKeyBundle once
  2. only accept PreKeyBundles from the deviceId owner
  3. prevent one device from clobbering another's deviceId 
PEP can not guarantee such integrity protection, so the clients have to take care of enforcing it themselves. 

The first restriction (only handing out any PreKeyBundle once) can not easily be replicated in this setup. Our approach here is to have the clients pick one of the PreKeyBundles at random, and have the owner refresh them frequently. This should all but prevent accidental double use of a PreKeyBundle. However, since this is essentially a self-imposed restriction, malicious parties don't have to do this, and can reuse PreKeyBundles as much as they want. Double use of a PreKeyBundle is not a security issue in and of itself, as long as certain security considerations are followed. In fact, some protocols (e.g. IKE) have (EC)DH public key reuse built in. A lockout mechanism might also be possible, in which a client will only accept a limited number of sessions initiated per PreKeyBundle. We have decided against implementing this for now, as it introduces additional complexity in handling accidental reuse, and could lead to some message loss.

The second and third restrictions can only be enforced by clients periodically policing their own PEP nodes to ensure no changes were made. Changes to the deviceId are noticed, as the client is subscribed to this node. Changes to the PreKeyBundles are currently checked on every login.

These concessions should have little to no impact on normal protocol operation. We rely on the fact that, if an attacker has stolen a user's XMPP credentials, they might be able to perform DoS-type attacks against opening new sessions, this is noticed by the user, who can then take steps to remedy the situation (i.e. change his passwords).

Next, I will spend a lot of time on building proper UI, testing, fixing bugs, and introducing all kinds of error handling. Until next week!

by Andreas Straub ( at June 24, 2015 14:09


Apple increasing security of Push service ahead of WWDC

Apple is tightening its push service encryption

Since this morning, Apple has been changing the setting of the push sandbox. This is generally good news, but it means that if your push notification system is written in Erlang, using Erlang stock SSL module, it will not work.

If your are using Erlang SSL to send push notification to Apple, you will need to patch Erlang to avoid the following error:

** {function_clause,[{ssl_cipher,hash_algorithm,"ï",[{file,"ssl_cipher.erl"},{line,1174}]},{ssl_handshake,'-decode_handshake/3-blc$^0/1-0-',1,[{file,"ssl_handshake.erl"},{line,898}]},{ssl_handshake,'-decode_handshake/3-blc$^0/1-0-',1,[{file,"ssl_handshake.erl"},{line,899}]},{ssl_handshake,decode_handshake,3,[{file,"ssl_handshake.erl"},{line,898}]},{tls_handshake,get_tls_handshake_aux,3,[{file,"tls_handshake.erl"},{line,153}]},{tls_connection,next_state,4,[{file,"tls_connection.erl"},{line,454}]},{tls_connection,next_state,4,[{file,"tls_connection.erl"},{line,458}]},{gen_fsm,handle_msg,7,[{file,"gen_fsm.erl"},{line,505}]}]}

The issue is that Erlang SSL implementation crashes on unknown hash and signature algorithms.

We have published a quick workaround for the issue on our own Erlang/OTP repository fork on Github and are hoping to help OTP team reproduce the issue to provide a long term more sustainable patch (as you need to disable completely unknown crypto hashes). In case you need it, the Erlang workaround is there: Do not crash on unknown hash and signature algorithms.

I hope this helps !

Good news for our customers

All our customers are already on the safe side. If you are using ejabberd SaaS, ejabberd Business Edition or Boxcar Push Developer Platform, you are already on the safe side and ready for the production roll out.

It feels good, right ?

Enjoy your week-end !

by Mickaël Rémond at June 24, 2015 12:33

Tarun Gupta (GSoC 2015)

Week 5 - Full of Testing!

Hello Everyone.

This week was kind of finishing off with all the basic things like FileSize, SafeString, etc which will be required by future functionalities. I have completed all Elements, their Parsers and Serializers. Now Stroke has all of them! Also this week was full of testing all these parsers and Serializers, which took most of the time. Some tests were added by me for some parsers and serializers (because they were untested!!) , which were also added to Switen, so that Swiften has feature parity with Stroke with respect to Elements, Parsers and Serializers.

I faced certain difficulties while doing so because of differences in C++ and Java. In Java, when creating a class which requires a typename and then calling some method using that typename, then that typename should inherit from some interface/class such that those interfaces/classes have those methods, which isn't the case in Swiften. So I made some extra interfaces, some for testing, some for Base functionalities providing those methods. At some places, I made anonymous inner classes to test the functionalities using Parser Tester.

Now next, I will be focusing on completing JID, but before that IDN (and yeah, maybe some dependencies!). A lot to do in remaining two months though.

by TARUN GUPTA ( at June 24, 2015 09:12

June 23, 2015

Adhish Singla (GSoC 2015)

Week 4


Read Requests


Read Request is sent to a Device JID to retrieve Numeric Values from them, for instance Temperature related Values from a Temperature Sensor Device. This Week we will use it to retrieve numeric values from Devices and get them displayed in ChatBoxes.


  • Send a hardcoded Read Query to a Device and retrieve its values in the console.
  • Extend sending Read Query from hardcoded to a command ‘/read’ that can be sent to a device using ChatBox.
  • Parse the message coming back from the Device to Display the Name and Value of Device in ChatBox.

Problems Faced and Work Arounds

Inputs for Read Request

  • There was a similar problem to that of Disco Query, we were not sending resources when we began, and the device sent back an Error IQ which was resolved as soon as we figured out the same for Disco Query.

Final Output

Read Requests

Road Ahead

  • We will implement Write and write an API for Raspberry Pi 2 in JavaScript for next week.

by Joachim Lindborg ( at June 23, 2015 22:02

June 22, 2015

Ignite Realtime Blog

Whack 2.0.0 released

2534 days after its last release, we are happy to announce the 2.0.0 release of the Whack API!


Whack is our Open Source XMPP (Jabber) component library for XMPP components. External components are processes that run outside of the Openfire's process but can connect to the server to add new functionality. Whack is an implementation of XEP-0114: Jabber Component Protocol.


This release brings a number of small improvements and bugfixes. Notably, Whack 2.0.0 is now based on the Tinder API.


Starting with the current release, Whack shall also be available through Apache Maven. The artifact coordinates of the core module are: org.igniterealtime.whack:core:2.0.0. The source code includes a number of small examples on how to use the library, which should have you up and running in no time!

by Ignite Realtime Blog ( at June 22, 2015 19:18

June 20, 2015

Ishan Khanna (GSoC 2015)

GSOC Serverless Messaging Project – #1

This is my first post regarding the Google Summer of Code 2015 Serverless messaging project that I am doing under the XMPP Standards Foundation. I am working on the Smack Project that allows you to create Chat clients for Java and Android based applications with the help of an XMPP server.

So far I have added the functionality to announce presence over a Link Local connection on the network. Also to conceal your presence from the network. Currently I am testing this with some clients like Gajim that have support for XEP-174.

by ishan1604 at June 20, 2015 17:37

June 19, 2015

Peter Saint-Andre

RFC 7590: TLS in XMPP

Following on the work that Yaron Sheffer, Ralph Holz, and I did on best practices for SSL/TLS in application protocols, Thijs Alkemade and I have now applied those recommendations to XMPP in the form of RFC 7590 (published today). This document explicitly updates the security considerations of the core XMPP spec and thus helps us further strengthen the security properties of the Jabber/XMPP network. Naturally there is still much to be done, but this is another step in the right direction...

June 19, 2015 00:00

June 18, 2015

Adhish Singla (GSoC 2015)

Week 3


Disco Requests


Disco Query is sent to a JID to check for features related to the JID. This Week we will use it to identify Devices and the IoT Features that they support.


  • Send Disco Query to all contacts as soon as a JID logs in.
  • Based on the features received from the contacts set ‘support_0323’ and ‘support_0325’ vars in the Contact Data Structure.
  • Set some Viewable Difference so as to Differentiate between Contacts and Devices Visually.

Problems Faced and Work Arounds

Inputs for Disco Query

  • Initially we faced problem with Disco Query that was, We were not able to retrieve features for Devices, while it was working good with normal JIDs.
  • Disco not working for Devices.

Disco not working for Devices

  • Disco working for JIDs.

Disco working for JIDs

  • We figured out that the problem faced was because we were sending the Disco Query to Bare_JID instead of sending it to JID/resource.
  • Disco working for Devices after using Resources.

Disco working for Devices

Visual Difference between Contacts and Devices

  • We started with the Idea of having a different Tabs and Views for IoT Devices, which we were unable to do because of Contact Rendering Issues.
  • Then we had 2 ideas to replace the above which were to have a different Group for IoT Devices or have a Different Icon for Devices.
  • We settled down on having a Different Icon for Devices and that is a ‘Wrench’ Icon.
  • Successful Disco Request and View.

Successful Disco Request and View

Road Ahead

  • For next week we will implement Read and Write for Devices.

by Joachim Lindborg ( at June 18, 2015 20:47

June 17, 2015

Tarun Gupta (GSoC 2015)

Week4 - Elements

Hello Everyone, And now in the fourth week of GSoC. Just one week before evaluation week,though.

I have implemented a couple of Elements, including Jingle and Hash Elements. Elements just provide various functionalities like Chat State Tracking, etc to store information. Elements require parsers and serializers to set and get their variables. Parsers parse the XML and extracts and sets the private variables for the Element. On the other hand, Serializers serializes an instance (of the Element) to XML format. So from last week, I have implemented a large number of elements, their parsers and serializers. And then there's tests, which checks the desired functionalities. Just a small number of Elements remaining, after which I'll go onto complete Base functionalities. I have skipped WhiteBoard from Elements, as it is not required for now.

Now comparing the current progress to that of my GSoC proposal, I think I have done quite more. On a short summary, I have completed all of Avatars (1 test remaining), all of Crypto, almost all of Elements, Parsers and Serializers, and some of Base functionalities.

Next week, I'll probably go according to my GSoC proposal plan (or maybe not) and implement and extend JID and EventLoop.

That's for now. Thanks Everyone.

by TARUN GUPTA ( at June 17, 2015 16:33

Andreas Straub (GSoC 2015)

Week 03 - Wire format

Hey everyone, and welcome back to the progress update! This week I want to talk a little bit about the wire protocol I want to use for this project.

The basic mechanism of the protocol involves encrypting each payload with a fresh, random key, and then encrypting that key separately for each partner involved in the conversation using long-standing axolotl sessions with those contacts. This is similar to how emails are encrypted with PGP, and has the advantage of fine-grained control over the intended recipients while minimizing overhead (as the payload is only present once in the message).

This data is serialized into an XML structure containing a <hdr> element for every participating contact, which contains an encrypted copy of the payload key, and a single <msg> element, which contains the encrypted payload. Every header is tagged with the remote device ID that corresponds to the contact device this header is intended for, so that recipients don't have to exhaustively try to decrypt every header, but only need to look at the ones that are relevant to them. The message is tagged with IV and HMAC. While axolotl already provides integrity protection, this obviously only applies to the individual axolotl-encrypted headers, so it is necessary to validate the encrypted payload as well, in this case using the standard encrypt-then-authenticate scheme.

A big goal of my design is minimizing overhead, especially in the headers. Every message sent in a multi-end to multi-end encrypted session contains one header for each own device, as well as for each of the contact's devices. Therefore, bloat adds up quickly. It would have been possible to reduce the size by around 20 bytes per header by opting to use a custom binary format, but using XML integrates much more nicely with the XMPP ecosystem, and will probably also aid others in implementing this protocol in the future.

As far as my progress goes, I'm still working on the single-end to single-end use case at the moment. It's turning out to be slightly more involved than anticipated because most of the code I have already written is geared towards the asynchronous PreKeyBundle based session management, as that will most likely be the only session establishing mechanism supported in the final release version. For that reason, I have had to make some adjustments, but it's coming along nicely, and I should be entering the testing phase very soon.

by Andreas Straub ( at June 17, 2015 15:04

Marvin Wißfeld (GSoC 2015)

Status Update - Recursive resolving

Ugh. You probably know this. You’re working hard, but joyful on a certain project. At sometime during the day you boss comes in your office asking you to write a report on this or that. Not only you have to do these boring thing now, you’re also told to not “just put it off for the sake of writing more code”.

Well, of course your boss has good reasons to do so. Summarizing will not only help people around you understand what you do, what you want to achieve and what they can do to support you, but recapturing your own work might also gives you a new view on your work and in the end might make it even better. However in the moment where the report is due, it always seems unreasonable and useless, doesn’t it?

What happened?

Last status post is already two weeks ago. There must be something to report!

  • minidns is now able to create output that is easily comparable with the output generated by the dig tool. This does not only come very handy when debugging the parsing results, but also makes output more valuable to expert users. (The output is not 100% RFC compatible, see here why).
  • As minidns supports both Android and desktop Java, it is able to handle Android specific ways to retrieve the stub DNS server setting. However these methods caused unreasonable overhead when performed on non-android systems. minidns now contains a proper platform detection to not call these Android specific routines on non-android systems.
  • To allow the proper testing announced in the last status post, minidns was refactored hugely and now has support for arbitrary network request backends. While this is normally just UDP and TCP (as announced last report), it is possible to inject our test framework there. Additionally custom network backends (like using the Tor network to resolve .onion-domains) can be injected there.

This was more generic contribution to the minidns library. When it comes to the project topic, there is also progress to report.

  • Support to parse NSEC3 and NSEC3PARAM records (see RFC5155) for signed denial of existence was added. These are not used yet, but parsing them is a requirement for later usage.
  • An initial version of a recursive resolver was added. Although it is already fully functional, it might have bad performance in certain circumstances.

What will happen?

A first DNSSEC specific code is already in the minidns-dnssec subproject in my working repository branch. With the recursive resolver being up and running, the base to work on the real DNSSEC part is done. So we can expect first DNSSEC features to arrive in short time.

June 17, 2015 00:00

June 13, 2015

Remko Tronçon

June 12, 2015

Ignite Realtime Blog

Spark 2.7.1 Released

The Ignite Realtime community has released Spark 2.7.1 for general availability and it can be downloaded from Ignite Realtime: Downloads (Note: there are no working Mac OS X installer as our current build environment has no working setup for Mac, also Spark has lots of issues on the current Mac OS versions and the community has no active Mac OS developers willing to step in).


This release contains much less changes comparing to the previous version (12 tickets with a minor changes and fixes). The plan is to do minor releases with a few changes, so it would be easier to find a culprit if regression happens. But there won't be a new version every other day. We don't want system admins to get mad at us


This is the complete list of changes in this version (official changelog):


SPARK-864 - Printing conversation margin cuts off characters from lines that wrap

SPARK-1512 - ***<user> is online at message does not always show in chat room

SPARK-1513 - After receiving XML data as a message Spark stops displaying history

SPARK-1604 - Buzz and stale settings overlap in the Preferences window

SPARK-1588 - Update French translation

SPARK-1607 - Show JID as contact name if instead an empty string would have been shown

SPARK-1609 - Default resource should be "Spark" without a version number

SPARK-1611 - Update Lithuanian translation

SPARK-1617 - Fix loading of Spellchecker's IgnoreUppercase setting

SPARK-979 - Add an option to disable graying out and italic for idle contacts

SPARK-1503 - Option to use hostname as a resource

SPARK-1584 - Update bundled JRE with the latest version


This release is bundled with the latest and last Java 7 update (7u80). Next releases will be bundled with Java 8 (most probably). Printing GUI has been replaced with the modern Java based version.


There is still no Project Lead developer for Spark (no active developers at all actually). So there won't be a regular schedule of releases. But you can always share your patches on the GitHub. If you find new issues, you can report them in the forums and we will at least file them in the bug tracker for the future developers to tackle.


Here are checksums for the downloads:




915d1268d83562fb1b01b6366fa1cc41b3e46528  spark-2.7.1.rpm

dc829d50691efcd4d7a8b0293fc5acb3c1c9e071  spark-2.7.1.src.rpm

1de66c31b93b9397f9c7666911b3829097141a6d  spark_2_7_1.deb

7f9e6921a703b7d0be33fe876f3a9daffdbd7cae  spark_2_7_1.exe

feeadbc8a8f1301f50e884fd62d5d2fb15921550  spark_2_7_1.tar.gz

bf483e4e8eece100ebce0159b9e1651071930370  online/spark_2_7_1_online.exe


or sha512sum


ed2e013876638a7a0a96dca84847910b688a2cbae8371097c3bfc715916b389a34a4152e180aa5e9 6b8a90ac64e8a5be408ae07d2bc08f7c57025199b197672f  spark-2.7.1.rpm

a75875ddc6fdd8a6c1a3d711ce60cc130e3becaae9d0a63b40515268105c80e1aa79a96216baa36d 7486d68ed15015f216cb9f839b98b6bac156adf6cd59bf62  spark-2.7.1.src.rpm

df9b8510e8619d09920416e14a680d4ef003700ac7d3c1f90be51c725f551b26515ba02c74bdb7f0 123f2651c7710f9cc09c561b180166eec9b05ded35c559da  spark_2_7_1.deb

0bc80508774ed5f8a2c85d73fa93b38d7ba2a7fa4c340c83df0d7080fb7b8dd8dea99dbf656469bc cc2a707a8bfe57260e9053f0fbd83cc38c45756a541dc86f  spark_2_7_1.exe

4486f298975c9824d69d8b98057fa326aa6d081044da498260c86573e0dd126cbe124763c22783b1 5bf38d1d6b6fe10fd457861e08980cae172a0d1b07d2802d  spark_2_7_1.tar.gz

67d08d397ba022d1ba1139291103a32a865abdee65b185373f16e04a88d658728b87a496a3004586 26d03066f8033f403db0f827bcf5d852f34185e73d6e4f0c  online/spark_2_7_1_online.exe

by Ignite Realtime Blog ( at June 12, 2015 15:15

June 11, 2015

Peter Saint-Andre

Two More Nietzschean Poems

Although my philosophical focus right now is on Thoreau, I'm also thinking once in a while about Songs of Zarathustra (a cycle of poems providing a positive interpretation of Nietzsche's ethics). Here are drafts of two more poems that might make the cut. As can be seen, these are related to my previous poem Eternal Recurrence.

June 11, 2015 00:00

June 10, 2015

Daniel Baczynski (GSoC 2015)

Account and AccountsManager classes

I have extracted some global-specific object instances out of MainController class. This way I started preparing MainController to be created for every account (we need to have multiple MainControllers and one Swift window).

We have now an Account and AccountsManager classes that control MainController instances (Account is passed for every MainController). Profile settings are loaded using current implementation of ProfileSettingsProvider and new options are set to default when loading a profile that has been created previously (backward compatibility). We can still log in into one account only but the aim was to prepare an appropriate design for multiple sessions.

I will test it more to find out potential problems and then it's time for login window GUI.

by DanielB ( at June 10, 2015 16:15

Coding started - plan for the summer

Coding started this week. This is my sketch of a plan for multi account support project:

25 May

* weeks 1-2: Extract some global-type things out of MainController so they're not initialized with every account. Change interfaces/implementation of single-account oriented classes to prepare them to multi-account use (partially).

* weeks 3-5: Accounts list in login window. Ability to change colour of account, name, connection options, select default, write and remember password. Logging in into one account from list enabled – one instance of MainController.

26 June: Mid-term

* week 6: Expandable list in roster header but changing accounts inactive. Accounts colour bar in roster.

* week 7-9: Logging in to multiple accounts (many complications expected).

* week 10-11: Edit profile, add contact, enter room, start chat, run server command – able to select account before an action. Changing status for every account at once. 

* week 12: Chat window account identifying convenience implemented. Searching contacts.

17 August: Suggested “pencils down”

* week 13: Last adjustments.

28 August: The end

by DanielB ( at June 10, 2015 15:53

Adhish Singla (GSoC 2015)

Week 2


Identifying Devices and Extending Client to all WebPages


ConverseJs is a Chat Client that uses XMPP standards. We need to extend its support to XEP-0323 and XEP-0325 standards, so that the client can distinguish between friends and devices.


  • Extended Chat Client to all Pages.
  • Instantiated our own BOSH Server at ‘’.
  • Made a Script that uses XEP-0323 and XEP-0325 to distinguish between devices by sending a Disco Query.
  • This is the Sequence Diagram for a Successful IoT-Sensor Data Request. Successful IoT-Sensor Data Request

Road Ahead

  • Set up a Different Tab for Devices which can read and write values to it.
  • Creating IoT Device APIs for Devices like intel edison, intel galileo, raspberry PI 2, beagle bone black, etc.

by Joachim Lindborg ( at June 10, 2015 13:46

Andreas Straub (GSoC 2015)

Week 02 - Sessions

Hey everyone, and welcome back to this week's progress report!

Last week, I talked about design decisions regarding session trust. As a result of those considerations, I spent this week implementing session handling. As a reminder: In our approach, we need to maintain one session per remote device, as well as one session per own device. Within each of those sessions, we use the TextSecure-style "trust on first use" policy, so that sessions can be established easily. This means that, if we simply pass messages to these axolotl sessions, they will happily encrypt them, which we don't want. We want to only ever send out messages on sessions that the user has manually confirmed as trusted. So we need to keep track of which sessions have been marked as trusted.

Because we can't easily modify the libaxolotl-java data structures without patching the entire library, I wrote a session wrapper class that encapsulates libaxolotl-java sessions and provides higher-level interfaces to the rest of the code. Furthermore, I expanded on the AxolotlService implementation, which is the central entity that manages all axolotl-based communications for a given account. It now provides two primitives that handle all the behind-the-scenes machinations involved with sending/receiving messages. I also implemented a basic form of payload encryption using the axolotl-based key transport mechanism, although this is more of a mockup right now, in order to obtain testable working code. Lastly, I designed and implemented the core data structures that will be used internally to manage and pass around messages during the various stages of encryption and tackled a basic form of wire protocol XML generation. This stuff is still subject to change, so I will go into more detail on the wire protocol in a future post.

I am anticipating spending still more time on internals next week before getting a to a working basic state. Most notably, the wire protocol still needs some tweaking. Then I can get started with connecting the AxolotlService up to the rest of Conversations, and hopefully run some testing to figure out any architectural issues before I continue on with the implementation of actual multi-end to multi-end session handling. Stay tuned.

by Andreas Straub ( at June 10, 2015 07:00

Peter Saint-Andre

RFCs 7572 and 7573: SIP-XMPP Messaging

And the hits keep coming! Today two more of my RFCs were published through the Internet Engineering Task Force, defining how SIP and XMPP can interoperate for one-to-one messaging: RFC 7572 covers single messages (also called "pager-mode" messaging in the SIP world), whereas RFC 7573 covers one-to-one chat sessions (a.k.a. "session-mode" messaging). These documents continue in the series started with RFCs 7247 and 7248 and have been in the works since early 2008, if you can believe it. I hate to brag, but it shows how much I care about interoperability that I've kept pushing these specs forward all this time. :-) There are two more documents still to be published in this series: one on multi-party text chat rooms and the other on voice and video call signaling, so stay tuned for more RFCs in the relatively near future...

June 10, 2015 00:00

June 09, 2015

Tarun Gupta (GSoC 2015)

Week 2 & 3

So Far ...

Hello everyone. Two weeks have gone past start of coding period. It has been quite a nice week with some coding and testing!

As far as progress is concerned, I have implemented all of the avatar functionalities for Stroke, but there are some minor bugs which needs to be fixed for proper implementation. And therefore some tests are still being implemented. I have started implementing different elements, their parsers and serializers, and have implemented some, including VCard Element, Bytestreams Element. Although a large amount of Elements are yet to be implemented, I will try to finish off with these by the end of this week.

I had some problems in implementing Avatars, so I have put them up for review on Gerrit. So just waiting for feedback on them so that I can squash bugs and yeah, still waiting for older commits to be reviewed and merged finally!

by TARUN GUPTA ( at June 09, 2015 17:02