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
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:
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 !
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.
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:
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.
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.
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.
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:
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.
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.
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
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.
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.
When done typing, commit the message (which will send the current message as normal chat message):realTimeMessage.commit();
On the receiver side, you can listen for it like this (and e.g. display it to a Label).Label label = new Label();
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.Work
GSOC MID-EVALUATION WEEK
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 “https://github.com/adhish20/converse.js/tree/dev_iot” and setting up an Development Environment for it.Road Ahead
Write Request is sent to a Device JID to set a Field to a particular Numeric Value , for instance Relay of a Device, or “hue” of Philips Hue can be changed through a write command.
History Request is sent to a Device with a FieldName so as to read its values over a period of time.
This Week we will use Write to set numeric values to Device Fields and History to get Values of a Field over a period of time from a Device.Work