XSF Discussion - 2018-05-22

  1. la|r|ma has joined

  2. lskdjf has joined

  3. ta has joined

  4. ta has joined

  5. Dave Cridland has left

  6. Dave Cridland has left

  7. lnj has left

  8. dwd has left

  9. j.r has joined

  10. j.r has joined

  11. Dave Cridland has left

  12. Dave Cridland has left

  13. Dave Cridland has left

  14. dwd has left

  15. Chobbes has left

  16. alexis has left

  17. dwd has left

  18. alexis has joined

  19. waqas has left

  20. dwd has left

  21. Dave Cridland has left

  22. Dave Cridland has left

  23. Neustradamus has left

  24. jonasw has left

  25. jonasw has joined

  26. alexis has left

  27. Neustradamus has left

  28. alexis has joined

  29. alexis has left

  30. alexis has joined

  31. Dave Cridland has left

  32. Neustradamus has left

  33. Neustradamus has joined

  34. Dave Cridland has left

  35. waqas has joined

  36. dwd has left

  37. Dave Cridland has left

  38. Dave Cridland has left

  39. dwd has left

  40. Guus has left

  41. j.r has left

  42. j.r has joined

  43. Zash has left

  44. Dave Cridland has left

  45. alexis has left

  46. alexis has joined

  47. efrit has joined

  48. alexis has left

  49. alexis has joined

  50. Dave Cridland has left

  51. dwd has left

  52. Chobbes has joined

  53. alacer has joined

  54. SamWhited has joined

  55. alacer has left

  56. alacer has joined

  57. alacer has left

  58. alacer has joined

  59. SaltyBones has left

  60. alexis has left

  61. alexis has joined

  62. alexis has left

  63. SaltyBones has joined

  64. alexis has joined

  65. alexis has joined

  66. Guus has left

  67. Neustradamus has left

  68. Ge0rG has joined

  69. ta has left

  70. ta has joined

  71. Neustradamus has left

  72. alexis has left

  73. mrdoctorwho has left

  74. alexis has joined

  75. lorddavidiii has joined

  76. efrit has left

  77. SamWhited has left

  78. SaltyBones has left

  79. SaltyBones has joined

  80. Nekit has joined

  81. marmistrz has joined

  82. jere has joined

  83. marmistrz has joined

  84. j.r has joined

  85. j.r has joined

  86. alexis has left

  87. lorddavidiii has left

  88. Tobias has left

  89. Tobias has joined

  90. winfried has joined

  91. winfried has joined

  92. Andrew Nenakhov has left

  93. Andrew Nenakhov has joined

  94. Andrew Nenakhov has left

  95. Andrew Nenakhov has joined

  96. Guus has left

  97. Andrew Nenakhov has left

  98. Andrew Nenakhov has joined

  99. Andrew Nenakhov has left

  100. Andrew Nenakhov has joined

  101. goffi has joined

  102. tux has left

  103. tux has joined

  104. Nekit has left

  105. Nekit has joined

  106. lovetox has joined

  107. bear has left

  108. andy has joined

  109. Seve/SouL has left

  110. Neustradamus has left

  111. Guus has left

  112. lorddavidiii has joined

  113. ralphm has left

  114. Tobias has left

  115. Tobias has joined

  116. bear has joined

  117. Guus has left

  118. mimi89999 has joined

  119. intosi has joined

  120. Guus has left

  121. Guus has left

  122. j.r has joined

  123. SaltyBones has left

  124. SaltyBones has joined

  125. j.r has joined

  126. j.r has joined

  127. j.r has joined

  128. Tobias has joined

  129. daniel has left

  130. SaltyBones has left

  131. SaltyBones has joined

  132. Tobias has joined

  133. SaltyBones has left

  134. Dave Cridland has left

  135. lnj has joined

  136. ralphm has joined

  137. la|r|ma has joined

  138. rtq3 has joined

  139. rtq3 has left

  140. remko has joined

  141. rtq3 has joined

  142. SaltyBones has joined

  143. nyco has left

  144. marmistrz has joined

  145. nyco has joined

  146. marmistrz has left

  147. SaltyBones has left

  148. SaltyBones has joined

  149. SaltyBones has left

  150. SaltyBones has joined

  151. SaltyBones has left

  152. SaltyBones has joined

  153. SaltyBones has left

  154. SaltyBones has joined

  155. Valerian has joined

  156. SaltyBones has left

  157. SaltyBones has joined

  158. Steve Kille has left

  159. Steve Kille has left

  160. Dave Cridland has left

  161. Steve Kille has joined

  162. pep. has left

  163. Valerian has left

  164. Valerian has joined

  165. SaltyBones has left

  166. la|r|ma has joined

  167. rtq3 has left

  168. Dave Cridland has left

  169. flow has left

  170. flow has joined

  171. flow has left

  172. flow has joined

  173. alexis has joined

  174. Steve Kille has left

  175. alexis has left

  176. alexis has joined

  177. blabla has left

  178. blabla has joined

  179. mimi89999 has joined

  180. lskdjf has joined

  181. alexis has joined

  182. rtq3 has joined

  183. alexis has left

  184. daniel has left

  185. daniel has joined

  186. j.r has left

  187. j.r has joined

  188. alexis has joined

  189. marmistrz has joined

  190. ralphm has left

  191. SaltyBones has joined

  192. lumi has joined

  193. jubalh has joined

  194. mimi89999 has left

  195. daniel has left

  196. ibikk has left

  197. ibikk has joined

  198. j.r has joined

  199. j.r has joined

  200. jubalh has joined

  201. jubalh has joined

  202. jubalh has joined

  203. jubalh has joined

  204. daniel has joined

  205. ralphm has joined

  206. edhelas has left

  207. edhelas has joined

  208. SaltyBones has left

  209. SaltyBones has joined

  210. jubalh has left

  211. jubalh has joined

  212. SaltyBones has left

  213. SaltyBones has joined

  214. waqas has left

  215. j.r has joined

  216. j.r has joined

  217. SaltyBones has left

  218. SaltyBones has joined

  219. lskdjf has left

  220. lskdjf has joined

  221. rtq3 has left

  222. rtq3 has joined

  223. andy has left

  224. SaltyBones has left

  225. SaltyBones has joined

  226. ibikk has joined

  227. la|r|ma has left

  228. SaltyBones has left

  229. SaltyBones has joined

  230. nyco has left

  231. nyco has joined

  232. j.r has left

  233. j.r has joined

  234. pep.

    gdpr meeting in 10?

  235. pep.

    jonasw, winfried, Ge0rG

  236. SaltyBones has left

  237. SaltyBones has joined

  238. SaltyBones has left

  239. SaltyBones has joined

  240. SaltyBones has left

  241. mimi89999 has joined

  242. SaltyBones has joined

  243. SaltyBones has left

  244. SaltyBones has joined

  245. SaltyBones has left

  246. SaltyBones has joined

  247. Ge0rG

    pep.: I thought 1230?

  248. Ge0rG

    But I can do either

  249. pep.

    Ah fail

  250. pep.

    10:30 UTC indeed

  251. jonasw

    sudo -u pep. sudo apt install tzdata 😸

  252. jonasw

    a.k.a. timezones are hard

  253. ta has joined

  254. pep.

    `useradd: invalid user name 'pep.'`

  255. Ge0rG

    RCE over MUC=

  256. winfried has left

  257. jonasw

    Ge0rG: only in signal :>

  258. jonasw has left

  259. j.r has left

  260. SaltyBones has left

  261. j.r has joined

  262. Andrew Nenakhov has left

  263. SaltyBones has joined

  264. Andrew Nenakhov has joined

  265. Steve Kille has left

  266. Andrew Nenakhov has left

  267. Andrew Nenakhov has joined

  268. ThibG has joined

  269. ThibG has joined

  270. SaltyBones has left

  271. daniel has left

  272. Steve Kille has joined

  273. ibikk has joined

  274. jonasw

    GDPR in 9, Ge0rG, winfried, pep.

  275. pep.


  276. Andrew Nenakhov has joined

  277. Valerian has left

  278. Ge0rG

    I have prepared temporary ToS and Privacy Policies for yax.im, which I would like to make available as a template for the XSF: https://yaxim.org/yax.im/tos/ and https://yaxim.org/yax.im/privacy/

  279. Valerian has joined

  280. Andrew Nenakhov has left

  281. Valerian has left

  282. daniel has joined

  283. winfried


  284. jonasw

    is a recital sufficient? or does it need an actual paragraph which instantiates that recital?

  285. Ge0rG

    a what?

  286. Valerian has joined

  287. alacer has left

  288. alacer has joined

  289. winfried bangs the gavel and welcomes pep. jonasw and Ge0rG to the GDPR meeting

  290. pep.


  291. jonasw

    Ge0rG, your opt-out wording is confusing: > You can opt out from this by unsubscribing these contacts from your contact list. ("what does unsubscribing from a contact list mean?") I’d suggest: > By allowing a user to subscribe (typically this is done when adding to the contact list), you opt into this transfer.

  292. jonasw waves at winfried

  293. winfried

    jonasw: yes, wording it as an opt-in is better

  294. winfried

    Agenda for to?

  295. winfried


  296. pep.

    yeah, opt-in might be better

  297. pep.

    What do we have on the agenda today? The template?

  298. alacer has left

  299. pep.

    Not much progress on the EULA XEP. I gathered the requirements here, https://cryptpad.fr/code/#/2/code/edit/IiUC5h-fzN14FAeSdcBoAQgc/ but I haven't started the protocol bits

  300. alacer has joined

  301. winfried

    I feel like taking a look at the bigger picture: where are we, what is the course of action (looking at the MAM discussion in standards@) what are the todo's and how to do them

  302. jonasw

    I’d also word the push service paragraph differently: now: > If you enable push notifications (e.g. on a mobile client), the data that is required to perform the push notification (typically a device ID and message meta data) is transmitted to the respective push service provider (Art. 6.1b, Art. 49.1b). my suggestion: > If you enable push notifications (e.g. on a mobile client), the message is transferred (Art. 6.1b, Art. 49.1b) to a server designated by the client application. The processing afterwards is subject to the data protection policies of the applications server and the respective push service provider.

  303. jonasw

    yeah, sorry about the EULA XEP, I was more busy than I anticipated

  304. pep.

    jonasw, no worries, I didn't have much time either

  305. jonasw

    re push paragraph: because technically, you’re transferring the complete message to the applications service and then it’s already out of your control, Ge0rG.

  306. winfried

    neither did I ;-)

  307. jonasw

    if my memory of the push protocol is right

  308. winfried

    jonasw: daniel posted a nice link to the implementation he uses. It reveals minimal data, the push service even doesn't know what application it is pushing to!

  309. pep.

    winfried, of course it does? How would that work otherwise

  310. jonasw

    winfried, true, but as an XMPP server provider, you can’t be sure about which app server software is used.

  311. winfried

    jonasw: correct

  312. jonasw

    and you transfer at teh very least message body and timestamp to the app server, at which point it’s out of your control

  313. pep.

    jonasw, "app server"?

  314. pep.

    the push component?

  315. jonasw

    pep., the server provided by the client (e.g. Conversations) which transforms the XMPP Pushes (as specified in XEP-0357) to whatever is needed on the provider (google) side.

  316. pep.


  317. jonasw

    pep., cf. https://xmpp.org/extensions/xep-0357.html#sect-idm139090519180208

  318. jonasw

    "Push Service" and "User Agent" are owned by e.g. google, but the App Server is run by the client application authors, and not by the XMPP server provider

  319. Ge0rG

    jonasw: I'm not pushing actual message content, just placeholders.

  320. jonasw

    Ge0rG, is that a modification of mod_cloud_push?

  321. Ge0rG

    jonasw: no, default behavior with a custom setting.

  322. jonasw

    in any case, the statement is incorrect insofar that it suggests that (only) google/apple is the nexthop, but there’s the app server inbetween

  323. Ge0rG

    `push_notification_important_body = "Important message";`

  324. Holger

    jonasw: The protocol allows for including the sender address and message contents with the push notification, but that's optional and neither Prosody nor ejabberd will do that by default.

  325. Holger

    jonasw: The notification is not a message stanza but a PubSub-like IQ.

  326. Ge0rG

    jonasw: updated both places, thanks. Please have a look at the new push wording

  327. Dave Cridland has left

  328. Ge0rG

    Holger: we are not talking about stanzas but about user content.

  329. Ge0rG

    Holger: so "message" in this context is rather the <body> element.

  330. jonasw

    s/opt in into/opt into/?

  331. alacer has left

  332. Ge0rG

    isn't the verb "opt in"?

  333. Ge0rG

    maybe "opt in to"?

  334. winfried

    Ge0rG: I would say so

  335. Ge0rG

    !summon native speaker

  336. jonasw

    okay, nits though

  337. jonasw

    otherwise I think this looks good

  338. jonasw

    but, IANAL

  339. pep.

    Ge0rG, can I link to your yax.im URLs or should we move that to the wiki

  340. pep.

    in the minutes

  341. Ge0rG

    pep.: They are WIP right now, so I'd rather not have them linked "publically"

  342. jonasw

    copying would be fine though?

  343. pep.

    k, so maybe we can copy that to the wiki

  344. rtq3 has left

  345. Ge0rG

    I'd like to establish some process where we have a master copy and the yax.im ToS are a fork of that.

  346. winfried

    Ge0rG: git!

  347. Ge0rG

    so you can fork it yourself and profit from later updates.

  348. jonasw

    maybe a repository under xsf?

  349. jonasw

    or xmpp?

  350. Ge0rG

    markdown + C preprocessor?

  351. Ge0rG

    jonasw: moving a git is the easiest part.

  352. Ge0rG

    the hard part is the split of template and specific server content.

  353. jonasw


  354. pep.


  355. jonasw

    jinja is a neat templating language

  356. Ge0rG

    Or maybe some kind of ToS generator?

  357. jonasw

    would be trivial to build a generator on top of that

  358. Ge0rG

    Jinja is Beautiful. {% extends "layout.html" %} {% block body %} <ul> {% for user in users %} <li><a href="{{ user.url }}">{{ user.username }}</a></li> {% endfor ...

  359. Ge0rG

    They lost me at {%

  360. jonasw

    they copied that from erb I think

  361. pep.

    I don't think we should focus on html

  362. Ge0rG

    Markdown is an ideal language for the content, minus the templating.

  363. jonasw

    the advantage I see in jinja that its inheritance and block stuff would allow for easy replacement of specific blocks.

  364. jonasw

    and extension

  365. jonasw

    that would be cumbersome with C preprocessor

  366. Ge0rG

    We could also `sed -e s/ZZZservernameZZZ/$SERVERNAME/g`

  367. jonasw

    those are technicalities

  368. Ge0rG

    or use bash here-documents.

  369. jonasw

    let’s focus on what winfried suggested

  370. Ge0rG

    I don't care. I just don't want to learn a new templating engine language.

  371. Ge0rG


  372. jonasw

    10:34:00 winfried> I feel like taking a look at the bigger picture: where are we, what

  373. jonasw

    Ge0rG, ^

  374. Ge0rG


  375. Ge0rG


  376. Dave Cridland has left

  377. pep.

    In the meantime I don't have anything to show for this part of the minutes :x

  378. pep.

    But we can sort this out later

  379. winfried

    hey, I am participating again :-P

  380. winfried

    Big picture: we have some things we want to change on protocol level

  381. winfried


  382. winfried


  383. winfried

    Transfer of data

  384. winfried

    (any other?)

  385. daniel has left

  386. winfried

    ah, defaults for MAM

  387. Ge0rG

    retention times for MAM and HTTP uploads.

  388. Ge0rG

    Current implementations lack auto-removal of "expired" entries

  389. pep.

    s/HTTP uploads/server-side file storage/

  390. winfried

    There was some discussion on the standards@ list about incorporating local laws in standards

  391. Dave Cridland has left

  392. daniel has joined

  393. winfried

    what is our opinion in that?

  394. pep.

    Allowing deletion via the protocol has nothing to do with local laws right

  395. winfried

    I guess some topics are generic and not specifically for one jurisdiction

  396. Ge0rG

    winfried: the protocol purist in me says we should not encode local laws into our protocols.

  397. Ge0rG

    OTOH, the pragmatist requests an easy way for server operators to comply with local laws.

  398. pep.

    Ge0rG, I think I agree with that, but deletion itself is just a technicality and not a law

  399. rtq3 has joined

  400. pep.

    We might want to have another informational "GDPR compliance" XEP

  401. winfried

    Ge0rG: and what about an optional extension that describes an action needed in a certain jurisdiction...?

  402. Ge0rG

    winfried: I'd go with Business Rules paragraphs in relevant XEPs

  403. andy has joined

  404. Ge0rG

    while true ; do killall -STOP lua5.1 sqlite3 prosody.sqlite 'DELETE FROM prosodyarchive WHERE host="yax.im" AND store="archive2" AND "when" < '$(($(date +%s)-14*24*3600))' LIMIT 5000;' killall -CONT lua5.1 sleep 2 done

  405. Ge0rG

    This is how I'm doing GDPR compliance right now.

  406. winfried

    Ge0rG: :-D

  407. Ge0rG

    And this is not only fugly, it's also killing my availability / latency.

  408. jonasw

    sleep 2?!

  409. winfried

    I can imagine you want something more... sophisticated

  410. Ge0rG

    jonasw: yes. I can't just delete *all* messages at once because there are too many.

  411. Ge0rG

    deleting 5k takes <10s, so it's just barely bearable.

  412. pep.

    How many users do you have again?

  413. pep.

    Active users

  414. Ge0rG


  415. Ge0rG

    But I have some active bots, it seems. And for reasons beyond my understanding, those bots are using MAM

  416. winfried

    So do we agree on: 1) patching XEPs / adding XEPs when generic functionality is needed for compliance 2) adding busisness rule paragraphs to relevant XEPs to explain about local laws?

  417. pep.

    Ok, so back to XEPs,

  418. winfried

    3) informational GDPR XEP?

  419. pep.

    if 3), is 2) required

  420. pep.

    We definitely need 1) in any case

  421. alacer has joined

  422. pep.

    And I don't think anybody will argue this

  423. winfried

    jonasw: ?

  424. Ge0rG

    what do we nee 1 for?

  425. Ge0rG

    patching XEPs is #2, isn't it?

  426. rtq3 has left

  427. winfried

    New XEP: eula XEP, http storage management

  428. jonasw

    Ge0rG, (1) is adding functionality, (2) is adding business rules

  429. jonasw

    those are differences, and (2) can be moved to a generic GDPR XEP, while (1) can’t

  430. jonasw

    (well, could, but it wouldn’t make sense)

  431. pep.

    jonasw, 1 could be added to an addon XEP, but :/

  432. pep.

    Not informal

  433. pep.


  434. Dave Cridland

    I'd rather not plaster every XEP with detailed GDPR implementation stuff. Rather, at most a pointer to another XEP. Otherwise the conflict between different jurisdictions is going to get very complicated, especially with normative language.

  435. Ge0rG

    Re EULA XEP: do we need explicit consent?

  436. winfried

    pep.: think we need to decide on a case to case base if an add on is better of patching the xep

  437. Ge0rG

    If we need explicit consent, the EULA-on-IBR would be one possible implementation, with a web form based registration another obvious one.

  438. pep.

    Dave Cridland, 1. above is not "GDPR implementation stuff", right

  439. pep.

    2 and 3 are, and I'm also leaning towards 3

  440. pep.

    rather than 2

  441. winfried

    I guess Dave Cridland meant the choice between 2 and 3

  442. Ge0rG

    Dave Cridland: I was thinking along the lines of "A server implementation must provide a way to delete user data by means of X"

  443. valo has joined

  444. Dave Cridland

    Ge0rG, Yes, but that's not true everywhere. Instead you need a feature to allow users to request deletion, but I'd rather a server in a jurisdiction that mandates retention isn't offering me that feature.

  445. pep.

    We will need to tell developers though where to find that XEP

  446. pep.

    XEP discovery is another common issue

  447. winfried

    pep.: "Privacy considerations: this XEP may have GDPR consequences, please see XEP-GDPR for more information"

  448. pep.

    winfried, k

  449. alexis has left

  450. Ge0rG

    I can't see how we can create an (informational or other) GDPR XEP until May 25h.

  451. alexis has joined

  452. j.r has joined

  453. jonasw

    I agree

  454. j.r has joined

  455. jonasw

    I wanted to get EULA done by today, but schedules

  456. winfried

    Ge0rG: Nope, I have to finish a DPIA before then :-D

  457. Ge0rG

    Dave Cridland: I still think that a mention under Business Rules is required. Even if it says "Depending on local laws, you MUST or MUST NOT provide a way ..."

  458. Dave Cridland

    Ge0rG, If a XEP has the phrase "MUST or MUST NOT" I will have to nuke it from orbit.

  459. pep.

    What winfried said above

  460. pep.

    "Privacy considerations: this XEP may have GDPR consequences, please see XEP-GDPR for more information"

  461. Dave Cridland

    Ge0rG, Also, "MUST" etc are related to interop, not legal requirements. I suspect that we (the XSF) may need to be careful about appearing to offer legal advice, too.

  462. winfried

    Ge0rG: can you explain why you think it is required?

  463. Dave Cridland

    pep., That phrasing works for me.

  464. Ge0rG

    Dave Cridland: why? It's only self-contradicting if it's "MUST *and* MUST NOT"

  465. rtq3 has joined

  466. Dave Cridland

    Ge0rG, Because it's meaningless.

  467. Ge0rG

    "this XEP may have global warming consequences, or may contain traces of nuts"

  468. pep.

    What doesn't have global warming consequences..

  469. alacer has left

  470. Seve/SouL

    And doesn't contain traces of nuts

  471. Seve/SouL


  472. Ge0rG

    Dave Cridland: but I agree that RFC 2119 language SHOULD NOT be applied to legal requirements.

  473. winfried

    pep.: the chilling effect (couldn't resist)

  474. jonasw


  475. Ge0rG

    winfried: LOL

  476. pep.


  477. pep.

    Ge0rG, so I read you'd prefer to have GDPR details *in* the XEP?

  478. pep.

    And not an informational XEP

  479. Andrew Nenakhov has joined

  480. Ge0rG

    pep.: I don't know. Whatever will make server implementors create compliant implementations works for me

  481. Valerian has left

  482. alexis has left

  483. jonasw

    I think general "privacy considerations" without mentioning legislation would be a good thing™

  484. pep.

    I'd see winfried's phrasing above, + informational GDPR xep

  485. Dave Cridland

    pep., Really don't want to do that. The problem there is that you'd also need to put in Sarbanes-Oxley, for example.

  486. jonasw

    it would help to create awareness, just like Security Considerations do

  487. jonasw

    and I think they have a place in the XEP

  488. pep.

    Dave Cridland, yes I don't want either

  489. Dave Cridland

    pep., That is, put GDPR sections in every XEP.

  490. pep.


  491. alexis has joined

  492. Dave Cridland

    pep., Ugh. I'm being really unclear. I do not want GDPR bits in every XEP.

  493. pep.

    what GDPR bits

  494. pep.

    You'd be ok with just saying "seealso GDPR XEP"?

  495. Dave Cridland

    pep., Yes.

  496. jonasw

    I have something like "The protocol specified herein allows users to store data on storage controlled by the server, so deletion and retention times need to be considered."

  497. pep.

    Dave Cridland, ok then we agree

  498. jonasw

    I have something like "The protocol specified herein allows users to store data on storage controlled by the server, so deletion and retention times need to be considered." in mind.

  499. winfried

    Dave Cridland: if we create an informational XEP about Sarbanes-Oxley, I wouldn't mind other XEPs pointing to it

  500. Ge0rG

    Maybe the issues is if we actually need *every* *other* XEP to point to the new one?

  501. Dave Cridland

    It might actually be useful to note what data is retained by each XEP, since that has very wide applicability and use.

  502. jonasw

    Dave Cridland, that’s what I had in mind for "Privacy Considerations" sections in XEPs

  503. jonasw

    and a separate GDPR document could point out what to do with specific data.

  504. Dave Cridland

    jonasw, Right, and I think it also forms very useful input to consent, privacy policy, etc stuff on a more generic level.

  505. jonasw

    so in general, PCs (Privacy Considerations) would list: - what data is stored - what data is exposed to other servers and users - what is needed for data exposure (know the JID / needs to be subscribed / ...)

  506. pep.

    jonasw, that still seems GDPR-specific. Some other law might define "private data" entirely differently

  507. winfried

    Like that idea, but it will be quite a bit of work to update all XEPs

  508. rtq3 has left

  509. jonasw

    pep., doesn’t matter, I’d consider all user data in that section.

  510. winfried

    jonasw: +1

  511. Dave Cridland

    jonasw, +1 from me too, for whatever it's worth.

  512. pep.

    jonasw, k

  513. winfried

    and should we also add a paragraph like that to the RFCs?

  514. jonasw

    I’ll re-word my '363 PR to conform with that.

  515. winfried

    jonasw: great!

  516. pep.

    winfried, mined territory I assume :p

  517. Ge0rG

    Having a "Privacy Considerations" section with that data in all XEPs would be great. We could just link those from the server ToS

  518. winfried

    Ge0rG: with autodiscovery based on service discovery!

  519. jonasw

    can we plan for enxt?

  520. pep.

    Can we define quickly what would go into that informational XEP

  521. pep.

    So we can start working on it quickly

  522. pep.

    jonasw, +whatever should work for me. Friday with the small delay as usual

  523. winfried

    pep.: - steps for compliance - red flags

  524. jonasw

    I can only make friday I think

  525. alexis has left

  526. jonasw

    so friday 1230 CEST or 1330 CEST would be good for me

  527. winfried


  528. pep.

    1230 CEST worksforme

  529. pep.

    1330 as well

  530. winfried

    1330 not for me

  531. jonasw

    1230 CEST on Friday, 25th it is then, Ge0rG?

  532. Ge0rG

    either is good

  533. Dave Cridland

    If someone writes the skeleton and an abstract for this GDPR XEP today, we can give it a number by tomorrow.

  534. winfried


  535. alexis has joined

  536. Dave Cridland

    ... which might help "advertise" what you guys are doing.

  537. Ge0rG

    next number is 403, right? ;)

  538. Dave Cridland

    (It'd also give us something to blog about as the XSF)

  539. jonasw

    Ge0rG, no, next is 409 I think

  540. pep.

    Ge0rG, no that's MIX?

  541. Ge0rG

    Oh, wow.

  542. winfried

    Dave Cridland: good plan, I don't have time :-(

  543. jonasw

    I’ll try to dedicate my afternoon to the EULA XEP

  544. Ge0rG

    I'm behind on that thread.

  545. jonasw

    Ge0rG, cf. https://github.com/xsf/xeps/pulls

  546. Dave Cridland

    Ge0rG, I think MIX wants that, but I'd love to see the Editor creatively rearrange...

  547. jonasw

    409 Conflict is also good ;-)

  548. Ge0rG

    I would have skipped 403 as well. But meh.

  549. jonasw

    Ge0rG, 404 isn’t skipped

  550. pep.

    yeah 409 is also fine :P

  551. jonasw

    it’s for MIX ANON

  552. jonasw

    (the order in the PRs is just weird)

  553. Ge0rG

    jonasw: NOOO!1!!

  554. jonasw

    gotta go now

  555. Dave Cridland

    I wondered if MIX Anon was intentionally at 404.

  556. jonasw

    Dave Cridland, it is

  557. Dave Cridland

    But yeah, I think we should skip it for amusement's sake.

  558. jonasw

    I don’t feel like renumbering them ;-)

  559. jonasw

    MIX anon is a good use for XEP-0404 imo :)

  560. Ge0rG

    I disagree. But what do I know.

  561. winfried

    Should I close the GDPR meeting? ;-)

  562. Dave Cridland

    By the way, huge thanks to you guys for doing this.

  563. pep.

    winfried, :)

  564. winfried

    jonasw: do you have time to also submit a skelton and abstract for a GDPR informational XEP?

  565. pep.

    jonasw, I can have a look at EULA, for the obvious bits? (if there is any)

  566. Dave Cridland wonders if he needed to opt-in to be mentioned in the minutes.

  567. pep.

    Dave Cridland, I was going to ask

  568. SaltyBones has joined

  569. winfried

    Dave Cridland: you revealed yourself, so no mercy :-D

  570. pep.

    But the logs of this room are public anyway, just like the minutes :P

  571. Andrew Nenakhov has joined

  572. jonasw

    winfried, no, sorry

  573. winfried

    I shouldn't do it, but I will give it a shot

  574. winfried


  575. jonasw

    winfried, why shouldn’t you do it?

  576. jonasw

    if you’re uncomfortable with the markup, you can also just send me a markdown or whatever based document

  577. jonasw

    and I’ll transform it

  578. winfried

    time, am already terrible behind on an other GDPR project

  579. jonasw


  580. winfried

    but it shouldn't be too much work

  581. jonasw

    do whatever you need to save time, my issue with the informational is mostly that I don’t have the big picture or anything

  582. jonasw

    I’m fine with an .odt if that’s what you’re most comfortable writing in

  583. winfried

    jonasw: k, let you know if I need anything

  584. winfried bangs a gavel and starts writing a XEP

  585. pep.

    Ge0rG, you're ok if I copy your tos/privacy policy to the wiki with a big "WIP"

  586. pep.

    And "To be moved to git"

  587. jonasw

    Dave Cridland, I don’t think I’ll be able to make the 24 hour agenda deadline for the council meeting with the EULA XEP though

  588. Ge0rG

    pep.: yeah

  589. andy has left

  590. andy has joined

  591. pep.

    We're still in Q1.1.2 right

  592. pep.

    or 1.1.3 maybe

  593. pep.

    Ah no 1.1.2

  594. pep.

    "consequences for server operators"

  595. pep.


  596. Valerian has joined

  597. ibikk has joined

  598. rtq3 has joined

  599. ibikk has left

  600. ibikk has joined

  601. Andrew Nenakhov has joined

  602. Andrew Nenakhov has left

  603. Andrew Nenakhov has joined

  604. SaltyBones has left

  605. SaltyBones has joined

  606. lumi has left

  607. pep.

    winfried, I'm not sure exactly what you meant by "Big picture: we have some things we want to change on protocol level" and "Transfer of data" specifically

  608. rtq3 has left

  609. winfried

    pep.: timestamp ? loosing my context ;-)

  610. pep.

    19:50:33 winfried> Big picture: we have some things we want to change on protocol level 19:50:43 winfried> EULA-XEP 19:50:47 winfried> Deletion 19:50:56 winfried> Transfer of data 19:51:09 winfried> (any other?) 19:51:31 winfried> ah, defaults for MAM

  611. pep.


  612. winfried


  613. winfried

    that is the portability thing, download everything so it can be put on an other server

  614. pep.

    I see

  615. SaltyBones has left

  616. SaltyBones has joined

  617. jere has joined

  618. SaltyBones has left

  619. SaltyBones has joined

  620. ibikk has joined

  621. Holger has left

  622. lorddavidiii has left

  623. lorddavidiii has left

  624. pep.

    https://cryptpad.fr/code/#/2/code/edit/j5ggWca+SLu32klePWFOeCIK/ winfried, jonasw, Ge0rG if you can have a quick look before I send

  625. Ge0rG

    pep.: 👍

  626. SaltyBones has left

  627. SaltyBones has joined

  628. rtq3 has joined

  629. ta has joined

  630. winfried


  631. jonasw


  632. jubalh has joined

  633. edhelas has left

  634. jonasw

    I’ll now try to merge the MIX PRs and then I’ll start to look at the EULA XEP

  635. edhelas has joined

  636. Steve Kille

    jonasw: thanks!

  637. Valerian has left

  638. Valerian has joined

  639. jjrh has left

  640. mimi89999 has left

  641. ta has joined

  642. lovetox has left

  643. SaltyBones has left

  644. SaltyBones has joined

  645. jjrh has left

  646. ta has joined

  647. Ge0rG

    jonasw: But 404!

  648. jonasw


  649. Ge0rG

    Okay, I didn't do anything when that window of opportunity was open, so I have no right to complain about it.

  650. jonasw

    Steve Kille, is "RELIABLE-DELIVERY" not there yet or am I missing something?

  651. Ge0rG

    I'll just pile my sadness on top of the Pidgin-officially-encouraged pile and move on with life.

  652. SaltyBones has left

  653. blabla has left

  654. blabla has joined

  655. Steve Kille

    RELIABLE-DELIVERY is a piece of MIX that is needed, but it was clear that hte text in MIX was wrong and it might be useful elseowere

  656. SaltyBones has joined

  657. Steve Kille

    So, I (or someone else) needs to work out exactly what needs doing and write it.

  658. Steve Kille

    Running without this is probably not going to be a big deal for most deployments

  659. Steve Kille

    BTW using 404 for MIX-ANON was the choice of my co-author

  660. Steve Kille

    I think the humour is good

  661. Ge0rG

    IMHO, that number should have been used for "XEP not found"

  662. Steve Kille

    Kev got there first

  663. Andrew Nenakhov has left

  664. ThibG has joined

  665. Andrew Nenakhov has joined

  666. lorddavidiii has left

  667. Andrew Nenakhov has joined

  668. Andrew Nenakhov has left

  669. Andrew Nenakhov has joined

  670. SaltyBones has left

  671. SaltyBones has joined

  672. jonasw

    MIXes merged

  673. jonasw

    Steve Kille, FWIW, the conflicts were because somebody submitted editorial changes in the meantime (0.10.1 was released), but that was trivial to handle

  674. Steve Kille

    thanks very much for sorting this out.

  675. lovetox has joined

  676. Steve Kille

    Meanwhile, I've received some private editorial comments on 1.0.0, whch I will work at soon

  677. jonasw

    I renumbered it to 0.10.2

  678. lumi has joined

  679. jonasw

    it is not draft yet, and only draft can have 1.x.x

  680. jonasw

    and since the split was editorial as discussed, it got 0.10.2

  681. Steve Kille

    ah - I did not realize this.

  682. Steve Kille

    Given that over half of the text vanished from 369, this scarecely seems editorial

  683. Steve Kille

    I'm going to have to confess now that there were some technical changes

  684. Steve Kille

    Mamking the XEPs independnent needed changes

  685. Steve Kille

    Making Proxy JIDs work without MIX-ANON needed various changes

  686. jonasw


  687. jonasw

    yeah, I saw a namespace bump in there

  688. jonasw

    but I think that’s going to be needed either way

  689. jonasw

    I can’t really fix the version number now anymore, I’m afraid.

  690. jonasw

    so we’ll have to live with t hat

  691. Steve Kille

    shall I move to 11.0 when I do the next set of changes?

  692. Steve Kille

    All the others are at 0.1.0

  693. jonasw

    increment the last digit (the z in x.y.z) for purely editorial changes, and the second digit (y in x.y.z, reset z to 0) for changes which include non-editorial chnages

  694. Steve Kille

    I think that the changes since 10.0 deserve a seond digit bump

  695. Steve Kille

    However, it is just a number, and I am happy with whatever the experts decree

  696. jonasw

    I agree that a second digit bump would’ve made sense

  697. jonasw

    but that’s spilled milk

  698. jonasw

    more or less

  699. Steve Kille

    I was asking if it makes sense to make the bump as part of the editorial changes I will make soon?

  700. jonasw

    ah, now I understand

  701. jonasw

    I’ll abort the build and fix the version number to 0.11.0

  702. Steve Kille

    if that is not too much trouble, I think that makes most sense

  703. jonasw


  704. Steve Kille

    you're a hero

  705. Valerian has left

  706. rtq3 has left

  707. jjrh has left

  708. jubalh has joined

  709. Valerian has joined

  710. j.r has joined

  711. j.r has joined

  712. marmistrz has left

  713. jonasw

    pep., Ge0rG, what do you think about announcing the TOS version via disco#info *and* stream features? This would allow servers to announce updates via stream features s.t. clients can pick that up

  714. pep.

    jonasw, sgtm

  715. Ge0rG

    jonasw: aren't we overloading our caps infra already?

  716. jonasw

    not sure

  717. jonasw

    for servers I don’t think so

  718. pep.

    jonasw, what do you do with it then? the client knows there's a new version, where does it fetch it

  719. jonasw

    pep., via the in-band protocol

  720. pep.

    Ok ok

  721. pep.

    iq or ad-hoc?

  722. jonasw

    not sure yet

  723. jonasw

    I think ad-hoc won’t do the trick

  724. Valerian has left

  725. Valerian has joined

  726. Valerian has left

  727. pep.

    I'd prefer iq I think, but I don't have a strong opinion

  728. rtq3 has joined

  729. SaltyBones has left

  730. pep.

    All the features a user will opt-in, they also need to be able to opt-out easily btw. Should that also be done via the xep (one place to rule them all, "easy discovery"), or let the client decide where each feature config should go? e.g, Preferences > MAM > [x] Enable; Preferences > Other feature > [ ] Enable

  731. pep.

    Meh, I don't think the one place to rule them all would work

  732. jonasw


  733. pep.

    that'd need to fiddle with every other modules

  734. Ge0rG

    There is one place to rule them all. "Delete account"

  735. jonasw

    that needs to go into the individual XEPs, just like it’s handled currently

  736. pep.

    Ge0rG, no

  737. pep.

    Say I still want to benefit from the services, but I want to opt-out of every consented feature

  738. pep.

    Doesn't have to be "please delete MAM", just "Please no MAM anymore"

  739. jonasw


  740. jonasw

    pep., Ge0rG, ^

  741. pep.

    "The user shall be able to retract consent [..]", I don't have the exact quote

  742. pep.

    An error occurred during a connection to paste.debian.net. SSL peer rejected your certificate as expired. Error code: SSL_ERROR_EXPIRED_CERT_ALERT :(

  743. jonasw


  744. pep.

    I'll have to change that client cert..

  745. jonasw

    s/https/http/ will work though

  746. pep.

    yeah.. unfortunately

  747. Ge0rG

    "The server subsequently replies with the &tos; payload:" - that sounds like it's a ToS *payload*, but it's merely a ToS *link*

  748. jonasw

    Ge0rG, it is a payload of the ToS protocol

  749. pep.

    Ge0rG, I'd like to allow for both

  750. Valerian has joined

  751. pep.

    If you want to point to an external source, good for you. You might also want to handle this in-band

  752. Ge0rG

    Let's talk about XHTML-IM ToS payloads.

  753. jonasw

    pep., it’s not realistic to have the complete document in-band

  754. pep.

    jonasw, that's fine as long as EULA is only used for c2s

  755. pep.

    I mean, oob is fine**

  756. jonasw

    I’m thinking however, if we actually make Ge0rGs thing into a template, that we could use that template and have the server say things like "this is template X version Y, with the following things filled in: MAM retention time = xyz, upload retention time = abc, representative = frank nord"

  757. Ge0rG

    representative = Jon Snow.

  758. andy has left

  759. pep.

    jonasw, I'm sure that template will get hairy quickly

  760. jonasw

    maybe, but maybe not

  761. pep.

    Plus operators will want to modify more than just placeholders

  762. jonasw

    pep., in any case, putting the whole ToS in-band won’t work.

  763. pep.

    won't work how?

  764. jonasw

    question 1: which markup format to use for formatting?

  765. pep.

    We don't have anything to do formatted payloads anymore? :)

  766. pep.

    Too bad

  767. jonasw

    I would have argued strongly against anything XHTML. way too much, markdown would be sufficient, if it was standardised.

  768. pep.

    but styling is not markdown.

  769. jonasw

    styling is not sufficient

  770. pep.

    Don't tell me

  771. jonasw

    you need headings in a ToS, and enumerations and lists

  772. jonasw

    I am confused

  773. Ge0rG

    Are we talking about Markleft or Markright?

  774. pep.

    Ge0rG, both

  775. pep.

    Also Markhtml

  776. jjrh has left

  777. Valerian has left

  778. Valerian has joined

  779. jonasw

    pep., do you happen ot have a link to your EULA XEP pad at hand?

  780. pep.


  781. jonasw


  782. Andrew Nenakhov has joined

  783. blabla has joined

  784. marmistrz has joined

  785. lovetox has left

  786. jonasw

    pep., Ge0rG: https://sotecware.net/files/noindex/tos.html

  787. jonasw

    sorry for the lack of CSS

  788. blabla has left

  789. blabla has joined

  790. jonasw

    pep., Ge0rG, winfried, here’s a preview version with CSS: https://sotecware.net/files/noindex/xeps/tos.html ; I’d appreciate any early feedback.

  791. jonasw

    I think this should cover the basic points for now, we can expand on this for including more information about the ToS in the payloads later.

  792. pep.

    jonasw, example 2 contains </stream:features>

  793. Ge0rG

    jonasw: the title might better be "ToS Reference" than just "ToS"

  794. jonasw

    pep., ty

  795. vanitasvitae has left

  796. jonasw

    Ge0rG, "Terms of Service Agreement"?

  797. jonasw

    because it also handles ACK-ing the ToS

  798. jonasw

    I find ToS a good name still.

  799. daniel has left

  800. daniel has joined

  801. pep.

    jonasw, can we not use oob or sims or something that's already there to give the url?

  802. jonasw

    pep., what would be the benefit?

  803. pep.

    Not reinventing the wheel

  804. alexis has left

  805. pep.

    hmm, oob doesn't allow for MIME, sims does though

  806. Ge0rG

    Wasn't there an IBR extension by daniel?

  807. winfried

    jonasw: what when there are several documents like a ToS and a separate Privacy statement?

  808. alacer has joined

  809. jonasw

    pep., but it wouldn’t be re-usable much except for wire format maybe, and it would tie us to the SIMS namespace

  810. pep.

    jonasw, I don't know what the convention is, but I'd put <deadline/> inside <tos/> maybe

  811. mhterres has joined

  812. mhterres has left

  813. jonasw

    pep., but semantically, the deadline is for the change not for the ToS itself

  814. SamWhited has left

  815. winfried

    Can it also be communicated when it is obliged to agree to the terms or when it should only be available

  816. SamWhited has joined

  817. jonasw

    winfried, that’s a good question

  818. jonasw

    winfried, that’s a good question (regarding multiple documents)

  819. pep.

    jonasw, right.. I'm a bit annoyed at having this directly in <message> for some reason

  820. jonasw

    winfried, regarding requiring agreement, sure, we can communicate that, but does it make sense?

  821. SaltyBones has joined

  822. jonasw

    winfried, is there a good reason to separate the documents?

  823. jonasw

    this will increase the complexity a lot because we either have to put human-readable titles in the wire-format (complexity with i18n) or pre-define the types of documents we want to support

  824. pep.

    Maybe we can just allow multiple sources of the same type

  825. Guus has left

  826. efrit has joined

  827. jonasw

    pep., how would that look in a client UI? > you have to agree to the following terms to use the service: > document 1 (link) > document 2 (link) :/ that looks awful

  828. alacer has left

  829. pep.

    Well.. having both links for plain/text and plain/html, what will clients display anyway?

  830. pep.

    randomly choose between the two?

  831. jonasw

    unless you’re poezio, you’d probably link the text/html thing

  832. jonasw

    and dispatch to a web browser

  833. jonasw

    poezio might as well show the text/plain version inline

  834. pep.

    pardon my UX skills, but as a user I'd prefer to have a choice

  835. jonasw

    most users don’t want to

  836. jonasw

    they don’t even care about the difference between html and plaintext :)

  837. Guus has left

  838. pep.

    which is also why I use poezio unlike "most users"

  839. Dave Cridland

    winfried, You know, you *could* use a SASL2 task for EULA agreement.

  840. pep.

    jonasw, anyway, I can live with just one document (and optionally multiple types), for the original question

  841. Andrew Nenakhov has joined

  842. jonasw

    Dave Cridland, i’d love to see a SASL2 task to replace my pre-bind/post-auth hack

  843. jonasw

    IBR integration is still on the todo

  844. winfried

    jonasw: communicating the requirement to agree: some documents (like the privacy statement) only need to be available, while some others, like a 6.1a question, need to be agreed upon.

  845. matlag has joined

  846. winfried

    jonasw: and that is also an answer to the other topic: if you have both, you want to present both with a different status

  847. jonasw

    winfried, okay, that makes things much more complex.

  848. pep.

    Right. I've seen services present me multiple ToS I could agree to

  849. jonasw

    I was operating under the assumption that we have a ToS document (including privacy policy) which needs to be agreed to always and that all 6.1a questions are handled separately already.

  850. jonasw

    (such as MAM)

  851. winfried

    pep.: yeah, that is ugly, but there may be good reasons for

  852. jonasw

    back to the scratchpad then

  853. pep.

    winfried, I guess we can skip this though, and do as jonasw says, have opt-in features be handled separately

  854. winfried

    jonasw: in our GDPR route, we avoid asking 6.1a questions, but other setups or other jurisdictions may have different needs

  855. pep.

    winfried, as in, clients would have UI for this, some configuration somewhere

  856. winfried

    pep.: IF you offer an 'agree-iq', then you should also communicate if it is mandatory to agree it. Otherwise it is just informational

  857. daniel has left

  858. jonasw

    my assumption was that it’s always mandatory

  859. winfried

    jonasw: Nope, misconception #1 about the gdpr ;-)

  860. pep.

    I don't think it is (always mandatory).

  861. jonasw


  862. jonasw

    okay, will have to re-do things then

  863. winfried

    jonasw: sorry...

  864. jonasw

    no, that’s great, we need a good thing here

  865. jonasw

    better sort it out before the first implementation comes along :)

  866. winfried

    Dave Cridland: love that idea, but I am happy you said *could* :-D

  867. pep.

    Yeah I'd like to see what that looks like as well

  868. lovetox has joined

  869. jonasw

    winfried, okay, would this work: - we have a list of documents which can be reviewed by the user - we have a list of tickboxes where users can consent to things which aren’t handled elsewhere (e.g. additional content analysis which would go into 9.1 territory or something) - the tickboxes default to false - agreement to individual documents is handled via the tickboxes, if at all. - a service would put the terms for the tickboxes in their privacy policy document by default

  870. daniel has joined

  871. Andrew Nenakhov has left

  872. Andrew Nenakhov has joined

  873. jonasw

    so the UI would be something like this: +----------------------------------+ | | | Terms of Service | | | | Service xy has the | | following Terms. | | Please review: | | | | - Terms of Service (link) | | - Privacy Policy (link) | | | | [ ] Allow analysis of my | | messages for marketing | | purposes | | (see Privacy Policy §12.3) | | [ ] Allow sharing my contacts | | with Facebook | | | | | +----------------------------------+

  874. Wiktor has left

  875. jonasw

    + a [Register] or [Continue] button

  876. jonasw

    the tickboxes would be provided by the service

  877. pep.

    Also [Cancel], that would close the stream? :-°

  878. jonasw


  879. pep.

    Would MAM go in these [ ], or would it be in client configurations like we said above

  880. jonasw

    I would put that in client configuration

  881. pep.

    Because then we're separating stuff that requires consent

  882. pep.

    I mean there would be stuff all around, not just one place to accept

  883. jonasw

    if you choose to enable MAM, you have of course already read the privacy policy and thus know the terms for MAM

  884. jonasw


  885. pep.


  886. jonasw

    A service could of course also put the MAM switch in there, but it’s useless if the client doesn’t support MAM, so it would be confusing.

  887. jonasw

    the tickboxes would be entirely service-define

  888. jonasw

    the tickboxes would be entirely service-defined

  889. pep.

    Makes sense

  890. Ge0rG

    that looks like a data form.

  891. jonasw

    Ge0rG, the tickboxes will use data form wire format indeed

  892. jonasw

    Ad-Hoc command wire format even

  893. Ge0rG

    The issue I have is that yaxim will not connect to the server until you fill out the username + password fields.

  894. jonasw


  895. ibikk has joined

  896. pep.

    Ge0rG, pulling down a XEP because of client implementation? how dare you :o

  897. Ge0rG

    pep.: I didn't write "The issue this XEP has"

  898. winfried

    pep.: a [Cancel] would be up to the server to decide, it may only disable certain functionality

  899. pep.

    Ge0rG, :)

  900. pep.

    winfried, if a user cancels, what happens legally? they don't agree to the ToS, but they can continue using the service?

  901. pep.

    I'm a bit confused

  902. Ge0rG

    I like how you have sorted out race conditions between the user reading and the ToS updating here... `<agree xmlns='urn:xmpp:tos:0'><version>0.1.0</version></agree>`

  903. winfried

    pep.: depends on the question. If the question is: "i agree to connecting to my facebook account" (or so) then not ticking the box would only stop that part of the processing, not all XMPP service

  904. jonasw

    is cancel really a thing?

  905. jonasw

    i mean yeah, cancel would mean that you don’t want to use the sevrice at all because you don’t agree with it’s ToS

  906. pep.

    jonasw, [disagree], I guess

  907. pep.

    jonasw, [Disagree], I guess

  908. Alex has joined

  909. jonasw

    the non-negotiable parts of the ToS, because the negotiable parts are formulated as tickboxes

  910. pep.

    jonasw, yes

  911. Ge0rG

    jonasw: I don't like the use of headline messages. With always-on clients, I'd always fear sending a user a message in the middle of the night.

  912. pep.

    Ge0rG, it's always the night somewhere..

  913. pep.

    Ge0rG, it's always night somewhere..

  914. Ge0rG

    pep.: that's exactly my point.

  915. winfried

    pep.: oops mixing up not ticking a box and [disagree]

  916. pep.

    Ge0rG, who cares, people should setup notifications properly

  917. Ge0rG

    pep.: the right thing™ would be to send another kind of notification and let the user agree when they re-open their client

  918. Guus has left

  919. Ge0rG

    pep.: people are using Jabber for important family notifications. Ringing them up at 3AM is not what I want to do.

  920. jonasw

    Ge0rG, the notification could be delayed until the next CSI Active if the client is CSI Inactive with a smart implementation :)

  921. Ge0rG

    jonasw: I don't believe in smart implementations any more.

  922. jonasw

    (with a delay of a few minutes to allow a client to go CSI Inactive after a reconnect)

  923. jonasw

    Ge0rG, do you have another idea for the notification?

  924. jonasw

    I don’t want to use an IQ because that won’t work with legacy clients at all.

  925. jonasw

    we don’t have a "silent" thing unfortunately

  926. Ge0rG

    jonasw: you encode the tos-version in the entity caps and push a presence update.

  927. jonasw

    presence update from whom?

  928. Dave Cridland

    I'm not convined you want to handle ToS changing mid-stream.

  929. Ge0rG

    from the server.

  930. jonasw

    and that won’t work with legacy clients at all.

  931. winfried

    Dave Cridland: why not?

  932. jonasw

    Ge0rG, users typically don’t have their server in the roster.

  933. Ge0rG

    Dave Cridland: what's your counter-proposal? Kick the client?

  934. Ge0rG

    jonasw: yes.

  935. pep.


  936. Ge0rG

    jonasw: this is why it's going to work.

  937. jonasw

    Ge0rG, you are an evil persion

  938. Ge0rG

    jonasw: what was discussed last time for mid-stream server-caps updates?

  939. Dave Cridland

    Ge0rG, Basically. If you're at the point where the ToS update is so pressing you need to get user agreement at that moment, you're going to need to anyway.

  940. jonasw

    but relatedly, I have an update for XEP-0390 pending which allows servers to push updates to their caps

  941. Guus has left

  942. Guus has left

  943. jonasw

    Dave Cridland, nobody’s talking about "in that moment"

  944. Guus has joined

  945. Ge0rG

    jonasw: yes. yes I am.

  946. jonasw

    the notification is supposed to be sent a few days ahead so that the user has time to review etc.

  947. Ge0rG

    you kick the user twice. First on the ToS update, second when they failed to accept the update in time.

  948. Ge0rG

    BTW, what happens if they fail to accept it? They get kicked and can't reconnect? Need to accept the ToS oob?

  949. jonasw

    Ge0rG, § 4.5 in the draft I linked

  950. jonasw


  951. jonasw

    ideally, this would be a SASL2 thing as suggested by Dave Cridland, but we don’t have SASL2 yet, and it can easily replaced with SASL2 later.

  952. Ge0rG

    jonasw: wow, well thought out :)

  953. lnj has left

  954. lnj has joined

  955. winfried

    Ge0rG: isn't that up to to the server

  956. Ge0rG

    data-forms in SASL2?

  957. jonasw

    Ge0rG, sasl2 is like zombo.com -- everything is possible in SASL2

  958. Ge0rG

    winfried: what that?

  959. SaltyBones has left

  960. SaltyBones has joined

  961. winfried

    [17:25:29] <Ge0rG> BTW, what happens if they fail to accept it? They get kicked and can't reconnect? Need to accept the ToS oob?

  962. Ge0rG

    winfried: yeah, but if you lock out the user, they need an oob mechanism to re-agree with the ToS

  963. jonasw

    (or an in-band mechanism ;-))

  964. Ge0rG

    an in-band mechanism between auth and bind, yes.

  965. Ge0rG

    can you 0198 resume such a semi-zombie?

  966. Wiktor has joined

  967. jonasw

    I was about to add that you’d kill the session completely when they don’t agree to the ToS in time

  968. jonasw

    you can’t know how long it’ll take for them to ack the new terms and shutting down the session cleanly and completely is probably the best you can do.

  969. Guus has left

  970. alexis has joined

  971. Guus has left

  972. waqas has joined

  973. alexis has left

  974. j.r has joined

  975. alexis has joined

  976. Dave Cridland has left

  977. SaltyBones has left

  978. SaltyBones has joined

  979. Guus has left

  980. Guus has left

  981. Guus has joined

  982. efrit has left

  983. jjrh has left

  984. SaltyBones has left

  985. SaltyBones has joined

  986. alexis has left

  987. alexis has joined

  988. Alex has left

  989. winfried

    jonasw: can you have a look? https://github.com/winfried/xeps/blob/master/inbox/GDPR.xml

  990. jonasw

    I would add a paragraph right into the introduction: "This document is not legal advice"

  991. jonasw

    this is probably a good start

  992. pep.

    winfried, interoperability*

  993. blabla has left

  994. blabla has joined

  995. Andrew Nenakhov has left

  996. winfried

    jonasw: thanks, added

  997. winfried

    pep.: thanks, fixed

  998. jjrh has left

  999. Andrew Nenakhov has joined

  1000. peter has joined

  1001. winfried

    jonasw: do you want a pull request?

  1002. jonasw

    winfried, you can do a PR, I’m not 100% convinced that this is enough to pass though.

  1003. jonasw

    and I’m not 100% sure if this is council or board matter

  1004. jonasw

    Dave Cridland, do you have an opinion?

  1005. winfried

    jonasw: we will see ;-)

  1006. Dave Cridland

    It's not procedural, so probably not Board.

  1007. jonasw

    it’s informational though

  1008. Dave Cridland

    Yes, but lots of Informational stuff is processed by Council.

  1009. jonasw

    winfried, pep., Ge0rG: updated https://sotecware.net/files/noindex/xeps/tos.html

  1010. jonasw

    Dave Cridland, true

  1011. Dave Cridland

    Board handle the XEPs that document XSF policy and procedures.

  1012. jonasw


  1013. jonasw

    so council it is

  1014. Dave Cridland

    (Which are "Procedural")

  1015. jjrh has left

  1016. rtq3 has left

  1017. winfried

    jonasw: pull request send

  1018. jonasw

    neat, thanks

  1019. flow has left

  1020. jjrh has left

  1021. flow has joined

  1022. winfried

    Of to dinner!

  1023. jonasw


  1024. jjrh has left

  1025. jjrh has left

  1026. rion has joined

  1027. j.r has joined

  1028. ibikk has left

  1029. SaltyBones has left

  1030. marc has left

  1031. SaltyBones has joined

  1032. jonasw

    another update

  1033. blabla has joined

  1034. xnyhps has joined

  1035. xnyhps has joined

  1036. ibikk has joined

  1037. j.r has joined

  1038. winfried has joined

  1039. jjrh has left

  1040. SaltyBones has left

  1041. SaltyBones has joined

  1042. Steve Kille has left

  1043. Steve Kille has left

  1044. tux has left

  1045. SaltyBones has left

  1046. SaltyBones has joined

  1047. Steve Kille has joined

  1048. jubalh has left

  1049. ralphm has left

  1050. marmistrz has joined

  1051. alacer has joined

  1052. Valerian has left

  1053. Valerian has joined

  1054. Valerian has left

  1055. Valerian has joined

  1056. Valerian has left

  1057. marmistrz has joined

  1058. Dave Cridland has left

  1059. Dave Cridland has left

  1060. SamWhited has left

  1061. pep.

    jonasw, no MIME anymore?

  1062. rion has left

  1063. Valerian has joined

  1064. rtq3 has joined

  1065. pep.

    meh, nvm. You gave me too much options in the first draft!

  1066. Steve Kille has left

  1067. pep.

    meh, nvm. You gave me too many options in the first draft!

  1068. pep.

    Ah wait, there is

  1069. Ge0rG has joined

  1070. Dave Cridland has left

  1071. jjrh has left

  1072. Dave Cridland has left

  1073. Valerian has left

  1074. pep.

    you say "The data form for legacy clients and additional opt-ins/opt-outs", but even if I'm a client implementing the XEP I'll want all this, no? What exactly can I get rid of in that form, especially when I have to reply with the same fields

  1075. SaltyBones has left

  1076. SaltyBones has joined

  1077. pep.

    hmm, maybe just to provide alternative versions/urls of the documents

  1078. j.r has left

  1079. Valerian has joined

  1080. marc has left

  1081. jonasw

    pep., yes, you can only remove the additional elements

  1082. jonasw

    pep., yes, you can only remove the documents

  1083. jonasw

    but that is written down there

  1084. pep.

    nit: "In the future, more children may be added to the <tos/> element. Conforming clients thus MUST ignore all children they do not understand.", I find "conforming" disturbing here, as conforming clients would understand these updates.. But I know you're talking about cases where deployments are not up-to-date

  1085. jonasw

    pep., it might also be that an additional XEP extends it

  1086. pep.

    Ok makes more sense in this case

  1087. matlag has joined

  1088. Tobias has joined

  1089. pep.

    jonasw, "[..] and use a richer representation obtained from the <tos/> element for the same data." you mean HTTP GET on the urls?

  1090. jonasw

    for example

  1091. pep.

    Does it have to be a url btw

  1092. jonasw

    and in the future maybe fancy things like machine-readable MAM retention times etc.

  1093. jonasw


  1094. pep.

    can it be a uri

  1095. lumi has left

  1096. jonasw

    ugh, I never get the difference

  1097. pep.

    I'm probably wrong, I mean does it have to be http

  1098. jonasw


  1099. pep.

    How would you display a plaintext file retrieved in your client, the question of rich formatting still stands

  1100. jonasw

    you could also have a text/markdown version.

  1101. jonasw

    or text/restructuredtext

  1102. ralphm has joined

  1103. pep.

    Instead of "Duplicate MIME types MUST NOT occur.", can we have "Duplicate url/MIME type pairs MUT NOT occur."

  1104. pep.

    hmm, I assume the url would use a different protocol though

  1105. Dave Cridland has left

  1106. jonasw

    pep., duplicate MIME types makes it hard for the client to decide which one ot use

  1107. pep.

    It can decide based on the protocol _and_ the mime type

  1108. jonasw


  1109. jonasw

    might add that later

  1110. jonasw

    I pushed it into the xeps repo now

  1111. pep.


  1112. rion has left

  1113. pep.

    What about errors when client submits filled-out form

  1114. pep.

    "not latest version", "invalid documents", "unknown opt-in feature", etc.

  1115. matlag has joined

  1116. j.r has joined

  1117. jonasw

    yeah, should probably be defined

  1118. pep.

    Ah I see you've added a <tos-push/> containe r:)

  1119. jonasw

    you can send those to the mai3ling list :)

  1120. pep.

    will do

  1121. jonasw

    (once the announcement is out)

  1122. jonasw

    which I’m not 100% sure I’ll get to today because I’m heading out in half an hour and the build takes ages :(

  1123. daniel has left

  1124. pep.


  1125. pep.

    something something incremental builds

  1126. jonasw


  1127. jonasw

    something something docker sucks

  1128. pep.

    I'd argue that's up to the CI

  1129. lskdjf has left

  1130. jonasw

    you can’t do that with docker hub, period.

  1131. pep.

    Ah, well docker hub != docker

  1132. SaltyBones has left

  1133. SaltyBones has joined

  1134. Valerian has left

  1135. lskdjf has left

  1136. pep.

    Did we had Privacy Considerations to the template btw

  1137. jonasw

    no, I didn’t want to do that in the climate after the XEP-0363 debate

  1138. pep.


  1139. jonasw

    and I still need to reword the ideas for that

  1140. blabla has joined

  1141. pep.

    "The version identifiers generated by servers MUST NOT be longer than 128 characters." a reason for this in particular? (even if unlikely)

  1142. la|r|ma has joined

  1143. pep.

    "Servers MUST NOT allow entities to query the Terms of Service of another server unless they are authenticated." I'm not sure I get this

  1144. jonasw

    before you are authenticated, your server MUST NOT allow you to query other servers for their ToS

  1145. pep.

    But other servers may allow anybody to attempt a connection and query their tos right

  1146. pep.

    Just like my https://service.example/tos will be public, I don't mind having my xmpp server disclosing them publicly

  1147. jonasw


  1148. jonasw

    but you don’t want to be an open proxy for entities sending IQs towards other servers.

  1149. pep.

    I see

  1150. pep.

    Also what about sasl anonymous

  1151. jonasw

    I don’t see how that’s relevant

  1152. pep.

    ToS acceptance is required only if there is account creation?

  1153. jonasw


  1154. jonasw

    IBR integration is still fully missing

  1155. pep.


  1156. ludo has joined

  1157. jonasw

    theoretically, a SASL ANONYMOUS thing could apply § 4.4 Inform client about Terms of Service expiry after authentication

  1158. Dave Cridland has left

  1159. pep.

    I'll reply to the thread when it's out and ask about all that

  1160. Dave Cridland has left

  1161. waqas has left

  1162. SamWhited has left

  1163. jonasw

    okay gotta go, build didn’t finish in time :( will send the mail tomorrow or later tonight

  1164. Dave Cridland has left

  1165. SaltyBones has left

  1166. SaltyBones has joined

  1167. Dave Cridland has left

  1168. jubalh has joined

  1169. daniel has joined

  1170. rtq3 has left

  1171. jjrh has left

  1172. bear has left

  1173. bear has joined

  1174. Dave Cridland has left

  1175. Zash has joined

  1176. Tobias has joined

  1177. waqas has joined

  1178. Dave Cridland has left

  1179. SaltyBones has left

  1180. SaltyBones has joined

  1181. Ge0rG has joined

  1182. alacer has left

  1183. alacer has joined

  1184. SaltyBones has left

  1185. SaltyBones has joined

  1186. SaltyBones has left

  1187. SaltyBones has joined

  1188. Tobias has joined

  1189. Valerian has joined

  1190. la|r|ma has joined

  1191. la|r|ma has joined

  1192. Dave Cridland has left

  1193. marmistrz has left

  1194. vanitasvitae has left

  1195. Guus has left

  1196. Valerian has left

  1197. rtq3 has joined

  1198. Guus has left

  1199. Guus has left

  1200. Guus has left

  1201. jjrh has left

  1202. jjrh has left

  1203. alexis has left

  1204. jjrh has left

  1205. Guus has left

  1206. alexis has joined

  1207. jjrh has left

  1208. Ge0rG has left

  1209. rtq3 has left

  1210. jjrh has left

  1211. jjrh has left

  1212. jjrh has left

  1213. jjrh has left

  1214. jjrh has left

  1215. sezuan has joined

  1216. alacer has left

  1217. alacer has joined

  1218. jjrh has left

  1219. matlag has joined

  1220. Dave Cridland has left

  1221. jjrh has left

  1222. rtq3 has joined

  1223. Ge0rG has joined

  1224. alacer has left

  1225. winfried has left

  1226. daniel has left

  1227. ralphm has left

  1228. jjrh has left

  1229. jjrh has left

  1230. jubalh has left

  1231. jjrh has left

  1232. jjrh has left

  1233. jjrh has left

  1234. jubalh has joined

  1235. Valerian has joined

  1236. Guus has left

  1237. jjrh has left

  1238. jjrh has left

  1239. Guus has left

  1240. jjrh has left

  1241. jubalh has left

  1242. jjrh has left

  1243. SamWhited has left

  1244. Ge0rG has left

  1245. jjrh has left

  1246. alacer has joined

  1247. marc has left

  1248. Nekit has left

  1249. Nekit has joined

  1250. jjrh has left

  1251. jjrh has left

  1252. jubalh has joined

  1253. alacer has left

  1254. Kev has joined

  1255. marc has left

  1256. jjrh has left

  1257. jjrh has left

  1258. jjrh has left

  1259. jjrh has left

  1260. jjrh has left

  1261. jjrh has left

  1262. jubalh has left

  1263. jubalh has joined

  1264. Ge0rG

    speaking of appropriate number mappings... 403 = GDPR Compliance 404 = Terms of Service

  1265. pep. grabs popcorns

  1266. rtq3 has left

  1267. moparisthebest

    Ge0rG, I think those have been reserved for the mix hatchet job

  1268. Ge0rG

    moparisthebest: not merely reserved, they are official now.

  1269. pep.

    moparisthebest, yes, he's been onto it for half a day now, now about this :P

  1270. Zash

    Popcorn you say?

  1271. moparisthebest

    ah so they are

  1272. Valerian has left

  1273. Valerian has joined

  1274. jjrh has left

  1275. Valerian has left

  1276. rtq3 has joined

  1277. jjrh has left

  1278. ludo has left

  1279. jjrh has left

  1280. nyco has left

  1281. nyco has joined

  1282. lskdjf has left

  1283. rtq3 has left

  1284. rtq3 has joined

  1285. jubalh has left

  1286. jjrh has left

  1287. Guus has left

  1288. lskdjf has joined

  1289. jjrh has left

  1290. jjrh has left

  1291. Kev has left

  1292. Guus has left

  1293. Wiktor has joined

  1294. jjrh has left

  1295. jjrh has left

  1296. jjrh has left

  1297. jubalh has joined

  1298. rtq3 has left

  1299. goffi has left

  1300. UsL has joined

  1301. Dave Cridland has left

  1302. Tobias has left

  1303. Tobias has joined

  1304. mimi89999 has left

  1305. jjrh has left

  1306. jjrh has left

  1307. lumi has joined

  1308. jjrh has left

  1309. jjrh has left

  1310. jjrh has left

  1311. UsL has joined

  1312. lovetox has joined

  1313. SamWhited has joined

  1314. SamWhited has joined

  1315. daniel has joined

  1316. remko has left

  1317. Dave Cridland has left

  1318. Dave Cridland has left

  1319. Dave Cridland has left

  1320. jjrh has left

  1321. Maranda has joined

  1322. Guus has left

  1323. Guus has left

  1324. Guus has joined

  1325. lorddavidiii has left

  1326. jubalh has left

  1327. jjrh has left

  1328. jjrh has left

  1329. marmistrz has joined

  1330. jjrh has left

  1331. jjrh has left

  1332. jjrh has left

  1333. lnj has left

  1334. vanitasvitae has left

  1335. lorddavidiii has left

  1336. jubalh has joined

  1337. jjrh has left

  1338. jjrh has left

  1339. marmistrz has left

  1340. ta has joined

  1341. jjrh has left

  1342. jjrh has left

  1343. jjrh has left

  1344. blabla has left

  1345. rtq3 has joined

  1346. jjrh has left

  1347. jjrh has left

  1348. Lance has joined

  1349. Maranda has left

  1350. Lance has joined

  1351. jjrh has left

  1352. rtq3 has left

  1353. blabla has joined

  1354. rtq3 has joined

  1355. jjrh has left

  1356. marmistrz has joined

  1357. jjrh has left

  1358. peter has left

  1359. Dave Cridland has left

  1360. sezuan has left

  1361. Dave Cridland has left

  1362. Dave Cridland has left

  1363. jjrh has left

  1364. Dave Cridland has left

  1365. jjrh has left

  1366. rtq3 has left

  1367. Dave Cridland has left

  1368. jere has left

  1369. jere has joined

  1370. Guus has left

  1371. Guus has left

  1372. Guus has left

  1373. Nekit has left

  1374. Guus has left

  1375. lskdjf has left

  1376. Dave Cridland has left

  1377. Dave Cridland has left

  1378. lumi has left

  1379. lumi has joined

  1380. jjrh has left

  1381. jjrh has left

  1382. jjrh has left

  1383. waqas has left

  1384. Dave Cridland has left

  1385. lskdjf has joined

  1386. Dave Cridland has left

  1387. Dave Cridland has left

  1388. lumi has left

  1389. lumi has joined

  1390. Dave Cridland has left

  1391. Dave Cridland has left

  1392. Dave Cridland has left

  1393. SaltyBones has left

  1394. Dave Cridland has left

  1395. SaltyBones has joined

  1396. Dave Cridland has left

  1397. jjrh has left

  1398. jjrh has left

  1399. Dave Cridland has left

  1400. jere has left

  1401. jere has joined

  1402. alexis has left

  1403. Bunneh has left

  1404. Bunneh has joined

  1405. Bunneh has left

  1406. Bunneh has joined

  1407. Bunneh has left

  1408. Bunneh has joined

  1409. Bunneh has left

  1410. Bunneh has joined

  1411. jjrh has left

  1412. jjrh has left

  1413. jjrh has left

  1414. waqas has joined

  1415. Guus has left

  1416. jjrh has left

  1417. Guus has left

  1418. moparisthebest has joined

  1419. Guus has left

  1420. Guus has left

  1421. Guus has joined

  1422. jjrh has left

  1423. jjrh has left

  1424. tux has left

  1425. tux has joined

  1426. SaltyBones has left

  1427. SaltyBones has joined

  1428. alexis has joined

  1429. jjrh has left

  1430. alexis has left

  1431. jjrh has left

  1432. alexis has joined

  1433. jere has left

  1434. Chobbes has joined

  1435. lumi has left

  1436. Guus has left

  1437. jjrh has left

  1438. alexis has left

  1439. alexis has joined