Planet Jabber

Distribuir contenido
Planet Jabber -
Actualizado: hace 2 horas 41 mins

ProcessOne: Building a simple chat client using XMPPFrameWork and Cocoapods

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

ProcessOne: Advanced Erlang Initiative

23 July, 2015 - 16:29

We are proud to be launching the Advanced Erlang Initiative, a new group of companies that use Erlang as a strategic technology to craft great products. Erlang ecosystems rely on those publishers that are producing person/years worth of code to build excellent products.

The Advanced Erlang Initiative recognises that those products in turn contribute to the fame of the Erlang platform. They help pushing the limits and contribute to the fame of our beloved programming language. Most of all, the Advanced Erlang Initiative acknowledges peoples energy and effort put in those great products to the good of every Erlang developer. We have created a forum for developers working with and contributing to those tools to meet and discuss their work.

The Advanced Erlang Initiative welcomes all developers that share our passion for Erlang, Elixir, the beam environment and our vision of technical excellence.

Our initiative is primarily centered around inexpensive highly technical workshops given around the world and educational videos on our Erlang products.

The first two members are:

  • ProcessOne, maker of the world class messaging server ejabberd, since 2002.
  • Quviq, maker of the Quickcheck property-based testing tool, innovation in quality assurance.

We are happy to meet you on the newly launched website Advanced-Erlang

We are already taking registration for the first two workshops:

More to come soon !

Enjoy and see you there after the summer break !

Thomas Arts, Quviq
Mickaël Rémond, ProcessOne

Swift Blog: Swift 3.0-beta2 Released

23 July, 2015 - 00:00

We have just released the second Swift 3.0 beta. Apart from several bugfixes, highlights include an emoticons menu in chat dialogs, bookmark for rooms can now be edited directly from the ‘Recent Chats’ list and rooms entered while offline will now get entered on reconnect.

Have a look at the changelog for a list of all the new features since 2.0.

We encourage everyone to get the new build and try it out, and tell us about any bugs they should come across.

Tarun Gupta (GSoC 2015): Week - 9

22 July, 2015 - 14:44
This week I have completed the remaining bit of serializers, completed StreamStack, Components, AdHoc, Compress and EventLoop. I'll give a brief description about each and what I changed.
In serializers, I just updated all the Non-payload serializers to return a SafeByteArray instead of a string.

There are two types of server-side components. Internal and External Components.External Components use internal API of a server while the external components communicate to a server over a wire protocol and therefore not tied to any particular implementation. An external component is called trusted because it authenticates with a server using authentication credentials that include a shared secret. This secret is commonly specified in the configuration files used by the server and component, but could be provided at runtime on the command line or extracted from a database. An external component is commonly trusted to do things that clients cannot, such as write 'from' addresses for the server's domain(s).External components do not use the obsolete NON-SASL Authentication nor they use SASL Authentication (yet), but use a special <handshake/> element whose XML character data specifies credentials for the component's session with the server. A simple getHandShake function takes a streamID and secret, concatenates them and replace some characters (like '&' with "&amp;", etc) and then generate a SHA1Hash and return the hexified value.
For example, ComponentHandshakeGenerator.getHandshake("myid", "mysecret") generates the hash "4011cd31f9b99ac089a0cd7ce297da7323fa2525". 
More information can be found here. This patch is under review now and I have ported all of component along with tests. However Component Connector test can still not be implemented because it needs certain bits of Network which aren't available now.
I have made a very minor change to AdHoc, allowing the connection to disconnect. Information about AdHoc can be read here.
We are using a third party library jzlib to accomplish the compresssion of XML Streams, in which ZLIB compression method is used. Here is the XEP for the same.
The EventLoop is a seemingly infinite loop that waits for XMPP events to occur (incoming messages, notification about connection errors, etc.). Whenever an event occurs, the eventloop calls the event handler method that is associated with the event. I just added simple eventloop tests and checked whether functionality is in parity with Swiften.Next up, I am covering SASL (Simple Authentication and Security Layer). Thanks.

Andreas Straub (GSoC 2015): Week 08 - Trust

22 July, 2015 - 11:11
Hey, welcome back!

A lot of exciting stuff has happened. The focus of work this week was the trust system. It was extended to encompass two additional states: INACTIVE and COMPROMISED. Along with some UI improvements, this got us to a stage where the protocol is starting to become usable for day to day communications.
In designig the logic driving these changes, we were faced with some tough problems. Recall that, so far, we have had three trust states: UNDECIDED, UNTRUSTED, and TRUSTED. UNDECIDED served as a default initialization for keys on which the user hasn't made a trust decision yet. The idea was that, if there are new keys available when the user sends a message, we'd drop them into a TrustKeysActivity. Here, the user would have to decide which of the UNDECIDED keys they want to trust before the message is sent. 
This activity was implemented this week, and it is triggered under two condition. Either if, as previously described, there are UNDECIDED keys for the current conversation (meaning for either the contact or the own account), or if there are no TRUSTED keys for the contact (as in that case, the message couldn't actually be sent). In the former case, only UNDECIDED keys are displayed. In the latter case, UNTRUSTED keys are displayed as well, as there may not necessarily be any UNDECIDED keys. The activity sets all pending keys to UNTRUSTED by default and lets the user pick which ones they want to trust. This way, no key can remain UNDECIDED, preventing the activity from reappearing every time a user tries to send a message. The activity is in a "locked" state until it is done fetching all keys in the background, and until, after commiting the selected changes, there will be at least one TRUSTED key. The user can of course revise these decisions in the ContactDetailsActivity (as before) and EditAccountAcitivity  (new this week). The TrustKeysActivity reuses the key display UI introduced for the ContactDetailsActivity and EditAccountActivity, which also got an overhaul this week. Take a look:

You'll notice we replaced the buttons with a slider and got rid of the trust state text, as this was now redundant. TRUSTED and UNTRUSTED keys obviously have an enabled/disabled slider respectively. UNDECIDED keys have a greyed-out slider that gets enabled (and initialized to UNTRUSTED) when the user clicks on it. 
You may also have noticed an entirely greyed-out key in the above screenshots. This represents an INACTIVE key. The INACTIVE state was introduced to deal with the problem of stale keys. Stale keys not only clog up the UI unnecessarily, they also create overhead. Because the device doesn't know that a key may not be needed anymore, it will still have to encrypt sent messages for that device. This creates computational as well as bandwidth overhead.
Let's say one of your contacts buys a new phone. They wipe their old one, and sell it. On their new phone, a new IdentityKey will be generated, that their contacts will have to trust. While your contact can use the "Clear devices" function to remove the announcement of that stale key from the PEP devicelist, this will only prevent new sessions from being established with that stale key. Contacts that already have a session with that device will still keep them around. Those contacts will notice that the device that key belongs to was removed from the announcement, but they can't use that as a trigger to delete the key and session from their database. The reason for this is that the "Clear devices" function has no way of knowing which devices it should actually clear, so it just removes all devices except for the current one. This is not a problem, because the other active devices will notice they were removed, and they will just immediately readd themselves. But at that point, we would have already deleted the session and key, if we simply used the event that a device was removed from PEP as a trigger to delete it. 
This is where the INACTIVE state comes in. When a device that was initially TRUSTED is removed from PEP, we now set it to INACTIVE rather than deleting it outright. While a device is considered INACTIVE, no messages are encrypted for it. INACTIVE devices are automatically reactivated and set back to TRUSTED if they either reappear in PEP or we receive a message from them. As a result, the "Clear devices" function works as expected, with active devices remaining in their TRUSTED state, while unused devices are set to INACTIVE automatically and not used for sending anymore. A side effect of this design is that after using "Clear devices", the user has to ensure all their devices come online so they can reannounce themselves. Until they do so, messages will not be encrypted for them, so the user might lose some of the history on some of their devices. We warn about this in a popup. 
Note that there is still no way for a device to ever get deleted. So while old devices will now end up INACTIVE, they will still clog up out UI. The same goes for devices that are explicitly not to be trusted because they don't match our contact's fingerprint(s). This problem is resolved by the second new state that was added, COMPROMISED. By long-pressing on a key, the user can purge them. The effects of this are twofold: the key is not displayed in the UI or used for message processing anymore but it is kept around in the database. The COMPROMISED keys effectively constitute a blacklist of keys that can never be used again. Once a key is set COMPROMISED by the user, there's no way back, as they are hidden from the user forever (or at least until they remove and readd their account to the app). This protects the user from accidentally re-trusting a key they shouldn't. This functionality is also intended to be used for the aforementioned stale keys. If one of your contact's keys has been INACTIVE for a while, you can now simply remove it. It not only makes sense to treat both of these cases -- keys that are not needed anymore, and keys that were never trusted at all -- identically to get a more streamlined UX, but they are in fact very similar semantically, as an old key no longer in use should be considered COMPROMISED anyway.
I have to give huge thanks to my mentor Daniel here for taking the time to sit down with me and talk this thing through. While this design may seem simple and intuitive in hindsight, we had to play through many different options in order to arrive at this point where these different choices mate to make a coherent whole. To my knowledge, no one has built anything quite like what we're working on before, so we're kind of flying by the seat of our pants here. It was our big goal to come up with a design that unburdens the user as much as possible, in order to yield a streamlined experience.  I think we've built something that is very simple to use and understand by automating wherver possible, yet letting the user make the important choices in order to ensure sufficient control over this crucial component. Daniel was also really helpful in debugging the UI code for this overhauled trust system. He took a lot of time for me and helped me find some really nasty bugs. :)
In other news, this week also marked an overhaul of the payload message encryption. We switched from our prototype implementation (plain AES-CTR, no HMAC) to AES-GCM, which provides encryption and integrity protection in one neat package. Less to implement means less sources for bugs. I also fixed some bugs relating to file transfers while in axolotl sessions amongst others, and I improved the "Clear devices" UI. And finally, my code has been merged into the development branch of Conversations! While it's not done yet, this will make it easier for interested users to help test it.
As you can tell, I've been pretty busy, and we've made a lot of progress recently. I will probably spend the next week on code quality improvements and bug fixes. Right now the code accesses the database way more than it should, which leads to performance problems and (in some cases) unresponsive UI. 
If you have any comments or suggestions, please let me know. Until next week!

Adhish Singla (GSoC 2015): Week 8

22 July, 2015 - 08:13
Objective Login and Contact Retrieval using Strophe for Mobile Application Abstract

Implementation of Mobile Application (Login, Roster and Presence).

  • Related Info :
  • Tested Strophe Login using a hardcoded Script to connect to the BOSH Server with fixed Login Details.
  • Made a View for Login to enter Username and Password.
  • Problem : Login Form does not remove after Login is Successful.
  • Contacts Retrieved are displayed as Jid under the login Form.
Problems Faced and Bugs
  • Bug : Login Form not removing.
  • Presence only received for one Device (Solved) : Occupied with this problem for quiet some time. Realized later that Handler needs to return true, otherwise they work only once.
Final Output

Road Ahead
  • Retrieve VCard, Bug Fixes, Implement Read, CSS Changes.

Marvin Wißfeld (GSoC 2015): Status Update - Finished yet?

22 July, 2015 - 00:00

It was some work, but finally we reached a state, where DNSSEC in minidns is fully usable*.

What happened?

Summarizing everything done as part of the Google Summer of Code so far gives us a pretty long list of features:

  • A full recursive resolver (not only stub resolving)
  • TCP and EDNS(0) usage
  • Support of a total of 9 new record types: DS, RRSIG, DNSKEY, OPT, NSEC, NSEC3(PARAM), TLSANEW, OPENPGPKEYNEW
  • Verification of DNSKEY entries using DS
  • Verification of RSA signatures using RRSIG
  • Verification of negative responses using NSEC and NSEC3NEW
  • RFC compatible output format (like dig)
What is to be done?

Testing. Yes that’s a main thing to do. As announced in this blogs first post, we want our DNSSEC implementation to be fully tested. Until now our test coverage is still less than 60%.

Another feature that is missing in the current implementation of minidns-dnssec, is verification signatures made using DSA or ECDSA keys. Currently this is done by a small number of DNSSEC systems and the feature is marked as optional, none the less it is an interesting feature.

Google Summer of Code is still a month to go, so I am certain these problems can be tackled in time and we can see DNSSEC used in smack and OpenKeychain until then.

Ishan Khanna (GSoC 2015): GSOC Week – 08

20 July, 2015 - 11:24

With great help from Florian, my mentor and some research I was able to get the XMPPLLConnection and XMPPLLConfiguration work together.  So a user can now create an XMPPLLConfiguration that takes some basic information about the presence and it can passed to the XMPPLLConnection’s constructor to establish a new link-local connection.

User can then call XMPPLLConnection#announcePresence() to broadcast the presence info on the network so that other clients listening to it can get it.

Here is a small demo of what is currently happening. Youtube – Announce Presence Test

What am I planning next?
Add sockets to the XMPPLLConnection and start listening for connections on them. As I am new to socket programming, I have been given a small task by my mentor to Learn basics of Socket Programming that I have completed and now waiting for his review. I am also looking into the java.nio package tutorials online.

Ishan Khanna (GSoC 2015): GSOC Week – 07

17 July, 2015 - 11:20

Got JmDNS Working in the code and tested it with Gajim on a Ubuntu VM. Written and tested POC implementations for announcing presence, discovering presences and concealing presences on the link local network.

Currently working on the implementation of the XMPPLLConnection and XMPPLLConnectionConfiguration to enable developers to use this API in Smack to initiate Link-Local connections.

ProcessOne: Securing ejabberd against logjam attacks … and future threats

16 July, 2015 - 09:56

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.

What is logjam security issue ?

In may 2015, a team of researchers (Henninger et. al) published a paper explain two possible weakness in client / server communication encryption (“Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice”) .

The paper covers two issues the team uncovered:

  • discrete logs attack on a 512-bit Diffie-Hellman (DH) group
  • protocol downgrade attack against TLS connections
TLS protocol vulnerability

The TLS protocol vulnerability can allow to downgrade security to 512-bit DHE_EXPORT keys with a man-in-the-middle attack. It requires the attacker to be in the same network and have access to network routing to perform the attack. This is condition that are difficult to reproduce, except on public wifi for example or mobile connections.

However, ejabberd default configuration forbids a set a weak ciphers. The default configuration in ejabberd bans export weak ciphers and a few others: "DEFAULT:!EXPORT:!LOW:!RC4:!SSLv2"

It means that using ejabberd with default setting is safe.

In case you are using custom cipher list in your ejabberd configuration, please, make sure you do not explicitly allow EXPORT ciphers in you configuration file.

Attack on small Diffie-Hellman groups

The researchers have shown that small 512-bit or 1024-bit Diffie-Helman prime groups are vulnerable to attack under the following circumstances: Many server comes preconfigured with 512 or 1024-bit prime group. Precomputing an attack against very common small groups mean that someone with access to the network could eavedrop on connections. Even if cost to precompute attack on a single 1024-bit prime are extremely expensive, it is recommended to be on the safe side (and future proof) to generate your own DH parameters.

At the moment, as ejabberd does not allow as default ‘export’ cipher, you are still safe. However, we recommend in our best practices to set your own DH parameters, as allowed in ejabberd Community Edition 15.06.

Using your own Diffie-Helman parameters with ejabberd

To generate your own parameters DH you can generate a .pem file with:

openssl dhparam -out dhparams.pem 2048

Then, simply tell ejabberd to use your own 2048-bit prime DH group by adding the following entries in your listener configuration file and global parameters for outgoing s2s connections:

listen: - port: 5222 module: ejabberd_c2s access: c2s shaper: c2s_shaper starttls: true certfile: "/etc/ejabberd/server.pem" dhfile: "/etc/ejabberd/dhparams.pem" max_stanza_size: 65536 - port: 5223 module: ejabberd_c2s access: c2s shaper: c2s_shaper tls: true max_stanza_size: 65536 - port: 5269 ip: "::" module: ejabberd_s2s_in shaper: s2s_shaper max_stanza_size: 131072 # For s2s connection, you need a global parameter: s2s_certfile: "/etc/ejabberd/server.pem" s2s_dhfile: "/etc/ejabberd/dhparams.pem" Conclusion

ejabberd team always work hard to make ejabberd highly secure and follow the state of the art practices in term of security. As security is highly depend on computing power available at any given time, we do our best to anticipate to make sure you will stay on the safe side for the years to come.

However, there is no emergency in implementing our recommendations. These are the best practice that you should look forward implementing as your time allows.

Daniel Baczynski (GSoC 2015): Account serialization

16 July, 2015 - 07:50
We wanted profile settings to be stored using boost::serialization. It's done now for Account class (including ClientOptions serialization and other) that remember profile details. Saving and loading objects is realized in AccountsManager.

Previously, account details were stored using ProfileSettingsProvider. Now, for backward compatibility reason, they're stored in both settings provider and serialized string. When no serialization string is detected in settings, Swift obtain details using current settings provider and stores them serialized also.

Places in code using settings provider were replaced to make use of Account serialization. In future, we are probably going to avoid using ProfileSettingsProvider at all.

Tarun Gupta (GSoC 2015): Week - 8

15 July, 2015 - 19:02
This week was a little less of work, and I completed VCards and MUC.
The basic functionality of VCards is for a user to store and retrieve an XML representation of his or her vCard using the data storage capabilities. This is done by by sending an <iq/> of type "set" (storage) or "get" (retrieval) to one's Jabber server containing a <vCard/> child scoped by the 'vcard-temp' namespace, with the <vCard/> element containing the actual vCard-XML elements as defined by the vCard-XML DTD. Other users may then view one's vCard information. The various use cases available are: retrieving and updating own VCard and accessing other's VCard too. More information can be read here.
I just had to make minor changes to VCard to have feature parity with Swiften. Although I had to add the whole test file from Swiften and check for any inconsistencies.
Next on, I completed MUC (Multi User Chat). In MUC, each room is identified as a "room JID" <room@service> (e.g., <>), where "room" is the name of the room and "service" is the hostname at which the multi-user chat service is running. Each occupant has an occupant JID. User enters a room by sending a directed presence to <room@service/nick>. Messages sent within multi-user chat rooms are of a special type "groupchat" and are addressed to the room itself (room@service), then reflected to all occupants. More information can be read here.
In this I changed MUC to be an abstract class and implemented MUCImpl. Also updated a little bit of MUCBookmark and MUCManager. The difficult part was to port the tests, as those were failing with some reasons. I had to debug all the way, and finally corrected the mistakes. Next on, I am doing Components (might take longer). Also we are trying to find out the unexpected behavior of ant which is not updating the required class files and tests are giving error i.e. NoSuchMethodError.
That's all. Thanks for reading.

Andreas Straub (GSoC 2015): Week 07 - Alpha

15 July, 2015 - 13:42
Hey everyone!
The majority of this week was spent on getting the code ready for alpha. This meant refactoring the logging, so that we would better be able to diagnose potential problems from the logs people would send in, along with some more random code cleanup.

I encountered some tricky issues with my in-memory SessionCache being out of sync with the database, due to the roster not having been present when the cache is initially populated. This took quite a bit of fiddling around to figure out, and a few iterations to completely fix, because there are several non-obvious, distinct failure modes here.
I also worked on a bunch of little UI tweaks, mainly relating to session trust. If you recall from week 2, we had originally planned to decide trust on a per-session basis. The idea back then was that you would only ever build one session per contact, which would never be ended, so it seemed superfluous to trust the IdentityKey. After some deliberation, it turned out to be much more complicated to achieve this in a robust way, so we decided instead to implement trust on an IdentityKey basis. This meant shifting around some of the code, as well as changing the database schema.
All this work was needed so that message locks now show whether they originate from a trusted session. If the session is untrusted, the lock is colored red. The ContactDetailsActiviy now shows per-IdentityKey trust, along with a trust toggle button for every key.

In addition to TRUSTED and UNTRUSTED, I internally keep track of a third state, UNDECIDED, which all keys are set to initially. So far, this third state is treated the same as UNTRUSTED, but in a future update, if there are UNDECIDED keys, the send message button in axolotl-enabled conversations will spawn a new activity, prompting the user to either accept or reject the individual UNDECIDED keys, before sending the message.
My goals for the next week are implementing this TrustKeysActivity, fixing message delay tagging for axolotl messages, and a slight overhaul of the crypto code, which is still missing an HMAC.

Ignite Realtime Blog: Smack 4.1.3 released

15 July, 2015 - 13:37

I've just released Smack 4.1.3 to Maven Central. This is a bugfix release which can act as drop-in replacement for any Smack 4.1 version. Users are encouraged to update since Smack 4.1.2 introduced a memory leak in the Roster API which was fixed in 4.1.3.

ProcessOne: Boxcar Android Developer SDK updated with GCM 3 support

15 July, 2015 - 10:24

Boxcar Developer Push service was recently updated to support Google Cloud Messaging 3.0 (GCM 3).

Google changed the semantic of the identifier. They replaced the ad-hoc RegistrationID with a new Universal Identifier. Android Developer will need need our new Boxcar Android SDK 3.0 to support it.

You can find more details on Boxcar Developer Blog: New Boxcar Android SDK 3.0.0 and SDK 2.0.4 released

Adhish Singla (GSoC 2015): Week 7

15 July, 2015 - 06:56
Objective Learning Cordova with Examples Abstract

Apache Cordova is a platform for building cross-platform applications using HTML, CSS and JavaScript.

This week I have tried various examples in order to have a better understanding of Cordova for the purpose of making an IoT Client application for Android and Apple iOS.

  • Made a starting application that shows a alert message on starting.
  • Directory Application that stores the information locally and implement search on it.
  • Learn View Routing on Cordova.
  • Understand how to use Location, Contacts and Camera APIs using Cordova.
Images from Example Application

Road Ahead
  • Start with implementation of Application(Login, Strophe Connection, Retrieve Contacts).

Fanout Blog: Realtime API management with Pushpin and Kong

14 July, 2015 - 23:59

Pushpin is the open source reverse proxy for the realtime web. One of the benefits of Pushpin functioning as a proxy is that it can be combined with an API management system, such as Mashape's Kong. Kong is the open source management layer for APIs. To use Kong with Pushpin, simply chain the two together on the same network path.

Why would you want to use an API management system with Pushpin? Realtime web services have many of the same concerns as request/response web services, and it can be helpful to centrally manage those aspects.


Christian Schudt: XMPP Real-time Text in Action

8 July, 2015 - 19:18
XMPP Real-time Text is definitively one of the most fun XMPP extension out there, from user's point of view as well as from a developer's point of view! Recently I've added support for it in the upcoming version 0.6.0 and I thought I'd make a short video which demonstrates this cool new feature in action!

It shows how it could look like when two XMPP contacts are chatting with each other and having real-time text enabled. Enjoy!

Roughly speaking you have to create a new outbound real-time message and just update its text while typing:

// Create a chat session with another user.
Chat chat = xmppClient.getManager(ChatManager.class).createChatSession(contact);
RealTimeTextManager realTimeTextManager = xmppClient.getManager(RealTimeTextManager.class);
// Create an new RTT message.
OutboundRealTimeMessage realTimeMessage = realTimeTextManager.createRealTimeMessage(chat);
TextArea textArea = new TextArea();
textArea.textProperty().addListener((observable, oldValue, newValue) -> {

When done typing, commit the message (which will send the current message as normal chat message):


On the receiver side, you can listen for it like this (and e.g. display it to a Label).

Label label = new Label();
// Upon receiving a RTT message, display it.
realTimeTextManager.addRealTimeMessageListener(e -> {
InboundRealTimeMessage rtt = e.getRealTimeMessage();
rtt.addRealTimeTextChangeListener(e1 -> Platform.runLater(() -> label.setText(e1.getText())));

Tarun Gupta (GSoC 2015): Week - 7

8 July, 2015 - 16:32
This week was finally completing JID based on reviews and to merge it into master. I have completed Disco, Roster and Queries this week.
Disco specifies XMPP protocol extension for discovering information about other XMPP entities. There are two types of information which can be discovered: 
Firstly, identity and capability of an entity along with its features, and Secondly, items associated with an entity. 
For discovering information about a jabber entity, the requesting entity MUST send an IQ stanza of type "get", containing an empty <query/> element qualified by the '' namespace, to the JID of the target entity. The target entity then MUST either return an IQ result, or return an error. The result MUST contain a <query/> element qualified by the '' namespace, which in turn contains one or more <identity/> elements and one or more <feature/> elements.
For discovering items associated with an Jabber entity, it MUST send an IQ stanza of type "get" to the target entity, containing an empty <query/> element qualified by the '' namespace. The target entity then MUST either return its list of publicly-available items, or return an error. The list of items MUST be provided in an IQ stanza of type "result", with each item specified by means of an <item/> child of a <query/> element qualified by the '' namespace.
More information can be found here. I have added all functionalities provided in Swiften and also ported tests for the same.
In XMPP, one's contact list is called a roster, which consists of any number of specific roster items, each roster item being identified by a unique JID (usually of the form ). A user's roster is stored by the user's server on the user's behalf so that the user may access roster information from any resource.
The existing XMPP core protocol defines four <iq/> types (get, set, result, and error). Protocols complying with the <query/> action protocol use <iq/> 'set' to initiate all request-response interactions. The particular action to be taken MUST be set as an "action" attribute in the <iq/> <query/> sub-element.
So finally, I have completed all these three functionalities, i.e. Disco, Roster and Queries. Next up, I'll be doing VCards. And try to find the problem with ant, as it is not updating the required class files for the changes and hence resulting into unstable patches.

Adhish Singla (GSoC 2015): Week 6

8 July, 2015 - 14:52
Objective History Request and its Visualization using ChartJs Abstract

History Request is sent to a Device with a FieldName so as to read its values over a period of time. Visualizing these Values can be usefull in many ways, like predicting Temperature Change based on the Previous Values of Temperature.

This Week we will use History to get Values of a Field over a period of time from a Device and Display them in the form of a Line Graph.

  • Send a hardcoded History Query to a Device and get Values of Field over a particular period of Time.
  • Extend sending History Query from hardcoded to a command ‘/history day/week/month/year FieldName’ that can be sent to a device using ChatBox.
  • Parse the Message to Data of ChartJs Line Graph.
  • Display Graph as a message in the ChatBox.
Problems Faced and Work Arounds History Command not receiving any messages.
  • As this was a part of last week work, It was resolved by sending ‘SEQNR’ as a part of the History Query which is Unique Reference Number for the IQ to identify messages related to that IQ.
Final Output


So this is the time when the First GSOC Evaluation takes place. We have completed 90% of what was mentioned as part of Project Timeline. Also the Features Added to Converse can be tested by cloning dev_iot branch from here “” and setting up an Development Environment for it.

Road Ahead
  • Making a Mobile Application of an IoT Client using Apache Cordova.