XSF Discussion - 2018-02-07

  1. ralphm


  2. ralphm

    Some comments on XMPP and IoT.

  3. tux

    Thanks for the link!

  4. tux

    Public transport seems to go for MQTT. :/

  5. tux

    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).

  6. tux

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

  7. zinid

    tech this days...

  8. zinid

    driven by buzzwords exclusively

  9. edhelas

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

  10. jonasw

    I think people did that

  11. tux

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

  12. tux

    Unless you are Google or so

  13. jonasw

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

  14. zinid

    > you cannot engineer against the market Nailed it

  15. zinid

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

  16. Ge0rG

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

  17. jonasw

    Ge0rG, hah

  18. Ge0rG

    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?

  19. Ge0rG

    Do we have those over XMPP?

  20. Ge0rG

    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.

  21. Ge0rG

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

  22. Ge0rG


  23. zinid

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

  24. Ge0rG

    zinid: are they?

  25. zinid

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

  26. zinid

    While xmmp is transport plus application specific payload

  27. Ge0rG

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

  28. zinid

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

  29. zinid

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

  30. jonasw

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

  31. jonasw

    (but IIRC authn was weird with MQTT)

  32. Tobias

    using TLS certs for auth?

  33. Ge0rG

    jonasw: was there any at all?

  34. jonasw

    lemme check

  35. jonasw

    I did a survey of IoT technologies in a class

  36. jonasw

    Ge0rG, plain text passwords

  37. jonasw

    not sure if you count that as authn

  38. Ge0rG

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

  39. jonasw

    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

  40. jonasw

    maybe that helps to get you on the same pages

  41. jonasw

    maybe that helps to get you on the same page?

  42. Ge0rG

    jonasw: so _you_ are that XXX guy!

  43. jonasw


  44. jonasw

    I should’ve used another thing to blank it out

  45. jonasw

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

  46. jonasw

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

  47. Ge0rG

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

  48. jonasw

    I planned to ask him at some point :-)

  49. jonasw

    maybe I should just do that

  50. zinid

    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

  51. zinid

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

  52. jonasw

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

  53. zinid

    jonasw, how will you find peers?

  54. Ge0rG

    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?

  55. Ge0rG

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

  56. zinid

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

  57. Ge0rG

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

  58. zinid

    sounds like a niche for XMPP

  59. zinid

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

  60. Ge0rG

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

  61. zinid

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

  62. zinid

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

  63. Ge0rG

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

  64. zinid

    Ge0rG, OMEMO!

  65. Ge0rG

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

  66. SaltyBones

    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.

  67. Ge0rG

    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

  68. SaltyBones

    I totally agree with that as well.

  69. zinid

    because nobody is working on these tools

  70. zinid

    well, at least currently

  71. SaltyBones

    Well... tigase?

  72. zinid

    I meant the specs

  73. zinid

    did tigase produce them?

  74. zinid

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

  75. Flow

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

  76. Flow

    peter waher that is

  77. Holger

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

  78. Holger

    I.e. SASL, sessions, routing.

  79. Ge0rG

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

  80. zinid

    Ge0rG, and what value does XMPP provide then?

  81. zinid

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

  82. Holger

    Ge0rG: On top of what?

  83. Holger

    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).

  84. Holger

    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.

  85. Dave Cridland

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

  86. Flow

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

  87. Flow

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

  88. Dave Cridland

    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.

  89. Flow

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

  90. Flow

    not tigase

  91. Flow

    which I assume is the group Holger talks about

  92. zinid

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

  93. Holger

    Flow: Right.

  94. Flow

    zinid, course we have

  95. zinid

    "Waher" people do IoT, others do MQTT and so on?

  96. Flow


  97. Holger

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

  98. zinid

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

  99. Flow

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

  100. jonasw

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

  101. Flow

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

  102. Flow

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

  103. Flow

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

  104. Flow

    or maybe even just some anonymous individual

  105. Holger

    Ah. Ok, whatever :-)

  106. Flow

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

  107. Holger

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

  108. Flow

    Holger, stefandxm has some stuff published

  109. Holger


  110. Flow

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

  111. Holger

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

  112. Flow

    as long as you care for open standards ;)

  113. Dave Cridland

    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.

  114. Flow

    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

  115. jonasw

    Flow, !xep 198

  116. jonasw waves at Bunneh

  117. Seve/SouL

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

  118. Flow

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

  119. Dave Cridland

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

  120. jonasw

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

  121. jonasw

    looks suspiciously as if that was the issue

  122. jonasw

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

  123. vanitasvitae

    jonasw: where exactly should I clamp?

  124. jonasw

    I thnik it’s written in the text

  125. jonasw


  126. jonasw

    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.

  127. vanitasvitae

    I'll check :)

  128. vanitasvitae

    Thank you

  129. jonasw

    -xep 198

  130. Bunneh

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

  131. jonasw

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

  132. vanitasvitae

    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?

  133. jonasw

    vanitasvitae, yes

  134. vanitasvitae

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

  135. vanitasvitae


  136. vanitasvitae

    Thank you :)

  137. jonasw


  138. Dave Cridland

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

  139. Seve/SouL

    Dave Cridland, yeah...

  140. Holger

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

  141. vanitasvitae

    jonasw: now it works. Nice :)

  142. Ge0rG

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

  143. Ge0rG

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

  144. Ge0rG

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

  145. Ge0rG

    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.

  146. tux

    Sorry, work called me out

  147. tux

    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.

  148. jonasw


  149. tux

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

  150. tux


  151. jonasw


  152. jonasw


  153. tux


  154. jonasw

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

  155. jonasw

    was wondering if there was a new shiny thing

  156. tux

    not really

  157. Flow

    -xep 363

  158. Bunneh

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

  159. tux

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

  160. jonasw


  161. tux

    is an option

  162. Ge0rG

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

  163. jonasw


  164. tux

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

  165. jonasw

    tux, json-over-websockets!

  166. tux

    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

  167. tux

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

  168. tux

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

  169. Ge0rG

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

  170. tux

    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.

  171. tux

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

  172. Dave Cridland

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

  173. tux

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

  174. tux

    Only that XMPP is not known.

  175. jonasw

    tux, depends on your requirements

  176. jonasw

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

  177. tux

    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.

  178. tux

    jonasw: well, they interest me.

  179. tux

    That's my actual application.

  180. jonasw

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

  181. tux

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

  182. jonasw

    that’s another possibility :)

  183. tux

    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"

  184. jonasw

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

  185. Bunneh

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

  186. jonasw

    has anyone heard of arc since the elections?

  187. zinid


  188. mathieui

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

  189. tux

    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.

  190. zinid

    mathieui: xmpp, IIRC

  191. edhelas


  192. Ge0rG

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

  193. pep.

    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

  194. pep.

    Wait there are logs of council right?

  195. peter

    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.

  196. peter

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

  197. peter

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

  198. peter

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

  199. peter

    Last updated 2017-03-17.

  200. ralphm

    Maybe some rewrite rule gone sideways.

  201. ralphm

    Maybe Kev or Intosi can figure that out

  202. peter

    Yeah I'll ping the iteam

  203. jjrh

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