Planet Jabber

August 18, 2017

Paweł Alameyo Ścibiorski (GSoC 2017)

#14 Wrapping up and bug fixing



This week apart from finishing last week things with mutual authentication I didn't done much new things. Instead I am focusing on fixing bugs in code made up to this point. One thing is creating KeyStores at Spark launch. While managing it's content work's Spark currently doesn't create KeyStores at the start up so user have to manually put them in security folder. Now it will not be a problem anymore but Spark lack a default certificates so I am still working on use of Java's cacerts content in Spark. That add a bit more complexity to existing Spark's KeyStore Management system as I want to use cacerts file only to read it's certificates, not to modify it's content (other applications can use it as well). I already use 4 KeyStores which are treated with different rules. Example problem is adding certificate to the exceptions list which usually mean adding certificate to the exceptions KeyStore and removing it from previous KeyStore. Not removing it would mean that there would be now 2 copies of the certificate in certificate table. There are some ideas how to work on that but as you can see things starting here to be complicate which might result in not so good looking code.


See you next week,


by Paweł Alameyo Ścibiorski (GSoC 2017) ( at August 18, 2017 22:42

Fanout Blog

Realtime data and continuous delivery

Software development teams are beginning to realize the benefits of continuous, test-driven delivery of new releases.

Instead of a single, milestone release (waterfall development) or multiple, internal test releases before major external ones (agile development), continuous delivery focuses on constant releasing of features to market throughout the development process.

The goal of continuous delivery is that code is always ready to deploy and features are constantly rolled out independent of ‘releases’ – and doing so properly requires realtime data.


by daniel at August 18, 2017 16:37

August 16, 2017

Paul Schaub

GSoC Week 11.5: Success!

Newsflash: My Jingle File Transfer is compatible with Gajim!

The Gajim developers recently fixed a bug in their Jingle Socks5 transport implementation and now I can send and receive files without any problems between Gajim and my test client. Funny side note: The bug they fixed was very familiar to me *cough* :P

Happy Hacking!

by vanitasvitae at August 16, 2017 14:49

Peter Saint-Andre

Providing an Alternative

Although I pay no attention to the news, I'm vaguely aware that perhaps the world is becoming more negative and irrational. Rather than getting lost in despair and confusion, I try to model a positive, reasonable alternative by living the best life I can and by writing philosophical books that are clear, concise, and constructive. I've written six such books, with a seventh half done and an eighth outlined. Even though each of these books takes 500-1000 hours to research and write, I make them all available for free on my website (however, I do charge for the paperback and ebook versions). To date I've also made no effort to market them, so I depend on word of mouth. If you have found value in any of these books, I'd greatly appreciate it if you could tell a friend, write a review at Amazon, or give a copy as a gift. Thanks. :-)...

August 16, 2017 00:00

August 14, 2017

Ignite Realtime Blog

Smack 4.2.1 released

I've tagged and released Smack 4.2.1 to Maven Central. We decided to omit the smack-omemo* in this release packages as the API is not yet stable. Paul is currently working on encrypted Jingle Transports as part of his GSOC project which also involves OMEMO, and we probably will make some API changes to the existing OMEMO API because of that. As always daily snapshot builds are available from

by Ignite Realtime Blog ( at August 14, 2017 19:08

Fanout Blog

Building a realtime chat app with Django and Fanout Cloud

Chat is one of the most popular uses of realtime data. In this article we’ll explain how to build a web chat app in Django, using Django EventStream and Fanout Cloud. The Django EventStream module makes it easy to push JSON events through Fanout Cloud to connected clients.



by justin at August 14, 2017 17:16


ejabberd 17.08

Happy summer with ejabberd 17.08 !
This release includes great improvements and new features. It also includes fixes and closes the biggest milestone about refactor we’ve made last couple of months.
If you have issues with 17.04 or troubles using PEP, upgrade to 17.08 will fix most known issues.

New features

Introduce ‘hosts’ option

The option can be used as a replacement of ‘host’ option when several (sub)domains are needed to be registered for the module.
Note that you cannot combine both ‘host’ and ‘hosts’ in the config because ‘host’ option is of a higher priority. Example:

     - "pubsub1.@HOST@"
     - "pubsub2.@HOST@"

XEP-0357: Push Notifications

This module tries to keep pending stream management sessions of push clients alive (as long as the disconnected clients are reachable via push notifications).

Modular cluster

For configuring the cluster new global option ‘cluster_backend’ is introduced. The default and only available value at the moment is ‘mnesia’.

Use c2s ‘certfile’ option

Use the ‘certfile’ listener option rather than a ‘domain_certfile’ for ejabberd_c2s listeners that have “tls: true” configured. A ‘domain_certfile’ should only be preferred for STARTTLS connections.

New mod_muc hooks

There are four new events: create_room, destroy_room, join_room and leave_room.
Note: destroy_room was previously used already by mod_mam and was named remove_room. remove_room is not renamed back to destroy_room for consistency.



  • Erlang/OTP 17.5 or higher is required, and 20 is now supported
  • Make ejabberd_cluster modular
  • Replace gen_fsm with p1_fsm to avoid warnings in OTP20+
  • Fix clustering table reg_users_counter
  • ext_mod: Update spec from custom and allow modules dependencies
  • Fix to support : in passwords
  • Set high water mark in lager for all backends
  • Fix old route record in mnesia’s route table haven’t been remove when restarting in some cases
  • ejabberd_cluster*.erl: Add copyright and fix description
  • Add support of rfc6120 section on node shutdown


  • ejabberd_c2s: Fix priority of ‘certfile’ option
  • Introduce ‘hosts’ modules option
  • Remove unused ‘managers’ option, related to the deferred XEP-0321


  • Fix errors when running ejabberdctl as root
  • Fix set_presence command to work in recent ejabberd
  • Rename stop_all_connections to stop_s2s_connections for consistency
  • Change policy of user_resources command, from user to admin
  • Remove old command calling interface
  • Describe more command arguments and results


  • mod_http_api: Use hide_sensitive_log_data option when registering users
  • mod_http_fileserver: Request basic auth dialog from browser
  • mod_muc: Fix nick bug with MUC on riak
  • mod_muc: new hooks
  • mod_push: Support XEP-0357: Push Notifications
  • mod_push_keepalive: New module


  • Keep disco#info on PEP compatible with XEP-0060
  • Preliminary export PubSub data from Mnesia tables to SQL file
  • Fix PubSub send last published items
  • Fix PEP node removal
  • Fix PEP node identity
  • Fix disco#items on PEP service
  • Fix getting cached last item
  • Add import of PEP from prosody


  • Improved API documentation


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 August 14, 2017 15:23

Paul Schaub

GSoC Week 11: Practical Use

You know what makes code of a software library even better? Client code that makes it do stuff! I present to you xmpp_sync!

Xmpp_sync is a small command line tool which allows you to sync file from one devices to one or more other devices via XMPP. It works a little bit like you might now it from eg. owncloud or nextcloud. Just drop the files into one folder and they automagically appear on your other devices. At the moment it works only unidirectional, so files get synchronized in one direction, but not in the other.

The program has to modes; master mode and slave mode. In general, a client started in master mode will send files to all clients started in slave mode. So lets say we want to mirror contents from one directory to another. We start the client on our master machine and give it a path to the directory we want to monitor. On the other machines we start the client in slave mode, and then add them to the master client. Whenever we now drop a file into the directory, it will automatically be sent to all registered slaves via Jingle File Transfer. Files do also get send when they get modified by the user. I registered a FileWatcher in order to get notified of such events. For this purpose I got in touch with java NIO again.

Currently the transmission is made unencrypted (as described in XEP-0234), but I plan to also utilize my Jingle Encrypted Transports (JET) code/spec to send the files OMEMO encrypted in the future. My plan for the long run is to further improve JET, so that it might get implemented by other clients.

Besides that I found the configuration error in my ejabberd configuration which prevented my Socks5 proxy from working. The server was listening at by default, so the port was not reachable from the outside world. Now I can finally test on my own server :D

I also tested my code against Gajims implementation and found some more mistakes I made, which are now fixed. The Jingle InBandBytestream Transport is sort of working, but there are some more smaller things I need to change.

Thats all for the week.

Happy Hacking :)

by vanitasvitae at August 14, 2017 14:43

August 13, 2017

The XMPP Standards Foundation

Easy XMPP: The Challenges

Over the last years, the XMPP community has had a hard time competing with other Instant Messaging implementations, especially in the mobile / smartphone ecosystems. By focusing a small part of our resources on user experience (UX), we can gain significant improvements. This article is the first in a series of "Easy XMPP" posts: easy ways for application developers to make XMPP easy to use.

Complexity of Federation

As opposed to most other Instant Messaging solutions, XMPP is a federated protocol. That allows everyone to run their own servers, at the cost of additional complexity for users:

  • the user identifier always consists of a user and a domain part,
  • there is no central registry that will consume your phone book and tell you who else is using XMPP,
  • some servers might be running an older stack not supporting modern features, etc.

This inherent complexity, together with many developers' lack of attention to good UX, have left us in a situation where on-boarding of new users and finding contacts is painfully hard, especially when compared to proprietary/centralized IM solutions.

It is not possible to remove the inherent complexity of federation without replacing XMPP with a completely different protocol. However, there is another federated system that is well established and used by people all over the world: email. XMPP and email share the same basic principles - they are federated, user identifiers are user@domain and it is possible (albeit less common) to run your own server (or to get your own domain hosted with a commercial provider).

By leveraging users' knowledge about how email works, learning from over forty years of email evolution, and applying ideas from modern UX design on top, it is possible to make XMPP easier to use today.

Our Challenges

There are several areas where our community needs to improve. This post provides an overview of the challenges we are currently facing in different areas. Subsequent posts will dive deeper into the individual topics and work out possible solutions.


The XMPP terminology is driven by technical requirements and exposes complexities of the protocol. Normal IM users don't want to know about PubSub Publish Options, asymmetric presence subscription in their roster, or MUC-PM Carbons. All they care about is to see whether their friends are online and that they can exchange cat pictures.

It is our task as the developer community to create understandable abstractions of the technical complexities, and to set up a common glossary for the user-facing elements, including translations into common languages. We need to define what the difference between "Jabber" and "XMPP" is, whether the user identifier is a "JID", a "Jabber ID", an "XMPP address", or a "user identifier", and fix all the other terms that are exposed to users and make clients inconsistent today. And then we need to apply this glossary to our implementations.

First-time User Experience

The first-time user experience for IM users needs to be streamlined. The users who need the most assistance are newcomers to the ecosystem who got invited by a friend, and start out with nothing but their friend's Jabber ID. They need help to accomplish these tasks:

  • install a modern client
  • create an account
  • add their friend
  • automatically find all their other friends
  • find other users and chat rooms

Projects like Easy XMPP Invitations, Pre-Authenticated Roster Subscription, and invite URLs are a first step in that direction, and getting them into your client today will make new users' lives easier. But there is also potential to further streamline the whole process.

Easy Group Chats

There are two typical IM use cases for group chats: chat with friends or family (private groups), or participate in a public chat room (typically for support purposes, pioneered by Internet Relay Chat).

The latter is well-covered by MUC, and the upcoming MIX should provide a solid technical basis for both use cases. The next logical step is to allow the easy creation and sharing of ad-hoc rooms between different clients, with a coherent user experience.

Fighting Spam

If the amount of spam is a measure of XMPP's popularity, the network is doing exceptionally well. Almost all of today's XMPP spam can be blocked with some easy pattern matching rules, and the inevitable arms race will move to the next round.

The community needs to prepare for that, by improving reporting between server operators, adding anti-spam features into clients and providing better whitelisting mechanisms to users.

Call for Action

You can help making XMPP easier to use. As a user, you can contribute ideas, add user stories, check your favorite client for confusing UI elements and non-helping wizards, and report those to the developers. As a developer, you can streamline the on-boarding process in your client and contribute to the common glossary.

Get yourself a wiki account and start hacking on Easy XMPP today!

by ge0rg at August 13, 2017 22:00

August 11, 2017

Paweł Alameyo Ścibiorski (GSoC 2017)

#13 Mutual authentication - continutation

Hi there,

It took me a bit longer than I thought to do mutual authentication but in the end, today it worked. How to present own certificates to remote party? Quite easily, 3 lines of code:

//Create KeyManagerFactory
KeyManagerFactory kmf = getInstance(String algorithm, String provider);

//Initialize it with content of the Keystore - it have to contain private key as well as certificate which will be send to remote server
public void init(KeyStore ks, char[] password);

//and during initializing SSLContext add:
context.init(kmf.getKeyManagers(), tmf.getTrustManagers(), new SecureRandom());

So what took me so long? It appears that somehow I was losing my private key during importing it to the Keystore. Also I had to create GUI for that. Still I have to polish it a bit and finish functionalities to create Certificate Sign Request and Self Signed certificates.

Here screenshot how it looks now:


Generally compared to Certificates tab, here table showing Keystore content is smaller as I assume user rarely will need more than one certificate. However it might happen, especially  when user often switch domains using the same client and different servers have different CA in it's Truststores. I hope to finish it over weekend and then I will move to bugs  from earlier part of project. There is some of them but one is particularly bad as during moving certificates from and to Exceptions it happens that content of one of the Keystores is deleted. I still didn't figured out what is reason but soon, after finishing mutual authentication panel I should be able to look more into that.

by Paweł Alameyo Ścibiorski (GSoC 2017) ( at August 11, 2017 22:10

Tigase Blog

XEP-0142 Workgroup Queues

Workgroups were developed as an extension to enable an XMPP server to behave like queue line for users awaiting assistance. The idea is that users are placed on a first-come first-served waiting queue to enter a chat room where they may communicate. Although an experimental extension, it is just one of the many ways in which XMPP can be shaped into a custom solution.

by Daniel at August 11, 2017 04:14

August 10, 2017

Peter Saint-Andre

None of My Business

Apropos of my latest journal entry "Politics is a Disease", here is a quote from Beyond Good and Evil (Section 251) by Friedrich Nietzsche:...

August 10, 2017 00:00

August 08, 2017

Tarun Gupta (GSoC 2017)

Week 9 & 10

Hello all,

We have a new design for MIX ! As proposed by mentors, we have a new implementation scheme for MIX involving MIX Registry, which will have access to all MIX objects for successfully joined channels. 

The new design allows requesting a MIX Registry from Client and detecting whether local server is supported.  It also adds XMPPRoster to be a part of MIXRegistry. A standard roster encoding is as follows:
<item jid=''/>
However, if a roster item is a MIX channel, the new encoding will be :
<item jid=''>
<channel xmlns=‘urn:xmpp:mix:roster:0'/>
Based on this, we now define a channel to be successfully joined or left based on the presence of channel JID in the user's roster. If a channel is successfully joined, a roster encoding with a channel element is added to user's roster. Similarly, when channel is left, roster encoding is removed from user's roster. 

In the upcoming weeks, I will update limber to have minor support for MIX and test my implementation against it.

by Tarun Gupta ( at August 08, 2017 14:03

August 07, 2017

Paul Schaub

GSoC Week 10: Finding that damn little bug

Finally!! I found a bug which I was after for the last week. Now I finally got that little bas****.

The bug happened in my code for the Jingle SOCKS5 Bytestream Transport (XEP-0260). SOCKS5 proxies are used whenever the two endpoints can’t reach one another directly due to firewalls etc. In such a case, another entity (eg. the XMPP server) can jump in to act as a proxy between both endpoints. For that reason, the initiator (Alice) first collects available proxies, and sends them over to the responder (Bob). The responder does the same and sends its candidates back to the initiator. Both then try to connect to the candidates (in this case proxies) they got sent from their peer. In order for the proxy to know, who wants to talk to whom, both include a destination address, which is calculated as SHA1(sid, providerJid, targetJid), where the provider is the party which sent the candidates to the target.

The alert reader will know, that there are two different destination addresses in the game by now. The first one being SHA1(sid, Alice, Bob) and the second one SHA1(sid, Bob, Alice). The issue is that somewhere in the logs I ended up with 3 different destination addresses. How the hell did that happen. For the answer lets look at an example stanza:

<iq from=’romeo@montague.lit/orchard’
<jingle xmlns=’urn:xmpp:jingle:1′
<content creator=’initiator’ name=’ex’>
<description xmlns=’urn:xmpp:example’/>
<transport xmlns=’urn:xmpp:jingle:transports:s5b:1′
<candidate cid=’hft54dqy’

Here we have a session initiation with a Jingle SOCKS5 Bytestream transport. The transport exists of one candidate. Now where was my error?

You might have noted, that there are two attributes with the name ‘sid’ in the stanza. The first one is the so called session id, the id of the session. This should not be of interest for our case. The second one however is the stream id. Thats the sid that gets crunched in the SHA1 algorithm to produce the destination address.

Well, yeah… In one tiny method used to update my transport with the candidates of the responder, I used session.getSid() instead of transport.getSid()… That was the bug, that cost me a week.

Now it wasn’t too bad. While I searched for the error, I read through the XEPs again and again, discovering some more issues which I discussed with other developers. Also I began testing my implementation against Gajim and I’m happy to tell you that the InBand Bytestream code is already working sort of. Sometimes a few bytes get lost, but we live in times of Big Data, so thats not too bad, am I right :P ?

In the last 3 weeks I plan to stabilize the API some more. Currently you can only receive data into files, but I plan to add another method which gives back a bytestream instead.

Also I need more tests. Things like that nasty sid bug can be prevented and found using junit tests, so I’ll definitely stock up on that front.

Thats all for now :) Happy Hacking!

by vanitasvitae at August 07, 2017 22:31

August 05, 2017

Remko Tronçon

Ken Burns Effect Slideshows with FFMPeg

One of the first things that impressed me about Mac OS X when I first saw it was its screensaver. Instead of just showing a simple slideshow of your pictures, it actually used a ‘Ken Burns’ panning and zooming effect with a fancy fading transition to make the otherwise static pictures really come to life. It always sounded like a fun project to create a standalone tool to create slideshow movies that used this effect, with full control over where and how much pictures should be zoomed. It turns out you don’t really need a new tool: you can get the same result using just FFMpeg. In this post, I’ll walk through the steps of creating slideshows using the Ken Burns effect.

Oh, and cats. There will be cats!

Continue reading post

by Remko Tronçon at August 05, 2017 22:00

August 04, 2017

Paweł Alameyo Ścibiorski (GSoC 2017)

#12 Client Side Authentication


What's going on this week? I started working on next and the last big feature which is client side authentication. Support for it will allow for response to server certificate request from client. If we add it to server side authentication then we can say that it is Mutual Authentication. It isn't so wide used as usually server presenting it's certificates to the client is enough. Nonetheless if server is meant to connect only to trusted clients then it is nice feature.

Adding client side authentication require to provide to client's certificate chain and having private key for decryption. Overly this adding client side authentication seems simpler than validating chain of certificates received from server. As I understand it for now I have to only create instance KeyManagerFactory and initialize it with credentials which will be provided by SSLContext to the server. As part of implementation of mutual authentication I intend to add utilities for creating certificate signing request and self signed certificates. So far this with proper KeyStore managing and connect it well with GUI can give me some headache but I hope to overcome any problems soon. There is still some things I am yet to figure how to do but I know general direction for implementing mutual authentication.


See you next week,


by Paweł Alameyo Ścibiorski (GSoC 2017) ( at August 04, 2017 21:33

August 03, 2017

Fanout Blog

Reliable Server-Sent Events for Django

Today we’re pleased to introduce Django EventStream, a module that provides Server-Sent Events capability to your Django server application. It relies on Pushpin or Fanout Cloud to manage the client connections. Events can optionally be persisted to your database, for highly reliable delivery.


by justin at August 03, 2017 01:42

August 02, 2017

Paul Schaub

GSoC Week 9: Bringing it back to life.

The 9th week of GSoC is there. I’m surprised of how fast time went by, but I guess that happens when you enjoy what you do :)

I’m happy to report that the third iteration of my Jingle code is working again. There are still many bugs and Socks5Transport is still missing, but all in all I’m really happy with how it turned out. Next I’ll make the implementation more solid and add more features like transport replacing etc.

Apart from normal Jingle File Transfer I also started working on my JET protocol. JET is short for Jingle Encrypted Transfers which is my approach to combining Jingle sessions with end-to-end encryption. My focus lays on modularity and easy extensibility. Roughly JET works as follows:

Lets assume, Alice wants to send an encrypted file to Bob. Luckily Alice and Bob already do have a secure OMEMO session. Alice now sends a JET File transfer request to Bob, which includes a security element which contains an OMEMO key transport message. Bob can decrypt the key transport message with his OMEMO session to retrieve an AES key. That key will be used to encrypt/decrypt the file Alice sends to Bob as soon as the jingle session negotiation is finished.

This protocol should in theory work with any end-to-end encryption method, for example also with OpenPGP. Also JET is in theory not limited to file transfer, but could also be used to secure other types of Jingle sessions, eg. Audio/Video calls. Since the development is in a very early state, it would be nice to get some feedback from more experienced developers and members of the XMPP community. A rendered version of the JET specification can be found here.

I’m very happy that encrypted File transfer already works in my implementation. I created an integration test for that, which transports the encryption key using OMEMO. Apropos tests: I created a basic JingleTransport test, which tests transport methods. Currently SOCKS5 is still failing, but I’m very close to a solution.

During the week I opened another PR against the XEPs repo, which adds a missing attribute to a XML schema in the Jingle File Transfer XEP.

by vanitasvitae at August 02, 2017 10:43

July 29, 2017

Tigase Blog

Push Notification Component

There are times when the business of an organization cannot rely on ‘posted business hours’. Most chat programs require a user to sign in to a service to receive messages, and when they’re offline messages will wait until later. But there are times when a message absolutely has to get through – even if the intended receiver may be offline. E-mails can be sent, but it lacks the same immediacy that a notification can provide. How to solve this problem? Enter Push notifications.

by Daniel at July 29, 2017 18:52

Fanout Blog

Realtime data for smart notifications

It’s becoming the new normal that messaging and collaboration apps and platforms are available across multiple devices.

Business tools like Slack and JIRA offer feature-rich mobile apps, and users increasingly consume content from social networks like Facebook on their mobile devices instead of a desktop or laptop.

This isn’t a surprise – and we’re here to share our perspective on how developers can use realtime data to provide cross-platform users with the best notification experience.


by daniel at July 29, 2017 10:50

July 28, 2017

Paweł Alameyo Ścibiorski (GSoC 2017)

#11 Online Certificate Status Protocol

Hi there ,


This week I was implementing Online Certificate Status Protocol. Java allow to implement it in form of PKIXRevocationChecker which is added to the parameters of certificate path which is later validated. PKIXRevocationChecker is abstract class so it need some work on implementation and it is Openfire's way to handle this problem (well, it also use more abstract PKIXCertPathChecker class). Before I come to the my solution for PKIXRevocationChecker let's try to grasp some knowledge about what is OCSP?


It's protocol defined in rfc6960 for checking certificate revocation. In many ways it is superior to the CRLs as it doesn't require downloading whole lists for certificates which we aren't processing. However is not included in the basic PKI document while CRL way of checking of revocation is. Why? I can only guess but it is maybe bit more complicated and requires constantly working server, while in theory CRL's can be cached for group certificates and used for some period of time. Anyway OCSP isn't so popular as CRLs so any implementation of it should support CRL as backup.

OCSP include two parts: client request and server response.


An OCSP request contains:

   - protocol version

   - service request

   - target certificate identifier

   - optional extensions

Basic response include:

  - version of the response syntax

  - identifier of the responder

  - time when the response was generated

  - responses for each of the certificates in a request  - that means by one request response we can check group of certificates. Response can be good, revoked or unknown.

  - optional extensions

  - signature algorithm OID

  - signature computed across a hash of the response

Protocol states that there can be many types of response but at least that one basic have to be supported in every server side implementation of OCSP.


Now back to Java implementation of OCSP. While creating own checker is completely fine I found out that according to the Java PKI Programmer's Guide I can use CertPathBuilder to get instance of OCSP checker ( which also checks as backup CRLs ). Then I can change some of the options in this checker and add it to the parameters used in certificate chain validation. That's all. Why Openfire doesn't use it? The reason might be that this PKIXRevocationChecker was introduced in Java 8, while Openfire is much older software. So Openfire's way is perfectly cool, just person who did it couldn't use Java 8 then, which simplify it now.


See you next week,


by Paweł Alameyo Ścibiorski (GSoC 2017) ( at July 28, 2017 21:58

July 26, 2017

Paul Schaub

GSoC Week 8: Reworking

The 8th. week of GSoC is there. The second evaluation phase has begun.

This week I was not as productive as the weeks before. This is due to me having my last (hopefully :D ) bachelors exam. But that is now done, so I can finally give 100% to coding :) .

I made some more progress on my Jingle code rework. Most of the transports code is now finished. I started to rework the descriptions code which includes the base classes as well as the JingleFileTransfer code. I’m very happy with the new design, since it is way more modular and less interlocked than the last iteration. Below you can find an UML-like diagram of the current structure.

UML diagram of the jingle code

UML-like diagram of the current jingle implementation

During the rework I stumbled across a slight ambiguity in the Jingle XEP(s), which made me wonder: There are multiple jingle actions, which denote the purpose of a Jingle stanza (eg. transport-replace to replace the used transport message, session-initiate to initiate a session (duh) and so forth). Now there is the session-info Jingle action, which is used to announce session specific events. This is used for example in RTP sessions to let the peers client ring during a call, or to send the checksum of a file in a file transfer session. My problem with this is, that such use-cases are in my opinion highly description related and instead the description-info action should be used. The description part of a Jingle session is the part that represents the actual purpose of the session (eg. file transfer, video calls etc.).

The session itself is description agnostic, since it only bundles together a set of contents. One content is composed of one description, one transport and optionally one security element. In a content you should be able to combine different description, transport and security components in an arbitrary way. Thats the whole purpose of the Jingle protocol. In my opinion it does no make much sense to denote description related informational stanzas with the session-info action.

My proposal to make more use of the description-info element is also consistent with other uses of *-info actions. The transport-info action for example is used to denote transport related stanzas, while the security-info action is used for security related information.

But why do I even care?

Lets get back to my implementation for that :) . As you can see in the diagram above, I split the different Jingle components into different classes like JingleTransport, JingleSecurity, JingleDescription and so on. Now I’d like to pass component-related jingles down to the respective classes (a transport-info usually only contains information valuable to the transport-component). I’d like to do the same for the JingleDescription. At the moment I have no real “recipient” for the session-info action. It might contain session related infos, but might also be interesting for the description. As a consequence I have to make exceptions for those actions, which make the code more bloated and less logical.

Another point is, that such session-info elements (due to the fact that they target a single content in most cases) often contain a “name” attribute that matches the name of the targeted content. I’d propose to not only replace session-info with description-info, but also specify, that the description-info MUST have one or more content child elements that denote the targeted contents. That would make parsing much easier, since the parser always can expect content elements.

That’s all for now :)

Happy Hacking!

by vanitasvitae at July 26, 2017 09:57

July 24, 2017

Tarun Gupta (GSoC 2017)

Week 7 & 8

Hello all,

It has been productive two weeks ! I have added some features to MIX in Swiften. These two weeks, I have added the following features:

1. Registering and setting Nick by a MIX client: This feature allows a MIX user to set and register a nick for a MIX channel by sending IQ stanzas of the following type:
<iq type='set'
<setnick xmlns='urn:xmpp:mix:0'>
This example shows an IQ stanza from a MIX client to a MIX channel asking to set nick "thirdwitch". Similarly, if a MIX channel supports registering nick (mix_nick_register), then client sends a register nick payload to the channel.

2. Requesting VCard of  a channel participant: A MIX client can now request a VCard of a channel participant by sending  an IQ request to bare proxy JID of the channel participant as follows:
<iq from='hag66@shakespeare.example/UUID-c8y/1573'
<vCard xmlns='vcard-temp'/>

3. Sending/Retracting/Receiving Messages: A client sends a message directly to a MIX channel as a standard group chat message, in exactly the same way as for Multi-User Chat. Messages are sent directly to the MIX channel from the user's client as follows:
<message from='hag66@shakespeare.example/UUID-a1j/7533'
<body>Harpier cries: 'tis time, 'tis time.</body>
Similarly, a client can request to retract a message by sending a retract payload with  message id to the channel. 

4. I've also added a lookup of proxy JID to determine real JID of a channel participant in JID-Visible and JID-Maybe-Visible channels. This is done by sending a PubSub payload to MIX channel with proxy JID as follows:
<iq from='hag66@shakespeare.example/UUID-c8y/1573'
<pubsub xlns=''>
<items node='urn:xmpp:mix:nodes:jidmap'>
<item id='123456#coven@mix.shakespeare.example'/>
For JID Maybe Visible rooms the lookup is performed on the JID Maybe Visible Map (jidmap2) node. If a user prefers to not share real JID, the result of this lookup of proxy JID will be the (same) proxy JID.

5. I've added MIXInvite use case which allows a user to send an invite to other user for joining a channel. Initially, a request is sent to MIX channel for requesting a valid token to join the channel. If the channel supports joining by invitation, this token is sent to invitee by inviter. The inviter also received an invitation-ack when invitee has made a decision (Joined/Declined). Following example shows invitee joining a MIX channel by invitation:
<iq type='set'
<join xmlns='urn:xmpp:mix:0'>
<subscribe node='urn:xmpp:mix:nodes:messages'/>
All the above are pull requests now, and will be updated based on feedback by the mentors. 

This week, I'll add presence use case in MIX client which allows the client to share its presence with the local server. Also, I'll add administrative use cases like creating a channel, destroying a channel, etc. I have some queries regarding these features, which I hope to get clarified soon. 

Thats all for now ! Thanks!

by Tarun Gupta ( at July 24, 2017 05:50

July 21, 2017

Paweł Alameyo Ścibiorski (GSoC 2017)

#10 Certificate Revocation List

Hi there,


This week I was continuing working on the trust managers, and I added support for Certificate Revocation List. Certificate extension with OID contain link to the server with CRL file. Spark Trust Manager before SSL connection downloads all CRL list from web, create additional CertStore, save this CRLs to that store and through PKIX parameters use it for checking certificates revocation.


What's wrong with that method? Sometimes CRL lists can grow really huge, easy over 1000 entries so sometimes it can be over few MB of data. That can be sometimes overkill for some networks (someone still use dial up? ) and just parsing through it can takes some time. Anyway there is other way of checking if certificate is revoked which is Online Certificate Status Protocol. It allow to just send to server request for status of just one certificate so this save bandwidth and time. The only problem with that is it is less common extension for certificates, so if one doesn't have it Trust Manager still have to support CRLs.


The fun thing I noticed is that often people asking for help on the Ignite Realtime forum and open chat have problem with establishing connection with Smack and they are happy when it starts work for them. In meantime I was few times happy when I couldn't establish connection, because that means that SSL is working as there were no adequate certificate in TrustStore or it was invalid.


See you next week,


by Paweł Alameyo Ścibiorski (GSoC 2017) ( at July 21, 2017 14:49

July 18, 2017

Paul Schaub

GSoC: Week 7

This is my update post for the 7th week of GSoC. The next evaluation phase is slowly approaching and it is still a lot of work to do.

This week I started to work on integrating encryption in my Jingle File Transfer code. I’m very pleased, that only very minor changes are required to my OMEMO code. The OmemoManager just has to implement a single interface with two methods and that’s it. The interface should be pretty forward to implement in other encryption methods as well.

Unfortunately the same is not true for the code I wrote during the GSoC. There are many things I haven’t thought about, which require major changes, so it looks like I’ll have to rethink the concept once again. My goal is to make the implementation so flexible, that description (eg. video chat, file transfer…), transport (eg. Socks5, IBB…) and security (XTLS, my Jet spec etc.) can be mixed in arbitrary ways without adding in glue code for new specifications. Flow told me, this is going to get complicated, but I want to try anyway :D . For “safety” reasons, I’ll keep a seperate working branch in case the next iteration does not turn out as I want.

Yesterday Flow found an error in smack-omemo, which caused bundles not getting fetched. The mistake I made was, that a synchronous CarbonListener was registered in the packet-reader thread. This caused the packet-reader thread to timeout on certain messages, even though the stanzas arrived. It is nice to have this out of the way and it was a good lesson about the pitfalls of parallel programming.

While reading the Jingle File Transfer XEP I also found some missing XML schemes and proposed to replace the usage of xs:nonNegativeInteger and xs:positiveNumber with xs:unsignedLong to simplify/unify the process of implementing the XEP.

Thats basically it for this week. Unfortunately I have an upcoming exam at university next week, which means even less free time for me, but I’ll manage that. In the worst case I always have a second try on the exam :)

Happy Hacking!

by vanitasvitae at July 18, 2017 16:04