I've just published Smack 4.2.0-alpha2 on Maven Central. Everyone who wants to look into which direction Smack is heading, and current Smack users eager to be prepared for the upcoming API changes are invited to test this version out. We are awaiting your feedback in the Smack Users forum.
More information about Smack 4.2 can be found in the Smack 4.2 Readme and Upgrade Guide.
The Ignite Realtime community is proud to announce the availability of Smack 4.1.4. This release includes some important fixes. Most notably MultiUserChat's UserStatusListener would not always get triggered in previous releases. Also the JOSN/GCM provider did not correctly parse JSON/GCM extensions. Smack 4.1.4 includes fixes for those and addresses a few other bugs. Since it is a patch level release, Smack 4.1.4 can be used as drop-in replacement for any previous version of Smack 4.1. Users are encouraged to update existing projects depending on Smack.
This is also a friendly reminder that Smack 3 has critical security vulnerabilities. Please check if you are affected by those if you are still using Smack 3 and update as soon as possible.
We are pleased to launch a new initiative to help developer get a better understanding of XMPP called “ProcessOne XMPP Academy”. The goal is to help developers get the big picture and get XMPP architecture and design tips from 15-years-experience XMPP experts.
We are targeting all XMPP developers interested in asking a question on specific XMPP topics. Selected questions will be answered during a live private session for our ejabberd SaaS customers. The recording will be available to anyone to see later on-demand on ProcessOne video channel.
We are planning to have a session every month.
The first session will takes place on September 28th at 6pm CET. If you are an ejabberd SaaS customer, you can save the date, as you will soon receive a free registration link to attend live.
For other XMPP developers, you are very welcome to send us your questions before September 25th through our contact form. We will select the most interesting topics / questions to reply to.
We are waiting for your input !
ejabberd is an ubiquitous Erlang application that is widely available in Linux distributions. For that reason, it needs to rely on the de facto Linux build tools like autotools to make integration very easy for Linux and FreeBSD packagers.
However, it does not mean that ejabberd does not play well with the standard Erlang release approach.
ejabberd is fully OTP and release compliant. OTP is the standard “pattern” to build Erlang applications and ejabberd rely on them. Moreoever, it fully supports the Erlang release mechanism. A release in Erlang is a way to prepare a standalone package of a system composed of several applications. A release includes version of the Erlang VM (Beam) and all the needed dependencies, for easy deployment. A release is also a way to perform upgrade of a live running system (and downgrade if you would like to rollback a deployed change).
In this tutorial, I will show how to build a standalone Erlang release for ejabberd and how to deploy and upgrade new code in a new release without stopping the service.
To demonstrate the feature, I will rely on Elixir toolchain to build an ejabberd release, and more specifically mix and exrm tools.
Here is the full video tutorial, but you can read on for complete written, step-by-step explanation:Prerequisites
As a prerequisite, you need to have Erlang R18+ and Elixir 1.0.5+ available on your machine, as well as standard GNU build tools. You can read more about ejabberd dependencies on ejabberd documentation site: [http://docs.ejabberd.im/admin/guide/installation/#installing-ejabberd-from-source-code](Installing ejabberd from source code).Build ejabberd with Elixir mix
First, you need to checkout ejabberd from source, from ProcessOne Github:(mkdir ejabberd-demo1; mkdir ejabberd-demo1/deploy; cd ejabberd-demo1; git clone https://github.com/processone/ejabberd.git)
Second step is to download ejabberd dependencies and to build the software. It can be done automatically with mix:cd ejabberd-demo1/ejabberd mix do deps.get, compile
Once this is done, we can prepare an ejabberd OTP release with the following command:MIX_ENV=prod mix release
You can now unpack the release you want to deploy using the package release file. It is not recommended to start ejabberd from the release directory directly as you can get issue later. I recommand you copy / extract the file rel/ejabberd/releases/15.07.0/ejabberd.tar.gz to your ejabberd deploy directory:(mkdir -p deploy/ejabberd; tar zxvf rel/ejabberd/releases/15.07.0/ejabberd.tar.gz -C deploy/ejabberd)
Note that I am deploying inside the same ejabberd directory to avoid cluttering the local drive, but on a real server I expect you will extract the release in a place like for example /app/ejabberd/ or /home/ejabberd/deploy or anywhere else that suit your taste.
Now, you can start ejabberd from the release directory. But first, you need to add an ejabberd config file. I have prepared a default ejabberd configuration file that you can download from Gist:(mkdir deploy/ejabberd/config; cd deploy/ejabberd/config; wget https://gist.githubusercontent.com/mremond/383666d563025e86adfe/raw/723dfa50c955c112777f3361b4f2067b76a55d7b/ejabberd.yml)
From that point, you should be able to start ejabberd successfully. You can start ejabberd and keep an Elixir console opened with:deploy/ejabberd/bin/ejabberd console
From that console, you can now create the user user1@localhost with password ‘mypass’::ejabberd_auth.try_register("user1", "localhost", "mypass")
If you open an XMPP client, you should now be able to connect with those credentials.
ejabberd can be stopped from the console with::init.stop()
You can run ejabberd in background with:deploy/ejabberd/bin/ejabberd start
At this point, you should be able to reconnect from your client.
If you want to deploy this software on your server, you can copy the compressed release package to your server, uncompress it there and run bin/ejabberd start from the release directory. File should be named: releases/15.07.0/ejabberd.tar.gz
Please note that you need to use the same architecture to build the release than the one you are deploying on. It means if you are deploying on Linux 64-bits, you need to build your service on the same architecture (so, not directly on your OS X laptop, you can use a VM). If you do not do that, the embedded Erlang and ejabberd .so binaries will not work.New release / hot code upgrade
Let’s demonstrate how to make a very basic change in the code, prepare a new release and do a live code update on a running server.
Open the following page in your browser: [http://localhost:5280/http-bind]
This is the info page return by the mod\_http\_bind module. Let’s say we want to replace the string in the code containing “To use HTTP-Bind” with “To use XMPP over BOSH” which sounds more correct.
Open the file src/mod_http_bind.erl and search for “HTTP-Bind” and replace that string with “XMPP over BOSH”.
As your change is ready to deploy, you are ready to increase project version in mix.exs. Increment the version number from 15.07.0 to 15.07.1.
You can now rebuild the project. Compile it to check all is fine:mix compile
You can prepare a release with the upgrade process:MIX_ENV=prod mix release
You can now upgrade the live system. To do that, you need to perform the upgrade not from your build structure, but from the actual target deployment directory. exrm deletes file during the upgrade process that may be used to produce subsequent releases.
So, to upgrade the live production system, you need to do:
Create new dir for release in your original deploy:mkdir -p deploy/ejabberd/releases/15.07.1
Copy the new release file:tar zxvf rel/ejabberd/releases/15.07.1/ejabberd.tar.gz -C deploy/ejabberd
Assuming the server is already running and you do not want to interrupt the existing users, you can launch live code upgrade:deploy/ejabberd/bin/ejabberd upgrade "15.07.1"
ejabberd should upgrade just fine. If you reload the page [http://localhost:5280/http-bind] you should now clearly see your updated text. Note, that only the needed module were reload and no client have been disconnected. The upgrade has been fully live.
However, be careful. Not all upgrade paths are that simple. Depending on how deep your change goes into the internal of ejabberd, preparing the upgrade process maybe become a project in itself, requiring skillfull work.Conclusion
As you have seen, ejabberd is:
This is primarily a bug fix release, which addresses some issues which were recently discovered and improves things here and there. It is compatible to version 0.6.0.
For detailed release notes, you can find the changelog here.
This is an updated version of this post
Oyez Oyez Oyez Swift lovers !
The new pod for XMPPFramework is finally ready !
You are just one pod install away of your next chat application client, in Swift !
The XMPPFramework Podspec was re-written to be fully compatible with Swift, check the full tutorial and download example here.
We are pleased to announce the stable releases of MatriX 2. More about the changes in the v2 version can be found in this blog post
Instead of installers we will use NuGet only for all future MatriX releases. You can find all MatriX NuGet packages here
Sample codes can be found in the Git repository here
All our customers with active support & maintenance can of course upgrade to MatriX 2 for free. Updating existing code bases to MatriX 2 should only take a few minutes. We highly suggest the update because there are many improvements in the MatriX 2 core, and also many new features on our roadmap.
As you may remember, last month we launched a newsletter about all things XMPP, called XMPP Radar. The goal of this newsletter is to inform readers about what has happened in the XMPP world each month.
We are happy to present you the second issue of XMPP Radar, with interesting links from August. You can subscribe to the newsletter, and do not hesitate to tweet XMPP Radar to suggest interesting links for the next issue, at end of September 2015.
Here are the links we found interesting in August:Push Development BBC News Launched a New Major Android and iOS App Release, Powered by Boxcar Push
BBC News app is one of the most popular in the world, with over 40m downloads since it launched. The international version has seen tremendous growth over the past 18 months, with page views up 44% to nearly half a billion per month. At ProcessOne, we are proud to be the project’s Push Notifications delivery partner.XMPP Development Converse.js 0.9.5 Released
Dave Cridland prepared an evolving blog post, describing and debunking the most common myths about XMPP. We concur!Monal OSX Beta 6
Monal is a popular XMPP client for iOS. Now, the developer is working on an OS X version. Among interesting thing, the desktop client will support OS X Continuity.Elixir in Production: Mickaël Rémond Interviewed by Plataformatec
A few months ago Plataformatec had the opportunity to interview Mickaël Rémond about his experience using Elixir in production. Mickaël is the CEO of ProcessOne.Internet of Things Know Your Real-time Protocols for IoT Apps
The XMPP, CoAP, and MQTT protocols have distinct pros and cons. Here’s a quick rundown of the trade-offs.Prototyping Tools for IoT
This project is a part of the Google Summer of Code 2015. Its goal is to implement IoT prtocols for XMPP chat client Converse.js, cross-platform sensoring and controlling data communication software, and a history logger for sensors.Long-form Analysis Why Messaging has the Momentum in Business Collaboration
An interesting piece by David F. Carr analysing the shift from email to instant messaging and stream communication in the enterprise environment. Prime example: Slack.It’s Operating Systems Vs. Messaging Apps In The Battle For Tech’s Next Frontier
As mobile devices continue to explore and colonize the technology landscape, their conquests are leading us to a new era, beyond search and apps.
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: http://www.goffi.org/tag/parlons_xmppThe 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).
In the software development field, and much in the libre software, group’s discussions are really common, mostly with IRC (Internet Relay chat).
This venerable protocol do what we ask it and XMPP is strongly inspired by it. Let’s see that closely.
Group’s discussions used nowadays are called MUC (Multi-User Chat) and are defined by XEP-0045. This one standardizes and extends the first solution called Groupchat. As all that comes from IRC, I’ll explain as they come the major differences between them.
It is possible to acces a chat room located on any server from any server (again, while it is not explicitly prohibited). Chat rooms do, as the users, have a jid, which has the pattern chat_room_name@service. For example, that of Salut à Toi is firstname.lastname@example.org: “sat” is the chat room’s name, “chat.jabberfr.org” the service.
The resource is used for occupants of the chat room: email@example.com/goffi corresponds to the occupant “goffi” in the chat room firstname.lastname@example.org. Ah little detail that I forgot in previous articles: everything is unicode in XMPP, including jid. So you can use arabic or russian nickname. But beware: some unicode characters are strongly similar, therefore it is possible to get 2 words graphically similar mixed up, we name it “homoglyphs”. For example “ｇοｆｆⅰ” looks like “goffi” but it uses different characters. This issue is mentioned in a unicode technical report: http://www.unicode.org/reports/tr36/. Also, do not rely exclusively on a nickname to identify someone (espcially that it is possible that it can be reused by someone else between two sessions).
The nickname is linked to the chat room and not to the service. You can have a nick “toto” in a chat room and “titi” in another one, and someone else can have “titi” on a third chat room. This is a big difference with IRC where we have only one nickname on a server that will be used in every chat room (channel on IRC).
To go in or go out a chat room, or to change nickname, we send an available (or not) presence directly to email@example.com/desired_nick, but this is normaly managed by your client.
It is also possible to write directly to all chat room’s occupants (under the hood this is a “groupchat” message that is sent to the chat room’s bare jid), or to have a private chat with a member (we write to the full jid of the recipient).
A chat room can be public or hidden (it will not appear in the chat room list), not anonymous or semi-anonymous (in the first case everyone can see the occupant’s real jid, in the second case only moderators and administrators can), persistent or temporary, open or accessible only by white list or can be protected by password, moderated or not.
All those parameters are normally defined at the creation of the chat room, or they can be modified after with the suitable option of your client (on Gajim: right click on chat room tab => Manage Room => Configure Room). According to the service you use, you can configure more or less things, for example limit the occupant’s maximal number.
A feature often implemented is the history or “back log”: when you get in a chat room, the service sends you the last X messages, allowing you to understand the context of the current conversation.
Also, if a public archive of the chat room is kept (we say “logged” chat room), the service must warn you (it’s mandatory in the XEP), this is another good point compared to IRC. For sure, one has to remember that anyone in the room can keep a log and could publish it without your consent.
So far, so good, but a great strength of IRC is its simplicity: no need to create an account, you just have to pick a nick (unique), with a server, and that’s it! So, you won’t be disapointed, XMPP has exactly the same thing with connections called “anonymous”. No anonymity in terms of Tor here, but rather the possibility to get a temporary account, with a jid more or less random, for the connection time. This comes built-in but it must often be explicitly enabled in the server configuration, and most of the time, anonymous connections are limited to the local network, no communication with other servers (to avoid spam).
If you want to chat as with IRC in a simple and intuitive way, and if you like the console, I would strongly recommend Poezio which is an excellent XMPP client that is easy to use: initially, without changing the configuration, you will be anonymously connected to the MUC service of Poezio. It is inspired by Irssi/Weechat and use the same commands (and more generally those of IRC). Below the welcome message, without changing the configuration, we see the anonymous jid assigned for the session time.
Well this episode is long enough, but I am not finished with MUC, therefore we will talk about it next time, probably with transports.
After about 3 months yet another GSOC has come to an end. This is the part of the program that I am sure almost every accepted student would feel sad about. End of those weekly meetings, end of those long chats with your mentors, and a lot more fun.
So my project was about adding support for Link Local (read Serverless) messaging (an XMPP Extension – 174) to Smack’s API. Though I didn’t complete everything that was expected as a part of my proposal but the basic implementation of this API is ready and working. Using the current API you can establish an XMPPLLConnection that is capable of announcing its presence over a local network and able to receive incoming connections and then communicate over a TCP connection. This was verified with the help of Gajim (an XMPP client for linux.) I made a video that demonstrates this process and shows messages being received over a Link Local Connection with the help of my API.
Even though officially the program has come to an end, I will actively contributing to Smack in future and will extend the current functionality to what I had written in my proposal, along side my Mentor Florian Schmaus.
Finally, the Google Summer of Code 2015 concluded. Over 1,000 students - including myself - used the summer to develop amazing open-source software, making our daily life better.DNSSEC for minidns
I successfully finished my project, to include support DNSSEC in minidns, a popular DNS client library for Java with support for Android. Just to summarize my previous posts, here is a list of things developed during the summer:
To ensure correctness of all features, I also added a lot of unit tests to minidns. Due to this I was able to find some relevant bugs in minidns. Unfortunately, some of the optionally desired features did not make it into usable state until today. I will further work on adding the following after this years GSoC:
I’d like to say a warm thank you, to everyone involved with the organisation of the GSoC at XSF (which acted as my host organization) or supported me at my project. This includes, but is not limited to:
This tutorial is regarding using Converse.Js to read values and write values to devices, and also retrieve history of fields.Getting Started
Follow the instructions given here
Use this converse.js file instead of the one given in above link.Start with logging into an XMPP account
Log into your xmpp account.
Contacts will be displayed with an Icon to their left.
These icons determine the type of contacts (Sensor Devices, Control Devices or Contacts)
Open a Chatbox with a Device.
We have used Command Feature to implement the functions.
It works for Sensor as well as Control Devices.
The command for reading a value is ‘/read’.
It will display the fields stored in the device along with their present values. Like this :
It works for Control Devices.
First perform a Read to know the FieldNames.
The command for writing a Value to a FieldName is ‘/write FieldName Value’.
Now you can again perform a Read to check if the Value for that FieldName is changed. Like this :
History Retrieval for a Field
It works for Sensor as well as Control Devices for Fields that store their History.
The command to retrieve Hisotry of a FieldName is ‘/history day/week/month/year FieldName’.
Output for the same looks like this:
Hope you like playing around with it :)
This tutorial is regarding using IEA Cordova Mobile Application, which can be used to read values and write values to devices, and also retrieve history of fields.Getting Started
Hope you like playing around with it :)