9 ms·
XMPP: A Communication Protocol for the Internet of Things
- rkagerer 7y agoUgh, is there a reason your web page doesn't work with my PAGEUP, PAGEDOWN or arrow keys?
- kiseleon 7y agoWorks fine in Firefox, but Chrome they don't work at all.
- millwork 7y agoThere's a circle numbered "8" in a very bad place, for web developers who modify browser shortcut keys and scrolling behaviour. There's a circle numbered "9" in that same bad place, for browser developers who refuse to allow end-users to easily stop keystroke-hijacking and scrolljacking with a simple preference checkbox. Explaining what I'd like to do to either group would probably land me in circle #5, and carrying it out would land me in #7.
- LeoPanthera 7y agoWhat browser are you using? Works fine in Mac Safari.
- Mountain_Skies 7y agoWorks in Edge. All one of us is happy.
- mattigames 7y agoIronically 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 7y agoIn 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.
- Kwpolska 7y agoThis is not a browser feature, this is a JS-provided thing. IME, the browser smooth scroll is pretty neat, but website-provided implementations suck.
- xellisx 7y agoWhy XMPP? Seems a bit of unneeded overhead.
- microcolonel 7y agoI never understood the desperate attempts to use XMPP, and the inevitable failure of EVERY attempt to run a popular messaging and/or presence application on it. If you want to IoT, why not just use NATS or something?
- ralls_ebfe 7y agoI am quite happy with xmpp being unpopular, as it means governmental pressure against E2E encryption will most likely never reach this place.
- Lazare 7y agoXMPP, a solution looking for a problem for over 20 years. :(
- userbinator 7y agoIndeed. 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.
- Lazare 7y ago> 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.
- jayd16 7y agoYou're not wrong but any solution has to start with sending a message.
- ken 7y agoXMPP seems to have failed, sadly, for its primary purpose. No major vendor uses it for (federated) messaging, even those that used to. And that's where there's a clear benefit to users. IOT vendors have a less clear use case and they've shown they're not particularly interested in openness or compatibility (or security). Why would this be any more likely to succeed for IOT than it did in messaging? You're right that it has to start with sending a message, but there's no incentive for companies in this industry to ever take step 2 here.
- K0SM0S 7y agoPeople 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.
- auscompgeek 7y ago> apparently the whole thing would be better off rewritten in a new form It seems to me that this is basically describing Matrix [1]. Funnily enough, since its current transport is HTTP, it looks like by the time HTTP/3 becomes a thing, network hopping would be solved essentially for free. [1]: https://matrix.org https://matrix.org
- geoah 7y agoWas wondering what you mean by network hopping. Assuming that by http3 we mean quic, does it provide some functionality for message routing that I’m missing? I’m most likely either misunderstanding what you mean by hopping or completely missing a feature if quic. Thank you
- auscompgeek 7y agoFrom what I understand, QUIC allows for IP roaming, much like how mosh does.
- RX14 7y agoMatrix is a fundamentally broken protocol held up by the prowess of it's UI design team.
- thrower123 7y agoI 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?
- stefan_ 7y agoAt this point, please just let XMPP meet it's long overdue death.
- Andrew_nenakhov 7y agoRumors of XMPP imminent death are greatly exaggerated.
- BrianHenryIE 7y agoMy 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.log.html https://brianhenryie.s3.amazonaws.com/2019/door_opened.xmpp.... 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 7y agoFor 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/
- sriku 7y agoXMPP 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.
- sudoaza 7y agoAny 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 7y agoIdeally 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 7y agoyes, 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.
- bborud 7y agoI 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.
- mikhailfranco 7y agoXMPP 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 7y agoDo 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 7y agoYes, Erlang was designed for fault-tolerant distributed scalable concurrent chat :) There is a good Erlang MQTT broker: emqtt / EMQX.
- contingencies 7y agoFar 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.
- jsilence 7y agoOfftopic: what are your thoughts on PJON (pjon.org)?