IoT SIG - 2019-09-04

  1. COM8

    So I started laying out the building blocks needed for a new approach to IoT. Now I would like to start working on the XEP(s). Should I create one single XEP or is it better when I spit stuff up into multiple XEPs. Any advice here? Planed topics: Registration, Discovery, Data Access, Trust Management, (Device Automatisation)

  2. flow

    COM8, I don't think that it does not matter that much at an early stage if you split or not. In general, splitting large XEPs in optional parts is usually a good idea

  3. flow

    COM8, I usually recommend setting up a system which automatically builds the XEPs from source and place the resulting html onto a webserver

  4. COM8

    Ok, sounds good. Since splitting up can be done later I will start working on one compact XEP

  5. flow

    COM8, also, be aware that writing a standard and getting it published is not an easy task

  6. flow

    I suggest to gather feedback early and to seek for a way has the highest chance to get consensus

  7. flow

    I think IoT is especially challenging here, since it has so many different meanings and everyone has a slight different requirements etc

  8. flow

    Aaaaaaaaaaaand: running code, you want to develop a standard hand-in-hand with a (prototype) implementation

  9. MattJ

    Also an important note: a suite of IoT XEPs covering these topics was already published some years ago

  10. flow

    MattJ, I think COM8 is aware of the waher xeps

  11. MattJ

    Ok, good

  12. COM8

    flow: Yes, I'm aware of that. At the moment I'm working on the overall system design. So as soon as I got this done I will try to create a first draft for discussion.

  13. COM8

    Mattj: Yes, since they have been revoked/deferred I started working on this.

  14. MattJ

    revoked and deferred are two very different things

  15. MattJ

    "deferred" just means they haven't been updated for a while, and nobody tried to advance them

  16. MattJ

    I don't think that's good enough reason to just do the same thing again

  17. MattJ

    a while == 12 months currently, iirc

  18. flow

    MattJ, are you sure that its the same thing? :) Also if someone feels like it, why not?

  19. flow

    I don't think much is salvageable from the existing XEPs, actually I can only think of one thing

  20. MattJ

    "why not?" => it's a waste of time just to gain 4 more XEPs that will be also deferred in 18 months from now

  21. COM8

    Also they were focusing more or less on automatisation/handling for large scale IoT networks and didn't had the simple enduser in mind. I want to define an XEP which lets enduser Bob register and handel his smart lightbulb/thermometer/... and control all of his devices in a way that is as simple and secure as possible.

  22. MattJ

    To be clear: I'm not against new XEPs, the old ones have plenty of issues

  23. MattJ

    But I think you need a clear objective that sets the new XEPs apart from the old ones

  24. MattJ

    COM8, people are already controlling light bulbs over XMPP, just ask ralphm

  25. MattJ

    Accomplished by registering a user account for a bot, and sending the bot a message

  26. MattJ

    We already have registration mechanisms in XMPP

  27. MattJ

    Why does IoT need something different?

  28. flow

    MattJ, well, even if they get deferred, there is probably a leasson learned or two, potentially only for COM8, but still

  29. flow

    MattJ, one issue that XMPP is missing is access control

  30. flow

    how do you set ACLs for your lightbulp?

  31. flow


  32. MattJ

    flow, by making the bot only accept requests from users on its roster

  33. flow

    MattJ, that is what I have for coarse grained ACLs in mind

  34. MattJ

    and the bot can manage its roster however it wants

  35. flow

    but how do roster entries get added and removed?

  36. MattJ

    How do ACL entries get added or removed? :)

  37. COM8

    Mattj: That is exactly what I do not want. I don't want an interface that is text based. I want that the device to provied a XEP004 based form where the user can change the color, brightnes, ... via a slider, color picker, ...

  38. flow

    Well we don't have a generic standard for that, that's the point i guess

  39. MattJ

    COM8, ok, so ad-hoc commands already exist, you're done :)

  40. flow

    and i think a generic standard for this would be benefical

  41. MattJ

  42. MattJ

    The gateway/bot can expose any commands it wants to, and serve forms

  43. MattJ

    And best of all: many clients and libraries already implement this

  44. flow

    MattJ, now some entity requests presence subscription from your thermometer, so that it can read its value. How does the thermometer forward the request to the owner of the thermometer?

  45. flow

    I aggree that existing building blocks should be used whenever sensible

  46. flow

    and it is probably sensible in most cases

  47. MattJ


  48. flow

    MattJ, so the full JID of the thermometer becomes a pubsub service?

  49. MattJ

    Why not the bare JID, which already is?

  50. flow

    that works for the pubsub case, but what if I want to pull the data?

  51. MattJ

    You can pull from pubsub

  52. flow

    live data, which some extra metadata what and how it should be pulled

  53. MattJ

    or you mean, you don't want the device to push to pubsub at all?

  54. flow

    i.e., when you don't want to talk to a pubsub service on the bare jid, but with the device itself via the full jid

  55. flow

    MattJ, it depends on the use case i'd say. Sure, for something like temperature, pubsub would be nice for most use-cases

  56. flow

    but there may be uses cases where you have to directly talk to the device

  57. MattJ may fit then

  58. flow

    for example because you don't want to read out a sensor, but talk to an actor

  59. flow

    not sure about xep244, I never understood or forgot the advantage over plain ad-hoc commands, but yes

  60. COM8

    Mattj: Yes, I know and I also do not want to reinvent the wheel again like it has been done in an earlier iteration. I want to use existing stuff where ever possible and define a simple and standartised way so every enduser even Bob how does not know what XMPP is and just want's to manage his stuff without having to send text messages with an exact sytax you allways have to remember/ look up

  61. MattJ

    COM8, so what will Bob use to interact?

  62. flow

    Also going back to First you said: use the roster, and then you came with pubsub. What is it now? ;)

  63. MattJ

    flow, I'm not claiming to have a specific solution, but I'm also not the person planning on yet more XEPs

  64. MattJ

    and I'll repeat: I'm not against new XEPs, if they're clearly needed

  65. MattJ

    I'd be happy to see gaps filled

  66. MattJ

    What I'm doing it throwing out proposals for reusing existing stuff, and if there's reasons they don't fit, that helps clarify exactly what is needed

  67. MattJ

    But when you tell me you just need an ACL, and we already have the roster being successfully used as an ACL in multiple situations already, I have a duty to point that out :)

  68. MattJ

    and it's very simple to implement, and widely supported

  69. MattJ

    So a XEP that allows delegated authority to approve roster requests may be all that is needed

  70. MattJ

    I live and breathe XMPP, and have done for a long time now. I also love IoT, and have far more home automation set up than the average person

  71. MattJ

    and yet I don't see a clear fit for XMPP into any of the stuff I've done

  72. COM8

    mattj: Yes that is the question! We have to make it as easy to use for endusers and as easy as possible to implement so everybody jumps ontop of our bandwagon. That's what I hope to archive with my XEP. A XEP that describes the process starting from pushing a button on the IoT device over scanning it's QR Code for registering it on your XMPP server. And once the device is registered how can a user manage and access the device. On top of that we can extend stuff like connecting it to ITTT, ... I'm not aware that any existing XEP describes this.

  73. flow

    > MattJ> So a XEP that allows delegated authority to approve roster requests may be all that is needed see topic of this MUC :)

  74. MattJ

    flow, perfect :)

  75. MattJ

    COM8, I think you need a bit more incentive to get people on the bandwagon

  76. MattJ

    Ease-of-use is about UI/UX, and can typically be done on top of any protocol, HTTPS, MQTT, etc.

  77. MattJ

    and given that XMPP won't run on many microcontrollers that can handle CoAP or MQTT, manufacturers probably aren't going to jump on it fast either

  78. MattJ

    It may be a good fit for a hub/gateway device, but they can just as easily speak HTTPS/MQTT, which are already widely supported

  79. MattJ

    I'm not really trying to discourage you, I'm actually trying to help you think about what problem you are trying to solve

  80. flow

    I do believe that there should also be a fine grained ACL mechanism, which puts the ACL in a PEP for the devices nodes (N.B. not talking about pubsub nodes here, but "xep30" nodes)

  81. MattJ

    So you don't waste your time

  82. COM8

    Yes and I'm really thankful for that. That's why I'm in here to discuss with people and see how they look at this stuff.

  83. MattJ

    Here's the way I see things. For a general end-user smart-home situation (which is what I think you are targeting), you have a handful of devices with different roles

  84. MattJ

    You have the device (e.g. a light bulb), a gateway (optional), a hub (also optional), and a controller (e.g. a phone or hardware control of some sort)

  85. MattJ

    Many IoT devices do not speak TCP/IP, or connect directly to a LAN - typically because of power constraints, microcontroller resources, wifi reliability, etc.

  86. MattJ

    So they will use Zigbee, Z-Wave, or something similar to communicate with a gateway/bridge device

  87. MattJ

    So there is no room for XMPP in this part of the stack

  88. MattJ

    Also this part of the stack is typically controlled by a single manufacturer, so doesn't necessarily need to be open, or is already based on an open(ish) standard such as Zigbee, Z-Wave or BLE

  89. MattJ

    For devices that don't need a gateway, but e.g. connect directly to wifi, you'll still generally find them using microcontrollers that are not capable enough to run XMPP

  90. MattJ

    and those devices tend to connect to a manufacturer's proprietary cloud anyway, so the manufacturer doesn't care about interop here

  91. MattJ

    Ok, so then you have the next layer: communication between a hub or controller and the gateway

  92. MattJ

    XMPP /could/ fit here, but why? It necessitates an extra piece of infrastructure (an XMPP server), and I don't see the gain

  93. MattJ

    I certainly don't want to depend on public XMPP services for turning my lights on/off, and neither do I expect everyone to run their own server (separate to all the stuff they'd already have)

  94. MattJ

    You could make the hub be an XMPP server, but again, I'm not sure of the benefit there

  95. MattJ

    That leaves communication between the hub and controlling device - would both need to communicate via an XMPP server instead of directly?

  96. MattJ

    Latency also becomes an issue

  97. MattJ

    If this is stuff you've already thought about, I'd love to hear your thoughts

  98. MattJ

    If not, hopefully it provides you something interesting to think about