XSF Discussion - 2018-05-15

  1. jonasw

    MattJ, Ge0rG, to be fair, the "worst" I did XMPP-wise was on that plastic router with 64 MiB of RAM. I used libstrophe/libcouplet there (despite a lua runtime available; I didn’t want to get into building libexpat for that system; when I was going to crosscompile, I could also simply crosscompile my C application).

  2. jonasw

    the SASL handshake still took considerable time on that system :)

  3. jonasw

    (one really wants PLAIN on really constrained systems)

  4. Ge0rG

    I'm not sure I can even fit TLS into the ESP

  5. ibikk

    MattJ, GeOrg: regarding home automation and mqtt: once I was fed up with openhab I hacked something which connects mqtt, some scripts and rules and a xmpp "command line interface". Maybe someone is interested? I'd have to document and upload it...

  6. Ge0rG

    ibikk: that's great but I want an Android app, so OpenHab is rather practical for that.

  7. Ge0rG

    What I hate about it is that it consumes gigabytes of RAM and that there is no way to abstract multiple identical multi-item controllers as entities

  8. ibikk

    the openhab app was OK, but I didn't want to expose openhab to the internet or use an VPN, therefore I did this xmpp command line, which in some aspects is far more powerful than openhab. also 'scripts' is misleading. it is a python app and provides scripts (have to be explicitly called by user) and (automatic) rules/controllers.

  9. ibikk

    in my home network there also is a browser interface.

  10. Ge0rG

    There is a subcommunity of people claiming that XMPP is awesome for IoT. I want to see that in practice.

  11. ibikk

    I do not. mqtt seems fine.

  12. Ge0rG

    ibikk: MQTT is okay for a small fleet of devices, but I want to have something where a device can bundle its API spec in a machine-readable way, like "I'm an RGBW controller and I support one HSV channel and one brightness channel and a global power switch"

  13. jonasw

    Ge0rG, there is a bearssl implementation.

  14. Ge0rG

    is there also a bearxmpp?

  15. Ge0rG

    and a bearxmppiot?

  16. jonasw

    I think hooking up libcouplet with that shouldn’t be too hard.

  17. Ge0rG

    jonasw: and then we are still lacking all of the IoT infrastructure that purportedly puts XMPP above MQTT for IoT.

  18. jonasw


  19. Ge0rG

    jonasw: feel free to prove me wrong.

  20. Ge0rG

    Right now I'm convinced that XMPP-IoT is overhyped to a degree that's actually harmful for IoT over XMPP

  21. jonasw

    I haven’t followed the work actual IoT people do

  22. jonasw

    I just do my own stuff with some pubsub and IQs

  23. jonasw

    that was easy enough to do with libcouplet and sleek and aioxmpp

  24. ibikk

    Ge0rG: I think people have proposed how to do something like this using mqtt? It does not fit my needs however. My devices don't even talk mqtt themselves.

  25. Ge0rG

    winfried: what was the scheduled appointment time again?

  26. jonasw

    Ge0rG, 1230 CEST

  27. Ge0rG

    Alright, thanks.

  28. MattJ

    Ge0rG, have you looked at Home Assistant? OpenHAB was a bit too heavy for me

  29. Ge0rG

    MattJ: that looks very interesting, thanks

  30. Ge0rG

    And it's not running node.js, despite being hosted on .io

  31. MattJ


  32. Ge0rG

    "Learn how Hass.io can turn your Raspberry Pi into the ultimate home automation hub" - Hass is the German word for "hate". So appropriate.

  33. MattJ

    They have an MQTT mode where the device posts its configuration

  34. MattJ

    Ge0rG, https://www.home-assistant.io/docs/mqtt/discovery/

  35. Ge0rG

    <node_id> (Optional): ID of the node providing the topic. <object_id>: The ID of the device. This is only to allow for separate topics for each device and is not used for the entity_id. node_id, object_id, entity_id... This looks like Designed by the XSF™

  36. MattJ


  37. Ge0rG

    I'm not sure why they need multiple topics for a single switch (set and state), if they could just have one that is read and written to and retained.

  38. Ge0rG

    and embedding the full path of that into the config kind of defeats the purpose

  39. MattJ

    The API has to handle many different kinds of devices, many APIs separate command and state, because in reality they are different

  40. Ge0rG

    right. Devices that react to "ON" and then set the HSV state to "0,0,100" or somesuch.

  41. Ge0rG

    It's awesome how fast you end up with a huge complexity overhead.

  42. MattJ


  43. jonasw

    also, sometimes setting might not work

  44. jonasw

    for example if the device is offline

  45. jonasw

    and you’d normally want to be able to detect that

  46. jonasw

    (or if it is slow or something)

  47. MattJ

    Yeah, the state essentially doubles as an ack for any command

  48. jonasw

    it’s common in commanding systems actually

  49. MattJ

    Also in Home Assistant it's generally optional anyway, if it's absent then the UI just assumes the state is whatever was requested, instantly (which obviously has downsides)

  50. Ge0rG


  51. Ge0rG

    I see where this is going.

  52. MattJ

    FWIW I consider XMPP suitable for higher-level IoT stuff, but not for device<->controller comms, unless the devices are powerful enough

  53. Ge0rG

    MattJ: my devices are sufficiently powerful.

  54. MattJ

    I consider most of the IoT XEPs to be over-engineered though

  55. MattJ

    Then XEP-0060 them and enjoy

  56. Ge0rG

    the hass discovery looks like a nice trade-off between complexity and comfort.

  57. Ge0rG

    The Converse.js on http://www.xmpp-iot.org is great. You have to click it away after Every. Freaking. Click.

  58. pep.

    When was the last gdpr meeting again, the one with all of us

  59. pep.


  60. Ge0rG

    pep.: I could tell you, but I need to gain consent from all attendees first.

  61. pep.

    yeah that sounds about right

  62. pep.

    Ge0rG, shut up :p

  63. Ge0rG

    pep.: do you want to make use of your right to Erasure?

  64. pep.

    let me gdpr the hell out of you. *goes and create a yax.im account*

  65. Ge0rG

    Damn. You win this round.

  66. Ge0rG goes looking for yax.im's power plug

  67. pep.

    hmm no there was nothing on 0504

  68. pep.

    last one with all of us seems to be 0430

  69. pep.

    Or my logs are lying to me

  70. pep.

    Ok I'm sending something for the minutes, 11 (& 12 that was cancelled)

  71. pep.

    Ge0rG, jonasw, winfried, meeting in ~10min

  72. winfried


  73. Ge0rG

    I'm on the run right now, can't promise anything

  74. pep.


  75. pep.


  76. winfried

    t -2 ;-)

  77. jonasw


  78. Ge0rG

    Okay, so I'm in the expected lunch break, but I'm alone so I can focus on the GDPR.

  79. winfried


  80. winfried

    lets recapp

  81. pep.

    There's a question (quotes) I added in the minutes, that I think we didn't really focus on

  82. pep.

    I don't know if we can answer it by ourselves though

  83. winfried

    pep.: can you repeat the question(s) here?

  84. pep.

    Do we have to find all the data scattered across all different services, re export/deletion

  85. pep.

    "all different services", meaning not ours

  86. Ge0rG

    We'd have to monitor all the services a user uses and how

  87. winfried

    pep.: from a legal perspective not: the data is transferred and not 'our' responsibility anymore

  88. pep.

    Ge0rG, I'm not saying it'd be easy or even fun, just asking from a legal standpoint

  89. pep.

    winfried, k

  90. winfried

    still thinking it would be fun ;-)

  91. pep.

    Ok, so what's left

  92. Ge0rG

    winfried: that's too easy for an answer. If we are the controller, we are probably still responsible, aren't we?

  93. Ge0rG

    What if Facebook "transfers" the data from Facebook EU Inc. to Facebook USA?

  94. winfried

    Ge0rG: IF we are controller yes, but there is no controller - processor situation but a transfer between two controllers

  95. winfried

    Ge0rG: FB EU -> FB US is transfer between two controllers, in the FB case that is not covered by 6.1b, so it has to be 6.1a

  96. Ge0rG

    winfried: so we are controllers, but the other servers are controllers too?

  97. winfried

    Ge0rG: yes... that was one of the first premises we started with ;-)

  98. Ge0rG

    winfried: I've always seen that as "controllers of our users' friends' data"

  99. Ge0rG

    Which is not the same thing

  100. winfried

    what difference do you see (I am still digesting that one)

  101. pep.

    Ge0rG, that would make the s2s server a processor, but then how do you say you're not liable for what the contact does with MAM

  102. jonasw

    I think with Ge0rGs interpretation we can argue that after the transfer the data is at the recipients control and the handling of the data is owned by the recipent, thus the recipient is responsible for all things GDPR and whether the senders privacy preferences are matched is a matter of trust between recipient and sender.

  103. Ge0rG

    winfried: remote PubSub is data that a user's server transmits to a different server (controller?) on behalf of the user. Now does the remote server need to obtain consent from the user?

  104. Ge0rG

    I'm explicitly not talking about data sent to other users.

  105. winfried

    Ge0rG: no, that is still 6.1b, so no consent. But the remote server, when it falls under the jurisdiction of the GDPR, needs to publish its privacy policy

  106. Ge0rG

    winfried: and if it's in a third country?

  107. pep.

    then it's 49.1b, no consent required

  108. winfried

    pep.: thanks, you got the article number before me ;-)

  109. pep.

    Ah hmm, if that's not a controller that's different?

  110. pep.

    Ah nvm

  111. Ge0rG

    winfried: great. Can we have that in the wiki, then?

  112. winfried

    yes pep. plz remind me ;-)

  113. pep.

    So wait, that means.. transfer between controllers? Or what Ge0rG said?

  114. Ge0rG

    pep.: it is transfer between controllers

  115. Ge0rG

    And what I said

  116. pep.

    > Ge0rG> winfried: I've always seen that as "controllers of our users' friends' data"

  117. Ge0rG

    What did I say? And when?

  118. Ge0rG

    pep.: two different use cases. Messages sent to other users vs things we store on other servers.

  119. winfried

    Ge0rG: yes, good to distinguish between them

  120. Ge0rG

    pep.: if I send you a message, you become the owner on your server. If I publish a post on movim, I stay the owner

  121. pep.

    Ok, so what winfried said doesn'T apply to MAM?

  122. Ge0rG

    pep.: what kind of MAM?

  123. pep.


  124. winfried

    pep.: if it is my server archiving your messages in the conversation I had with you, then that MAM is my responsibility

  125. Ge0rG

    pep.: and what did winfried say?

  126. pep.

    winfried, yes that's what I thought until now, but you're all confusing me with words :p

  127. winfried

    I propose I try to write it down in clear wording in the Wiki, plz correct if that is still confusing/incorrect. agreed?

  128. pep.

    Ge0rG, so "Ge0rG> winfried: I've always seen that as "controllers of our users' friends' data"" < this is wrong?

  129. pep.


  130. Ge0rG

    winfried: s/propose/volunteer/, right?

  131. pep.

    It's "not the interpretation we choose to think will be applied"

  132. winfried

    Ge0rG: yes

  133. Ge0rG

    pep. [12:57]: > Ge0rG, so "Ge0rG> winfried: I've always seen that as "controllers of our users' friends' data"" < this is wrong? This is true as well, for the remote copy of the message I sent to my friend

  134. winfried

    pep.: correct, but we can only discuss/check an interpretation if it is worded complete and clear

  135. Ge0rG

    We need to choose an interpretation anyway, and then hope we don't have to defend it in court

  136. Ge0rG

    It's better to have an interpretation that we can reasonably agree on than not to have any

  137. pep.


  138. winfried

    and there is an interesting subtle issue here: when becomes my message the responsibility of the receiving person?

  139. pep.

    Once it gets over s2s?

  140. winfried

    I will try to word as precise as I can so we can decide ...

  141. Ge0rG

    winfried: when the receiving person opted to use offline storage / MAM and the message arrives there?

  142. winfried

    :-D I see different opinions here

  143. winfried

    I tend to the pov of Ge0rG

  144. winfried

    as long as it is on the receivers server and not transferred to the receiver, the message is nobodies responsibility if we take s2s as border

  145. winfried

    but let me think about that one a bid and let me word it in the wiki

  146. pep.


  147. Ge0rG

    winfried: if the message is discarded, it doesn't matter. If it is stored, the recipient is the most logical person

  148. winfried

    Ge0rG: correct

  149. pep.

    I'd like to see setups where there is no offline storage / MAM at all

  150. winfried

    Have you seen the pdf I posted to the members list? Is that the way to go for the consequences for server operators? (Q1.2)

  151. winfried

    (oops it was odg)

  152. winfried


  153. pep.

    yes, digesting all this

  154. jonasw

    still sick :(

  155. jonasw

    I’m half-following

  156. winfried

    jonasw: :-( hope you get better soon!

  157. jonasw


  158. Ge0rG

    I didn't see a PDF, but there was an .odg

  159. winfried


  160. pep.

    The table?

  161. pep.

    So today is clarification day

  162. pep.

    How are we regarding things that can be sent to standards@ already

  163. winfried

    GDPR scheme.odg attached to a reply to minutes 10

  164. pep.

    hmm, should we plan for next, doesn't seem to be really active today

  165. winfried

    Waiting for reactions... ;-)

  166. Ge0rG

    winfried: waiting for the mail server? Forget it.

  167. jonasw

    why waiting for the email server?

  168. pep.

    winfried, you're talking about https://wiki.xmpp.org/web/GDPR/Table ?

  169. Ge0rG

    winfried> GDPR scheme.odg attached to a reply to minutes 10

  170. jonasw

    Ge0rG, it’s already been sent last week

  171. jonasw


  172. jonasw

    that’s a screen shot of it

  173. Ge0rG

    oh, I misread that as "10 minutes ago" and was looking for new replies.

  174. jonasw

    timestamp of the mail is 2018-05-08 11:56Z

  175. pep.


  176. Ge0rG

    yeah, had that open already.

  177. winfried

    jonasw: that is the first page

  178. jonasw

    there are more pages?

  179. jonasw


  180. pep.

    winfried, "on a large scale", is this even important?

  181. jonasw

    I don’t know that tool

  182. Ge0rG

    Oh, there is a second page!

  183. jonasw

    I assumed when I scroll down and reach the end of a page there aren’t more pages :D

  184. winfried

    jonasw: yeah bad UI

  185. winfried

    pep.: not for the XSF context, but it helps asses server operators if they should to anything

  186. pep.


  187. pep.

    I guess I should start working on that XEP quick

  188. pep.

    10days to write it and get it council approved(tm)!

  189. winfried


  190. pep.

    And just after that, deployed everywhere!

  191. jonasw

    noooot gonna happen

  192. jonasw

    unless you manage to submit it today :)

  193. pep.


  194. pep.


  195. winfried

    of you don't have your act together on the 25th in the Netherlands, you may get a warning and some more months to correct it :-P

  196. pep.


  197. pep.

    I guess they'll have to do that for a lot more people

  198. winfried

    any amendments to the scheme?

  199. Ge0rG

    in Austria you get a warning. Full stop.

  200. pep.

    winfried, template looks ok to me. Maybe alongside MAM specify offline storage

  201. pep.

    How do you even set offline storage available but not active by default

  202. Ge0rG

    winfried: step 5 might be "require consent for processing beyond the XSF template"

  203. winfried

    good points!

  204. winfried

    maybe split step 5 in two options: when using the XSF template (or equivalent) or when doing processing beyond that.

  205. pep.

    Zash, MattJ, is there a way to have offline storage stanby and do nothing atm?

  206. MattJ


  207. pep.

    Have offline storage opt-in

  208. winfried

    Next meeting: friday 13:30 CEST

  209. pep.

    winfried, ok

  210. MattJ

    pep., not currently possible to configure per-user, if that's what you mean

  211. pep.

    ok, I guess that also need changing in the protocol

  212. MattJ

    Totally possible, just not implemented

  213. pep.

    ah ok

  214. MattJ

    Well, M-Link uses ad-hoc commands for that

  215. MattJ

    Though a number of clients don't support them

  216. pep.

    Yeah so it's not specified

  217. pep.

    -xep offline

  218. pep.

    Bunneh! where are you when I need you

  219. MattJ

    I always wanted a "user account configuration" XEP

  220. pep.

    There is IBR, in some ways

  221. Ge0rG

    With data forms! And hookers!

  222. winfried

    pep.: do you summarize minutes again?

  223. pep.

    winfried, I'll try to do that yes :x

  224. winfried

    pep.: thanks!

  225. winfried

    then there is one thing left for me:

  226. winfried *bangs* the gavel

  227. winfried

    thanks once again guys!

  228. pep.

    Ge0rG, and jonasw ok with the date?

  229. jonasw

    thanks folks

  230. Ge0rG

    pep.: hope so

  231. jonasw

    pep., yes, still OK

  232. pep.


  233. pep.

    Updated the date on the wiki

  234. winfried

    pep.: thanks!

  235. edhelas

    winfried I'm telling it you here, I don't have OMEMO on my device, so please desactivate it with my JID

  236. winfried

    Done, thank Daniel :-P

  237. edhelas

    because I'm getting more and more like that I'm thinking of an automatic reply

  238. Holger

    edhelas: I could sell you <https://github.com/processone/ejabberd-contrib/tree/master/mod_deny_omemo> ...

  239. edhelas

    no it's more a client side feature

  240. Ge0rG

    Dave Cridland: was there an update to hacx to put it onto the agenda again? Cc jonasw

  241. moparisthebest

    nope will get it out tonight if we don't have another unexpected area-wide power outage :)

  242. jonasw

    Ge0rG, not that I knew

  243. Dave Cridland