XSF Discussion - 2018-02-07

https://news.ycombinator.com/item?id=16319418

Some comments on XMPP and IoT.

Thanks for the link!

Public transport seems to go for MQTT. :/

No apparent reason, ie I never met an engineer who could tell me why the standards say "MQTT" (not much more, actually, it's still HTTP and SOAP).

I am trying to get XMPP in there, at least as a showcase, but so far MQTT has won by being the IoT buzzword.

tech this days...

driven by buzzwords exclusively

well a good ol' comparison/benchmark could bring some nice bases for a proper discussion

I think people did that

edhelas: but our product management is right when they say that you cannot engineer against the market.

Unless you are Google or so

edhelas, for XMPP e.g. "Access to Global and Federated Smart Objects Using XMPP" by Schuster et al.

> you cannot engineer against the market Nailed it

that's why I think XMPP is lost because reputation is lost and you cannot fix that by creating good software or standards

jonasw: "Access to Global and Federated Smart Objects" - things like this cause me sleepless nights

Ge0rG, hah

I'm not an XMPP IoT expert, but what MQTT provides is a very low-level pub-sub primitive protocol with no auth and no device enumeration. Are there IoT libs/specifications on top of that which allow automatic discovery, integration into complex control systems etc?

Do we have those over XMPP?

Last time I did IoT (over MQTT), I had to hard-code room names into event channel names and make custom firmware images for different rooms.

I think that providing an easy-to-use abstraction library for the typical IoT developer problems will bring out acceptance to super-high automatically.

*our

I also do not understand how you can compare mqtt and xmpp, they are on different layers

zinid: are they?

Ge0rG: from what I understand mqtt is just a hack on top of transport layer, it only improves transport, it defines no payload

While xmmp is transport plus application specific payload

zinid: MQTT is a pub-sub mechanism, too.

Ge0rG: so you can build federation with authentication and such using mqtt?

Also if pubsub is the only requirement let's use Redis!

just because something doesn’t do federation, doesn’t mean that it’s just "a hack on top of transport layer" O_o

(but IIRC authn was weird with MQTT)

using TLS certs for auth?

jonasw: was there any at all?

lemme check

I did a survey of IoT technologies in a class

Ge0rG, plain text passwords

not sure if you count that as authn

jonasw: I don't know. Are we in 1998 or in 2018?

Ge0rG, zinid: https://sotecware.net/files/noindex/iot.pdf FWIW, that’s my summary on IoT protocols (MQTT, XMPP, CoAP and AMQP) from 2013 or something

maybe that helps to get you on the same page? ✏

jonasw: so _you_ are that XXX guy!

damn

I should’ve used another thing to blank it out

I blanked it out because I’m not sure whether it’s fine to link to it publicly.

(contains my supervisors name in the original version, which may or may not be ok)

jonasw: generally I consider it fine to publish academic works that were reviewed and approved by the supervisor

I planned to ask him at some point :-)

maybe I should just do that

jonasw, ok, so MQTT is an improved transport protocol with message broker, great. Now you need to implement your own application protocol on top of it to do federation, authentication, session lookups and so on

and you will end up with a custom solution, or what? will it be documented?

I’m not sure what you mean by session lookups.

jonasw, how will you find peers?

zinid: of these problems, XMPP solves federation. Authentication is a not-quite-solved problem for IoT devices. sessions and message delivery are a nightmare. And what kind of light-weight "smart object" abstraction do you run when you have messaging set up?

And I'd argue that federation is not generally a good idea for IoT

well, I'm not an IoT expert, so I cannot say if federation is needed, but whatever

IoT federation is when Latvian hackers demand US dollars from Australian citizens to give back control over their Chinese thermostats.

sounds like a niche for XMPP

we already have a lot of criminals in XMPP, need moar

tux: do you have an idea of useful IoT device abstraction libraries/protocol on top of either MQTT or XMPP?

I think federation is important if you want to configure your toster from the phone

if you don't, and you only need to connect tosters, then fuck that shit

zinid: how does your toaster know which phone is yours?

Ge0rG, OMEMO!

"Sorry, I can't make breakfast today, I have a new smartphone".

I agree with zinid. XMPP does much more than the comparisons. Unfortunately, I think that is one of the problems that people have with it XMPP is too many things at once.

SaltyBones: I'm not saying XMPP is bad for IoT, I'm merely saying that we don't have the tools that reduce the work for IoT developers

I totally agree with that as well.

because nobody is working on these tools

well, at least currently

Well... tigase?

I meant the specs

did tigase produce them?

From what I see currently the specs are deferred due to inactivity

IIRC peter retracted the IoT XEPs, or at lest tried to

peter waher that is

Yes they're don't their own thing now. But from what I know they're quite happy with XMPP core.

I.e. SASL, sessions, routing.

But that doesn't provide any on top value for IoT.

Ge0rG, and what value does XMPP provide then?

seems like doesn't fit very much for chats as well

Ge0rG: On top of what?

Ge0rG: I'm just saying the Waher people see core XMPP as a good fit, e.g. compared to HTTP (which is what others do).

Of courese they need custom stuff to do their thing, communication with the XSF didn't work so they now do non-standard extensions. But from what I've heard the core might actually work better for them than for modern IM.

Tigase folk are working essentially without any deviation from the "normal" XMPP extensions.

Holger, I don't think they do non-standard extension, it's just not an XEP

which raises the question if it's a good idea for $company to XEP things up

Flow, A XEP for them owuld be more or less informational. They're simply using pubsub and other normal stuff. The only thing they pulled from the IoT stuff was the payload format.

Dave Cridland, I was talking about "the waher people" aka. clayster

not tigase

which I assume is the group Holger talks about

I'm lost: so we now have different protocols for IoT devices?

Flow: Right.

zinid, course we have

No

Flow: An extension that isn't standardized is not a "non-standard extension"? :-)

"Waher" people do XMPP, others do MQTT and so on? ✏

both, clayster and tigase, appears to do IoT with XMPP

(i think it isn’t about "standard" adn "non-standard", but about whether it is even an extension, Holger)

Holger, well if you write it down it's standarized, if you make it public its an open standard

for me, it doesn't metter which entity is behind the standard

if it's a standards org like ISO, or just some random company

or maybe even just some anonymous individual

Ah. Ok, whatever :-)

of course you can better market things if it's a XEP, or even if PSA appears on the authors list

(I think they didn't even publish their stuff so far but were quite open to do so.)

Holger, stefandxm has some stuff published

Yeah.

(of course i meant above "if you make it public *and* freely implementable, then it is an open standard")

Fine with me. I just meant to say "it's not an XEP" and wasn't insisting on any definition of 'open standard' :-)

as long as you care for open standards ;)

Council Agenda sent out, by the way. I've put Guus's 198 PR on, of the existing PRs, because it seems to have had some discussion - but I suspect it won't be resolved today nonetheless.

Dave Cridland: thanks, one small suggestion: it would be great if you would mention the full XEP title and not just the number, i'm not good maping numbers to whatever the XEP does

Flow, !xep 198

Didn't know about https://coy.im/

jonasw, well 198 is the actually one of the few numbers i am able to remember ;)

Flow, We've internally referred to it by number all the time, I think.

vanitasvitae, re XEP-0392: tried clamping your values to the [0..1] range?

looks suspiciously as if that was the issue

(but I don’t have time to check that right now; other values are affected by this too)

jonasw: where exactly should I clamp?

I thnik it’s written in the text

ha

vanitasvitae, ah, I’m using the verb "clip" there. §5.4, step 2: > Clip the values of r, g and b to the range from 0 to 1.

I'll check :)

Thank you

-xep 198

jonasw: Stream Management (Standards Track, Draft, 2016-12-08) See: https://xmpp.org/extensions/xep-0198.html

ah, Flow ^ that’s how it works :)

So basically if any value of r,g,b exceeds the range of 0,1, just round it to the nearest value in 0,1?

vanitasvitae, yes

For example 1,6 → 1,0, 0,43→0,43, -2 →0

Ok

Thank you :)

exactly

Seve/SouL, I don't remember seeing that one either. But it's another Security over Usability. I mean, no clickable links?

Dave Cridland, yeah...

https://xmpp.org/extensions/xep-0313.html#prefs -- is the 'default' attribute mandatory?

jonasw: now it works. Nice :)

Dave Cridland: your agenda is full of 363 links :>

Guus: there is a typo in https://github.com/xsf/xeps/pull/579 - "to high" --> "too high"

Guus: but I think the new wording is pretty convoluted and might be cleaned up with a bit of thought.

daniel: I've provided some feedback to XEP-0363 in November, that went largely uncommented. If you happen to have a moment to think about it before the Council Meeting, we might be able to accelerate things.

Sorry, work called me out

Ge0rG: I don't have a specific IoT library for XMPP. I have used Gloox once for the XMPP part and was quite satisfied, but for a show case the Gloox license is not viable. It seems that right now, based on available licenses, we are down to strophy in an embedded environment.

strophy?

In contrast to MQTT, XMPP can handle mobile connections and has built-in security features. However, MQTT5 counters this, wehen available

erm,strophe

ah

right

http://strophe.im/libstrophe/

yeah, used that in an ... embedded ... context myself

was wondering if there was a new shiny thing

not really

-xep 363

Flow: HTTP File Upload (Standards Track, Proposed, 2017-12-03) See: https://xmpp.org/extensions/xep-0363.html

But yeah, it would be much easier if there was an XMPP based library for IoT under a viable license (not GPL)

LGPL?

is an option

tux: auth and (limited) mobile support also exist in HTTP.

heresy!

Ge0rG: but only in request/response scheme and features such as presence management would have to implemented, where XMPP already does this

tux, json-over-websockets!

Basically, XMPP allows us to 1) Log in a device by it's ID 2) Report and track its status in a presence stanza 3) send push-messages both ways 4) have built-in security 5) have handling for roaming mobile connections with constant link failures

We'd have to re-build many of these features on HTTP or MQTT

There is one thing XMPP cannot do: having very brief messages.

tux: my point is that between "XMPP" and "how do I switch on a light" there is still a large development effort

However, MQTT is already out there and part of standards (such as ITxPT) name these as _the_ IoT protocol, even though there is no further specification on how to actually use the protocol.

It seems that many industries cannot imagine that IoT can happen without MQTT.

Ge0rG, FFS. Cut and paste error, of course. It's right in the Spreadsheet Of Doom.

Ge0rG: Yes, there is. But XMPP is farther down the road than many other solutions.

Only that XMPP is not known.

tux, depends on your requirements

I can imagine that things like (1) and (4) may not interest a lot of people, or even (5)

It's a bit like the Microsoft thing: Maybe not the best solution available, but so many people are sure that this is _the_ solution that they are willing to spend tremendous effort to actually make it work.

jonasw: well, they interest me.

That's my actual application.

tux, sure; I’m trying to explain why MQTT is seen as _the_ protocol without thought

jonasw: Really, I have the feeling that "MQTT" is just copy-pasted as buzzword.

that’s another possibility :)

I've talked to hardware vendors about why they choose to build an MQTT gateway and they say something along the line of "IoT needs MQTT"

re brief messages: have a look at EXI. {xep exi}

jonasw: Efficient XML Interchange (EXI) Format (Standards Track, Deferred, 2018-01-25) See: https://xmpp.org/extensions/xep-0322.html

has anyone heard of arc since the elections?

"Efficient"

https://nextcloud.com/talk/ anyone knows what they’re using?

I once built a system that used jstrophe and Smack to transfer data between Browser-based application and backend. However, this has been superseded by JS frameworks now. The advantage was that the Browser used the same backend as every other part of the system.

mathieui: xmpp, IIRC

https://telegram.org/blog/login

Heh, I was expecting to see a CMS login mask under that URL

https://bpaste.net/show/9e375f6d5d66 for those not in council@, interesting discussion (that should have be done here) about including non-white male in the XSF, and membership process

Wait there are logs of council right?

While working on https://tools.ietf.org/html/draft-ietf-mile-xmpp-grid-04 just now, I noticed that https://xmpp.org/extensions/xep-0030.html is version 2.5rc3. It would be good to get that spec out of whatever interim state it's in.

Also we seem to have lost https://xmpp.org/extensions/refs/ in transition at some point.

Which is bad because that's referenced from https://xml2rfc.tools.ietf.org/

Huh, the files are on the server, though...

Last updated 2017-03-17.

Maybe some rewrite rule gone sideways.

Maybe Kev or Intosi can figure that out

Yeah I'll ping the iteam

mathieui, https://github.com/nextcloud/server/search?q=xmpp&type=Issues&utf8=%E2%9C%93 XMPP it seems