Is there a reason why all XEPs related to IoT are "Retracted" or "Deferred"?
Ge0rG
COM8: yes, lack of author commitment.
COM8
hmm so what's the state of XMPP for IoT then?
Ge0rG
COM8: very sad
COM8
nice :D
Ge0rG
I'm not sure whether there is a set of actually usable IoT protocols, and AFAIK there is no set of libraries / widget toolkits / whatever at the middleware layer.
ralphm
I believe these protocols are actually being used, mostly in collaboration with their author. However, I would say they deviate XEP-0134: XMPP Design Guidelines.
ralphm
In the sense that there seem to be preexisting models which where then modeled on top of XMPP.
adityaborikarhas joined
COM8
Ge0rG: Yes, noticed that too since I was doing research on it.
I'm currently planning to create a XMPP-IoT extension for my client (UWPX) and setup a simple image for ESP32s.
COM8has left
ralphm
I think it would be great if someone took a fresh look at this domain and design a set of protocols that use existing building blocks and disregard this prior work, to see what it would look like. I think it could be all a lot simpler and more elegant.
Ge0rG
ralphm: yes, that was also my general impression.
Ge0rG
But then again, "IoT" means something different to everybody, so we should maybe try to define more precise scopes, and have a first phase of distinct protocol desings for each, and then look how we can aggregate them
ralphm
Sure
Ge0rG
Going the good ol' design-by-committee route of the XSF will lead to yet another monstrosity that's impossible to implement
Ge0rG
because everybody will bring in their pet feature, and in the end it will be unbearably unmaintainable
COM8has joined
COM8has left
Steve Killehas left
COM8has joined
ralphm
The problem with the current set of IoT protocols was that they were not designed by people with previous XMPP protocol knowledge.
COM8has left
Ge0rG
I have knowledge of XMPP and I have knowlede of home automation, but I lack the time.
ralphm
And that everyone in our community didn't really have the cycles to make it better aligned.
ralphm
I'm not a fan of design by committee; having three or so people, with some XMPP experience, hammering it out with running code, is usually pretty good.
Ge0rG
Agreed.
lorddavidiiihas left
ralphm
But sometimes this is hard, like with Jingle.
jonasโ
there is now a Triage permission on github which allows to read and clone a repo, plus manage issues and PRs.
jonasโ
this would be excellent for folks like pep. who want to get their hands dirty on editor tasks, but are not official editor team members and thus should not be given +w on the repository
Ge0rG
When I did my own IoT deployment, I ended up reinventing the wheel on top of MQTT. I really wish we had an XMPP based middleware for sensors and actors, and maybe a bunch of pre-defined profiles like "RGB light"
ralphm
Ge0rG: I think XMPP shines as a routing mechanism, using simpler protocols locally (on resource constrained devices) and bridging them.
flow
I wrote the "Simple IoT" XEP after working with peter wahers XEPs (the "IoT XEPs"): http://geekplace.eu/xeps/xep-siot/xep-siot.html
Most of his XEPs re-invent the wheel when existing building blocks could be used IMHO
ralphm
flow: didn't I just say that? ๐คฃ
Ge0rG
"Last Updated: 2016-09-04" ๐
flow
ralphm, just wanted to confirm that
flow
Of course, everyones idea of "IoT" is different
Ge0rG
flow: while you are there, I've recently had an ugly (but non-breaking) stacktrace from the Smack debugger during roster load: https://op-co.de/tmp/smack-roster-trace.txt
madhur.garghas left
valohas joined
flow
Ge0rG, where is the source of org.yaxim.androidclient.util.JULHandler ?
flow
> Ge0rG> "Last Updated: 2016-09-04" ๐
I am not sure what this is trying to express: Disappointed because I did not work at it? Or because nobody cared enough to try it and continue working on it?
COM8has joined
flow
Also I believe XMPP already has most things for IoT. Any further/new IoT XEP would probably be a specification allowing vendor interoperability. And since vendors do not have interest in that, we see no activity in this regard. If you want to do IoT for your own, e.g. control your lightbulb, you probably would just go ahead and implement it based on ad-hoc commands (which would allow your 10 year old PSI instance to control it FWIW \o/)
ralphm
If it hasn't been submitted to the editor, then indeed chances are it is not being looked at
Besides exposure, submission of XEP creates a more clear legal situation for others to contribute.
ralphm
a
Ge0rG
a.k.a. "don't call it a (proto)XEP until it's submitted"
Dele (Mobile)has joined
flow
ralphm, I am not sure I would agree, at least I don't see why that is the case
flow
But it's not like I have problems submitting XEPs, I guess you know that ;)
Ge0rG
flow: before you submit it to the XSF, it's just an XML or HTML file on your web server.
flow
Ge0rG, the question is why submission or the acceptance as protoXEP creates a more clear legal situation for others to contribute?
flow
I mean, yes the editor asks you questions, but those questions could also be seen as answered by writing the xml/html file
flow
and publishing it
kokonoehas left
flow
Ge0rG, which smack version is it, because the stacktrace does not match what is at https://github.com/igniterealtime/Smack/blob/4.3/smack-im/src/main/java/org/jivesoftware/smack/roster/Roster.java#L1601
Ge0rG
flow: because by submitting it as a proto-XEP, you accept the https://xmpp.org/about/xsf/ipr-policy
flow
I'd say I already accept that by publishing a document which states that it is full conformance of the XSF's IPR
kokonoehas joined
Steve Killehas joined
ralphm
Having a document with rights assigned to the XSF, but not formally received or hosted by it, makes it muddy.
COM8
Regarding IoT: Since I'm working on it anyway for my B.Sc. Thesis I will try to come up with a protocol that uses already existing features of XMPP and try (once I got it up and running) to standardize it.
Ge0rG
flow: the stacktrace also doesn't match my source files (WTF?), but the error happens in `LOGGER.log(Level.FINE, "RosterResultListener received {}", packet);` when single-stepping
adityaborikarhas left
Ge0rG
COM8: you might or might not use http://geekplace.eu/xeps/xep-siot/xep-siot.html as a foundation
ralphm
COM8: splendid
ralphm
Ge0rG: well, maybe. As I said, muddy.
flow
COM8, also feel free to join iot@muc.xmpp.org
COM8
Ge0rG: Thanks will have a look at it
COM8
flow: ๐๐ป
Ge0rG
COM8: what kind of IoT are you doing?
ralphm
flow: if you believe your document is worthy of being worked on, just send it to the editor. Even if it results in major rewrites
Ge0rG
I know that Cisco and some others are pushing XMPP for IT Security Incident data exchange, which is also a hot topic for me
ralphm
Ge0rG: interesting. Is any of them in our community?
well PSA is listed as author for xmpp-grid (RFC8600)
j.rhas left
j.rhas joined
COM8
Ge0rG: Home automation so trying to provide an interface for all sensors/devices in XMPP apps (DataForms).
COM8
ralphm: Yes
ralphm
I'm not opposed to do work in the IETF, t.b.h.
Ge0rG
at a high level, you need to define sensor / actor types ("switch", "temperature sensor", "RGB light", ...) which probably map to abstract types like "1x binary", "3x float value (0...1)"
Ge0rG
and then have a discovery mechanism, a config mechanism and a pubsub mechanism
ralphm
So is it reasonable?
adityaborikarhas joined
ralphm
I think I looked at it before. This work started in 2016 or so
ralphm
And MILE is older.
ralphm
https://tools.ietf.org/wg/mile/charters
adityaborikarhas left
Danielhas left
Danielhas joined
Steve Killehas left
Ge0rG
Is M2M the same as IoT?
Danielhas left
Danielhas joined
ralphm
I think so
ralphm
Or at least some subset
COM8has left
Ge0rG
We are depressingly understaffed.
COM8has joined
pdurbinhas joined
adityaborikarhas joined
Nekithas left
Nekithas joined
UsLhas joined
j.rhas left
Ge0rG
flow: are you interested in corrected line numbers from the stacktrace?