
XMPP: A Communication Protocol for the Internet of Things - liotier
https://www.briskbraintech.com/xmpp-a-communication-protocol-for-the-internet-of-things/
======
Lazare
> XMPP supports federation, which means that devices from different
> manufacturers connected to different platforms can talk to each other with a
> standard communication protocol.

The idea behind federation with XMPP for humans (aka, Jabber) is that my
friend can have an account on server A (friend@a.com), and I can have an
account on server B (me@b.com), and we can tell each other our addresses
(because we know each other in real life), and then get messages to each
other, which is cool, because we're friends, and both know English, and so
will be able to meaningfully communicate. Not bad!

The idea behind federation with XMPP for IoT devices is...what? That my smart
lighbulb can be talking to a control server run by Phillips, and my smart
fridge will be talking to a server run by Samsung, and...they have no idea
each other exists, have no ability to address each other, and have no ability
to generate messages the other can consume, because they're completely
different devices, from different manufacturers, with different protocols?
Even if the fridge wanted to tell the smart lightbulb to turn on when the door
is open, they need a shared "lightbulb control protocol", no? This feels like
claiming email lets any two people on Earth hold a meaningful conversation;
just because you can transport the message to the recipient doesn't mean they
can understand the language of the message.

How does federation help here? Or any other XMPP feature? There's just no
attempt to tie any XMPP feature or characteristic to the nominal use case.

~~~
netsharc
It'd be cool if the fridge just announces "my door has just been opened", and
a controller decides what to do with the lightbulb (or should the logic be on
the bulb with some parsing like if (device == "refrigerator" and location ==
my.location and component == "door" and state == "open") { ... }?)

It'd be cool if the sunroof can open when it gets the message from the weather
monitor that it's a nice day out, and the AC can switch off when it gets the
message that the sunroof is opening...

~~~
Aloha
Federation won’t solve tha.

Heck, the best way for your house is to use multicast, with a unique IP for
each endpoint type, and a unique port for each distinct endpoint within the
type.

The endpoint IDs could even be self assigned, with the idea that you’d only
really need a gateway for use outside the home. Standard but extendable
protocols can be developed too, so everything can interop but still include
custom stuff beyond the standard.

~~~
toomuchtodo
Apple’s Bonjour protocol?

~~~
Andrew_nenakhov
Bonjour is actually an XMPP extension.
[https://xmpp.org/extensions/xep-0174.html](https://xmpp.org/extensions/xep-0174.html)

~~~
duskwuff
Bonjour is Apple's name for their implementation of mDNS service discovery. It
doesn't involve XMPP.

XEP-0174 is a peer-to-peer extension to XMPP which uses mDNS ("Bonjour") to
discover other clients on a local network. For a while, Apple had an
implementation of this in iChat.

~~~
Aloha
I think they still do, in Messages

~~~
duskwuff
Not anymore. I believe XMPP support was finally removed from Messages in macOS
10.14. (Almost nobody noticed.)

------
K0SM0S
People who worked extensively with XMPP in the past told me that it just
wasn't cut for the current paradigm, with real-time and asynchronous
communication, network hopping (mobile, wifi, etc) and just the way things
evolved since... 1999. There were some changes planned but apparently the
whole thing would be better off rewritten in a new form, and the effort never
really kicked off, much like the protocol itself faded from use as we moved
towards more and more hybrid networks and uses.

It's a sad realization, I always thought XMPP would save the day some day, but
apparently there's a lot of work between now and there. And it might just as
well be called something else. I think the latest move towards HTTP/3
enforcing SSL1.3 is one way to envision a fully secured web, 10 years from
now.

~~~
Andrew_nenakhov
We work extensively with XMPP, so I can speak with some authority on this
topic.

It is true, the protocol was invented in 1999 for then-relevant conditions.
There are good things - everything that is related to federation works
remarkably well, and bad things - multi-device usage, reconnection, etc.

However, the very thing that is mostly panned here by Matrix proponents -
modularity and extensibility - allows to uplift it for the modern world.
Actually, we recently did just that, by developing a bunch of new protocols
and implementing them on an XMPP server. I'll spare the verbose details, but
in short, we redesigned reconnection process from a resumption of an XML
stream to restoration of messenger state, and it works rather well. That set
of protocol extensions greatly helps to improve the performance of our
upcoming XMPP client.

~~~
e12e
Who are "we" and what client/projects are you working on? Are these changes
new public XEPs that others can/will implement?

~~~
Andrew_nenakhov
"We" are makers of Xabber, a popular XMPP client for Android. It had gotten a
bit stale lately: a few years ago we figured out that XMPP improvement should
start on the server-side, so we diverted all our resources towards creating a
set of protocol and implementation it on a server, an alpha version of which
was released last month, it has a built-in an insanely great web version of
Xabber, which likely offers the best XMPP UX ever, on any platform. We also
plan to release an iOS version of Xabber soon - this month or next.

Our protocols are public, and we plan to submit them to XSF, once we're done
translating them from our native language. Hopefully, these XEPs would be
supported one day by other clients. We believe they are crucial for XMPP
future.

~~~
e12e
Very interesting. Which server are you enhancing? Do you provide xmpp hosting?

~~~
Andrew_nenakhov
We forked ejabberd because it's the best existing XMPP server. We do provide
XMPP hosting (at xabber.com/xabber.org domains), but currently, it's just
standard ejabberd, a transition to our own build will come later, hopefully,
this year. We also plan to provide domain hosting.

------
BrianHenryIE
My GE Microwave uses XMPP for its control. It sends its status using a JSON
object of hexadecimal addresses and values:
[https://brianhenryie.s3.amazonaws.com/2019/door_opened.xmpp....](https://brianhenryie.s3.amazonaws.com/2019/door_opened.xmpp.log.html)

I started reverse engineering it but haven't quite finished. The plan is to
connect it to Home Assistant and negate any need to communicate outside my
house. To get the above output, I wrote a tool for logging the communication
in iOS:
[https://github.com/brianhenryie/xmppframeworklogger](https://github.com/brianhenryie/xmppframeworklogger)

------
defanor
For some reason the article doesn't mention it, but there is a few retracted
XEPs for IoT (sensor data[0], provisioning[1], control[2], etc). I think it
would be neat if they've incorporated Semantic Sensor Network Ontology[3] and
were actually used. But it seems that in practice there are mostly custom and
unspecified binary protocols, with inherent TOCTOU issues, awkward integrity
checks, and with no security measures (anecdata, based on 7-8 years of dealing
with various devices that can be classified as IoT).

Regarding the use of XMPP for it, as pointed in other comments, it indeed
looks like unnecessary overhead, but I think it is quite similar to using HTTP
for transfer of things other than hypertext: not a perfect fit, but already
has good software support, standards, and additional features that are useful.
And perhaps more importantly, no wheels to reinvent poorly and hide from
customers.

[0]
[https://xmpp.org/extensions/xep-0323.html](https://xmpp.org/extensions/xep-0323.html)

[1]
[https://xmpp.org/extensions/xep-0324.html](https://xmpp.org/extensions/xep-0324.html)

[2]
[https://xmpp.org/extensions/xep-0325.html](https://xmpp.org/extensions/xep-0325.html)

[3] [https://www.w3.org/TR/2017/REC-vocab-
ssn-20171019/](https://www.w3.org/TR/2017/REC-vocab-ssn-20171019/)

------
xellisx
Why XMPP? Seems a bit of unneeded overhead.

~~~
userbinator
Indeed. XML itself is nontrivial to parse and the "infinite" extensibility is
just overkill for probably 99% of the time I've seen it used, XMPP included.

As an aside, this article seems quite devoid of actual content, bordering on
spam IMHO. The title mentions IoT but the term appears only _once_ in the
entire article at the end, in a vague "XMPP is for messaging and IoT also
needs messaging, so.... XMPP and IoT!" way. This is the sort of page that
clogs search engine results with useless non-content.

~~~
duskwuff
XMPP's own extensibility is a huge stumbling block as well. Almost every major
feature of the protocol is implemented as an optional extension, so it's very
difficult for clients to rely on anything being consistently available.

~~~
upofadown
Well you have a choice. You make a protocol extensible and live with the fact
that people are eventually going to extend it. Otherwise you choose a
different fixed protocol for each and every task and live with the fact that
you will never get any level of interoperability at all.

If one complains about extensible protocols, one should be willing to come up
with some other approach that works.

------
sudoaza
Any IOT protocol should be lightweight and ideally UDP, 3 ways TCP handshake
takes too long, XMPP is supper verbose. Use HTTP like the mozilla IOT thing
for that... MQTT QOS 0 is pretty ok.

~~~
nomel
Ideally you absolutely don’t use UDP if you care about data delivery, or you
just reinvent a poor implementation of TCP. I want my smart light to come on,
my doorbell to ring, and my dryer to tell me the cycle is complete 100% of the
time.

~~~
sudoaza
yes, if you care about delivery you also dont use MQTT QOS 0, use 1 or 2. FOr
sensors that report often (and you can loose some packets in the middle) or
idempotent actions that you can repeat should be fine though.

------
stefan_
At this point, please just let XMPP meet it's long overdue death.

~~~
Andrew_nenakhov
Rumors of XMPP imminent death are greatly exaggerated.

------
mikhailfranco
XMPP was too heavy even for its intended purpose - chat.

MQTT is the way to go for IoT.

MQTT at the edge, Kafka at the core.

~~~
Andrew_nenakhov
Do you know a better "less heavy" solution for federated chat? Matrix? That
matrix which server can handle 50x fewer users than ejabberd on similar
hardware?

~~~
mikhailfranco
Yes, Erlang was designed for fault-tolerant distributed scalable concurrent
chat :)

There is a good Erlang MQTT broker: emqtt / EMQX.

------
bborud
I really wanted XMPP to work, but it was a hard protocol to like. It ticked a
lot of the right boxes on paper, but in practice it didn't always lend itself
to efficient or neat implementation. It didn't feel like it was designed by
programmers for programmers.

(A feeling I'm very familiar with these days as I work in the telco business -
an entire business that knows fuck-all about how you create standards that
lend themselves to clear implementation)

It kind of started off on the wrong foot by using XML. XML is too complicated.
There is too much freedom, and freedom to screw things up. It also puts too
much flexibility and semantics in the wrong place. Complexity, gnarly
performance characteristics and design dilemmas abound.

And not paying attention to important detail such as cheap and predictable
message framing is such a boneheaded mistake - you have to pay attention to
things that make implementation awkward. It is the first problem you need to
solve when creating a somewhat performant implementation and you find yourself
stumbling out of the gates having to compromise. Sometimes by having more than
one XML parser - one to do framing and one to deal with messages.

It has been many years since I worked on anything XMPP-related. I have no idea
if XMPP has improved (probably a good idea to spend a weekend playing with
XMPP again to have a look). But if it still depends as heavily on XML, it is
not for IoT.

Please do not put it in IoT devices. Please, please, please.

IoT spans from devices with systems more powerful than your desktop computer
(in kilowatts and MIPS) to small systems that have perhaps hundreds of BYTES
of RAM.

While microcontrollers are getting bigger, with some having megabytes of flash
and even hundreds of kilobytes of memory, the most interesting growth areas
are in devices that use very little power. Ofte as little as a dim LED. And
when they sleep, which many do most of the time, they need to draw so little
current you'll spend many sleepless nights poring over datasheets to figure
out if there's a voltage regulator out there that doesn't blow your entire
energy budget.

For the big systems you can do whatever you want. Go crazy. For constrained
devices, not so much.

If you need some infrastructure for communication that is to be useful, you
have to be able to scale down. Paradoxically scaling up is easy - scaling
things down is hard. It tends to make systems grow ugly warts when you create
adapters all over the place to translate between domains.

And it isn't just about size. It is about asymmetries in communication
patterns as well.

More primitive protocols are quite popular (like MQTT and CoAP). Things that
can be done with more or less constant memory and CPU requirements. But
they're not necessarily great for everything. And people do not necessarily
understand how to design with them. They tend to exist at the edges of systems
and concern themselves with hauling data back and forth between constrained
devices and the luxury world of more powerful computers.

Then there's the traditional embedded world where it feels like you are always
dealing with hermits that got cut off from the rest of the world 25 years ago.
Things are getting better as the embedded world is gradually being invaded by
more mainstream programmers, but it is painful to watch. People who aren't
very good at software versus people who aren't very good with constraints.

What is almost shocking is when you get a peek inside the kimono of different
embedded companies / chip manufacturers and you realize the stark difference
between where they are in a developmental sense. Some understand where they
need to go, and mainly struggle with getting there - others just have no clue
how far behind they are from where they need to be.

And then mix in politics, companies that are hysterically protective about
their IPR, and the time pressures that exist, and you have multiple culture
collisions at once.

I can understand the attraction of XMPP. I really can. But if you ask me we
need to do messaging over again. And it has to do less - not more.

------
contingencies
Far too verbose to take seriously. Small devices don't have enough memory to
store all those strings, or do complex parsing. Then again we are discussing
'IoT' which is sort of like the tooth fairy... so basis in reality is
optional.

------
sriku
XMPP for this purpose feels like an overkill. Open Sound Control might be an
interesting alternative. After all, like MQTT, it originated in a world where
equipment needed to talk to each other.

------
jsilence
Offtopic: what are your thoughts on PJON (pjon.org)?

------
thrower123
I guess if you have one really bad idea, you can't make it any worse by
mashing it up with another really bad idea, right?

------
rkagerer
Ugh, is there a reason your web page doesn't work with my PAGEUP, PAGEDOWN or
arrow keys?

~~~
mattigames
Ironically the fault is due some code intended to make scrolling smoother but
some bug is making it so instead it doesn't scroll at all (source:
[https://i.imgur.com/XIewJXS.png](https://i.imgur.com/XIewJXS.png))

~~~
userbinator
In practice, "smoother" almost always means laggy and sluggish. It's one of
the things I always turn off upon a new install of a browser.

