
XMPP: Swiss Army Knife for the Internet of Things - DyslexicAtheist
https://blog.securitycompass.com/xmpp-swiss-army-knife-for-internet-of-things-iot-9eff783c44ba#.6fzzosfqh
======
KaiserPro
For IoT XMPP is utterly wrong. Yes, some planes use it for a message bus. But
that was silly then as it is now.

most IoT application have to worry about both power and network efficiency.
XMPP is neither light nor concise.

For example, I'm building a sensor network that needs to report a range of
sensors every n seconds. I _could_ use XMPP, but first I'd have to figure out
how to make a decent XML parser in < 2kb or ram. Let alone a full IP stack.
The cheap radio I have has an MTU of 60 bytes.

None of this is going to fly, for what is effectively: Node Address: 1: 56.456
2: -6704 3: 80

If we ignore the <node><sensor><value> boiler plate that will instantly blow
our packet budget, lets look at how the values are represented as: ascii. so
sensor 1 which was a 4byte float is now a 6 byte varchar.

We are of course ignoring the address which is going to be at least 16 bytes.

We haven't even touched on the server requirements either. Can you name a
decent XMPP server? I can't they are all finicky and nasty.

So, no XMPP is not the swiss army knife of IoT, because its too large, too
power hungry and just a massive pain in the arse.

Anything that uses ascii representations of numbers is probably a bad fit for
IoT

~~~
ge0rg
Your argument only shows how wide the field of "IoT" is. For embedded sensor
networks, your arguments apply without restriction.

However, for things like "smart lightbulbs" or other devices connected to the
cloud (not that I would endorse such things), where you need a scalable
infrastructure for secure bidirectional communication between nodes deployed
somewhere and your frontend application, XMPP provides a solid base.

Besides, embedded nodes are getting more and more powerful (consider the
ESP8266, which runs IPv4 and TLS and could easily handle XMPP), and it
provides huge benefits to have a common end-to-end protocol that is not based
on periodic polling like HTTP.

~~~
KaiserPro
The ESP* sucks power, which means bigger PSU, or in the case of lightbulbs, no
config support when the light switch is off. Making a PSU that is both small
and efficient for both low current draw and high is rather hard.

Protocol design is trivial for something like a light bulb, compared to the
cost of designing the device, and making the scalable backend (and no XMPP is
no shortcut for that.

I know how wide the IoT field is. I also know the sheer volume of shite that
is being produced. Most of the Wifi products will die a horrid death. replaced
by something better and more suitable to low power usage.

Failing that something more secure, after a rash of home fires caused by a
terribly insecure system that was able to be turned off and on again
repeatedly until it caught fire.

~~~
0xdeadbeefbabe
Would you suppose it will be something like bluetooth keyboards getting
replaced by a usb dongle that talks to your keyboard using some other radio
protocol that isn't bluetooth?

~~~
KaiserPro
There is nothing inherently wrong with bluetooth. So long as you are prepared
to put work in over the top to handle security.

Bluetooth LE has a reasonable power profile, and the advantage of being about
to interop with lots of other things.

------
INTPenis
Now I love XMPP and before that I was even building website support apps with
IRC. But it seems strange now in 2016 to be looking at XMPP for the new IoT
wave because there are plenty of other interesting protocols available.

AVS from Wire Swiss for example.

Websockets that is being used by slack, signal and maybe more.

Maybe fresh eyes, fresh code is a positive thing if we're going to move
forward. Instead of using XML. ;)

~~~
ungzd
What's wrong with XML? It's more human-writable than json, more flexible, less
quirky than yaml (which I even cannot write without constantly looking into
specification). Binary protocols are not better too, in age of lightbulbs
running linux.

~~~
_ZeD_
>>> What's wrong with XML? It's more human-writable than json

wait, what?

~~~
mgamache
XML is more readable to people that learned XML first (like me). The younger
crowd reads JSON better then XML. Just a matter of perspective. The only
argument for XML is that you see the closing tags to know where the element
ends. However, I avoid using XML for anything these days.

~~~
jeremiep
They're not the same.

Both YAML and JSON map to data structures in your program; scalars, sequences
and mappings.

XML on the other hand maps to.. a DOM! You've still got to normalize that into
what your program expects. SAX is not any better.

Everytime I land in a project using XML I know I'll spend orders of magnitude
more time dealing with data than if the project had used YAML or JSON.

~~~
Mikhail_Edoshin
What if you need DOM-like data, like formatted text? And "formatted" may mean
something relatively simple, like a a basic math formula or even a subscript?

~~~
jeremiep
Store it as a plain string. Most GUI libraries I know of will accept that type
only for their rich text controls anyways.

If I need to work on the data I'll parse it into a data structure. Then I get
something like ["Hello " [:b "World!"]] where I can leverage the existing
functions operating on data in order to manipulate it.

------
mrmondo
We use XMPP + OTR internally @Infoxchange and it's been really fantastic for
us.

It's cross platform (although the Windows clients aren't that pretty to be
honest, but we don't have many machines running Windows anymore), it's
reliable, we can run it on site and ensure that secure chats are not logged
(i.e. 1 on 1 chats aren't logged, rooms are just for history when someone
joins), it integrates with monitoring / alerting and general operational
notifications such as alerts or notifications from Nagios, GitLab CI builds,
Application releases, Errors discovered in logs, Changes to oncall rosters,
'interesting' stats from load balancers, global notifications, secure file
transfers and the list goes on.

One thing I keep meaning to get around to implementing for everyone is a web
interface for say people that are volunteering / on a temporary device etc...

------
roymurdock
If you really want to figure out which messaging protocols are being used for
"IoT" deployments, looks at the leading IoT device management services
providers: AWS IoT and Azure IoT Hub.

AWS IoT uses MQTT and HTTP (over WebSocket).

Azure allows customers to choose between MQTT, AMQP, and HTTP, but suggests
that its users choose AMQP as a good general-purpose protocol.

HTTP is usually used for devices/machines with external power supplies that
are sending high volumes of relatively complex data. MQTT/AMQP are generally
used for nodes/sensors with internal power supplies that are sending low
volumes of telemetry data.

Neither service supports XMPP natively which should give you a good indication
of how suitable it is for IoT applications.

~~~
azdle
What measure do you use to determine that AWS and Azure are the leading IoT
providers? (Genuinely curious.) I know that they're large infrastructure
players who are doing IoT, but are they also leaders in the IoT space?

~~~
roymurdock
Revenue share of the overall "IoT Services" market, which includes
connectivity, remote monitoring & control, storage, and data analytics
services.

Pub/sub protocols like XMPP, AMQP, MQTT are generally used in solutions that
are sold into the remote monitoring & control services market.

There is not "IoT market" though, so it's impossible to say who is a leader in
the IoT space in general. It depends on the technology category. Eg
NXP/Freescale is a leader in the IoT processor space, Wind River/Green Hills
are leaders in the IoT OS space (RTOS), Amazon/MS are leaders in the IoT
services space.

------
joshstrange
I wondered how common XMPP was for IoT, my IR Hub (Hub for IR + RF remote) for
my TV/Media center speaks XMPP and thanks to some people who reverse
engineered it I was able to drop in a library and start sending it commands
pretty easily.

~~~
ge0rg
It also looks like XMPP is used in some home alarm systems [0]. Unfortunaltey,
the developers there did too many things wrong, not only security-wise but
also in how they used XMPP [1].

[0] [http://www.heise.de/ct/artikel/Home-security-systems-
hacked-...](http://www.heise.de/ct/artikel/Home-security-systems-hacked-
with-1234-password-3248831.html)

[1] [http://geekplace.eu/flow/posts/drafts/xmpp-iot-
antipatterns....](http://geekplace.eu/flow/posts/drafts/xmpp-iot-
antipatterns.html)

------
JoLi
Getting sensors, data and actuators to work for ONE usecase has always been
easy. just use what you need.

The problem is still how you get these different company systems (silos) to
cooperate. "how can you securely give the inside temperature from your alarm's
smoke detector and feed it to the heating system to act upon". These services
are provided from two different IoT companies.

Here XMPP is the simple and perfect match. Any device in any company can talk
to any other device in any other company just as easy as you send email to
some one you know in another company.

These companies can solve and hide there internal legacy systems with
x500,modbus,coap, binary junk or whatever they need but when you pass the
company xmpp server you pack it in a nice letter for others to easily
understand what you are saying. With encryption and certificates. And you
don't talk to servers/endpoints you don't do business with.

How can NEST homes talk to openHAB? Zigbee legacy with new coap things? And
how can they all participate in a smart city ?

~~~
detaro
And then everything sends a different payload in their XMPP messages, and
everything is broken again. XMPP is a possible part of a solution, but not
_the_ solution alone.

~~~
JoLi
Thats why the XMPP
[http://www.xmpp.org/extensions/](http://www.xmpp.org/extensions/) is there
defining the payload. reading values
[http://www.xmpp.org/extensions/xep-0323.html](http://www.xmpp.org/extensions/xep-0323.html)
writing values
[http://www.xmpp.org/extensions/xep-0325.html](http://www.xmpp.org/extensions/xep-0325.html)

No there will always be several solutions interacting for different usecases,
XMPP fits very well in some.

------
betimsl
Also, MQTT.

~~~
IshKebab
MQTT suffers from not having a real RPC system. Eventually with pub/sub you're
going to end up with a "request ID" that is copied in replies, and at that
point you've just invented a really shitty RPC system.

Better to use one that was designed from the start for RPC (and that also
supports streaming/push/pubsub as you'll want that too). I recommend gRPC (if
your IoT think is beefy enough to support HTTP2), or something lighter like
CapnProto's RPC.

------
babayega2
Any good Python XMPP library you guys may know ?

~~~
goffi
Twisted with Wokkel
([https://github.com/ralphm/wokkel](https://github.com/ralphm/wokkel)). It
looks unmaintained, but a Python 3 port is on its way, and we are using it
actively

SleekXMPP ([http://sleekxmpp.com/](http://sleekxmpp.com/))

and it's asynchronous fork Slixmpp
([https://pypi.python.org/pypi/slixmpp/1.1](https://pypi.python.org/pypi/slixmpp/1.1))

------
erikb
Do you know about the TR-069 standard?

------
lasermike026
Use it right. It's not a message bus. XMPP is a chat protocol. Message
delivery is not guaranteed.

~~~
rakoo
Same old, same old: _Core_ XMPP doesn't provide guaranteed delivery, but
Extensions do, and today XMPP is more or less unusable without Extensions. I'm
talking about XEP-0184
([https://xmpp.org/extensions/xep-0184.html](https://xmpp.org/extensions/xep-0184.html))
which is pretty much used in all maintained clients and servers. Note that
XEP-0184 provides end-to-end delivery receipts; if you're only interested in
hop-to-hop delivery, you're going want XEP-0198. I believe this one is a bit
less widespread though.

~~~
SamWhited
For guaranteed delivery you really want XEP-0198
([http://xmpp.org/extensions/xep-0198.html](http://xmpp.org/extensions/xep-0198.html))
which effectively provides TCP like ack's and session management at the wire
protocol level. It's fairly straight forward to implement, and works really
well for both chat and message bus style applications where acks are required.

~~~
rakoo
I think it really depends about what we mean by "guaranteed delivery". If you
are more interested in the infrastructure and consider each piece as a
different part then yeah, hop-to-hop reliability is important to you and you
want XEP-0198. That's like "guaranted delivery of a packet". If however you
are more interested in the application that sits on top of the infrastructure,
then what you really care about is whether the recipient did receive your
message: that's XEP-0184. That's more like "guaranted delivery of a message".

Of course both are complementary (and to me both should be implemented)

