COM8Is there a reason why all XEPs related to IoT are "Retracted" or "Deferred"?
Ge0rGCOM8: yes, lack of author commitment.
COM8hmm so what's the state of XMPP for IoT then?
Ge0rGCOM8: very sad
COM8nice :D
Ge0rGI'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.
ralphmI believe these protocols are actually being used, mostly in collaboration with their author. However, I would say they deviate XEP-0134: XMPP Design Guidelines.
ralphmIn the sense that there seem to be preexisting models which where then modeled on top of XMPP.
adityaborikarhas joined
COM8Ge0rG: 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
ralphmI 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.
Ge0rGralphm: yes, that was also my general impression.
Ge0rGBut 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
ralphmSure
Ge0rGGoing the good ol' design-by-committee route of the XSF will lead to yet another monstrosity that's impossible to implement
Ge0rGbecause 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
ralphmThe problem with the current set of IoT protocols was that they were not designed by people with previous XMPP protocol knowledge.
COM8has left
Ge0rGI have knowledge of XMPP and I have knowlede of home automation, but I lack the time.
ralphmAnd that everyone in our community didn't really have the cycles to make it better aligned.
ralphmI'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.
Ge0rGAgreed.
lorddavidiiihas left
ralphmBut 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
Ge0rGWhen 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"
ralphmGe0rG: I think XMPP shines as a routing mechanism, using simpler protocols locally (on resource constrained devices) and bridging them.
flowI 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
ralphmflow: didn't I just say that? 🤣
Ge0rG"Last Updated: 2016-09-04" 😞
flowralphm, just wanted to confirm that
flowOf course, everyones idea of "IoT" is different
Ge0rGflow: 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
flowGe0rG, 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
flowAlso 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/)
ralphmIf it hasn't been submitted to the editor, then indeed chances are it is not being looked at
ralphmBesides exposure, submission of XEP creates a more clear legal situation for others to contribute.
ralphma
Ge0rGa.k.a. "don't call it a (proto)XEP until it's submitted"
Dele (Mobile)has joined
flowralphm, I am not sure I would agree, at least I don't see why that is the case
flowBut it's not like I have problems submitting XEPs, I guess you know that ;)
Ge0rGflow: before you submit it to the XSF, it's just an XML or HTML file on your web server.
flowGe0rG, the question is why submission or the acceptance as protoXEP creates a more clear legal situation for others to contribute?
flowI mean, yes the editor asks you questions, but those questions could also be seen as answered by writing the xml/html file
flowand publishing it
kokonoehas left
flowGe0rG, 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
Ge0rGflow: because by submitting it as a proto-XEP, you accept the https://xmpp.org/about/xsf/ipr-policy
flowI'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
ralphmHaving a document with rights assigned to the XSF, but not formally received or hosted by it, makes it muddy.
COM8Regarding 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.
Ge0rGflow: 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
Ge0rGCOM8: you might or might not use http://geekplace.eu/xeps/xep-siot/xep-siot.html as a foundation
ralphmCOM8: splendid
ralphmGe0rG: well, maybe. As I said, muddy.
flowCOM8, also feel free to join iot@muc.xmpp.org
COM8Ge0rG: Thanks will have a look at it
COM8flow: 👍🏻
Ge0rGCOM8: what kind of IoT are you doing?
ralphmflow: if you believe your document is worthy of being worked on, just send it to the editor. Even if it results in major rewrites
Ge0rGI know that Cisco and some others are pushing XMPP for IT Security Incident data exchange, which is also a hot topic for me
ralphmGe0rG: interesting. Is any of them in our community?
flowwell PSA is listed as author for xmpp-grid (RFC8600)
j.rhas left
j.rhas joined
COM8Ge0rG: Home automation so trying to provide an interface for all sensors/devices in XMPP apps (DataForms).
COM8ralphm: Yes
ralphmI'm not opposed to do work in the IETF, t.b.h.
Ge0rGat 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)"
Ge0rGand then have a discovery mechanism, a config mechanism and a pubsub mechanism
ralphmSo is it reasonable?
adityaborikarhas joined
ralphmI think I looked at it before. This work started in 2016 or so
ralphmAnd MILE is older.
ralphmhttps://tools.ietf.org/wg/mile/charters
adityaborikarhas left
Danielhas left
Danielhas joined
Steve Killehas left
Ge0rGIs M2M the same as IoT?
Danielhas left
Danielhas joined
ralphmI think so
ralphmOr at least some subset
COM8has left
Ge0rGWe are depressingly understaffed.
COM8has joined
pdurbinhas joined
adityaborikarhas joined
Nekithas left
Nekithas joined
UsLhas joined
j.rhas left
Ge0rGflow: are you interested in corrected line numbers from the stacktrace?
XSF Discussion - 2019-08-16