- Alacer has left
- Alacer has joined
- Alacer has left
- Alacer has joined
- patrik has joined
- Alacer has left
- Alacer has joined
- Alacer has left
- Alacer has joined
- Tobi has joined
- Alacer has left
- Alacer has joined
- jjrh has left
- jjrh has joined
- jjrh has left
- jjrh has joined
- jjrh has left
- jjrh has joined
- COM8 has joined
-
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)
-
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
-
flow
COM8, I usually recommend setting up a system which automatically builds the XEPs from source and place the resulting html onto a webserver
- Alacer has left
- Alacer has joined
-
COM8
Ok, sounds good. Since splitting up can be done later I will start working on one compact XEP
- jjrh has left
- jjrh has joined
- jjrh has left
- jjrh has joined
-
flow
COM8, also, be aware that writing a standard and getting it published is not an easy task
-
flow
I suggest to gather feedback early and to seek for a way has the highest chance to get consensus
-
flow
I think IoT is especially challenging here, since it has so many different meanings and everyone has a slight different requirements etc
-
flow
Aaaaaaaaaaaand: running code, you want to develop a standard hand-in-hand with a (prototype) implementation
-
MattJ
Also an important note: a suite of IoT XEPs covering these topics was already published some years ago
-
flow
MattJ, I think COM8 is aware of the waher xeps
- Alacer has left
-
MattJ
Ok, good
-
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.
- Alacer has joined
-
COM8
Mattj: Yes, since they have been revoked/deferred I started working on this.
-
MattJ
revoked and deferred are two very different things
-
MattJ
"deferred" just means they haven't been updated for a while, and nobody tried to advance them
-
MattJ
I don't think that's good enough reason to just do the same thing again
-
MattJ
a while == 12 months currently, iirc
-
flow
MattJ, are you sure that its the same thing? :) Also if someone feels like it, why not?
-
flow
I don't think much is salvageable from the existing XEPs, actually I can only think of one thing
-
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
-
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.
-
MattJ
To be clear: I'm not against new XEPs, the old ones have plenty of issues
-
MattJ
But I think you need a clear objective that sets the new XEPs apart from the old ones
-
MattJ
COM8, people are already controlling light bulbs over XMPP, just ask ralphm
-
MattJ
Accomplished by registering a user account for a bot, and sending the bot a message
-
MattJ
We already have registration mechanisms in XMPP
-
MattJ
Why does IoT need something different?
-
flow
MattJ, well, even if they get deferred, there is probably a leasson learned or two, potentially only for COM8, but still
-
flow
MattJ, one issue that XMPP is missing is access control
-
flow
how do you set ACLs for your lightbulp?
-
flow
*lightbulb
-
MattJ
flow, by making the bot only accept requests from users on its roster
-
flow
MattJ, that is what I have for coarse grained ACLs in mind
-
MattJ
and the bot can manage its roster however it wants
-
flow
but how do roster entries get added and removed?
-
MattJ
How do ACL entries get added or removed? :)
-
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, ...
-
flow
Well we don't have a generic standard for that, that's the point i guess
-
MattJ
COM8, ok, so ad-hoc commands already exist, you're done :)
-
flow
and i think a generic standard for this would be benefical
-
MattJ
https://xmpp.org/extensions/xep-0050.html
-
MattJ
The gateway/bot can expose any commands it wants to, and serve forms
-
MattJ
And best of all: many clients and libraries already implement this
-
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?
-
flow
I aggree that existing building blocks should be used whenever sensible
-
flow
and it is probably sensible in most cases
-
MattJ
flow, https://xmpp.org/extensions/xep-0060.html#subscriber-subscribe-approval
-
flow
MattJ, so the full JID of the thermometer becomes a pubsub service?
-
MattJ
Why not the bare JID, which already is?
-
flow
that works for the pubsub case, but what if I want to pull the data?
-
MattJ
You can pull from pubsub
-
flow
live data, which some extra metadata what and how it should be pulled
-
MattJ
or you mean, you don't want the device to push to pubsub at all?
-
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
-
flow
MattJ, it depends on the use case i'd say. Sure, for something like temperature, pubsub would be nice for most use-cases
-
flow
but there may be uses cases where you have to directly talk to the device
-
MattJ
https://xmpp.org/extensions/xep-0244.html may fit then
-
flow
for example because you don't want to read out a sensor, but talk to an actor
-
flow
not sure about xep244, I never understood or forgot the advantage over plain ad-hoc commands, but yes
-
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
-
MattJ
COM8, so what will Bob use to interact?
-
flow
Also going back to https://xmpp.org/extensions/xep-0060.html#subscriber-subscribe-approval: First you said: use the roster, and then you came with pubsub. What is it now? ;)
-
MattJ
flow, I'm not claiming to have a specific solution, but I'm also not the person planning on yet more XEPs
-
MattJ
and I'll repeat: I'm not against new XEPs, if they're clearly needed
-
MattJ
I'd be happy to see gaps filled
-
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
-
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 :)
-
MattJ
and it's very simple to implement, and widely supported
-
MattJ
So a XEP that allows delegated authority to approve roster requests may be all that is needed
-
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
-
MattJ
and yet I don't see a clear fit for XMPP into any of the stuff I've done
-
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.
- Tobi has left
- Tobi has joined
-
flow
> MattJ> So a XEP that allows delegated authority to approve roster requests may be all that is needed see topic of this MUC :)
-
MattJ
flow, perfect :)
-
MattJ
COM8, I think you need a bit more incentive to get people on the bandwagon
-
MattJ
Ease-of-use is about UI/UX, and can typically be done on top of any protocol, HTTPS, MQTT, etc.
-
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
-
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
-
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
-
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)
-
MattJ
So you don't waste your time
-
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.
- COM8 has left
-
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
- Alacer has left
- Alacer has joined
-
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)
-
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.
-
MattJ
So they will use Zigbee, Z-Wave, or something similar to communicate with a gateway/bridge device
-
MattJ
So there is no room for XMPP in this part of the stack
-
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
-
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
-
MattJ
and those devices tend to connect to a manufacturer's proprietary cloud anyway, so the manufacturer doesn't care about interop here
-
MattJ
Ok, so then you have the next layer: communication between a hub or controller and the gateway
-
MattJ
XMPP /could/ fit here, but why? It necessitates an extra piece of infrastructure (an XMPP server), and I don't see the gain
-
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)
-
MattJ
You could make the hub be an XMPP server, but again, I'm not sure of the benefit there
-
MattJ
That leaves communication between the hub and controlling device - would both need to communicate via an XMPP server instead of directly?
-
MattJ
Latency also becomes an issue
-
MattJ
If this is stuff you've already thought about, I'd love to hear your thoughts
-
MattJ
If not, hopefully it provides you something interesting to think about
- Tobi has left
- Tobi has joined
- Alacer has left
- Alacer has joined
- Alacer has left
- Alacer has joined
- Alacer has left
- Alacer has joined
- Alacer has left
- patrik has left
- patrik has joined
- patrik has left
- Tobi has left
- Alacer has left
- Alacer has joined
- Alacer has left
- Alacer has joined
- patrik has joined
- Alacer has left
- Alacer has joined
- Alacer has left
- Alacer has joined
- Tobi has joined
- Alacer has left
- Alacer has joined
- jjrh has left
- jjrh has joined
- jjrh has left
- jjrh has joined
- jjrh has left
- jjrh has joined
- COM8 has joined
- Alacer has left
- Alacer has joined
- jjrh has left
- jjrh has joined
- jjrh has left
- jjrh has joined
- Alacer has left
- Alacer has joined
- Tobi has left
- Tobi has joined
- COM8 has left
- Alacer has left
- Alacer has joined
- Tobi has left
- Tobi has joined
- Alacer has left
- Alacer has joined
- Alacer has left
- Alacer has joined
- Alacer has left
- Alacer has joined
- Alacer has left
- patrik has left
- patrik has joined
- patrik has left
- Tobi has left