Handling Multiple Presences in Openfire


XMPP is a terrific protocol for communications based media. For P2P networking, it is the or at least among the most robust. Well supported distributions like the ultralight eJabberd and extensive though somewhat resource intensive Openfire exist which implement the 20 year old protocol to a tee.

Still, there is that nagging need to detect multiple statuses at once to avoid overburdening resources with what could be thousands of extra requests. This article examines how to poll for multiple presences at once by extending Openfire’s presence service with a JSON plugin.

Code is available on my Github account.

Presence API

JiveSoftware, creator of the presence plugin, created a decent and simple presence API whose code is available on Github.

This API is easy to extend.

Using my plugin

My plugin simply adds a few lines to the PresencePlugin class and creates a JSONPresenceProvider class that can be used to return one or more statuses.

The available options are:

  • jid: Takes presidence and obtains the status of a single JID
  • jids: A semi-colon (;) separated list of jids of which to obtain statuses
  • type: This should be json to obtain the list of statuses

For instance:


This allows GET requests to be kept fairly simple. The same parameters may be used in a POST request as before.

Values are returned in a JSON object containing an array of user information objects:

     "user": "username",
     "jid": "username@server",
     "status": "[available | unavailble | etc.]"
  "success": [true | false]


Building the plugin is simple on Linux (or Windows). Simply execute the following on Linux at the root of the project.

 mvn clean package
 cd ./target
 mkdir build
 mv presence*jar ./build
 cd ./build && jar -xvf presence.jar && jar -xvf presence-X.X.X.jar
 mv *jar ../
jar -cvf presence.jar .

This will combine the dependency and code jar into a single jar which can be placed in the plugins folder of Openfire. Openfire automatically detects new plugins.


Extending Openfire is simple. This article reviewed my modification to the presence plug-in allowing users to obtain the status of multiple JIDS at once through JSON.

Private Immutable Configuration Hack in Python

Pyhton is notoriously not secure by default. However, it is still possible to generate a level of security through name mangling and other means. This article explains how to use name mangling, the singleton pattern, and class methods to create more secure access to configuration in Python3.

Singleton and Class Methods

Setting up a singleton in Python is simple:

class ChatConfig():

    __config = None

    class __Config:

        def __init__(self, config):
            self.config = config

    def set_config(cls, config):
        if cls.__config is None:
            cls.__config = config

    def get_config(cls):
        return cls.__config


The internal class and variable are mangled so as to make the variable itself private. This allows a single configuration to exist across the different packages while keeping the internal variable private and allowing for the variable to be set only once.


Python is not entirely insecure. It only takes code. This article offers an example of a way to set a variable once and share the setup among multiple packages.


There are a few old debates with little interest given to them. This article examines the effectiveness of the XMPP and AMQP protocols and provides recommendations for areas of usage.

My own startup is using both for different reasons, XMPP serves as our bi-directional communications and multimedia backbone while AMQP through RabbittMQ serves as our content provider, uni-directional communications tool, and task queue engine (through Celery and our custom backend tool.


Xmpp is now going on two decades old. It is solid and broad. However, it is XML based so it may be slow. Still, Simplr Insites, LLC chose XMP over MTQQ since it can handle both audio/video and chat communications.

XMPP communicates using stanzas which wrap different XML tags containing a wide array of information. The link above provides an excellent starting resource for learning XMPP.

XMPP offers:

  • bi-directional communications
  • p2p and multi-user communications
  •  information regarding presence and status
  • supports video and audio through Jingle or another client
  • large scale servers such as eJabberd and Openfire
  • has the strophe.js library for implementation

XMPP is not:

  • a great solution for the producer consumer pattern
  • requires decent hardware and is easy to abuse (overuse of the presence component)


While we found XMPP to be a great tool for communications and multi-media. We also moved to task queuing upon finding the actor method to be too cumbersome in Python.

XMPP requires passing a large amount of XML and has no subscribe-able queues. AMQP libraries, these are protocols, offer robust structures and implement many enterprise patterns which are useful in data processing.

AMQP solutions tend to offer:

  • robust enterprise patterns
  • robust flow processing
  • task queuing libraries with speeds slightly slower than Akka (the best-in-class for everything library)

AMQP solutions tend to not offer:

  • state and presence support without extensive implementation by the developer
  • robust bi-directional queues for large scale communications (there are bi-directional queues)
  • audio/video support


If considering moving away from Scala/Java and thus the actor model and towards different platforms while requiring proven and robust real-time frameworks, XMPP libraries and AMQP libraries should be considered for their advantages. XMPP solutions work well in communications and real-time, non-flow based processing. AMQP solutions work well, not as well as Akka, in flow processing.

Opinion: Why Self-Driving Cars Will Fail in Customer Service

All to often, we are faced with a technology we feel is innovative and will break down an entire economy. That seems nearly certain with delivery, right? Wrong. If anything, the next 20 years will see a critical failure in an industry better suited to long haul trucking, train driving, and other even more mundane or menial tasks.

So many decent initiatives in technology fail because they do not consider the most important end games, people, security, and cost. In self-driving delivery game, that comes in the base pay vs. maintenance and LIDAR debate, security, and the customer services side.

There is an important reason to consider delivery as the improper industry for self driving cars, customer service.

No matter how many times a person is called, how hard, the door is knocked, or how friendly the front desk is. 25% or more of deliveries require problem solving well beyond route finding to provide both quality customer service or just complete a sale. This is well beyond the basic people enjoy interactions with others more than vehicles, another crucially important element.

Even a UPS driver will find that person just too completely unaware of their surroundings or un-trusting of their phone to respond to the door.

There are also the slew of factors not capable of being solved by a car that cannot fit through the front entrance, the factors that can drive the average tip over $5.

  • some high end establishments require talking to the front desk and arranging pickup due to ‘security’ reasons
  • some people require two or three approaches to reach
  • there are an increasing number of gated neighborhoods hiding miles of housing
  • People need an outlet to complain and the busy storefront will just hang up on them. They accomplish satisfaction by lodging a complaint with your driver.
  • stores tend to shift blame for failed quality control to drivers as near independent contractors to avoid the blame being placed on the store
  • many people, whether they consciously realize it or not, actually order delivery because someone comes to their door with good etiquette, a smile, and an assurance that their order is 100% correct
  • people tend to feel more secure when a trusted agent is in control of their goods and makes this fact known.
  • wrong orders made by everyone and everything are caught with good quality control and pizza chains follow CASQ better than most IT companies to achieve near 95% success

Imagine if every store lost even 15% of their business. Chains and restaurants paying drivers are already stretched to their capacity in a delivery radius that cannot be changed. That 15% will hurt and possibly close a store.

Consider, next, the lesser factor, maintenance and vehicle costs.

The cost of maintaining an electric car is, in fact more expensive than the cost of maintaining a fleet of drivers. If the average drive is paid $9.50 on average ($7.25  if tips are not equal to this price or you work for a better store attracting better quality employees + $10.25 per hour in store + $1 per mile), and the cost of LIDAR maintenance is roughly equal in addition to the cost of additional IT support staff and technicians, the store loses money.

That is not to mention the expenditure per car. The base delivery vehicle in the tech company’s target industry is $0, the driver provides the vehicle. The cost per vehicle for  a fleet of 13 cars running constantly is much higher even if by the time of writing this that cost goes down significantly. There is the $17000 base per vehicle, the breakdown of even electric vehicles and their maintenance at $120 per month, any electricity at $30 per vehicle per month, the cost of wifi at $100 per month per vehicle, $500 for an entire phone line setup for your fleet per month, and the cost of  wear and tear at $.50 per mile due to the technical nature of the vehicle. Gasoline costs will range between $20 and $40 per night if the vehicle is fueled by gasoline. A new car will be required every 4 years. Repairs can add thousands of dollars per year not considering LIDAR as the vehicle ages.

Finally, let’s consider security. In the past few years, the military lost at least 2 drones to Iran who simply launched a DDOS attack on them. How hard is it to lob requests at a cars network? Not difficult. Ask Charlie Miller.

If every drone carried $1000 in cash on a good day and there were dozens of drones to hack, that is more money than even a help desk employee makes in an entire year. Most attacks can be bought from the dark web. There isn’t as much skill involved in hacking as there used to be.

In sum total, delivery is the wrong industry to target self-driving vehicles towards.

There is a reason delivery drivers in my city, Denver, can earn $21- $25+ per hour, this is my part time go to when starting a company so I know this is true. That reason is not the store which usually pays $9 per hour on average per driver. The reason is the bizarre nuances of the delivery game.

It does not matter whether you are driving for brown (UPS), FedEx, or Papa Johns. That extra mile can make your business.

The right industry will always be long haul trucking, train engineering, and, to a lesser extent, air travel. Anywhere the task is more monotonous and there is no customer service, people are more replaceable. For the food industry, that means the back of house.