XSF logo 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