5 ms·

> XMPP supports federation, which means that devices from different manufacturers connected to different platforms can talk to each other with a standard commun

by 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 ago
You're not wrong but any solution has to start with sending a message.
- ken 7y ago
  XMPP 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.
  - stephenr 7y ago
    Most major vendors did use it, and likely still do internally, but with federation turned off. If you have a billion “users” using a working chat system and the concern is “with federation they can chat with outsiders and we can bleed users” you don’t just drop the whole thing, you turn off federation and prevent third party client logins.
netsharc 7y ago
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 7y ago
  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 7y ago
    Apple’s Bonjour protocol?
    - Andrew_nenakhov 7y ago
      Bonjour is actually an XMPP extension. https://xmpp.org/extensions/xep-0174.html https://xmpp.org/extensions/xep-0174.html
      - toomuchtodo 7y ago
        Interesting! Thanks for sharing this!
      - duskwuff 7y ago
        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.
zamalek 7y ago
I assume that, assuming you can get custom software on the fridge, you could get an iq stanza over to the toaster (that also assumes that the toaster and the fridge each contact respective services that allows server-to-server/federation). It's highly unlikely to pan out in the real world, there's a lot of assumptions there that Philips, Samsung + co are highly unlikely to satisfy.
Andrew_nenakhov 7y ago
The federation does help here. Device manufacturers might provide built-in XMPP addresses for devices (fridge124529@samsung.kr, bulb981232545@phillips.nl, etc), and they can interact with each other and with home automation hub over a reliable standard protocol. And if you're not fine with the idea of having your lightbulb having a Phillips account you can configure everything to work with your home router. And of course, you can get notifications from all these devices right in your chat.
- Lazare 7y ago
  > Device manufacturers might provide built-in XMPP addresses for devices (fridge124529@samsung.kr, bulb981232545@phillips.nl, etc), and they can interact with each other and with home automation hub over a reliable standard protocol. Yeah, but they haven't. And almost certainly won't. And even if they did, in order to interact with each other they'll need to agree on a common language, which would be an enormous task. But if that enormous challenge was solved, then yes, federation would be one of the ways you could let devices find each other, but there's others. For example, the home router you suggest could configure all your smart devices could also, say, act as a simple registry. Saying "federation does help" oversells it greatly, I think. It's more like "federation could help, one day in the far future, if we solve a lot of difficult problems".
  - Andrew_nenakhov 7y ago
    Well, I agree with you that currently federation does not help, cause it is not used. However, XMPP is actually very easy to use protocol. It only gets hard when you're building a chat application that does all sorts of things that are expected from a modern messenger. But receiving a message, replying, is easy, fast, and requires surprisingly low power. It is no coincidence why both apple and Google use a modified XMPP to power their push notifications. So supplying every 'smart' device with a capability to talk over xmpp potentially solves all interroperability issues. You just need to agree on message format, all other infrastructure is already in place.
dustfinger 7y ago
> ... 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? That is what a message broker [1] is for. [1] https://en.wikipedia.org/wiki/Message_broker https://en.wikipedia.org/wiki/Message_broker
skywhopper 7y ago
Right. XMPP is merely a transport protocol. That solves one very minor problem which can be solved dozens of other ways. The contents of those transport packets have to make sense between devices. How do you do that? Say you introduce a new device to the network. Whatever magic transport protocol you are using discovers it and your control hub takes ownership after some handshake process. Now, how does the hub—and by implication every other device on the network—know what that new device is and what it can do? It’s a lightbulb? Okay, that’s just on and off right? Oh, no it might have dimming capability. Maybe it’s a candelabra with multiple bulbs? Maybe the bulb can show different colors. Maybe it has a wake-up gradual brightening process built in. Maybe it has a sensor built in to adjust brightness and color temperature based on existing light sources. Maybe you want to disable that but also set the color to purple. How do you exchange all this capability information? And this is just a lightbulb. XMPP federation doesn’t solve for that.

by Lazare 7y ago

jayd16 7y ago

You're not wrong but any solution has to start with sending a message.

ken 7y ago
XMPP 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.
- stephenr 7y ago
  Most major vendors did use it, and likely still do internally, but with federation turned off. If you have a billion “users” using a working chat system and the concern is “with federation they can chat with outsiders and we can bleed users” you don’t just drop the whole thing, you turn off federation and prevent third party client logins.

netsharc 7y ago

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 7y ago
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 7y ago
  Apple’s Bonjour protocol?
  - Andrew_nenakhov 7y ago
    Bonjour is actually an XMPP extension. https://xmpp.org/extensions/xep-0174.html https://xmpp.org/extensions/xep-0174.html
    - toomuchtodo 7y ago
      Interesting! Thanks for sharing this!
    - duskwuff 7y ago
      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.

zamalek 7y ago

I assume that, assuming you can get custom software on the fridge, you could get an iq stanza over to the toaster (that also assumes that the toaster and the fridge each contact respective services that allows server-to-server/federation). It's highly unlikely to pan out in the real world, there's a lot of assumptions there that Philips, Samsung + co are highly unlikely to satisfy.

Andrew_nenakhov 7y ago

The federation does help here. Device manufacturers might provide built-in XMPP addresses for devices (fridge124529@samsung.kr, bulb981232545@phillips.nl, etc), and they can interact with each other and with home automation hub over a reliable standard protocol. And if you're not fine with the idea of having your lightbulb having a Phillips account you can configure everything to work with your home router. And of course, you can get notifications from all these devices right in your chat.

Lazare 7y ago
> Device manufacturers might provide built-in XMPP addresses for devices (fridge124529@samsung.kr, bulb981232545@phillips.nl, etc), and they can interact with each other and with home automation hub over a reliable standard protocol. Yeah, but they haven't. And almost certainly won't. And even if they did, in order to interact with each other they'll need to agree on a common language, which would be an enormous task. But if that enormous challenge was solved, then yes, federation would be one of the ways you could let devices find each other, but there's others. For example, the home router you suggest could configure all your smart devices could also, say, act as a simple registry. Saying "federation does help" oversells it greatly, I think. It's more like "federation could help, one day in the far future, if we solve a lot of difficult problems".
- Andrew_nenakhov 7y ago
  Well, I agree with you that currently federation does not help, cause it is not used. However, XMPP is actually very easy to use protocol. It only gets hard when you're building a chat application that does all sorts of things that are expected from a modern messenger. But receiving a message, replying, is easy, fast, and requires surprisingly low power. It is no coincidence why both apple and Google use a modified XMPP to power their push notifications. So supplying every 'smart' device with a capability to talk over xmpp potentially solves all interroperability issues. You just need to agree on message format, all other infrastructure is already in place.

dustfinger 7y ago

> ... 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? That is what a message broker [1] is for. [1] https://en.wikipedia.org/wiki/Message_broker https://en.wikipedia.org/wiki/Message_broker

skywhopper 7y ago

Right. XMPP is merely a transport protocol. That solves one very minor problem which can be solved dozens of other ways. The contents of those transport packets have to make sense between devices. How do you do that? Say you introduce a new device to the network. Whatever magic transport protocol you are using discovers it and your control hub takes ownership after some handshake process. Now, how does the hub—and by implication every other device on the network—know what that new device is and what it can do? It’s a lightbulb? Okay, that’s just on and off right? Oh, no it might have dimming capability. Maybe it’s a candelabra with multiple bulbs? Maybe the bulb can show different colors. Maybe it has a wake-up gradual brightening process built in. Maybe it has a sensor built in to adjust brightness and color temperature based on existing light sources. Maybe you want to disable that but also set the color to purple. How do you exchange all this capability information? And this is just a lightbulb. XMPP federation doesn’t solve for that.