XSF Discussion - 2018-05-31


  1. muppeth has left

  2. blabla has joined

  3. muppeth has left

  4. vanitasvitae has left

  5. waqas has left

  6. la|r|ma has joined

  7. lskdjf has joined

  8. Zash has left

  9. alexis has left

  10. alexis has joined

  11. alexis has left

  12. alexis has joined

  13. j.r has joined

  14. j.r has joined

  15. rishiraj22 has left

  16. rishiraj22 has joined

  17. muppeth has joined

  18. rishiraj22 has left

  19. rishiraj22 has joined

  20. j.r has joined

  21. j.r has joined

  22. SamWhited has left

  23. SamWhited has joined

  24. alexis has left

  25. rishiraj22 has left

  26. alexis has joined

  27. tux has left

  28. tux has joined

  29. rishiraj22 has joined

  30. rishiraj22 has left

  31. moparisthebest has left

  32. rishiraj22 has joined

  33. rishiraj22 has left

  34. mrdoctorwho has joined

  35. mrdoctorwho has left

  36. Chobbes has joined

  37. matlag has left

  38. daniel has joined

  39. efrit has left

  40. alexis has left

  41. alexis has joined

  42. winfried has left

  43. Guus has left

  44. Guus has left

  45. Guus has left

  46. Guus has left

  47. waqas has joined

  48. rishiraj22 has joined

  49. rishiraj22 has left

  50. rishiraj22 has joined

  51. Nekit has joined

  52. rishiraj22 has left

  53. rishiraj22 has joined

  54. efrit has joined

  55. igor75 has left

  56. igor75 has joined

  57. j.r has joined

  58. j.r has joined

  59. igor75 has left

  60. igor75 has joined

  61. lorddavidiii has joined

  62. j.r has joined

  63. j.r has joined

  64. lorddavidiii has left

  65. lorddavidiii has joined

  66. Andrew Nenakhov has left

  67. mikaela has joined

  68. lnj has joined

  69. xnyhps has joined

  70. j.r has left

  71. j.r has joined

  72. mikaela has left

  73. Lance has joined

  74. Lance has joined

  75. Dave Cridland has left

  76. Dave Cridland has joined

  77. Dave Cridland has left

  78. Dave Cridland has joined

  79. rishiraj22 has left

  80. rishiraj22 has joined

  81. ibikk has joined

  82. mimi89999 has left

  83. mimi89999 has joined

  84. mimi89999 has joined

  85. alexis has left

  86. alexis has joined

  87. rion has left

  88. daniel has joined

  89. Dave Cridland has left

  90. Dave Cridland has joined

  91. j.r has joined

  92. Dave Cridland has left

  93. Dave Cridland has joined

  94. thorsten has left

  95. efrit has left

  96. j.r has joined

  97. efrit has joined

  98. goffi has joined

  99. Nekit has left

  100. ibikk has joined

  101. Andrew Nenakhov has joined

  102. Lance has joined

  103. Nekit has left

  104. Nekit has joined

  105. Lance has joined

  106. jonasw

    Kev, I heard swift can do XEP-0055 (Jabber Search). Does it support RSM-based pagination and if so, where is the RSM element included? And if not, do you think RSM would be a reasonable way to do that and if so, where would the RSM element go?

  107. Nekit has joined

  108. alexis has left

  109. Dave Cridland has left

  110. alexis has joined

  111. daniel has left

  112. efrit has left

  113. Guus has left

  114. alexis has left

  115. alexis has joined

  116. Guus has left

  117. rishiraj22 has left

  118. Dave Cridland has left

  119. Dave Cridland has joined

  120. rishiraj22 has joined

  121. j.r has joined

  122. j.r has joined

  123. Guus has left

  124. Guus has left

  125. Guus has joined

  126. daniel has joined

  127. Zash has left

  128. Tim has joined

  129. blabla has left

  130. blabla has joined

  131. rion has left

  132. Kev

    It does 55, I don't believe we RSM.

  133. jonasw

    I’d very much like to not return 4000 entries in one reply though

  134. Kev

    I don't think 55 supports RSM does it?

  135. jonasw

    does *anything* before XEP-0059 "support" RSM?

  136. jonasw

    oh look at this, XEP-0059 even uses XEP-0055 as example for RSM

  137. jonasw

    and it’s allegedly used with disco#items

  138. jonasw

    (even though I haven’t seen that in the wild with MUC services yet)

  139. goffi

    I though RSM could be applied anywhere without need to specify it. This this was we answered to me when I asked for disco in the past.

  140. jonasw

    (AFAICT)

  141. goffi

    I thought RSM could be applied anywhere without need to specify it. This this what was answered to me when I asked for disco in the past.

  142. rion has left

  143. ibikk has joined

  144. Andrew Nenakhov has joined

  145. Andrew Nenakhov has left

  146. Andrew Nenakhov has joined

  147. Andrew Nenakhov has left

  148. Andrew Nenakhov has joined

  149. Andrew Nenakhov has left

  150. Andrew Nenakhov has joined

  151. Zash has left

  152. waqas has left

  153. rion has left

  154. Andrew Nenakhov has left

  155. Andrew Nenakhov has joined

  156. mikeao has joined

  157. jubalh has joined

  158. la|r|ma has joined

  159. blabla has left

  160. blabla has joined

  161. rishiraj22 has left

  162. edhelas has left

  163. jonasw

    is there any standard for something like XEP-0055 (Jabber Search) but for MUCs? (not disco#items)

  164. Valerian has joined

  165. ibikk has joined

  166. Andrew Nenakhov has left

  167. Andrew Nenakhov has joined

  168. xnyhps has left

  169. edhelas has left

  170. xnyhps has joined

  171. daniel has left

  172. marc has left

  173. blabla has left

  174. blabla has joined

  175. ta has joined

  176. Steve Kille has left

  177. Steve Kille has left

  178. Zash has left

  179. Steve Kille has joined

  180. jubalh has joined

  181. j.r has left

  182. j.r has joined

  183. mikaela has joined

  184. goffi

    jonasw: what prevent you from using XEP-0055 with MUC ? It returns jid and can use data form for any extra data you wish.

  185. andy has joined

  186. Valerian has left

  187. Valerian has joined

  188. marmistrz has joined

  189. Andrew Nenakhov has left

  190. lskdjf has joined

  191. Andrew Nenakhov has joined

  192. andy has left

  193. andy has joined

  194. lorddavidiii has left

  195. lorddavidiii has left

  196. ralphm has joined

  197. Valerian has left

  198. Valerian has joined

  199. muppeth has joined

  200. SaltyBones has left

  201. marc has left

  202. Andrew Nenakhov has left

  203. Chobbes has joined

  204. winfried has joined

  205. lorddavidiii has joined

  206. lorddavidiii has left

  207. lorddavidiii has joined

  208. muppeth has joined

  209. SaltyBones has left

  210. Andrew Nenakhov has joined

  211. Lance has joined

  212. daniel has joined

  213. Lance has joined

  214. lnj has left

  215. Zash has joined

  216. jonasw

    goffi: sure, I can re-use bits of 55 but I was wondering whether there was any precedent for that

  217. Andrew Nenakhov has left

  218. muppeth has left

  219. Andrew Nenakhov has joined

  220. Andrew Nenakhov has left

  221. Andrew Nenakhov has joined

  222. Andrew Nenakhov has left

  223. Andrew Nenakhov has joined

  224. blabla has left

  225. blabla has joined

  226. marmistrz has joined

  227. Zash has left

  228. rtq3 has joined

  229. Syndace has joined

  230. lumi has joined

  231. Valerian has left

  232. Valerian has joined

  233. Valerian has left

  234. muppeth has left

  235. edhelas has left

  236. ta has left

  237. Andrew Nenakhov has left

  238. Ge0rG has left

  239. mikaela has left

  240. jubalh has joined

  241. marc has left

  242. rtq3 has left

  243. rtq3 has joined

  244. edhelas has left

  245. edhelas has joined

  246. edhelas has left

  247. edhelas has joined

  248. Syndace has joined

  249. Syndace has joined

  250. Lance has joined

  251. Lance has joined

  252. Zash has left

  253. ibikk has joined

  254. ibikk has joined

  255. la|r|ma has left

  256. daniel has left

  257. daniel has left

  258. blabla has left

  259. Lance has joined

  260. blabla has left

  261. Lance has joined

  262. muppeth has joined

  263. mimi89999 has joined

  264. rishiraj22 has joined

  265. alacer has left

  266. muppeth has joined

  267. alacer has joined

  268. blabla has left

  269. jubalh has joined

  270. daniel has left

  271. lumi has left

  272. Valerian has joined

  273. Valerian has left

  274. Valerian has joined

  275. andy has left

  276. jubalh has left

  277. jubalh has joined

  278. Valerian has left

  279. Valerian has joined

  280. jubalh has left

  281. Valerian has left

  282. Valerian has joined

  283. jubalh has joined

  284. Andrew Nenakhov has joined

  285. Zash has left

  286. Valerian has left

  287. rishiraj22 has left

  288. rishiraj22 has joined

  289. Valerian has joined

  290. jubalh has joined

  291. blabla has left

  292. Valerian has left

  293. Valerian has joined

  294. Valerian has left

  295. Andrew Nenakhov has left

  296. Valerian has joined

  297. Valerian has left

  298. ibikk has joined

  299. Valerian has joined

  300. Valerian has left

  301. matlag has left

  302. Valerian has joined

  303. Lance has joined

  304. Lance has joined

  305. Zash has left

  306. Andrew Nenakhov has left

  307. Andrew Nenakhov has joined

  308. xnyhps has left

  309. Dave Cridland has left

  310. Andrew Nenakhov has joined

  311. Guus has left

  312. Guus has left

  313. Guus has left

  314. Andrew Nenakhov has left

  315. Andrew Nenakhov has joined

  316. Andrew Nenakhov has left

  317. Andrew Nenakhov has joined

  318. Valerian has left

  319. Valerian has joined

  320. Guus has left

  321. Valerian has left

  322. moparisthebest has joined

  323. xnyhps has joined

  324. moparisthebest has joined

  325. rtq3 has left

  326. Tim has joined

  327. Lance has joined

  328. ibikk has left

  329. Lance has joined

  330. jubalh has joined

  331. vanitasvitae has left

  332. moparisthebest has joined

  333. moparisthebest has joined

  334. mikaela has joined

  335. mimi89999 has left

  336. rishiraj22 has left

  337. Tobias has left

  338. Tobias has joined

  339. rishiraj22 has joined

  340. alexis has left

  341. vanitasvitae has left

  342. alexis has joined

  343. matlag has left

  344. alexis has joined

  345. rion has left

  346. vanitasvitae has left

  347. jubalh has joined

  348. SaltyBones has left

  349. ibikk has joined

  350. daniel has left

  351. blabla has left

  352. rtq3 has joined

  353. rtq3 has left

  354. rtq3 has joined

  355. rishiraj22 has left

  356. rishiraj22 has joined

  357. vanitasvitae has left

  358. j.r has left

  359. j.r has joined

  360. efrit has joined

  361. Valerian has joined

  362. xnyhps has joined

  363. jubalh has joined

  364. vanitasvitae has left

  365. alexis has left

  366. alexis has joined

  367. xnyhps has joined

  368. alexis has left

  369. alexis has joined

  370. vanitasvitae has left

  371. muppeth has left

  372. Guus

    Board o'clock

  373. MattJ

    Hey

  374. Guus

    o/

  375. Guus

    ralphm, martin, nyco ?

  376. ralphm

    I am here, was held up

  377. rtq3 has left

  378. ralphm set the topic to

    XSF Board Meeting | Logs: http://logs.xmpp.org/xsf/ | Agenda https://trello.com/b/Dn6IQOu0/board-meetings

  379. Guus

    yey

  380. ralphm bangs gavel

  381. ralphm

    1. Welcome & Agenda

  382. ralphm

    Who's here and what topics do you prefer to discuss today?

  383. Guus

    I'm here

  384. MattJ

    I'm here

  385. MattJ

    We can discuss the next steps for the results of the survey

  386. Guus

    Also: gdpr compliance?

  387. ralphm

    Cool. Maybe revisit the GDPR discussion

  388. ralphm

    That should fill most of the meeting.

  389. Guus

    also: did anyone hear from Martin in the last few weeks?

  390. Guus

    he didn't renew XSF membership - I wonder if that was intentional.

  391. ralphm

    Not since May 3.

  392. MattJ

    Likewise

  393. vanitasvitae has left

  394. ralphm

    While there's no requirement to be a Member to be a Director, I share your curiosity.

  395. ralphm

    2. Survey.

  396. MattJ

    The survey "officially" ended yesterday, with 24 responses

  397. MattJ

    Which I don't consider too bad, I was expecting worse

  398. vanitasvitae has left

  399. alexis has joined

  400. MattJ

    I haven't had time to do anything with the responses, barely look at them. I propose I do that and share a Google Spreadsheet over email, and we can discuss in more detail next week?

  401. MattJ

    and if anyone has specific things they'd like to discuss (e.g. points raised) we can add those to the agenda

  402. Guus

    Sounds good to me.

  403. ralphm

    Agreed

  404. ralphm

    3. GDPR

  405. ralphm

    So there a few things here and maybe we should split them.

  406. vanitasvitae has left

  407. ralphm

    1) the XSF's compliance

  408. ralphm

    2) the proposed XEP

  409. MattJ

    Agreed, sensible

  410. Guus

    this feels like a beast: can we further split them?

  411. Andrew Nenakhov has joined

  412. ralphm

    Go aheah

  413. Guus

    I would if I knew how 🙂

  414. ralphm

    Well, there are a few things on 1)

  415. vanitasvitae has left

  416. ralphm

    - The foundation membership

  417. ralphm

    - The e-mail archives

  418. ralphm

    - The XMPP server with its rooms and archives

  419. ralphm

    shout if you can think up more items

  420. Guus

    that is: items where we potentially store private information?

  421. Guus

    do we use cookies on the website?

  422. MattJ

    s/private/personal/

  423. vanitasvitae has left

  424. ralphm

    personal, indeed

  425. Guus

    Matt just asked for everyone's mail address in a nice (but one-off) poll

  426. Zash has left

  427. MattJ

    I also stated how they would be used, and that they would not be kept permanently

  428. ralphm

    We can probably continue doing all the things we do, but we have to document what we process, for what reason, etc.

  429. Guus

    ok, stepping back: I'm unsure what exactly the end-goal is (other than 'be compliant' which I don't know what that entails)

  430. Zash has left

  431. ralphm

    And we need to revisit/reinstate the Privacy Policy that was written in 2008

  432. vanitasvitae has left

  433. Guus

    (we've got personal data in the wiki too, probably - and there's author information in each XEP)

  434. ralphm

    (for a discussion on this, see the archives of this room -1W)

  435. ralphm

    I also thought about the Wiki indeed, and the XEP

  436. Zash has left

  437. ralphm

    s

  438. Guus

    I was knee-deep in water at the time, have not read back 😕

  439. Zash has left

  440. ralphm

    Basically we had a PP for both jabber.org and xmpp.org, but with all the website transitions it is no longer available

  441. ralphm

    we have it somewhere still, though

  442. Zash has left

  443. vanitasvitae has left

  444. Zash has left

  445. Guus

    okay, say we are able to restore that: is there someone available that can tell if it is GDPR compliant?

  446. Zash has left

  447. alexis has joined

  448. rtq3 has joined

  449. Zash has left

  450. Andrew Nenakhov has joined

  451. ralphm

    First of all, no-one probably is 100% compliant, and you will know when somebody has sued you

  452. MattJ

    Nobody can really say for certain, there are too many grey areas - however I'm really not worried

  453. efrit has joined

  454. vanitasvitae has left

  455. MattJ

    Pretty much all we have is public, and given by people knowingly

  456. Zash has left

  457. ralphm

    The focus points will be documentation, the pp, and possibly retention, and information and deletion requests.

  458. MattJ

    There may be hidden things like server logs, but if we don't keep those for "too long", we "should" be ok

  459. Guus

    sure, and although I assume that that's ok, that's not based on any knowledge of gdpr on my part.

  460. flow has left

  461. flow has joined

  462. ralphm

    Well, I've been involved professionally, so I know a few things

  463. alexis has left

  464. Guus

    good. Tag, you're it. 🙂

  465. alexis has joined

  466. vanitasvitae has left

  467. ralphm

    I think we should also involve Alex

  468. ralphm

    haha, good one

  469. ralphm

    Sounds like MattJ knows things, too

  470. jubalh has joined

  471. Guus

    maybe we should task a certain group of people with doing an inventory of our data, and make recommendations?

  472. MattJ

    iteam?

  473. vanitasvitae has left

  474. Andrew Nenakhov has left

  475. Andrew Nenakhov has joined

  476. Guus

    or an adhoc one (Ralph, Alex, the people that have bene working on the XEP)

  477. vanitasvitae has left

  478. Guus

    I'd be happy to do leg-work, but I need someone to tell me what to do.

  479. vanitasvitae has left

  480. MattJ

    Well in the case I gave (server logs), that's something that requires iteam - an inventory of running services and what they collect

  481. vanitasvitae has left

  482. Guus

    RIght - that's why I suggest to have a SIG or WT with people like yourself that know what to look for. A small group of people that maintains an overview, and coordinates efforts with other WTs and board.

  483. ralphm

    I think a work team

  484. vanitasvitae has left

  485. Guus

    This all might be me being overcautious, based on a lack of understanding - if you see a way to shorttrack things, that's also fine by me.

  486. ralphm

    so indeed, you need iteam for inventory, someone the leads the effort, and in any case the Secretary should be involved

  487. ralphm

    There are probably helpful 10-step plans out there, but I haven't looked at that at all

  488. Guus

    I'm unsure if we can volunteer the Secretary for a WT, but we can at least ask the WT to inform the Secretary. 🙂

  489. Guus

    Ralph, would you mind spearheading that team?

  490. vanitasvitae has left

  491. Guus

    you seem to have a good grasp on tings.

  492. Guus

    things*

  493. ralphm

    On the involvement of the Secretary, probably yes we can volunteer him:

  494. ralphm

    Section 6.7 Secretary. Unless provided otherwise by a resolution adopted by the Board of Directors, the Secretary shall keep accurate records of the acts and proceedings of all meetings of the Members and Directors. The Secretary shall give all notices required by law and by these Bylaws. He or she shall mail to all Directors within thirty (30) days after each meeting copies of all said actions and minutes of said proceedings. In addition, the Secretary shall have general charge of the corporate books and records and of the corporate seal, and he or she shall affix, or attest the affixing of, the corporate seal to any lawfully executed instrument requiring it. The Secretary shall have general charge of the membership records of the Corporation and shall keep, at the principal office of the Corporation, a record of the Members showing the name, address, telephone number, facsimile number and electronic mail address of each Member. The Secretary shall sign such instruments as may require his or her signature and, in general, shall perform all duties as may be assigned to him or her from time to time by the Chair, the Executive Director or the Board of Directors.

  495. ralphm

    Note the part on 'corporate books and records'

  496. vanitasvitae has left

  497. Guus

    Let's aim to have a mission statement / member list ready for next week, so that we can procedurally establish the team.

  498. ralphm

    But of course we should ask Alex how he can help us on this

  499. ralphm

    seems reasonable

  500. ralphm

    Ok then, I guess we should move on to the other part

  501. ralphm

    4. GDPR XEP

  502. Guus

    (I don't have much more time to spend today)

  503. ralphm

    Oh, it is that time already.

  504. Guus

    as for the XEP: what are downsides of publishing such a XEP?

  505. ralphm

    Well, in principle it is unclear if the XSF should publish a specification that would give guidelines in direct relation to the GDPR

  506. ralphm

    I'm not familiar with US law, but the concept of Legal Advise is a apparently a Thing

  507. ralphm

    Advice even

  508. Guus

    what is "giving legal advice" ? Does publishing that XEP qualify?

  509. ralphm

    Well, in the state that it was in last week, there wasn't much in there yet

  510. ralphm

    I haven't checked since

  511. MattJ

    It's a combination of factors - for example, in some places you need to be licensed to practice law

  512. ralphm

    But I think it is more important for any such document to provide general guidelines in terms of knowing what you process and what things to take into account to ensure privacy for your service, and leave the rest up to people who Know Things (typically lawyers) for actual compliance

  513. MattJ

    It's a stretch, but if it was taken as the XSF is giving legal advice without being qualified to do so, that's illegal in those $some_places

  514. muppeth has joined

  515. Guus

    My perspective is that I'd prefer to help the XMPP community by providing information, as long as a) we're not opening ourselves up to liability, and b) we can somehow be reasonably certain that we're not spreading misinformation.

  516. MattJ

    and separate from this issue, but similar - someone could try to blame the XSF if they followed published advice but got fined under GDPR

  517. Guus

    There's a huge gap between practice law and give information

  518. efrit has left

  519. ralphm

    Right, so as Peter has suggested, and I agree with, I'd like any such document to be actual best practices, not related to any particular legislation

  520. Guus

    that's reasonable

  521. MattJ

    Me too

  522. Guus

    ok, I need to be going now

  523. Guus

    can we pick this up next week?

  524. ralphm

    Sure

  525. ralphm

    4. Date of Next

  526. ralphm

    +1W

  527. ralphm

    5. Close

  528. ralphm

    Thanks all.

  529. ralphm bangs gavel

  530. MattJ

    Thanks

  531. Andrew Nenakhov has joined

  532. ralphm set the topic to

    XSF Discussion | Logs: http://logs.xmpp.org/xsf/ | Agenda https://trello.com/b/Dn6IQOu0/board-meetings

  533. Guus

    woah, I alt-tabbed for two seconds 🙂

  534. Guus

    thank you 🙂

  535. ralphm

  536. ralphm

    Also, I'm sure I used 4 two times, so whoever is making the Minutes (*wink*) should take that into account

  537. vanitasvitae has left

  538. Guus has left

  539. Zash has left

  540. vanitasvitae has left

  541. Guus has left

  542. Guus has left

  543. alexis has left

  544. alexis has joined

  545. lskdjf has joined

  546. Guus has left

  547. vanitasvitae has left

  548. la|r|ma has joined

  549. vanitasvitae has left

  550. vanitasvitae has left

  551. lumi has joined

  552. vanitasvitae has left

  553. muppeth has left

  554. muppeth has joined

  555. vanitasvitae has left

  556. vanitasvitae has left

  557. rtq3 has left

  558. blabla has left

  559. blabla has left

  560. blabla has joined

  561. vanitasvitae has left

  562. mikaela has left

  563. muppeth has left

  564. vanitasvitae has left

  565. muppeth has joined

  566. ibikk has joined

  567. rtq3 has joined

  568. mikaela has joined

  569. muppeth has joined

  570. muppeth has joined

  571. alexis has left

  572. alexis has joined

  573. andy has joined

  574. efrit has joined

  575. jubalh has joined

  576. mimi89999 has joined

  577. Valerian has left

  578. Valerian has joined

  579. Valerian has left

  580. Valerian has joined

  581. tux has joined

  582. daniel has left

  583. ibikk has left

  584. rishiraj22 has left

  585. muppeth has joined

  586. muppeth has left

  587. jubalh has joined

  588. j.r has joined

  589. j.r has joined

  590. rishiraj22 has joined

  591. Guus has left

  592. goffi

    would not it be possible for the XSF to hire some legal advisor to create a document? I mean this is expensive for a single project, but if XSF is hiring one describing general helping document, we could do some kind of crowdfunding among XMPP community. Maybe FSF have some helpful contacts

  593. goffi

  594. Guus has left

  595. jubalh has joined

  596. vanitasvitae has left

  597. jere has joined

  598. Zash has left

  599. Dave Cridland has left

  600. Dave Cridland has joined

  601. rtq3 has left

  602. lorddavidiii has left

  603. Zash has left

  604. Dave Cridland has left

  605. flow

    I'm pretty sure I've asked years ago on standards@ if an IQ send to the own bare JID is semantically equivalent to the same stanza without a 'to' attribute, but my google-fu is not strong enough to find that thread again

  606. Kev

    The answer is "yes". Also "no".

  607. Kev

    It is the same, except that there's some odd text still lying around that hints otherwise, like that roster queries must be no-JID (rather than bare-JID), maybe?

  608. flow

    I feared that this was the conclusion back then

  609. Zash

    Can we have that odd text accidentally dropped down a well?

  610. flow

    would a MAM IQ to the own bare JID be equal to the same query without to attribute?

  611. Kev

    flow: Yes.

  612. flow

    *without 'to' attribute

  613. MattJ

    As far as I'm concerned, and Prosody is concerned, yes

  614. Zash

    Prosody treats to=own bare jid identical to missing to

  615. daniel

    Can we just get rid of missing to and missing froms

  616. Zash

    In fact, it removes the 'to' and uses its absense for security related things

  617. blabla has left

  618. Zash

    daniel: make them mandatory always, like on s2s?

  619. flow

    Zash, interesting, care to elaborate on these "security related things" that you get when you handle stanzas without 'to'?

  620. MattJ

    daniel, in a way I prefer it, you know this stanza isn't going anywhere

  621. daniel

    Zash: yes. If you want to send something to your account you have to address it

  622. daniel

    And vice versa

  623. ibikk has joined

  624. MattJ

    flow, these stanzas are typically special in most XEPs (from user to their own account), they are privileged and Prosody handles them separately from normal stanzas that are to be routed

  625. rishiraj22 has left

  626. waqas has joined

  627. j.r has joined

  628. j.r has joined

  629. Zash

    daniel: I want the opposite

  630. MattJ

    and we normalize the to/from to 'missing to' so that there can't be any JID normalization accidents in modules

  631. Zash

    And then it bites Ge0rG right in the carbons

  632. daniel

    MattJ: but if you address your server the stanza isn't going anywhere either...

  633. daniel

    For some definition of not going anywhere

  634. Kev

    MattJ: Do you do some sort of NAT to get the right address injected when you reply then?

  635. Kev

    Because replying to a to=bare stanza with missing to isn't ok.

  636. MattJ

    Kev, 'from' is always set, and that's what we reply to

  637. MattJ

    and 'to' is not needed on c2s streams

  638. Kev

    Because replying to a to=bare stanza with missing from isn't ok.

  639. Zash

    to and from should default to the entities on each end of c2s streams, ie the client and their account

  640. MattJ

    Obviously from and to are swapped in any reply

  641. Kev

    One has to be fairly careful when claiming anything is obvious, when talking about this ;)

  642. Guus has left

  643. Guus has left

  644. jonasw

    Kev, why is it not ok? missing from is identical to comes from bare jid, isn’t it?

  645. Zash

    client sending <message> == <message from=ownfulljid to=ownbare>

  646. jonasw

    (missing from when server sends)

  647. jonasw

    oh okay, MUST include the from attribute

  648. jonasw

    I am /pretty/ sure that I’ve seen servers which do not do that.

  649. jonasw

    I have ugly workarounds for that

  650. jonasw

    ah, no I am at the wrong place in the text

  651. Zash

    Whowhere?

  652. jonasw

    3. When the server generates a stanza from the server for delivery to the client on behalf of the account of the connected client (e.g., in the context of data storage services provided by the server on behalf of the client), the stanza MUST either (a) not include a 'from' attribute or (b) include a 'from' attribute whose value is the account's bare JID (<localpart@domainpart>).

  653. jonasw

    Kev, so, there’s no NAT needed, just don’t emit the @from in the reply ^

  654. Guus has left

  655. daniel

    Zash: hoover?

  656. Kev

    jonasw: Yes, but if it's a reply to a stanza the client sent, the server must swap the to/from.

  657. Zash

    🕴

  658. Kev

    You can't, as a server, receive a stanza that is to=bare JID, and reply with no from.

  659. MattJ

    Kev, says?

  660. Zash

    The holy text.

  661. Alex has joined

  662. Kev

    MattJ: 6120, somewhere.

  663. Kev

    e.g. for error stanzas "The error stanza SHOULD simply swap the 'from' and 'to' addresses from the generated stanza"

  664. MattJ

    That's a stretch to say it applies to all stanzas, as you're saying

  665. Kev

    Yes, that was just the quickest thing to find.

  666. MattJ

    I think the text jonasw pasted is pretty clear that the server has two valid options

  667. Kev

    Yes, but not clear that both are always right.

  668. ta has joined

  669. MattJ

    Then that text might as well be removed, and let the text you remember specify what the 'from' should be

  670. lumi has left

  671. jonasw

    Kev, ok, then I found a server with a bug.

  672. Guus has left

  673. jonasw

    because that’s why I needed workarounds (because servers did exactly that)

  674. jonasw

    ah, well

  675. jonasw

    if the swap is only a SHOULD, I can see this to be an exception

  676. Guus has left

  677. Kev

    I can't find the odd text about rosters now on a quick search either, so there's clearly text I'm failing to find.

  678. Guus has left

  679. Guus has left

  680. lnj has joined

  681. Kev

    jonasw: We have handling too, in https://github.com/swift/swift/blob/master/Swiften/Queries/Request.cpp#L79

  682. Kev

    (In fact, we have further workarounds for ejabberd issues where they used to reply with full JIDs)

  683. jonasw

    oh yes

  684. jonasw

    I love those

  685. Steve Kille has left

  686. Steve Kille has left

  687. Wiktor has joined

  688. Guus has left

  689. Steve Kille has joined

  690. goffi has left

  691. valo has joined

  692. valo has joined

  693. jubalh has joined

  694. alacer has left

  695. alacer has joined

  696. jjrh has left

  697. muppeth has joined

  698. muppeth has joined

  699. rtq3 has joined

  700. Neustradamus has left

  701. j.r has joined

  702. koyu has joined

  703. koyu has left

  704. Alex has left

  705. jere has left

  706. jere has joined

  707. alexis has left

  708. Alex has joined

  709. alexis has joined

  710. alexis has left

  711. alexis has joined

  712. koyu has joined

  713. koyu has joined

  714. koyu

    hey, i just setup my own xmpp server

  715. SaltyBones has left

  716. Kev

    Welcome to the cool club. Or something.

  717. MattJ

    :)

  718. koyu

    yeah, i just can't get omemo to work on ejabberd

  719. Wiktor

    As far as I remember omemo is disabled by default in ejabberd, but you may check in ejabberd room

  720. Wiktor

    xmpp:ejabberd@conference.process-one.net?join

  721. alexis has joined

  722. Neustradamus has joined

  723. muppeth has left

  724. muppeth has joined

  725. lumi has joined

  726. waqas has left

  727. koyu has joined

  728. jjrh has left

  729. koyu has joined

  730. jjrh has left

  731. jubalh has joined

  732. tux has joined

  733. koyu has left

  734. koyu has joined

  735. jjrh has left

  736. alexis has left

  737. alexis has joined

  738. alexis has joined

  739. alexis has left

  740. alexis has joined

  741. koyu has left

  742. koyu has joined

  743. alexis has left

  744. alexis has joined

  745. waqas has joined

  746. j.r has joined

  747. Steve Kille has left

  748. Steve Kille has left

  749. jonasw

    Ge0rG, chat.yax.im down?

  750. tux has joined

  751. Dave Cridland has left

  752. Dave Cridland has joined

  753. Andrew Nenakhov has left

  754. Andrew Nenakhov has joined

  755. Guus has left

  756. Guus has left

  757. Valerian has left

  758. Valerian has joined

  759. Andrew Nenakhov has left

  760. Andrew Nenakhov has joined

  761. efrit has left

  762. efrit has joined

  763. jere has left

  764. jere has joined

  765. Ge0rG

    jonasw: works for me

  766. jonasw

    yeah, it just had a few minutes of hangup

  767. jonasw

    17:04:14 <--- You (jonasw) left the room (the MUC server is not responding) 17:07:17 ---> You (jonasw) joined the room

  768. jonasw

    (or maybe it was just the link between us. who knows)

  769. Valerian has left

  770. Valerian has joined

  771. Lance has joined

  772. Lance has joined

  773. jubalh has joined

  774. SaltyBones has left

  775. SaltyBones has left

  776. SaltyBones has left

  777. rtq3 has left

  778. jjrh has left

  779. koyu has left

  780. jjrh has left

  781. jjrh has left

  782. rtq3 has joined

  783. jubalh has left

  784. jjrh has left

  785. lskdjf has joined

  786. lskdjf has joined

  787. lskdjf has joined

  788. jjrh has left

  789. lskdjf has left

  790. ibikk has joined

  791. SamWhited has left

  792. vanitasvitae has left

  793. la|r|ma has joined

  794. la|r|ma has joined

  795. Guus has left

  796. Guus has left

  797. Tobias has joined

  798. Tobias has joined

  799. vanitasvitae has left

  800. Dave Cridland has left

  801. Dave Cridland has left

  802. Dave Cridland has joined

  803. la|r|ma has left

  804. mikeao has left

  805. jere has left

  806. Lance has joined

  807. vanitasvitae has left

  808. Lance has joined

  809. ta has left

  810. ta has joined

  811. andy has left

  812. jere has joined

  813. Dave Cridland has left

  814. SaltyBones has left

  815. andy has joined

  816. j.r has joined

  817. Guus has left

  818. ta has joined

  819. Valerian has left

  820. Valerian has joined

  821. UsL has joined

  822. mikaela has joined

  823. Dave Cridland has left

  824. Dave Cridland has joined

  825. Valerian has left

  826. Valerian has joined

  827. vanitasvitae has left

  828. rtq3 has left

  829. Dave Cridland has left

  830. Dave Cridland has joined

  831. vanitasvitae has left

  832. j.r has joined

  833. Alex has left

  834. andy has left

  835. Valerian has left

  836. vanitasvitae has left

  837. Dave Cridland has left

  838. Dave Cridland has joined

  839. Zash has left

  840. vanitasvitae has left

  841. rtq3 has joined

  842. vanitasvitae has left

  843. vanitasvitae has left

  844. jubalh has joined

  845. rtq3 has left

  846. vanitasvitae has left

  847. vanitasvitae has left

  848. vanitasvitae has left

  849. vanitasvitae has left

  850. vanitasvitae has left

  851. vanitasvitae has left

  852. vanitasvitae has left

  853. vanitasvitae has left

  854. vanitasvitae has left

  855. la|r|ma has joined

  856. vanitasvitae has left

  857. Tobias has left

  858. Tobias has joined

  859. Dave Cridland has left

  860. Dave Cridland has joined

  861. Dave Cridland has left

  862. jjrh has left

  863. Dave Cridland has joined

  864. jubalh has left

  865. j.r has joined

  866. MattJ

    So MIX proxy JIDs... if someone creates a MIX channel that is <1023 bytes>@mix.example.com... what happens to the userid part?

  867. jonasw

    "boom"

  868. jonasw

    I imagine servers simply wouldn’t allow that

  869. MattJ

    So how long is the generated id?

  870. jonasw

    probably service-defined

  871. MattJ

    It's such a hack

  872. jonasw

    do you have a better suggestion?

  873. MattJ

    Well instead of overloading what should be an opaque identifier why not re-use a mechanism that is already in the protocol as a secondary identifier behind bare JIDs?

  874. rtq3 has joined

  875. jonasw

    because that leads to the same situation

  876. jonasw

    just in a different part and with different moving parts

  877. jonasw

    with Kevs variant (1), the multiple pieces are in the nodepart, with variant (2) the multiple pieces are in the resource

  878. jonasw

    so both are bad w.r.t. that

  879. jonasw

    one way out of that would be to use $service-wide-user-id@$service-domain/$resource instead (so the MIX identifier wouldn’t be part of the node at all). but that requires to have the JID of the MIX inside the relevant stanzas

  880. MattJ

    All existing routing, libraries and... everything already knows how to correctly split a JID

  881. jonasw

    true

  882. jonasw

    and I think that the semantics assumed with "bare JID" work better with variant (1) than with variant (2)

  883. SamWhited has left

  884. MattJ

    Trust me, someone will want to implement some higher-level logic to know which messages are associated with a MIX channel

  885. MattJ

    Except with variant (1) you can't really do that

  886. MattJ

    You have to know it *is* a MIX channel, and that you have to strip the bit before the #

  887. MattJ

    Block a MIX channel? Ok, but messages from participants would still reach you

  888. jonasw

    and other people want to have high-level logic to konw which messages are associated with a MIX channel occupant.

  889. ibikk has joined

  890. MattJ

    any kind of filtering or logic based on the channel JID now almost always will need to be adapted to look for the # part

  891. vanitasvitae has left

  892. jonasw

    we should’ve followed email and allowed multiple @s in addresses

  893. MattJ

    Yes, that would really have helped... :)

  894. MattJ

    so now nobody knows what an email address actually is, but everyone has their own idea that's good enough for them

  895. MattJ

    Pretty much what's going on here, to be honest :)

  896. MattJ

    The # is the extra @ to the entities that can see it

  897. MattJ

    To the others, it's not and it's weird

  898. jonasw

    the variant (2) would make things worse than MUC actually

  899. MattJ

    Can you (or someone) lay down the reasons for that?

  900. jonasw

    didn’t I?

  901. jjrh has left

  902. MattJ

    I didn't see if you did, /me checks

  903. jonasw

    but the point which I just realized is, that with variant (2), there’s no single JID which will ever occur in a message identifies an occupant

  904. jonasw

    so if you wanted to filter all messages from an occupant, you’d have to know that they’re MIX messages

  905. jonasw

    to split them correctly

  906. jonasw

    kinda the same issue you describe with MIX channels in variant (1)

  907. MattJ

    Hmm, what do you mean?

  908. jonasw

    for example, presence

  909. jere has joined

  910. jonasw

    and avatar hashes

  911. jonasw

    I keep those in a cache, usually keyed by the bare JID

  912. jonasw

    which I can’t do for MUC, I have to use the full JID, but that’s okay

  913. jonasw

    (I actually have to break layers to detect that a presence is MUC related at that point)

  914. jonasw

    now with MIX, it’s worse, because not only do I have to check that it’s MIX-related, I also have to use a non-RFC6122 splitting function on the JID to determine the cache key

  915. jonasw

    i.e. do determine the identity this JID belongs to

  916. jonasw

    really, the same thing you described earlier, just with occupants instead of channels

  917. MattJ

    Right

  918. jonasw

    I think your issue is more server-side and my issue is more client-side, actually, and that might be why we see them strongly each

  919. jonasw

    (clients may be more interested in occupant identities, while servers may be more interested in channel identities because that’s the granularity they work on)

  920. MattJ

    So how do you know it's a MIX message and you need to split the nodepart? Payload?

  921. jonasw

    yes

  922. mikaela has left

  923. jonasw

    Strawman proposal: - proxy JID does not contain the MIX channel, but only the proxy identifier in the nodepart - resource as usual - MIX channel is identified in payload, e.g. <message from="ac2c37a7-10a6-4cd7-a708-4973d5d365f8@mixservice.domain.example" to="user@other.example" type="groupchat"><mix channel="..."/></message>

  924. Dave Cridland has left

  925. Dave Cridland has joined

  926. jonasw

    Strawman proposal: - proxy JID does not contain the MIX channel, but only the proxy identifier in the nodepart - resource as usual - MIX channel is identified in payload, e.g. <message from="ac2c37a7-10a6-4cd7-a708-4973d5d365f8@mixservice.domain.example/client-resource" to="user@other.example" type="groupchat"><mix channel="..."/></message>

  927. MattJ

    Heh, part of me wants to dislike that, but I prefer it

  928. MattJ

    I feel like the security aspects need to be investigated here though

  929. jonasw

    that’s not how straw-mans are supposed to work

  930. jonasw

    which part exactly?

  931. MattJ

    Well you need to verify the service in every case, I think

  932. jonasw

    what do you mean exactly?

  933. MattJ

    Otherwise I register mattj#rocks@jabber.org and send you a message wih a MIX payload

  934. Andrew Nenakhov has left

  935. jonasw

    and then?

  936. Andrew Nenakhov has joined

  937. MattJ

    Don't know, currently I got as far as "your client breaks"

  938. jonasw

    the client or server would drop it because it doesn’t know about a MIX rocks@jabber.org

  939. jonasw

    just like we currently drop type="groupchat" from MUCs we don’t know.

  940. MattJ

    Right, the whole "participant's server needs to know MIX" thing

  941. Andrew Nenakhov has joined

  942. jonasw

    at least we’re honest about it this time (not with MUC, where servers were blindsided by interesting interaction sideeffects e.g. when changing nicknames)

  943. jonasw

    at least we’re honest about it this time (not like with MUC, where servers were blindsided by interesting interaction sideeffects e.g. when changing nicknames)

  944. MattJ

    I like your straw-man because it opens up the possibility for a user on a MIX service to have a stable JID across multiple channels

  945. Guus has left

  946. jonasw

    I’m not sure that’s a good thing

  947. jonasw

    but mmm, it could be

  948. jonasw

    it makes it more difficult for MIX services though

  949. Guus has left

  950. Guus has left

  951. MattJ

    How so?

  952. jonasw

    when I send a message to ac2c37a7-10a6-4cd7-a708-4973d5d365f8@mixservice.domain.example, they need to verify that I share a channel with them

  953. jonasw

    (or may need to, depending on the service policies; but I assume that this is how most services will want to operate)

  954. jonasw

    hm, or we require <mix channel="…"/> elements even in non-groupchat messages

  955. jonasw

    then the sender would assert through which channel this message shall be "tunneled" and the server would not have to form the intersection of both channel lists

  956. jonasw

    question is whether that’s reasonable

  957. SaltyBones has left

  958. MattJ

    Totally if you ask me

  959. jonasw

    so I’ll post that to the list now

  960. MattJ

    Variant 3! Thanks :)

  961. MattJ has left

  962. Guus has left

  963. alacer has left

  964. jere has joined

  965. Tobias has left

  966. Tobias has joined

  967. jonasw

    Advantages: - No re-write of resources - Bare JID refers to occupant identity (good for clients) - Servers can simply filter on message/mix@channel - Opens up the possibility of re-using the same proxy JID for the same occupant across different channels (may be useful in some deployments, via MattJ) Disadvantages: - All (including 1:1) stanzas exchanged between occupants require the <mix channel="…"/> element for MIX channels to be able to easily route them - Entities filtering on MIX channel identity still need to know about MIX (and the <mix channel="…"/> element)

  968. jonasw

    did I miss something?

  969. rtq3 has left

  970. rtq3 has joined

  971. vanitasvitae has left

  972. jonasw

    sent

  973. MattJ

    Sorry, lgtm

  974. vanitasvitae has left

  975. MattJ has left

  976. Lance has joined

  977. peter has joined

  978. Lance has joined

  979. Dave Cridland has left

  980. Dave Cridland has joined

  981. efrit has left

  982. efrit has joined

  983. vanitasvitae has left

  984. Andrew Nenakhov has left

  985. Andrew Nenakhov has joined

  986. Kev

    I'll reply properly onlist in the morning, but now you need to do DPI to be able to routing in your client, because the routing information is no longer in the header? That's terribly unpleasant.

  987. Kev

    I'll reply properly onlist in the morning, but now you need to do DPI to be able to do routing in your client, because the routing information is no longer in the header? That's terribly unpleasant.

  988. Kev

    i.e. I think option 3 is the worst of the three.

  989. Kev

    (And possibly worse, your server needs to be doing DPI in order to make archiving work)

  990. jonasw

    Kev, don’t you need to do DPI anyways because you need to be sure you’re looking at a MIX message?

  991. jonasw

    (otherwise, the "MIX JID splitting function" (whatever that is) would operate on non MIX JIDs and possibly yield wrong results)

  992. Kev

    No, you don't :)

  993. jonasw

    servers need to do DPI anyways today for archiving to work.

  994. Kev

    Not at this level.

  995. MattJ has left

  996. jonasw

    normally, type="groupchat" isn’t archived at all, right?

  997. Kev

    That obviously has to change.

  998. jonasw

    for MIX, yes

  999. Kev

    type=groupchat to the bare JID gets archived.

  1000. Kev

    (Once routing/archiving rules are fixed)

  1001. jonasw

    right

  1002. jonasw

    that would work

  1003. Kev

    I have to sort out bins and then go to bed, but I think option 3 has worse issues than the conflation in option 1/2.

  1004. jonasw

    looking forward to your reply

  1005. jonasw

    and the discussion :)

  1006. Valerian has joined

  1007. Andrew Nenakhov has left

  1008. Andrew Nenakhov has joined

  1009. moparisthebest has joined

  1010. rion has left

  1011. Valerian has left

  1012. Dave Cridland has left

  1013. Valerian has joined

  1014. Valerian has left

  1015. Valerian has joined

  1016. Andrew Nenakhov has left

  1017. Andrew Nenakhov has joined

  1018. Valerian has left

  1019. lorddavidiii has left

  1020. MattJ has left

  1021. j.r has joined

  1022. j.r has joined

  1023. Holger has left

  1024. rtq3 has left

  1025. Andrew Nenakhov has left

  1026. Andrew Nenakhov has joined

  1027. j.r has joined

  1028. j.r has joined

  1029. Holger has left

  1030. lorddavidiii has left

  1031. MattJ has joined

  1032. j.r has joined

  1033. j.r has joined

  1034. peter has left

  1035. Andrew Nenakhov has left

  1036. Andrew Nenakhov has joined

  1037. j.r has left

  1038. lorddavidiii has left

  1039. j.r has joined

  1040. SamWhited has left

  1041. blabla has left

  1042. blabla has joined

  1043. rtq3 has joined

  1044. daniel has left

  1045. jjrh has left

  1046. Andrew Nenakhov has left

  1047. Andrew Nenakhov has joined

  1048. Andrew Nenakhov has left

  1049. Andrew Nenakhov has joined

  1050. Dave Cridland has left

  1051. Dave Cridland has joined

  1052. Dave Cridland has left

  1053. Dave Cridland has joined

  1054. mimi89999 has joined

  1055. mimi89999 has left

  1056. mimi89999 has joined

  1057. valo has left

  1058. Ge0rG has left

  1059. valo has joined

  1060. rtq3 has left

  1061. moparisthebest has joined

  1062. Kev has left

  1063. rtq3 has joined

  1064. alexis has joined

  1065. alexis has left

  1066. alexis has joined

  1067. lskdjf has joined

  1068. SamWhited has left

  1069. UsL has left

  1070. Syndace has joined

  1071. Syndace has joined

  1072. lumi has left

  1073. vanitasvitae has left

  1074. jere has left

  1075. jere has joined