Planet Jabber

March 24, 2018

Ignite Realtime Blog

Openfire 4.2.3 Release

@akrherz wrote:

The Ignite Realtime Community is pleased to announce the availability of Openfire 4.2.3. This release signifies our continued effort to provide a stable 4.2 series release while work continues on the next release of Openfire.

The changelog denotes the full listing of Jira issues addressed in this release. Of note, this release fixes the regression of inability to update plugins from the admin console.

Here is a listing of sha1sum values for the release binaries, which can be found on our download page.

a469ba44e962d31bad74d47133fc45b6229a44a3  openfire-4.2.3-1.i686.rpm
0ef044976e27bc13576ddc4ffd28dd1e26240046  openfire-4.2.3-1.noarch.rpm
9e3fe913a4de7644d3d0ec614086db0ab4a39c63  openfire-4.2.3-1.x86_64.rpm
ed6ce37bf335520fdd8928b04a716d22481908fc  openfire_4.2.3_all.deb
d4e025c7cdf67327119b56c249d34c04e7347d84  openfire_4_2_3_bundledJRE.exe
f875d55fcdb35700378640af203880080fedfc9f  openfire_4_2_3_bundledJRE_x64.exe
18c14e0784ddd6e05b2dac6d06c4ba9c3726361b  openfire_4_2_3.dmg
82ea13f16ef9b44154d0c7c0588e0acf2defff78  openfire_4_2_3.exe
868e05c7b9be84f7d6b834ae6b7e3b405e9f8055  openfire_4_2_3.tar.gz
dcff9422c9f06fbf17fac504ec7978ab385f4602  openfire_4_2_3_x64.exe
bdd9b2405dc965612a728f186b678276e4efe585  openfire_src_4_2_3.tar.gz

Please let us know of any troubles you find by either visiting our webchat or creating posts in our Discourse Openfire Dev Forum. Thanks for using Openfire!

Posts: 1

Participants: 1

Read full topic

by @akrherz daryl herzmann at March 24, 2018 01:50

March 20, 2018


Real-time Stack Issue #8

ProcessOne curates two monthly newsletters – tech-focused Real-time Stack and business-focused Real-time Enterprise. Here are the articles concerning tech aspects of real-time development we found interesting in Issue #8. To receive this newsletter straight in your inbox on the day it’s published, subscribe here.

Red Hat to acquire CoreOS, expanding its Kubernetes operations

Red Hat, Inc. the provider of open source solutions, announced that it has signed a definitive agreement to acquire CoreOS, Inc.

XMPP: Chat with a Future

XMPP is the Extensible Messaging and Presence Protocol standardized by the IETF. This standard provides the framework for doing anything you want to do with chat, and more. Why is XMPP (formerly known as Jabber) not the mainstream chat protocol? Actually it is.

GitHub: hui6075/mosquitto

Mosquitto is an open source implementation of a server for version 3.1 and 3.1.1 of the MQTT protocol. This fork provides a built-in, autonomous Mosquitto Cluster implementation.

ejabberd 2017 year in review

This was an amazing year for ejabberd! With almost regular monthly updates, tons of new features and improvements, we worked hard to make ejabberd the best XMPP server available. Let’s take a look at the past year, and let us wish you a Happy New Year! We started last year with a cleanup.

ejabberd 18.01 released

ejabberd 18.01 is a bugfix release. This version of ejabberd Community Server is a good candidate for Linux distributions packaging as it concludes a year of development and stabilised all recent changes for production use.

GitHub: ortuman/jackal

Jackal is a new XMPP server written in Go that aims to be known for its stability, simple configuration and low resource consumption.

Using TLS authentication for your Go Kafka client

If you want to access a Kafka server that have enabled TLS, you will need to be able to use certificate to connect from your Sarama / Go client. This article outlines the needed steps to configure it properly.

If you are interested in the Go programming language, be sure to check out ProcessOne Realtime Go Development & Consulting services.

by Marek Foss at March 20, 2018 09:32

Real-time Enterprise Issue #7

ProcessOne curates two monthly newsletters – tech-focused Real-time Stack and business-focused Real-time Enterprise. Here are the articles concerning business aspects of real-time enterprise we found interesting in Issue #7. To receive this newsletter straight in your inbox on the day it’s published, subscribe here.

100,000 IoT Sensors Monitor a 1,400-Kilometer Canal in China

As an engineering feat, China’s massive South-to-North Water Diversion Project is a stunner. Three artificial canals, each more than 1000 kilometers long, are in various stages of completion and designed to reroute water from the country’s rainy south to its parched north.

The Coming Boom of Healthcare IoT

Given the higher barrier to entry in the medical device market, connectivity will be driven by discrete clinical benefit. There are some incredibly compelling and practical reasons to connect a medical device to the internet.

IoT Drives Progress Towards Low-power Technology

The Internet of Things is growing rapidly, as huge numbers of connected meters and machines come online, all bristling with sensors to measure the world around them. But what will power all this electronic gadgetry?

‘Quantum Radio’ May Aid Communications and Mapping Indoors, Underground and Underwater

Researchers at the National Institute of Standards and Technology (NIST) have demonstrated that quantum physics might enable communications and mapping in locations where GPS and ordinary cellphones and radios don’t work reliably or even at all, such as indoors, in urban canyons, underwater and underground.

26,000 Blockchain Projects Launched in 2016, 92% are Now Dead

Consulting heavyweight Deloitte claims that over 26,000 new blockchain-based projects were launched on GitHub in 2016. GitHub is a development platform that houses codes for more than 86,000 blockchain programs, including large projects such as Bitcoin.

NASA Awarded a Grant for Ethereum Blockchain-Related Research

Space exploration has taken monumental leaps, but many of our tools are still tethered to Earth for data and instructions. As satellites move further from Earth, NASA must send information further into deep space to reach them. As the distance grows, sending transmissions takes more and more time.

Announcing Go Support for AWS Lambda

Amazon is excited to announce Go as a supported language for AWS Lambda. This is the perfect time to look at ProcessOne Custom Go Development and Consulting »

by Marek Foss at March 20, 2018 09:25

Swift Blog

Swift 4.0 is Ready

We’re excited to announce that Swift 4.0 has reached full release status. The packages can be downloaded from the releases page and a full list of new features can be found in the 4.0 changelog.

We encourage everyone to get the new build and try it out, and give us feedback on our latest release.

March 20, 2018 00:00

March 18, 2018

Arnaud Joset

Demo Website: Authentication with XMPP

This article follow up the article about Authentication without password using XMPP on a Django website previously presented here. This article introduced the XMPP extension (XEP-0070) which allows one to connect on a website with his XMPP account, without additional password.

Unfortunately, the XEP-0070 is not widely used but this article aims to present you my little contribution to change this situation.


Those who know me know that I tends to have multiple projects in parallels. I have one in the back of my head since several months but it is too early to talk about it yet. I want this project to be usable with XMPP. Some resources will be accessible on a web server but I don't want to force users to manage additional passwords. This is the perfect use case of XEP-0070.1

In order to test the accessibility and the number of user-friendly clients that support this extension, I published a small demo website:

This website is built with the famous Django framework. Moreover, the revelant code is available in the previous post and on the Gitlab page.

You can try the demo by clicking on the "Sign In" button. The only information needed is your XMPP account (JID). You will then receive a request on your XMPP client. If it does support the XEP, you will be invited to click in a dialog box in order to accept the connection.

It your client does not support it, there is a fallback mechanism where you receive a message from "". Unfortunately, The method may be tedious on some mobile clients. It is quite sad because it is the best use case of the XEP.


Movim (new)

Shortly after I submitted a bug report about this feature, edhelas from the Movim project implemented it. His reactivity is remarkable. The feature is available on the official pods.



Gajim XEP-0070

Salut à toi (Primitivus)

Primitivus XEP-0070


Unfortunately, Conversations, one of the best mobile clients, does not support the feature yet.



The sources are available on my account.

The service is still in beta. Do not hesitate to contact me if you experience some bugs with the demo.


You no longer have excuses to avoid to authenticate users on your platform with XMPP.

  • Nice and user-friendly clients implement it.
  • The Chteufleur's component is stable and easy to use.
  • It is quite easy to add the functionality on the website running with django, Wordpress and it should not be an insurmountable challenge with ruby on rails.

In the future, I will probably encourage new users to use Movim with my projects as it does not require installation and it supports the XEP.

I hope to be able to give you updates soon about the agayon project.

In the meantime, bug reports have been submitted:

Stay tuned !


  1. Goffi from the Salut à Toi project is curently working on a different solution to adress these kind of challenges.

by Arnaud at March 18, 2018 18:00

March 16, 2018

Tigase Blog

IoT One Cloud Update

We’re hard at work on developing and bringing the world of IoT to your raspberry pi, and we’re excited to show off some of the work we’ve been doing. Today we released a video showing compatibility with an LED matrix screen.

by Daniel at March 16, 2018 21:12

March 12, 2018

JC Brand

Slack's bait and switch

Slack has finally decided to close down their IRC and XMPP gateways.

True to form, you can only read their announcement if you already have a Slack account and are logged in to a workspace.

Here's the gist of their announcement:

As Slack has evolved over the years, we've built features and capabilities —
like Shared Channels, Threads, and emoji reactions (to name a few) — that the
IRC and XMPP gateways aren't able to handle. Our priority is to provide a
secure and high-quality experience across all platforms, and so the time has
come to close the gateways.

They're of course being economical with the truth here.

Perhaps their XMPP gateway can't handle "Shared Channels" and "Threads", but that's because they purposefully stopped working on it.

A "Shared Channel" simply means a chatroom which people from outside your workspace can participate in. If a workspace is mapped to a members-only chatroom, then making something a shared channel simply means updating the members list or making the chatroom open (so anybody can join it).

Threads can be implemented by adding a <thread> element in the message stanza, as documented in XEP-201.

And emoji... there's nothing in XMPP that prevents people from sending emoji.


UPDATE: Several readers have pointed out that "emoji reactions" and emoji are different things. Emoji reactions can be tacked to a particular message.

Still, there's nothing fundamental about XMPP that prevents emoji reactions, and work is currently underway to add support for them.

The protocol is designed to be eXtensible (hence the X in XMPP) and new features are continuously being added.

Classic bait and switch

We all know the real reason Slack has closed off their gateways. Their business model dictates that they should.

Slack's business model is to record everything said in a workspace and then to sell you access to their record of your conversations.

They're a typical walled garden, information silo or Siren Server

So they have to close everything off, to make sure that people can't extract their conversations out of the silo.

We saw it with Google, who built Gtalk on XMPP and even federated with other XMPP servers, only to later stop federation and XMPP support in favour of trying to herd the digital cattle into the Google+ enclosure.

Facebook, who also built their chat app on XMPP at first allowed 3rd party XMPP clients to connect and then later dropped interoperability.

Twitter, although not using or supporting XMPP, had a vibrant 3rd party client ecosystem which they killed off once they felt big enough.

Slack, like so many others before them, pretend to care about interoperability, opening up just so slightly, so that they can lure in people with the promise of "openness", before eventually closing the gate once they've achieved sufficient size and lock-in.

On Federation

When we talk about "federation" in networks, we mean the ability to communicate between different service providers.

For example, email is federated. You can set up your own email server, and then send emails to people with their own email servers, or to people with Gmail or Yahoo! accounts.

You can email any other email address in the world, regardless of where that email address is hosted.

If email never existed, and a company like Slack today would come out with this brand new concept of "Electronic Mail", let's call it digimail, do you think they would standardise the digimail protocol and allow you to send messages to other digimail purveyors?

We all know the answer to that. They won't, and neither would Google, Microsoft or Facebook.

Heck, Facebook is actively trying to replace email since years.

The reason email is federated, is because it was developed before surveillance capitalism was a thing and because it was established and entrenched long before these companies came around.

There's a reason why your email address is still the de facto way to sign up for any service on the web (sometimes with one or two degrees of separation), and it's because of federation.

XMPP is designed to allow federation. Think about that. Instead of having to sign up to various different chat providers, all which try to lock you in and monetize your conversations, you could instead have one chat account, and use that to chat with anybody else, regardless of which chat provider they are using.

Alas, that's the dream, but because XMPP came much later to the scene, it didn't develop the critical mass as email has, and here we are. With dozens of chat apps, all non-interoperable and closed off.

What would it take for XMPP to take off?

One of the sad things that has come out of Slack's meteoric rise to success, has been how many free and open source projects have jumped over to using it (after previously using IRC or XMPP).

In so doing, they have closed off their discussions from search engines and they prevent people from accessing their past archives.

Slack has many cool features, and they work very well, I'm not going to deny it.

However, the XMPP Software Foundation has done a lot of work in recent years to enable protocol extensions that provide features that people have come to expect from chat applications, for example:

Unfortunately XMPP clients have been lagging far behind in various respects.

One of the main problems is funding. The modern digital economy is largely set up around surveillance capitalism and user lock-in.

So attempts to create software that doesn't follow these precepts, often end up unfunded or underfunded.

However, our "weakness", is also our strength.

XMPP clients, and the XMPP network can provide something that Slack never can. Federation, free and open software, interoperability, extensibility and user choice.


For the last few years I've been working in my spare time on making a JavaScript XMPP chat client, called converse.js.

Originally the idea was to make a Gtalk like chat client that you integrate in your website, and it can still be used like that.

A screenshot of converse.js as overlayed chatboxes

However, in the last year I've updated it further so that it can also be used as a fullscreen application, like Slack is used.

You can try the fullscreen version at

A screenshot of converse.js as a fullscreen application

If you have no-one to chat to, then come join the chat room.

This link will take you directly there (via

Converse.js still lacks lots of features that Slack has, but that's not because XMPP itself can't support those features.

What converse.js however does have, is that it's free and open source software, based on a standard protocol and it can be extended, updated and improved upon, by anyone.

We're actively working on adding new features and more and more people are joining in.

Moreover, anybody can host it and you can integrate it into any website.

Ultimately, I believe in the power and utility of interoperability and software freedom, even though the current trend is to close off and lock down.

These information silos are as powerful as we make them. If enough projects choose standardised protocols and FOSS software, we will be able to create viable alternatives that foster freedom instead of lock-in.


Hacker News discussion

This blog post triggered a lively discussion on Hacker news, you can read that here:

March 12, 2018 12:30


Developing a basic Swift Echo Server using Swift-NIO

Swift-NIO: a port of Netty

I am not a Java or JVM type of developer. That’s probably one of the reasons I never felt the need to try Netty framework. I have been developing all my high-performance server code in Erlang, Elixir or Go and was happy with the tooling.
However, Apple recently published Swift-NIO, a new library and framework to develop cross-platform server and client applications.

I am more a scalable back-end developer than a front-end developer. That said, I love the Swift programming language and have followed the progress since Apple released it in 2014. That’s why this new framework caught my attention. How good is it to write server-side software?

As Swift-NIO is a port of Netty, made by a team led by a prominent Netty contributor, Norman Maurer, I have first looked at Netty design to better understand how Swift-NIO is working. I like what I read about it.

Netty’s concepts provide a very nice generic abstraction that is common to good networking applications. It is a reference framework, used in Java world to build a lot of very advanced server and client tools.

The concepts map very well with Swift programming language. It is a good fit that makes me thinks that this could indeed accelerate Swift server-side development and cross-platform reach.

I bet it could have a big impact and help Swift continue its fast rise as one of the top programming languages.


Swift-NIO relies on non-blocking IO. It means that you can have a relatively small number of threads managing a very large number of network connections by having an intermediate layer dispatching the network operations that are ready to process to the worker threads.

Network operations are thus non-blocking from the processing thread perspective. They can fully use the CPU, as they can share network operations for a large number of sockets, without the wait.

In Swift-NIO wording, blocking operations are delegated to channels. Channels triggers events on network operations to the event loops in charge of managing the channel. Developers provide the logic of the server or client to the event loop as handlers. Handlers are pieces of code that implement the operation to perform when networking events are triggered.

They can be combined in handler pipelines for extra flexibility. This adds an extra layer for decoupling and makes handlers more reusable.

Implementing a basic server

In client-server world, the ‘Hello World’ application is generally an “Echo” server. The server takes what the client sends and send it back to the client.

This is very easy to implement with Swift-NIO. Let’s see how it could be done.

Please, note that the following steps were tested on MacOS, but they should work on Linux as well if you have Swift installed.

Create Swift project

You can bootstrap your project with Swift command-line:

$ mkdir EchoServer
$ cd EchoServer/
$ swift package init --type executable
Creating executable package: EchoServer
Creating Package.swift
Creating .gitignore
Creating Sources/
Creating Sources/EchoServer/main.swift
Creating Tests/

Add Swift-NIO as dependency

To change your project configuration, you will need to edit the Package.swift file.

You can add the Swift-NIO repository in the general package dependency list:

dependencies: [
   .package(url: "", from: "1.1.0"),

and add NIO in your EchoServer target dependencies:

              name: "EchoServer",
              dependencies: ["NIO"]),

The full Package.swift file is as follow:

// swift-tools-version:4.0
// The swift-tools-version declares the minimum version of Swift required to build this package.

import PackageDescription

let package = Package(
    name: "EchoServer",
    dependencies: [
        // Dependencies declare other packages that this package depends on.
        // .package(url: /* package url */, from: "1.0.0"),
        .package(url: "", from: "1.1.0"),
    targets: [
        // Targets are the basic building blocks of a package. A target can define a module or a test suite.
        // Targets can depend on other targets in this package, and on products in packages which this package depends on.
            name: "EchoServer",
            dependencies: ["NIO"]),

Finally, you can use the command swift package resolve to download the dependencies:

$ swift package resolve
Resolving at 1.1.0
Resolving at 1.0.0

The EchoServer code

The server code is implemented in Sources/EchoServer/main.swift.

The ChannelInboundHandler

The EchoServer code is very simple. The first part if about creating the ChannelInboundHandler implementation, that will implement the server logic.

In our case, we will implement only five callback methods:

  • channelRegistered: invoked on client connection.
  • channelUnregistered: invoked on client disconnect.
  • channelRead: invoked when data are received from the client.
  • channelReadComplete: invoked when channelRead as processed all the read event in the current read operation. We use this to ensure we flush the data to the socket.
  • errorCaught: invoked when an error occurs.

The other important thing to note is that each callback method receives a context that can be used to get information on the session. It contains information about the client IP address, for example. The context also provides methods, for example, to write data back to a given client.

private final class EchoHandler: ChannelInboundHandler {
    public typealias InboundIn = ByteBuffer
    public typealias OutboundOut = ByteBuffer

    // Keep tracks of the number of message received in a single session
    // (an EchoHandler is created per client connection).
    private var count: Int = 0

    // Invoked on client connection
    public func channelRegistered(ctx: ChannelHandlerContext) {
        print("channel registered:", ctx.remoteAddress ?? "unknown")

    // Invoked on client disconnect
    public func channelUnregistered(ctx: ChannelHandlerContext) {
        print("we have processed \(count) messages")

    // Invoked when data are received from the client
    public func channelRead(ctx: ChannelHandlerContext, data: NIOAny) {
        ctx.write(data, promise: nil)
        count = count + 1

    // Invoked when channelRead as processed all the read event in the current read operation
    public func channelReadComplete(ctx: ChannelHandlerContext) {

    // Invoked when an error occurs
    public func errorCaught(ctx: ChannelHandlerContext, error: Error) {
        print("error: ", error)
        ctx.close(promise: nil)

Setting up the server

The rest of the code is about setting up the server. Swift-NIO provide some “Bootstrap” helpers to make the process even simpler for a common situation.

In that example, we use the ServerBootstrap.

// Create a multi thread even loop to use all the system core for the processing
let group = MultiThreadedEventLoopGroup(numThreads: System.coreCount)

// Set up the server using a Bootstrap
let bootstrap = ServerBootstrap(group: group)
        // Define backlog and enable SO_REUSEADDR options atethe server level
        .serverChannelOption(ChannelOptions.backlog, value: 256)
        .serverChannelOption(ChannelOptions.socket(SocketOptionLevel(SOL_SOCKET), SO_REUSEADDR), value: 1)

        // Handler Pipeline: handlers that are processing events from accepted Channels
        // To demonstrate that we can have several reusable handlers we start with a Swift-NIO default
        // handler that limits the speed at which we read from the client if we cannot keep up with the
        // processing through EchoHandler.
        // This is to protect the server from overload.
        .childChannelInitializer { channel in
            channel.pipeline.add(handler: BackPressureHandler()).then { v in
                channel.pipeline.add(handler: EchoHandler())

        // Enable common socket options at the channel level (TCP_NODELAY and SO_REUSEADDR).
        // These options are applied to accepted Channels
        .childChannelOption(ChannelOptions.socket(IPPROTO_TCP, TCP_NODELAY), value: 1)
        .childChannelOption(ChannelOptions.socket(SocketOptionLevel(SOL_SOCKET), SO_REUSEADDR), value: 1)
        // Message grouping
        .childChannelOption(ChannelOptions.maxMessagesPerRead, value: 16)
        // Let Swift-NIO adjust the buffer size, based on actual trafic.
        .childChannelOption(ChannelOptions.recvAllocator, value: AdaptiveRecvByteBufferAllocator())
defer {
    try! group.syncShutdownGracefully()

// Bind the port and run the server
let channel = try bootstrap.bind(host: "::1", port: 9999).wait()

print("Server started and listening on \(channel.localAddress!)")

// Clean-up (never called, as we do not have a code to decide when to stop
// the server). We assume we will be killing it with Ctrl-C.
try channel.closeFuture.wait()

print("Server terminated")

You can check the full code of the server on Github: Sources/EchoServer/main.swift.

Running the server

You can run the server with the command:

$ swift package resolve
Resolving at 1.1.0
Resolving at 1.0.0
MBP-de-Mickael:EchoServer mremond$ vim Sources/EchoServer/main.swift 
MBP-de-Mickael:EchoServer mremond$ swift run 
Compile CNIODarwin shim.c
Compile CNIOLinux shim.c
Compile CNIOAtomics src/c-atomics.c
Compile Swift Module 'NIOPriorityQueue' (2 sources)
Compile Swift Module 'NIOConcurrencyHelpers' (2 sources)
Compile Swift Module 'NIO' (47 sources)
Compile Swift Module 'EchoServer' (1 sources)
Linking ./.build/x86_64-apple-macosx10.10/debug/EchoServer
Server started and listening on [IPv6]::1:9999

Swift will compile the server and run it.

You can also build the server with swift build and run the executable from the .build directory:

$ swift build
$ .build/debug/EchoServer

Testing the server with Telnet client

You can connect to your echo server with telnet.

$ telnet localhost 9999
Trying ::1...
Connected to localhost.
Escape character is '^]'.
telnet> close
Connection closed.

As you see, all your commands are repeated, sent back from your EchoServer.

The server will print a message on each connection and the total of messages processed during the session on each disconnect:

channel registered: [IPv6]::1:62759
we have processed 2 messages

Note: On latest MacOS version, telnet is not installed as default, but you can install it easily with homebrew.


Swift-NIO is a very interesting framework for developing server and client applications. I think it will help spread the use of Swift on the server-side. Vapor, a well-known server-side framework, has already changed their own code to use Swift-NIO as a building brick, and this is only the beginning.

Netty is at the heart of many server-side components in the Java world (Akka, PlayFramework, Gatling, Finagle, Cassandra, Spark, Vert.x, …). Swift-NIO will play a similar role for Swift, making it an interesting contender among the wide choice of languages you can use for back-end development.

Please, send me comments and feedback to let me know if you are interested by more content on Swift-NIO, server-side Swift (or Swift in general).

by Mickaël Rémond at March 12, 2018 11:45

March 05, 2018


The Challenges of Building Real-Time Applications

Real-time is everywhere. Users are now expecting that applications can update and display pieces of information in real time.

Whether you are building a chat application, a website, a mobile app, or a business application, users want to be notified, receive pushes (properly targeted), be able to react instantly and have the user interface always up to date.

However, the real-time domain is quite broad. A chat application is very different from a business dashboard. Far too often, I have seen “real-time” web applications that were just doing refresh queries every 5 seconds to keep the data up to date. This is a naive way to build real-time applications, but the real problem is that most of the time, it does not scale. In the case at hand, each request was doing a whole set of database queries. It worked fine with ten users but collapsed under load with just a hundred users.

What you need is to stop pulling data and switch to a server push approach. However, it needs to be designed that way from the beginning, as you need to think your system in terms of subscription scope, consistent set of data (channels). You need to design how real-time information will propagate and update your system.

This is just a simple example coming from a real case. I can find many other examples and I am sure you can too.

So, depending on the type of applications you need to write, you must consider the toolset you have available and possibly mix them. You need to design your data flow, your events, your integration points, etc. Real-time tools are often seen as a commodity, but not the skills needed to build such systems. This expertise is very rare. Real-time is not something you learn at school. It is a very advanced topic in information system design.

In practice, many developers and software architects struggle to introduce real time in their applications or information systems. You not only need to introduce a new set of skills, but they also need to learn about the available tools to implement real-time systems.

I have been very aware of the issues developers were having. I have helped tens of companies build real-time messaging systems since 2002. However, this is only in the last years that I realized that I needed to put in place a holistic approach for real-time software design. Real-time is much more than building chat systems. It needs to be placed at the heart of your application. So, that’s why we expanded our core skills to new tools, protocols, and type of applications. We have a unified vision of real-time that often mix XMPP, MQTT, Kafka, among other protocols, to connect people, things and applications together. It helps us use the right tool for the real-time job at hand. It broadens the vision and helps us help developers.

We can thus help developers and software architects better understand what is the type of real-time data they will manipulate, how critical they are, what are the best architectural design and what are the best tools for the jobs and why.

However, to get further, we need to understand more broadly your struggles. What are you facing as challenges in developing and building your system? Which tools have you selected? How is it working for you?

You want to build a better development team, that think about architecture and integrates real time from the beginning? What is restraining you to do so? Are you fighting with server platforms? Software architecture design? Client developments? Skills? Which tools are you using today? What do you plan to use tomorrow?

I am preparing contents to help you get better at overcoming the challenges of real-time systems, so do not hesitate to comment or mail me (mickael.remond@[mycompanydomain]). Please, share your feedback and issues to help me help you.


by Mickaël Rémond at March 05, 2018 20:21

March 04, 2018

Ignite Realtime Blog

Smack 4.2.3 and 4.3.0-beta1 released

@Flow wrote:

Smack 4.2.3 was tagged and released recently to Maven Central. As always, patchlevel releases of Smack are API compatible and can be used as drop-in replacement.

We like to thank everyone who contributed to this release. This not only includes the various contributors shown below, but also everyone who reported an issue or suggested an improvement.

$ git shortlog -sn 4.2.2..4.2.3
    20  Florian Schmaus
     5  Paul Schaub
     1  dave-stanley
     1  lohse

The list of fixed bugs can be found in the Smack 4.2.3 changelog. Or have a look at the github comparison of the 4.2.2…4.2.4 tags.

In the meanwhile Paul was busy contributing various new features to Smack. Some of them have been already merged into the 4.2 branch and are scheduled for the 4.2.4 release.

The first beta of Smack 4.3 was also published. We encourage everyone willing to try out the 4.3.0-beta1 in preperation of upcoming release of 4.3. Any feedback about the latest beta is highly appreciated.

Posts: 2

Participants: 2

Read full topic

by @Flow Florian Schmaus at March 04, 2018 11:03

February 27, 2018

The XMPP Standards Foundation

The XMPP Newsletter, 28 February 2018

Welcome to the first edition of our newsletter.

Eve Online, the massively multiplayer online role-playing game have announced that they are using Ejabberd in a new chat backend and ProcessOnce have written a a blog article about it.

Staying with games, Epic Games have written a postmortem of a service outage where they mention certain stats related to their usage of XMPP.

Alex Rogers, who attended the 22nd XMPP summit and participated in discussions around the business case for federation, has been featured in an article from UC Today titled Integrating the Islands of IM: The Continual Rise of XMPP.

Alan R. Earls wrote an article for IoT Agenda discussing XMPP as protocol for Internet-of-Things applications: XMPP: IoT protocol winner, or second place to MQTT?

Arnaud Joset has created Errol, an XMPP Automatic file sender as well as a demonstration of website authentication with XMPP account.

Christian Schudt has written about his implementation of XEP-0390 Entity Capabilities 2.0 in Babbler, the Java XMPP library.

Jérôme Poisson has written about the 0.7 release of Salut à Toi, and the fact that its web frontend Libervia is now a web framework in Build a decentralized internet with Libervia (Salut à Toi).

Daniel Gakwaya has created a course on Udemy, titled XMPP and Smack and has written a friendly introduction to XMPP.

Ivan Vučica compares IRC and XMPP in his blog post: What can XMPP do that IRC can’t?.

JC Brand has created a badge for linking to your project's XMPP chat, and wrote a short summary of the The 2018 XSF Summit.

Paul Schaub has written about the new XEPs added to Smack.

German website Die Datenschutzhelden (The privacy heroes) wrote an article comparing XMPP/OMEMO with Whatsapp. Here is the Google machine translated version and the original German article: OMEMO: XMPP im Direktvergleich mit WhatsApp.

Server host wrote why they don't fully support the "Jabber Spam Fighting Manifesto".

Software releaseѕ

Erlang Solutions have released MongooseIM 2.1.1

Tigase 7.1.3 has been released.

OpenFire 4.2.2 has been released.

W. Martin Borgert wrote Pain in the APT, which lets you "pester people about available package updates by email or jabber".

There were 3.3.x releases of Converse.js.

Fork Awesome, a fork of Font Awesome which includes more community contributed icons, now has an XMPP icon.

by jcbrand at February 27, 2018 23:00


ejabberd invites students to Google Summer of Code 2018

ejabberd has joined other Erlang projects in the BEAM Community to invite student developers to Google Summer of Code (GSoC), a global program focused on bringing them into open source software development. Through this program, students have an opportunity to receive a stipend (2400–6600 USD) and work with an open source organization on a 3 month programming project during their break from school.

How to join?

If you are a student and wish to join one of ejabberd GSoC projects, be ready from March 12 until March 27. Register on the GSoC website, select the BEAM Community organization and submit your project proposal. You can choose an ejabberd idea or suggest your own project you wish to work on during the summer.

If you have questions before the deadline, you can chat with us via XMPP groupchat at

Why get involved?

For a student, GSoC is a great opportunity to learn new skills, learn to work with a team of experienced developers, help open source projects and get a fair compensation.

ejabberd is one of the most used XMPP servers in the world, deployed on huge scale deployments in large corporations. This is a unique chance to get your code running for tens of millions of users and have a real impact with your work.

This year, we prepared five ejabberd ideas to choose from:

  • Idea #1: Spam fighting with Blockchain
  • Idea #2: Support for Things Discovery service in ejabberd
  • Idea #3: Web UI administration improvements: Manage ejabberd services, MUC rooms, etc
  • Idea #4: XMPP and HTTP convergence
  • Idea #5: MQTT to XMPP session

Please, make sure that you are eligible before investing time on the project. Details are available on the GSoC FAQ.

The ejabberd community looks forward to working with you!

by Marek Foss at February 27, 2018 11:55

February 23, 2018


Eve Online Chat is Moving to ejabberd

I am player at heart. I do not have time to play much, but since my young years, I have always been fascinated by gameplay mechanisms, to the point I am more interested in understanding the game design than by the act of playing the game.

Even if I do not have much time to play, I still follow the game scene. Eve Online has been on my radar since a long time, as one of the true and hardcore massively multiplayer online game in existence. It has managed to gather a community of fans and gather players consistently since its launch 15 years ago.

Eve Online universe is mesmerizing. What fascinates me is the way it had led players through epic moments, gathering thousands of players online in large-scale battles. It is the same kind of fascination I had with large coordinated operations in Ingress.

Being a multiplayer game and massively online, ability to chat between the player is a critical component of the game. It is a service that could strengthen the bonds between the players or severely damage the user experience.

So, Eve is a unique game, and its chat system is a central service. That’s why I am so proud to share that Eve Online has decided to replace its custom chat system by a standard protocol, XMPP, powered by ejabberd server, by ProcessOne. CCP Games will roll out the new service in March:

With the March release, we’ll be updating the chat system in EVE Online, moving from the custom solution we’ve been using since EVE was initially designed, to an industry standard XMPP chat server that will offer better performance and flexibility for the future.

Eve Online Blog: Preparing for the future – retirement of Eve Voice

That industry standard server is, of course, ejabberd, as confirmed by the development team on Twitter:

ejabberd repository fork is also visible on the Github of the CCP Games, maker of Eve Online.

ejabberd has been used as a key component in many major games, gathering millions of active players online.

We are once again delighted to have written a robust, ubiquitous software stack that makes such large-scale communities possible.

by Mickaël Rémond at February 23, 2018 09:45

February 19, 2018

JC Brand

A badge for linking to your XMPP chat

You've probably noticed the coloured badges at the top of project READMEs on Github and Gitlab.

These badges indicate various metrics about the project's current state and its supporting infrastructure.

For example, the README page for converse.js contains the following badge:

Bountysource bounties

It indicates how many open bounties there are for converse.js on Bountysource.

There are dozens such badges available nowadays, just take a look at

Some projects have badges that link to a chatroom, hosted by Gitter, Slack etc.

Converse.js, being an XMPP-based project, has its own XMPP chatroom at

So I created a badge for its README, which points to that chatroom and also indicates how many users are currently in it.

It looks like this:

Link to the Converse.js chatroom on

The Markdown syntax for showing the badge looks like this:

[![Link to XMPP chat](](

The target URL for this badge is, which means that it takes the user to and then once the user has logged in, the room will be opened.

To go to a different room, just specify a different JID (Jabber ID) in the URL parameters.

The image URL is

Here you specify the room JID with the room URL parameter.

The image is an SVG which is generated by a tiny Flask app, which includes a chatbot written with SleekXMPP that checks how many users are in a particular chatroom.

The code is open source, and hosted on Github at jcbrand/xmpp-chat-badge.

If you're using this badge for your project, I'd be happy to hear about it.

You can let me know in the converse.js XMPP chatroom at (or through the web with or by using this website's contact form.

February 19, 2018 12:30

February 16, 2018


ejabberd joins Google Summer of Code 2018

Each year since 2015 ejabberd has joined other Erlang projects in the BEAM Community to invite student developers to Google Summer of Code (GSoC), a global program focused on bringing them into open source software development. Through this program, students have an opportunity to work with an open source organization on a 3 month programming project during their break from school.

This year is no different! ejabberd is offering five intriguing ideas to develop, and five expert ProcessOne mentors to help the participants. Next month, from March 12 until March 27, students can select an organization and a project they wish to work on during the summer – registration will be opened on the GSoC website.

In the meantime, we invite interested students to learn more about the ideas we propose to develop, and get ready for their GSoC applications.

Idea #1: Spam fighting with Blockchain

XMPP being a federated open protocol is subject to spam, using messages and contact addition requests. If it is easy to limit messages spam by blocking messages that are not sent by existing contacts in roster, contact additions spam is both quite inefficient for spammers but also very annoying for users and difficult to block.

By allowing servers to require a small blockchain payment to be attached to contact requests addition, it could be possible to make the cost of mass sending contact addition requests not cost effective to use for spammers.

Idea #2: Support for Things Discovery service in ejabberd

The first step in getting Internet of Things over XMPP to take off is to be able to register things. Implementing XMPP-IOT protocol would allow Things to be installed, configured and claimed by their owner.

Idea #3: Web UI administration improvements

ejabberd comes with a web console to manage the server. However, many administration features are only available from XMPP clients from users with admin rights or from ejabberdctl command-line tools. To spread the use of ejabberd as an easy to use corporate chat services, it is important to make it more manageable through a web browser.

Idea #4: XMPP and HTTP convergence

XMPP is a difficult protocol for a web developer. It is a connected, stateless protocol. However, it’s possible to map a lot of the operations, semantics of XMPP, on top of HTTP using traditional REST. A lot could be done to open up a whole new range of use cases of ejabberd to traditional web developers or to an environment where using XMPP directly is difficult.

Idea #5: MQTT to XMPP session

XMPP is used for many IoT project, as it provides federation and identity for objects, allowing message routing. However, for smaller objects, XMPP is too heavy to be embedded directly and run directly on the object. In those cases, MQTT is often a good choice.

The goal of this project is to provide a connector allowing small devices to connect to ejabberd using MQTT protocol.

by Marek Foss at February 16, 2018 11:22

February 13, 2018

Ignite Realtime Blog

Openfire 4.2.2 Release

@akrherz wrote:

The Ignite Realtime Community is pleased to announce the availability of Openfire 4.2.2. This release signifies our continued effort to provide a stable 4.2 series release while work continues on the next release of Openfire.

The changelog denotes the full listing of Jira issues addressed in this release.

Here is a listing of sha1sum values for the release binaries, which can be found on our download page.

a5912ecef9b217cfc8523a1511a4dbd246c85b79  openfire-4.2.2-1.i686.rpm
452d0cc9be6ac6ca1d48a7cb9eb179288cb188f9  openfire-4.2.2-1.noarch.rpm
81319bf1a2d7043fe8a268928b74d96726958ed9  openfire-4.2.2-1.x86_64.rpm
d0efd045551b889b34b545536dd35dda25731879  openfire_4.2.2_all.deb
adbbdb95d689363c23a3a4f99299a984ea5edb36  openfire_4_2_2_bundledJRE.exe
affa39ff5f8b7dac4fef4c0006fe7368d13d7b0b  openfire_4_2_2_bundledJRE_x64.exe
4dd17b0c63e90c7da95d6cc693529267a8c2c33e  openfire_4_2_2.dmg
3e52c491eecae1d59e60d595b70cb3ae619a3ac0  openfire_4_2_2.exe
740b1e50f736d85672c5ecbe77006a69d9019723  openfire_4_2_2.tar.gz
8ee27f266891cc323f3bd5382286dc80c70549d0  openfire_4_2_2_x64.exe
107b2c77ccf020d254d5343c215beeb06045d3d0  openfire_src_4_2_2.tar.gz

Please let us know of any troubles you find by either visiting our webchat or creating posts in our Discourse Openfire Dev Forum. Thanks for using Openfire!

Posts: 4

Participants: 3

Read full topic

by @akrherz daryl herzmann at February 13, 2018 17:43

February 12, 2018

Peter Saint-Andre

Aristotle Research Report #4: ἀρετή

I'm starting to see that Aristotle's conception of ἀρετή (which I translate as thriving but which is more commonly translated as excellence or virtue) describes a deliberate practice of good judgment, reasoned choice, and planned activity resulting in a balance between extremes of action and emotional reaction in a particular domain of human life....

February 12, 2018 00:00

Aristotelian Questions

My intent in writing a book on Aristotelian ethics is not to present exactly what Aristotle said (I'll leave that to scholars such as J.O. Urmson in his excellent epitome Aristotle's Ethics), but hopefully what he meant and even more pointedly what he means for us 2300+ years later. The goal is to present my own direct encounter with Aristotle, unmediated by millennia of often misguided scholarship and mistranslation. (Ironically, we need some scholarship to do that, so separating the wheat from the chaff is necessary.) Here are some of the questions I'll be trying answer:...

February 12, 2018 00:00

February 11, 2018

Christian Schudt

Experimenting with Entity Capabilities 2.0

Enthusiastic XMPP developers probably already know about the new XEP-0390: Entity Capabilities 2.0 specification which is intended to replace the old one, XEP-0115.

I've recently implemented it and like to share my experience with it.

One of the requirements of the spec was to have both the old and new specification in place for a certain transition period.

It was pretty clear, that we need some kind of abstraction for both specs, which led to the following interface:

public interface EntityCapabilities {

Set<Hashed> getCapabilityHashSet();

byte[] createVerificationString(InfoNode infoNode);

String createCapabilityHashNode(Hashed hashed);

Both have a set of hashes (the old one only has one, which is itself), both can create a verification string from a set of features and identities and both can create a "capability hash node", each using their own algorithm.

The interface Hashed is implemented by the old Entity Caps and also by the XEP-0300 hash element. InfoNode is a disco#info query response (features, identities, extensions).

The class structure looks like this:

Processing Entity Capabilities

When processing a presence stanza or stream features with either or both old and new Entity Capabilities, the flow has become quite complex as you can see in the following flow chart. However, the good news is that it works with only the above interface. Take a look at how it's implemented right now:

Generating Entity Capabilities

The generating entity side is a bit easier:

I hope you liked this little presentation about how both XEP-0115 and XEP-0390 can be implemented behind the same interface.

Entity Capabilties 2.0 will of course be available in the next release.

by Christian Schudt ( at February 11, 2018 23:26

February 07, 2018

Paul Schaub

More XEPs for Smack

I spent the last weekend from Thursday to Sunday in Brussels at the XSF-Summit (here is a very nice post about it by JCBrand) and the FOSDEM. It was really nice to meet all the faces belonging to the JIDs you otherwise only see in the MUCs or on GitHub in real life.

There was a lot of discussion about how to make XMPP more accessible to the masses and one point that came up was to pay more attention to XMPP libraries, as they are often somewhat of a gateway for new developers who discovered the XMPP protocol. A good library with good documentation can help those new developers immensely to get started with XMPP.

During my stay and while on the train, I found some time to work on Smack again and so I added support for 3 more XEPs:

Ge0rG gave a talk about what’s currently wrong with the XMPP protocol.  One suggested improvement was to rely more on Stable and Unique Stanza IDs to improve message identification in various use-cases, so I quickly implemented XEP-0359.

XEP-0372: References is one dependency of XEP-0385: Stateless Inline Media Sharing, which I’m planning to implement next, so the boring lengthy train ride was spent adding support for XEP-0372.

A very nice XEP to implement was XEP-0392: Consistent Color Generation, which is used to generate consistent colors for usernames across different clients. I really like the accessibility aspect of that XEP, as it provides methods to generate colors easily distinguishable by users with color vision deficiency.

I hope my contributions will draw one or two developers who seak to implement a chat client themselves to the awesome XMPP protocol :)

Happy Hacking!

by vanitasvitae at February 07, 2018 14:05

February 04, 2018

Peter Saint-Andre

Aristotle: A First Encounter

Aristotle's views on living well and doing well - what the ancient Greeks called εὐδαιμονία or eudaimonia - are some of the most enduring insights into ethics ever put into words. Yet the deepest meaning of those words is usually obscured by efforts to translate and interpret Aristotle's thoughts. In part the problem is linguistic, in part it is cultural, but ultimately it is philosophical: ancient Greek world views, Aristotle's among them, are very far from our modern ways of thinking and feeling....

February 04, 2018 00:00

February 03, 2018

JC Brand

The 2018 XSF Summit

This year I again attended the XMPP Software Foundation's summit in Brussels. The summit spans two days and is held at Cisco's offices.

It's a rare opportunity to get community members together to discuss and make decisions around protocol extensions (the so-called XEPs). On the second day interesting discussions were had regarding the state of XMPP today, for example how and by whom its used, how to foster and support client development and the merits of federation (i.e. communication between different messaging providers).

We heard that XMPP is heavily used and respected within the Telecoms industry, and that there's a lot of "hidden" use of XMPP that even most of the Summit participants were unaware of.

The distinction was made between XMPP, which represents the protocol, and Jabber®, which represents the ideal of federated instant messaging as used by end users.

Besides what some people may think, XMPP is alive and well, and used extensively in many applications and in various sectors.

Jabber®, on the other hand, not so much. Mindshare has moved largely to siloed (i.e. non-federated and non-standardized) messaging apps like Slack et al.

The Tigase guys Andrzej Wójcik and Daniel Wisnewski gave a demo of the new Internet-of-things module of the Tigase XMPP server which also drew attention at the realtime communications stand at FOSDEM.

Minutes for the XSF Summit

I volunteered to be the minute taker this year, for which I used my favorite notes-taking app: Vimwiki.

With Vimwiki you can generate HTML from your wiki files, so I was able to make the notes available online roughly as I was typing them. which I did by pushing the generated HTML to a git repo and then pulling again via cron on a server and serving with Nginx.

Me writing the notes at the summit.

I N C E P T I O N (an original piece by Guus der Kinderen)

I also wanted to make the minutes available on the XMPP wiki, but Vimwiki's syntax is a little bit different than the Mediawiki syntax.

Pandoc came to the rescue, and with a one-liner I could generate Mediawiki files from all my notes.

So here are the 2018 XSF Summit minutes on the XMPP wiki:

Final thoughts

It was fun to meet up again with kindred spirits and to see some familiar and friendly faces from the XMPP world.

This year was also the first time I attended the fancy XSF dinner. I had the sea bass with endive and beurre blanc.

See you folks next year and thanks for all the fish!

The XSF summit dinner.

February 03, 2018 20:30

Peter Saint-Andre

Songs of Zarathustra Now Published

My short book on Friedrich Nietzsche, Songs of Zarathustra, is now published in paperback and ebook formats, and of course also on my website. Once again both the form and the content are unorthodox: I construe Nietzsche in a more humanistic way than most interpreters, and I do so in a cycle of 73 brief poems (including translations of some of Nietzsche's own verse). Neither aspect is likely to endear me to academics, but then I don't write for a scholarly audience - even though my books are based on a deep reading of the original texts....

February 03, 2018 00:00

February 01, 2018

Tigase Blog

Tigase XMPP Server v7.1.3 Released!

Tigase XMPP Server v7.1.3 has been released! Please review the change notes below to see what has changed since our last release.

by wojtek at February 01, 2018 01:31

January 30, 2018

Daniel Pocock

Imagine the world's biggest Kanban / Scrumboard

Imagine a Kanban board that could aggregate issues from multiple backends, including your CalDAV task list, Bugzilla systems (Fedora, Mozilla, GNOME communities), Github issue lists and the Debian Bug Tracking System, visualize them together and coordinate your upstream fixes and packaging fixes in a single sprint.

It is not so farfetched - all of those systems already provide read access using iCalendar URLs as described in my earlier blog. There are REST APIs to manipulate most of them too. Why not write a front end to poll them and merge the content into a Kanban board view?

We've added this as a potential GSoC project using Python and PyQt.

If you'd like to see this or any of the other proposed projects go ahead, you don't need to be a Debian Developer to suggest ideas, refer a student or be a co-mentor. Many of our projects have relevance in multiple communities. Feel free to get in touch with us through the debian-outreach mailing list.

by Daniel.Pocock at January 30, 2018 18:52