Agregador de noticias

ProcessOne: XMPP Extensions are now managed on Github

Planet Jabber - 9 August, 2015 - 16:21

The XMPP Standards Foundation has moved a while back the repository for the XMPP specification documents to Github: xsf/xeps

This is quite an important change in the XMPP Extensions Proposal workflow. It is now easier than before to track the changes as they are happening.

I am curious to see the contributions rate in the next few months but I bet we will see involvement and contributions increasing. Even for small fixes and typos, this is a good thing.

You can see our work / proposal on processone/xeps or track our own custom work, possible candidates for new XMPP Extensions on processone/ejabberd-saas-docs.

ProcessOne: Jose Valim interviews Mickaël Rémond on Elixir language integration in ejabberd

Planet Jabber - 9 August, 2015 - 16:20

Here is a video interview from Jose Valim from Plataformatec about the integration of Elixir programming language as a standard way to write modules in ejabberd.

ejabberd is an extremely extensible and versatile server. Using ejabberd API together with Elixir programming language expressivity certainly makes writing ejabberd modules easier. It opens ejabberd module development to a whole new set of use cases. This integration makes ejabberd module development more approachable to new ejabberd developers and make it an even better choice for building advanced high-performance messaging platforms.

You can read the full blog post on Plataformatec website: Elixir in production interview: Mickaël Rémond

ProcessOne: BBC News launch new major Android and iOS app release, powered by Boxcar Push

Planet Jabber - 9 August, 2015 - 16:19

BBC News has launched a beautiful new version of its international application in July 2015.

It has still the same great content with a new modern look.

Coming from a server and scalability perspective, the best part is the incredible audience the International version of the app has, adding to their own UK audience. More figures are available from their slides, but the international version has 27 million downloads and an audience of 5.4 million monthly users.

We thank them for mentioning ProcessOne as their Push Notifications delivery partner. This is a project we are proud working on.

You can learn more about the brand new BBC News mobile app from BBC Media Center: BBC continues digital transformation of news on the go with new-look international BBC News app

Adhish Singla (GSoC 2015): Week 10

Planet Jabber - 5 August, 2015 - 13:57
Objective Write and History for Mobile Application Abstract

Implementation of Write for Control Devices and History Retrieval for a Sensor Device.

  • Implemented Write for numerical Fields.
  • Implemented History using Chart.js for Sensor devices which stores history.
  • History for a field is displayed as Graph on top of the Contacts.
Problems Faced
  • Setting up Proxy Settings for Gradle (Solved) : Gradle needs proxy settings in order to use maven for building Android Application.
Final Output

Road Ahead
  • Implementing History Retrieval for SleekXMPP.

Andreas Straub (GSoC 2015): Week 10 - Beta

Planet Jabber - 5 August, 2015 - 13:45
Hey everyone!
Some stuff came up that delayed the beta launch by a couple of days, but it's out now, so grab it while it's hot! 
My mentor and I realized that it might be nice to have a content-agnostic key transport mechanism built into the protocol, which could then be used for things like encrypted file transfer. This topic hadn't come up earlier due to the excellent work Daniel has been doing with his HttpUploadComponent, but it seemed like a prudent addition nonetheless. As this would involve changes to the wire protocol, we decided to delay the beta until this feature is completed.
We decided to implement it by introducing KeyTransportMessages, which are the same format as regular XmppAxolotlMessages, except they don't have a payload. The key that is encrypted in the message headers, which is otherwise used to encrypt the message payload, could then be used for other purposes. By itself, this is a very small change to the protocol, and adds very little complexity. We also took this chance to make some additional modifications to the packet layout (example).
In the course of implementing these changes, I refactored a lot of the message processing code. It had organically grown over the course of the project, and the workflow of using the API got pretty inconsistent. I also removed some dead code along the way, and ended up with a much cleaner and simpler interface. :)
Daniel also had some problems publishing the beta via Google Play, because the axolotl-java library targets midSdk version 1, which implicitly pulls in additional permissions that Conversations doesn't want or need. Thankfully he was able to resolve that, and publish the beta. I'm looking forward to your feedback, so go out and get it!
Now that all breaking changes should be out of the way and that we're pretty much feature-complete is a good time to start getting serious about standardizing this protocol. So my goal for next week is to prepare an XEP draft.

Jérôme Poisson: Let's talk XMPP - episode 3 - core and extensions (part 2)

Planet Jabber - 5 August, 2015 - 07:46

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

The translation to English was done thanks to: Poulet, Éfrit, Paco, mbarbarosa, Weyfonk and Chteufleur. The whole series is under CC By-SA, and any help would be appreciated to help with the translation of next articles. (Follow the corresponding link to read the previous episodes).   Some functionalities can be added to this central part, hence the X of XMPP (which stands for “eXtensible”).   Extensions are written using “XEP” (XMPP Extension Protocol) , following an idea taken from Python (if I am not mistaken). This is why the features supported by a server or a client are identified as XEP-0XXX. Obviously, no need to know this to use a XMPP client, but it can be useful to read an extension (you can find them at to understand correctly the utility of a functionality. Two parts are particularly useful without the need to enter in the implementation details: the “abstract” part (summary) in the top that indicates what the XEP is doing, and the “introduction” section (the very first section) that provides further details about the cause of the extension and its use cases.     An XEP can describe a feature, a process (for instance the XEP-0001 explains the life cycle of the XEPs themselves), a historical legacy (related to something created before the XMPP Standard Foundation), information (like good practices), even a joke (yes, there are also lousy jokes in the XEPs!). It can have several statuses, detailed in the XEP-0001. It is interesting to note that a lot of XEPs are “experimental” and so technically not (yet) standards, but often implemented anyway. Such XEPs can be widely modified before they get the “Draft” status and eventually become a standard.   Why am I talking about all this? For you to get one thing loud and clear: XMPP is not only about instant messaging!   Some interesting examples of extensions:  
  • Extended Stanza Addressing (XEP-0033): to send messages to several recipients at once, or to do carbon copies, as well as blind carbon copies (as the… yes, yes you see what I mean).
  • Multi-User Chat (XEP-0045): IRC-like group chat.
  • Ad-Hoc Commands (XEP-0050): a generic system to handle any kind of commands. Related to users' permissions, it is a great tool!
  • vcard-temp (Business cards, temporary version, XEP-0054): The legacy way to manage electronic business cards, which are a kind of public profile. A new extension will eventually replace it (XEP-0292).
  • Jabber Search (XEP-0055): used to search for jid, mostly used by directories.
  • Publish/Subscribe (XEP-0060): a big piece, used to publish all kinds of information, and its recovery based on permissions, with a notification system in real time.
  • XHTML-IM (XEP-0071): to publish with an XHTML subset, which enables formatting (to write bold text or include a picture for example).
  • Gateway Interaction (XEP-0100): to manage gateways, i.e. links to external networks.
  • Personal Eventing Protocol (XEP-0163): a kind of simplified Publish/Subscribe system.
  • Jingle (XEP-0166): Peer-to-peer session establishment with a wide range of possible applications, the most well-known being video conference.
  • Serverless Messaging (XEP-0174): unsurprisingly used to communicate without servers.
  • Message Archive Management (XEP-0313): to recover messages or other objects (works with Publish/Subscribe as well) following criteria such as a date. In particular, used to get a conversation history on a server, which is useful to access it from all your clients.
  Keep in mind that we’ve barely scratched the surface here.   Further details will be provided about some of these extensions in future articles. Please note that extensions can be referred by using short names, for instance “MAM” for “Message Archive Management”. Such names are usually mentioned at the end of the related XEPs, in the “Document Information” appendices.   This may lead to situations where clients and servers don’t support the same extensions subsets… How to make both parties agree on which one to use? This problem is solved through another extension (though so essential and widely implemented that it could nearly be considered as a main standard): “Service Discovery”, aka XEP-030, short name: “disco”.   The idea is simple: each client, server or component discloses who it is, what it can do, or associated items. A component is a service that plugs itself into a server, see below.   who it is An XMPP address (or jid) can be used by all kinds of elements, be it a server, a client, a gateway, or a bot for instance. The latter is a robot, i.e. a program that automates tasks, and is often used to behave like a client.   When a client or another element sees a jid, it may need to know what kind of element is associated to that jid, for instance to render it in a special way in the user interface. This is how clients and gateways are shown in distinct ways in your contacts list.   Disco’s identity provides this through a category (“client” or “server” for instance), a type (e.g. a client can be “bot”, “web”, “game”…), and a free name (eg “ejabberd”). A list of categories and their associated types can be found on   what it can do   XMPP’s extensibility makes it very feature-rich, therefore knowing what the software we are talking to is able to do is mandatory. Disco provides a list of such supported features, which is why you may see disabled buttons or icons (e.g. for video conference) while talking to someone. This means the client you are talking to indicates that it does not support this feature, or more accurately: it does not reveal that it supports it.   These features are linked to namespaces that are mentioned in the related XEPs. A list of XEPs based on namespaces is available here:   associated items   Beside its identity and available features, an XMPP entity can have associated elements. They can be servers indicating where to find chat rooms, or gateways to other networks.
  Let's try Let’s make this clear with an example. Salut à Toi’s command line interface “jp” can retrieve an entity’s disco using the command “jp info disco”, see below with     % jp info disco Features: iq jabber:iq:register jabber:iq:time jabber:iq:version msgoffline presence presence-invisible urn:xmpp:time vcard-temp -- Identities:   ejabberd (server/im) -- Extensions:   -- Items:   [] [] [j2j] [] [] []     As we can see, supports legacy vCards management (vCard-temp, XEP-0054) as well as ad-hoc commands (, XEP-0050), and the server (server/im) used for instant messaging is called “ejabberd”. We can also notice that various services are available, one of them being Let’s take a closer look:   % jp info disco Features: jabber:iq:browse jabber:iq:last jabber:iq:register jabber:iq:time jabber:iq:version urn:xmpp:ping vcard-temp -- Identities:   Public Chatrooms (conference/text) -- Items:   [...] JabberFR (13) [] [...]     We see that we are dealing with a chat rooms service (conference/text), which use the protocol “Multi-User Chat” ( It is at the moment the only one which is available for groups’ discussions (we will talk about it later). “Items” elements contain rooms’ list, with the name, the occupiers’ number with the corresponding JID. I shorten the list which was very long.   In’s information, you may have noticed the “extensions” section, it is the XEP-0128 which allow to extend disco for all kind of information. In the case of ejabberd here, it is to give contact addresses of server, but they aren’t indicated for   Below the disco’s window of Gajim:   The first time I used XMPP, with Psi in the early 2000s, I was a bit intimidated by the “service discovery” menu, which shows near directly all information we just saw. This kind of menu is often, at my opinion, showed too abruptly in XMPP clients: using disco directly (that is all except what is automated by the client) is already advanced use.     Furthermore, I will quickly mention the “software version” extension (XEP-0092) which allows, as indicated by its name, to know to which software we are talking to, and the operating system used. jp allows to show these information with “jp info version”, let’s try on   % jp info version Client name: ejabberd Client version: 2.1.13 Operating System: unix/linux 3.2.0   We now know the ejabberd version that is used. Useful when we know if a feature is supported or if a bug is fixed. And this work with every entity which implement the XEP, not only servers.   % jp info version Client name: MU-Conference Client version: 0.9-svn (Jan 27 2014) Operating System: Linux 3.2.0-4-amd64   That’s it. Knowing about the extensions allows to truly know what we can do with a client or a server. Next time I think I will explain groups’ discussions and see what changed in relation to IRC.

Marvin Wißfeld (GSoC 2015): Status Update - Keep calm, the end is near!

Planet Jabber - 5 August, 2015 - 00:00

Only two weeks left in this year’s Google Summer of Code. This means that we’re reaching the final state. Development should be mostly finished by now and documentation and testing are the main tasks left.

What happened since last report?
  • Support for DSA signatures.
  • Tests. A lot of them. Test coverage is at about 75% now.
  • API stabilitzation and documentation (JavaDocs).
  • Various fixes here and there.
What is to be done?

More testing and full documentation are important for the project completion, as well as the integration in smack and OpenKeychain (which are a task for the last week once everything else is done).

Interesting other features are ECDSA support and DLV (DNSSEC look-aside validation).

ProcessOne: XMPP Radar Newsletter #1

Planet Jabber - 4 August, 2015 - 15:03

As XMPP experts that love sharing lovely contents we found on the web relating to XMPP messaging protocol, we have decided to launch a monthly newsletter about “All things XMPP”, called XMPP Radar. The goal of the newsletter is to inform readers about what is happening in the XMPP world.

Despite all the saying, XMPP protocol have been there since more than 15 years and is here to stay. It covers so many useful features for realtime messaging and solves issues that no one else even tried to tackle, like federation. From mobile messaging to Internet of Things and gaming, we have no doubt that the protocol is here to stay.

Changes in web technologies, like the general availability of Websockets, and extension dealing with mobile networking are quickly changing the face of the protocol. XMPP is improving so much at the moment, that I think it is entering the second phase of its evolution. I truly think we are on the eve of an XMPP renaissance.

I know Facebook recently shut down its XMPP client gateway, but given the closed nature of the Facebook chat it has little significance for the XMPP protocol itself. It may be even the starting point on which XMPP can start building its own life outside of the shadow of tech giants.

Whether you are excited by the prospect or doubting that XMPP is a solution to your messaging needs, you should subscribe to XMPP Radar. We hope that month after month we will amaze you or prove you wrong, but no matter what is ahead, I am sure you will find the experience enlightening.

You can subscribe to XMPP Radar Newsletter here: XMPP Radar Subscription.

You can also follow XMPP Radar on Twitter.

Do not hesitate to contact us to suggest interesting links for the next newsletter, at end of August 2015.

Here is a few links we put together as a teaser:

XMPP Development Create a Chat App using Intel XDK and XMPP

Here is a nice tutorial on Web based ejabberd, showing how to create a chat app using Intel XDK and XMPP.

Protocol advancements XEP-0359: Unique and Stable Stanza IDs

Unique and stable IDs for stanzas, which are set by a XMPP service, are beneficial in various ways. They can be used together with Message Archive Management (XEP-0313) to uniquely identify a message within an archive. They are also useful in the context of Multi-User Chat (XEP-0045) conferences, in order to identify a message reflected by a MUC service back to the originating entity.

This is an important extension to build future XMPP enhancements.

Security Securing ejabberd against logjam attacks … and future threats

As a default, ejabberd is secured and resistant to logjam attacks. However, ejabberd 15.06 adds improvements that makes ejabberd even more resistant to future attacks. We hope you will find valuable information there, even from a general XMPP security standpoint.

XMPP Servers ejabberd 15.07 released

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

New WebSocket plugin for Openfire

Openfire now has support for the latest Websocket specification. This will help spread the use of Websocket as de facto standard for browser-based XMPP connection. This is good news for everyone, as Websocket make XMPP much more responsive in the web browsers.

XMPP Clients Swift 3.0 beta 2 XMPP client

This is an rich iteration on a client that we are looking forward to try in version 3.

XMPP Companies News Advanced Erlang Initiative and ejabberd Workshops

ProcessOne and Quviq have launched the Advanced Erlang Initiative, a new group of companies that use Erlang as a strategic technology to craft great products. As part of the initiative, ProcessOne will be organising Advanced Erlang Workshops on ejabberd. This will be a great opportunity to meet advanced XMPP hackers and learn about the future of the platform.

ProcessOne: ejabberd 15.07 installer supports Windows Server

Planet Jabber - 31 July, 2015 - 14:49

If you already installed ejabberd 15.07 Windows installer but have post installation issue, you’d better give the updated installer a try.

It is still ejabberd 15.07, so installer name does not change, but new package brings improved scripts.

With few minor fixes, this installer now supports:
– Windows Server 2008 and higher
– Program Files on another drive than C:
– Fix PATH issue on some edges cases

You can download it from ejabberd download page.

Ignite Realtime Blog: A new WebSocket plugin for Openfire

Planet Jabber - 30 July, 2015 - 16:31

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


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

Isode: Adding a Security Policy to M-Link

Planet Jabber - 30 July, 2015 - 15:50

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

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

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

Jérôme Poisson: Let's talk XMPP - episode 2 - core and extensions

Planet Jabber - 30 July, 2015 - 12:29

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

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

Andreas Straub (GSoC 2015): Week 09 - Polish

Planet Jabber - 30 July, 2015 - 03:35
Hey, welcome back to this slightly delayed -- sorry about that -- progress update!

We had some big changes last week, so this week's focus was on improving the code driving the trust ecosystem. The biggest sticking point has been responsiveness. Previously, the UI code would repeatedly hit the database when building and updating the fingerprint trust rows. Along with some poorly-timed UI refreshes, this lead to skippy toggle animations and annoying delays.
After going down the rabbit hole of caching for a while, it was obvious that the only sensible thing to cache are the trust values. These are queried for all over the place with high frequency, and they also seldom change. In the course of adding caching here, I also refactored the code base a bit. This caching still didn't fix some of the jumpy animations we were seeing though. It turned out that UI refreshes were being triggered while the switch animation was in progress, causing the slider to skip back and forth. This happened due to the fact that I initially wrote the UI code to simply visualize the state of the application, and on state changes, trigger refresh. Now the UI explicitly sets just the necessary changes, without refreshing entirely, which solved the problem.
Another addition this week is a new logic for determining whether a given message should be considered part of an encrypted session. We were faced with the problem of making unencrypted (or differently encrypted) messages received while in an encrypted session more noticeable, as the missing lock icon is easily overlooked. So in order to avoid marking ALL plaintext messages whenever encryption is enabled, I decided to use own sent messages as session boundaries. In practice, this means that for any given message, we need to find the most recently sent (by our own device) messages before and after it (using next message encryption choice if no messages have been sent after it). If their encryptions match and neither is unencrypted, the current message is deemed as part of an encrypted session with the type of the previos/next message's encryption. If the current message's encryption mismatches that type, it is highlighted.

And lastly, when pressing on an Avatar in a Conversation, the fingerprint that the corresponding message was encrypted with is now highlighted in the ContactDetailsActivity and EditAccountActivity so it's easier to selectively trust/distrust specific keys for the user:

We're just about ready to release the beta, so stay tuned for that, and until next week!

Fanout Blog: Runscope JWT authentication

Planet Jabber - 29 July, 2015 - 22:24

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

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


Daniel Baczynski (GSoC 2015): Roster model proxy

Planet Jabber - 29 July, 2015 - 15:13
It's time for roster. We want to show multiple accounts in one window. Hence we decided to make every active account being a top level element of roster and thereby downgrade group elements.
I have implemented proxy model that makes use of current RosterModel. It contains collection of <RosterModel, Account> pairs. For now, we can show one account contacts but code is more prepared to jump into multiple view.

Tarun Gupta (GSoC 2015): Week - 10

Planet Jabber - 29 July, 2015 - 11:30
Hello everyone,

This week I completed some incomplete bits of SASL ( Simple Authentication and Security Layer ) , TLS ( Transport Layer Security ) , Session, Presence and Client.
XMPP includes a method for authenticating a stream by means of an XMPP-specific profile of the SASL protocol. SASL specification defines the core authentication method for XMPP: an application profile of the Simple Authentication and Security Layer (SASL) protocol that enables a client to authenticate with a server or for one server to authenticate with a peer server. This profile may be used for both client-to-server and server-to-server connections. For client connections, the service name used is "jabber-client". For server connections, the service name used is "jabber-server". The following XML namespaces are used in the context of the Simple Authentication and Security Layer protocol: urn:ietf:params:xml:ns:xmpp-sasl. I added DIGESTMD5ClientAuthenticator, DIGESTMD5Properties and tests for these as well as the existing authenticators. More information available here.
TLS specification defines the core channel encryption method for XMPP: an application profile of Transport Layer Security (TLS) that enables a client to encrypt its XML streams with a server or for one server to encrypt its XML streams with a peer server. By its nature as a TLS profile, XMPP channel encryption also includes the ability to compress XML streams. The following XML namespaces are used in the context of the Transport Layer Security protocol : urn:ietf:params:xml:ns:xmpp-tls. I added TLSError, TLSOptions, SimpleCertificate and also made sure that all other features are in line with Swiften. Session only needed updates for the signal definition and some other minor changes.
In Presence, I just added three tests i.e. DirectedPresenceSenderTest, PayloadAddingPresenceSenderTest and PresenceOracleTest. In Client, I updated existing files and also added Client Block List Manager, Client XML Tracer, XML Beautifier along with their tests.
Next Up, I'll do Network which needs a lot to port including proxies and then Jingle and FileTransfer.

Jérôme Poisson: Let's talk XMPP - episode 1 - the basics

Planet Jabber - 29 July, 2015 - 10:14

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

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

ProcessOne: ejabberd 15.07 released: Summer Progress

Planet Jabber - 29 July, 2015 - 09:40

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

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

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

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

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

Changes Message Archive Management (XEP-0313)
  • Add “complete” attribute to MAM final response
  • Fix mod_mam compatibility with RSM
  • Changed mam iq get to set as specified by XEP-0313 v0.3
Modules management
  • Ensure config snippet is loaded at module installation
  • Allow contribution to include .yml or .yaml config file
  • Allow include of simple dependencies
Multi User Chat
  • New API hook: muc_filter_packet
  • Send notifications on MUC configuration changes
  • Omit warning message regarding non-anonymous room
  • During halt only shutdown MUC rooms on local node
  • Allow migration of old pubsub items with old xmlelement structure in body
  • Trigger PEP notifications on CAPS updates
  • Check for node subscription of bare JID
  • Flat is now the default plugin
Stream Management (XEP-0198)
  • Increase timeout during resumption
  • Increase default “max_ack_queue” value
ejabberd Client connection
  • API change: user_send_packet is now a run_fold hook and pass the c2s State as a parameter. It was already the case in ejabberd 15.06, but it was not mentioned in the changelog, by mistake. So, now, you know :)
  • Do not rely on behaviour info when doing config validation, so that it can work with ejabberd binary installers
  • When passwords are scrammed, report check_password_hash cannot work
  • Fix problem with merging values from multiple config files
  • If local guide.html file not found, redirect to the online guide
  • Support RTL page direction in WebAdmin for Hebrew
  • add AC_CONFIG_MACRO_DIR and static AC_INIT
  • Don’t crash web admin when displaying info about websocket using users
  • Both RPM and DEB now are using the improved post-install script which creates ejabberd user when installing as root. This let ejabberd running as user without any manual setup.

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


As usual, the release is tagged in the Git source code repository on Github.

The source package and binary installers are available at ProcessOne.

If you suspect that you’ve found a bug, please search or fill a bug report on Github.

Adhish Singla (GSoC 2015): Week 9

Planet Jabber - 29 July, 2015 - 08:13
Objective VCard, CSS Changes and Read Implementation for Mobile Application Abstract

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

  • We use the NickName and Image from the VCard for the Contacts View.
  • Bug Fix for Login Form Removal after the connection has been established.
  • CSS Changes for the Views.
  • Add Dynamic Event Listener for Tap on Contacts to send a Read Request.
  • Display Read Values as a Dropdown to the Device in the Contacts View.
Problems Faced
  • (Solved) Dynamic Event Handler was not working when using jQuery on(‘tap’) function. The problem was with the older version of jQuery, replacing it with the latest version solved the problem.
Final Output

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

ProcessOne: Building a simple chat client using XMPPFrameWork and Cocoapods

Planet Jabber - 28 July, 2015 - 13:15

When it comes to building an XMPP client on iOS, one will immediately struggle with the lack of documentation and a complex setup involving tweaking files and laborious try’n fail attempts.

Suffer no more !

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

See more and download example here

Distribuir contenido