Planet Jabber

Distribuir contenido
Planet Jabber -
Actualizado: hace 56 mins 52 segs

Paweł Alameyo Ścibiorski (GSoC 2017): #14 Wrapping up and bug fixing

18 August, 2017 - 22:42



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,


Fanout Blog: Realtime data and continuous delivery

18 August, 2017 - 16:37

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.


Paul Schaub: GSoC Week 11.5: Success!

16 August, 2017 - 14:49

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*

Happy Hacking!

Peter Saint-Andre: Providing an Alternative

16 August, 2017 - 00:00
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. :-)...

Ignite Realtime Blog: Smack 4.2.1 released

14 August, 2017 - 19:08

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

Fanout Blog: Building a realtime chat app with Django and Fanout Cloud

14 August, 2017 - 17:16

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.


ProcessOne: ejabberd 17.08

14 August, 2017 - 15:23

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:

mod_pubsub: ... hosts: - "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.

Changes Core
  • 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.

Paul Schaub: GSoC Week 11: Practical Use

14 August, 2017 - 14:43

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

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

The XMPP Standards Foundation: Easy XMPP: The Challenges

13 August, 2017 - 22:00

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!

Paweł Alameyo Ścibiorski (GSoC 2017): #13 Mutual authentication - continutation

11 August, 2017 - 22:10

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.

Tigase Blog: XEP-0142 Workgroup Queues

11 August, 2017 - 04:14

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.

Peter Saint-Andre: None of My Business

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

Tarun Gupta (GSoC 2017): Week 9 & 10

8 August, 2017 - 14:03
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'/>
</item>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.

Paul Schaub: GSoC Week 10: Finding that damn little bug

7 August, 2017 - 22:31

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 ?

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!

Remko Tronçon: Ken Burns Effect Slideshows with FFMPeg

5 August, 2017 - 22:00

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

Paweł Alameyo Ścibiorski (GSoC 2017): #12 Client Side Authentication

4 August, 2017 - 21:33


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,


Fanout Blog: Reliable Server-Sent Events for Django

3 August, 2017 - 01:42

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.


Paul Schaub: GSoC Week 9: Bringing it back to life.

2 August, 2017 - 10:43

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.

Tigase Blog: Push Notification Component

29 July, 2017 - 18:52

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.

Fanout Blog: Realtime data for smart notifications

29 July, 2017 - 10:50

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.