XSF Discussion - 2018-03-22


  1. Dave Cridland has left
  2. Dave Cridland has left
  3. Dave Cridland has left
  4. Dave Cridland has left
  5. remko has left
  6. daniel has left
  7. Dave Cridland has left
  8. Dave Cridland has left
  9. Dave Cridland has left
  10. Dave Cridland has left
  11. waqas has left
  12. winfried has joined
  13. Dave Cridland has left
  14. ludo has joined
  15. efrit has joined
  16. daniel has left
  17. lskdjf has joined
  18. la|r|ma has joined
  19. remko has joined
  20. Dave Cridland has left
  21. ludo has left
  22. blabla has joined
  23. Dave Cridland has left
  24. Dave Cridland has left
  25. remko has joined
  26. Dave Cridland has left
  27. Dave Cridland has left
  28. ludo has joined
  29. Dave Cridland has left
  30. Dave Cridland has left
  31. Dave Cridland has left
  32. ta has joined
  33. waqas has joined
  34. Dave Cridland has left
  35. tux has left
  36. tux has joined
  37. Dave Cridland has left
  38. remko has joined
  39. Dave Cridland has left
  40. ludo has left
  41. Guus has left
  42. Dave Cridland has left
  43. Guus has left
  44. efrit has left
  45. Dave Cridland has left
  46. Dave Cridland has left
  47. ludo has joined
  48. remko has joined
  49. Dave Cridland has left
  50. Dave Cridland has left
  51. Dave Cridland has left
  52. Dave Cridland has left
  53. Dave Cridland has left
  54. ludo has left
  55. Dave Cridland has left
  56. Dave Cridland has left
  57. ludo has joined
  58. Dave Cridland has left
  59. Guus has left
  60. Dave Cridland has left
  61. ludo has left
  62. lumi has left
  63. Dave Cridland has left
  64. remko has joined
  65. Dave Cridland has left
  66. Dave Cridland has left
  67. Dave Cridland has left
  68. Dave Cridland has left
  69. remko has left
  70. Guus has left
  71. daniel has left
  72. jere has joined
  73. Dave Cridland has left
  74. Dave Cridland has left
  75. vanitasvitae has left
  76. marc has left
  77. marc has joined
  78. lskdjf has joined
  79. marc has joined
  80. marc has joined
  81. marc has joined
  82. marc has joined
  83. marc has joined
  84. marc has joined
  85. marc has joined
  86. marc has joined
  87. marc has joined
  88. Dave Cridland has left
  89. Guus has left
  90. Dave Cridland has left
  91. remko has joined
  92. Guus has left
  93. Yagiza has joined
  94. Dave Cridland has left
  95. Dave Cridland has left
  96. Guus has left
  97. Dave Cridland has left
  98. daniel has left
  99. Dave Cridland has left
  100. Guus has left
  101. remko has joined
  102. ralphm has joined
  103. Guus has left
  104. la|r|ma has left
  105. marc has joined
  106. Dave Cridland has left
  107. Dave Cridland has left
  108. rion has joined
  109. rion has left
  110. rion has joined
  111. Guus has left
  112. lskdjf has joined
  113. jere has joined
  114. Dave Cridland has left
  115. Dave Cridland has left
  116. Guus has left
  117. la|r|ma has joined
  118. remko has joined
  119. Guus has left
  120. Dave Cridland has left
  121. ludo has joined
  122. Dave Cridland has left
  123. rion has left
  124. Guus has left
  125. Dave Cridland has left
  126. ludo has left
  127. Dave Cridland has left
  128. remko has joined
  129. jere has left
  130. marc has left
  131. marc has joined
  132. Dave Cridland has left
  133. Dave Cridland has left
  134. Guus has left
  135. Dave Cridland has left
  136. rion has left
  137. Nekit has left
  138. Nekit has joined
  139. Dave Cridland has left
  140. Dave Cridland has left
  141. Guus has left
  142. ta has left
  143. ta has joined
  144. Dave Cridland has left
  145. rion has left
  146. Dave Cridland has left
  147. Dave Cridland has left
  148. rion has left
  149. remko has joined
  150. Dave Cridland has left
  151. winfried has joined
  152. winfried has joined
  153. Guus has left
  154. Dave Cridland has left
  155. Dave Cridland has left
  156. Dave Cridland has left
  157. Guus has left
  158. Dave Cridland has left
  159. remko has joined
  160. Dave Cridland has left
  161. j.r has joined
  162. j.r has joined
  163. daniel has left
  164. Dave Cridland has left
  165. rion has left
  166. j.r has joined
  167. j.r has joined
  168. marmistrz has joined
  169. marmistrz has joined
  170. LNJ has joined
  171. j.r has joined
  172. j.r has joined
  173. Dave Cridland has left
  174. Guus has left
  175. rion has joined
  176. goffi has joined
  177. Dave Cridland has left
  178. remko has joined
  179. j.r has left
  180. j.r has joined
  181. j.r has left
  182. j.r has joined
  183. j.r has left
  184. j.r has joined
  185. ludo has joined
  186. daniel has left
  187. Nekit has left
  188. Nekit has joined
  189. Guus has left
  190. remko has joined
  191. marmistrz has joined
  192. Dave Cridland has left
  193. blabla has joined
  194. ralphm has left
  195. ralphm has joined
  196. Dave Cridland has left
  197. ralphm has left
  198. ralphm has joined
  199. goffi has left
  200. goffi has joined
  201. ludo has left
  202. Dave Cridland has left
  203. Dave Cridland has left
  204. marmistrz has joined
  205. Zash has left
  206. Zash has joined
  207. ralphm has left
  208. ralphm has joined
  209. Dave Cridland has left
  210. Guus has left
  211. Dave Cridland has left
  212. LNJ has left
  213. Dave Cridland has left
  214. Holger has left
  215. ralphm has left
  216. ralphm has joined
  217. tim@boese-ban.de has joined
  218. remko has joined
  219. Dave Cridland has left
  220. Guus has left
  221. Dave Cridland has left
  222. Valerian has joined
  223. Guus has left
  224. ralphm has left
  225. ralphm has joined
  226. Dave Cridland has left
  227. remko has joined
  228. Dave Cridland has left
  229. mimi89999 has joined
  230. ludo has joined
  231. marmistrz has left
  232. pep. has left
  233. Guus has left
  234. ta has left
  235. moparisthebest has joined
  236. Dave Cridland has left
  237. moparisthebest has joined
  238. ludo has left
  239. remko has joined
  240. daniel has left
  241. SaltyBones has left
  242. marmistrz has left
  243. ralphm has left
  244. ralphm has joined
  245. pep. has left
  246. Yagiza has left
  247. Yagiza has joined
  248. marc has left
  249. marc has joined
  250. Ge0rG moparisthebest: yes, all MUC messages go to all participants immediately, because the server doesn't know the user's notification settings
  251. Ge0rG moparisthebest: if the user has "notify on all messages", delaying would be bad
  252. jonasw but the users server may delay them with CSI
  253. jonasw if it knows about the notification settings :)
  254. jonasw moparisthebest, obviously, you haven’t been in the MUC of the local hacker space. People there think that using OMEMO in a public muc is a super great idea.
  255. Yagiza has left
  256. jonasw haven’t been there in a while, mind, all this "This message is OMEMO encrypted but your client doesn’t support it" was getting annoying.
  257. Yagiza has joined
  258. daniel has left
  259. jonasw great way to alienate people.
  260. Yagiza has left
  261. Yagiza has joined
  262. Ge0rG jonasw: if it knew. Which it can't.
  263. jonasw Ge0rG, yet. I think it was discussed at summit that a way for the server to know would be good?
  264. Ge0rG jonasw: yes. "would be good" is very far from an actual implementation, one might imagine.
  265. Ge0rG jonasw: if I had some time, I'd maybe write a PEP-based proto-XEP
  266. jonasw Ge0rG, better write a pep-based implementation first.
  267. Ge0rG which just stores a list of JIDs and their respective notification settings (always / mention / never)
  268. jonasw oh wait, we don’t even have reliable private PEP storage everywhere :<
  269. Yagiza has left
  270. Yagiza has joined
  271. Ge0rG jonasw: I didn't check in the last year. Do we have private PEP widely deployed already?
  272. Ge0rG Bookmarks2 FTW
  273. jonasw bm2 needs multi-item, persistence and private PEP. that’s gonna be hard.
  274. Ge0rG I'll just stick to 0048
  275. Ge0rG like I stick to google:queue.
  276. sezuan has left
  277. Maranda *has CSI dealing only with presences mostly*
  278. Ge0rG Maranda: was that supposed to be a /me ?
  279. SaltyBones has left
  280. Dave Cridland has left
  281. Andrew Nenakhov has left
  282. Andrew Nenakhov has joined
  283. Kev Ge0rG: I think so, we've been deploying it for years. The recent pubsub options change notwithstanding.
  284. Kev I *think* it's just Prosody that's had problems with PIP and things.
  285. daniel OpenFire and ejabberd should handle that fine I believe
  286. Andrew Nenakhov has left
  287. Andrew Nenakhov has joined
  288. Steve Kille has left
  289. Steve Kille has left
  290. Ge0rG So ~1/3 of the servers out there don't even have an implementation, and the other 2/3rds depend on which version they were abandoned at?
  291. jonasw Kev, are you intentionally calling it PIP? it confuses the hell out of me because of pythons package manager being called the same.
  292. Kev jonasw: Yes, because that's what 223 was called.
  293. marmistrz has left
  294. jonasw Kev, what’s the first P for?
  295. jonasw (the last is for PEP I guess)
  296. Ge0rG Private data In PEP? *guessing*
  297. jonasw (or PubSub)
  298. Kev Ge0rG: Maybe. Different people have different priorities here. Mine is mostly in moving things forward and having stuff available to people who do update servers and clients.
  299. jonasw Ge0rG, Kev, what’s the acronym for '222 then?
  300. jonasw PuIP?
  301. Kev Private Information Via Pubsub is 223
  302. jonasw or even PubIP, just one dash and a mirror operation away from a bad pun.
  303. Kev 222 is POP - Persisting Objects via Pubsub
  304. Ge0rG I thought it was Persistent Storage of Private Data via PubSub
  305. Ge0rG Which would make it PSoPDvPS
  306. Ge0rG But we could shorten it down to PSPDPS probably.
  307. Kev You young people, no respect for history :)
  308. Valerian has left
  309. Kev https://xmpp.org/extensions/attic/xep-0222-0.1.html https://xmpp.org/extensions/attic/xep-0223-0.1.html
  310. jonasw goes to rm those versions from the attic
  311. Dave Cridland has left
  312. jonasw I’ll show you how no respect looks like!!k
  313. Steve Kille has joined
  314. intosi has left
  315. intosi has joined
  316. jonasw (if you need to detect sarcasm/irony/bad jokes in my messages, the following regex will help: /!{2,}k+\b/. it won’t show all instances, but has a zero false-positive rate)
  317. SaltyBones has left
  318. jonasw (I think at least :))
  319. marmistrz has left
  320. Ge0rG jonasw: what's the "k" for?
  321. jonasw Ge0rG, it’s 1, but on my keyboard layout.
  322. jonasw modifier + k = !
  323. jonasw like modifier + 1 = ! on qwert[zy]
  324. Ge0rG jonasw: why are you leaking your keyboard layout to the general community?
  325. jonasw Ge0rG, because it’s 9:30am and I still haven’t gotten anything done probably.
  326. Ge0rG My goal for today's morning is to get onto that VPN that didn't let me work yesterday.
  327. jonasw so that it won’t let you work today either?
  328. jonasw sounds like a plan
  329. marmistrz has left
  330. ludo has joined
  331. Maranda Ge0rG possibly
  332. Kev Raising a slightly contentious idea...maybe we should bring back SIFT
  333. Kev Not actually SIFT, but something a bit like that.
  334. jonasw what’s SIFT
  335. Kev To solve this 'squelch MUC on mobile' issue.
  336. Kev SIFT's 273
  337. waqas is sad that he wrote mod_sift for Prosody, but there were no clients to be found
  338. Ge0rG Kev: what's wrong with an account-side notification prefs list that will be used by CSI?
  339. jonasw SIFT looks like privacy lists, complexity wise.
  340. Kev jonasw: SIFT itself isn't the right solution here, no.
  341. SaltyBones has left
  342. Ge0rG Let's collect all the requirements we had for SIFT, privacy lists and CSI and then make one big XEP to cover them all.
  343. Tobias has joined
  344. Kev Ge0rG: Nothing's wrong with that, but I'm not sure that goes far enough. Unless you're intending notification settings to be very powerful - which might work.
  345. Ge0rG Maybe also Message Archive.
  346. waqas Ge0rG: Just make sure it runs on top of pubsub
  347. Ge0rG Kev: I'm not sure how powerful you think I want them for this to work out.
  348. Kev Like, if you say things like "Squash messages from this JID unless they have a reference payload to my JID or @everyone but make sure they're in the archive, I'll fetch them when the user opens the window"
  349. jonasw Kev, actually, if SIFT had an "defer" action which would integrate with CSI, I can see a lot of use in that.
  350. ludo has left
  351. Ge0rG Kev: I wouldn't even touch archival in there. Just a tri-state of "never|mention|all"
  352. Kev Well, if it's not archived you've lost the ability to catch up again.
  353. Ge0rG and maybe a separate global setting what "mention" means exactly, like "nickname / string-list / @all"
  354. Kev But in XMPP2 where it would have been archived automatically...fine.
  355. Ge0rG Kev: I thought MAM was the way to archive things?
  356. jonasw what’s wrong with getting all messages, but CSI-delayed if they’re not notification-worthy?
  357. Ge0rG jonasw: it delays resync from zombie state
  358. Kev jonasw: Are you suggesting a server should buffer messages from a 5000-user IRC channel indefinitely?
  359. jonasw Kev, it could fetch them from MAM for the user.
  360. jonasw no need to keep them in memory.
  361. jonasw just a pointer to the point in the archive
  362. Kev If it's in MAM, there's no need for a buffer at all, the client can just request what it wants.
  363. jonasw ejabberd does it like that I think, even with presences.
  364. jonasw Kev, except that the client needs to do a thing the server could be doing for it ;-)
  365. Ge0rG Kev: a sane CSI implementation could dump the backlog periodically and/or when a certain number of messages have been backlogged
  366. Kev (Which is the better model - as the client will likely only want the most recent 100, or whatever, that contains the mention that caused you to open the room, not the previous 10,000)
  367. jonasw hm.
  368. jonasw maybe
  369. Kev Ge0rG: Maybe, although then you have to communicate to the user that they've got holes that they backfill with MAM.
  370. jonasw makes things much more complex though
  371. Ge0rG Kev: we've had that before. There is the "full client" and the "thin client" model.
  372. Ge0rG Kev: by "dump" I meant "send out to the client"
  373. jonasw Kev, so the client would have to make a MAM query after each message it receives in a room where it isn’t set to "notify on everything" to ensure it doesn’t have gaps?
  374. Kev jonasw: Not exactly, no.
  375. jonasw why no-?
  376. jonasw why not?
  377. Steve Kille has left
  378. Ge0rG filling backlog gaps from MAM is slightly challenging, and also not supported by RSM.
  379. Kev It's not ensuring that it doesn't have gaps, it knows it has gaps.
  380. jonasw Kev, depends on your use-case.
  381. Ge0rG I really don't want to model MAM gaps in my database structure.
  382. Kev Ge0rG: That's fine, you don't have to if you want to be a 'complete client'.
  383. jonasw I can see use for CSI in a desktop client if we can work out the timely notification thing.
  384. jonasw what’s a "complete client"?
  385. Ge0rG Kev: you seem to have modelled all the required protocol flows for both kinds of client in your head. I'd love to read up on that in a more persistent way than by querying you in a MUC
  386. Ge0rG jonasw: one that keeps a full local log of messages by default, without resorting to MAM whenever the user opens a chat tab
  387. jonasw isn’t that exactly the type of client which has to keep book of holes to ensure it can fill the gaps?
  388. Kev As opposed to a recent-only client, which just queries recent messages when you open a chat, and backfills as needed when the client scrolls.
  389. SaltyBones has joined
  390. Valerian has joined
  391. ludo has joined
  392. Dave Cridland has left
  393. waqas has left
  394. ludo has left
  395. daniel has left
  396. intosi has left
  397. ludo has joined
  398. Wiktor has joined
  399. Wiktor Hello! I'd like to extend the wiki page (https://wiki.xmpp.org/web/Tech_pages/XEP-0368) with info on how to route HTTP/2 and XMPP TLS traffic on port 443 with nginx (the ability to route based on ALPN was recently added: http://mailman.nginx.org/pipermail/nginx/2018-March/055798.html ). If it's possible would someone set me an account on wiki.xmpp.org? Thanks in advance!
  400. Andrew Nenakhov has left
  401. jonasw Ge0rG, ^
  402. intosi has joined
  403. Ge0rG Wiktor: please send me a message with your desired username (Wiktor?) and your email address for the password delivery.
  404. MattJ Looks like I lost my privileges after the great wiki disaster of 2017 :/
  405. jonasw s/wiki //
  406. jonasw actually, the server was a tad late. it would’ve been a great fit for '16
  407. Maranda "great wiki disaster" :O
  408. Dave Cridland has left
  409. Ge0rG Wiktor: The current content of Tech_pages/XEP-0368 is very raw. It would be great if you could also add some structture :)
  410. jonasw anyone a suggestion for a wiki page name for that bookmark autojoin discussion?
  411. Wiktor Yep I noticed that, I need to reformat it anyway as some sections (like SRV records) would be the same for all methods.
  412. Ge0rG like maybe an intro sentence what the page is about, an auto-generated TOC and then headings for different implementations / common settings
  413. Ge0rG jonasw: Easy Bookmarks™
  414. jonasw and add a link to it on https://wiki.xmpp.org/web/SRV_Records
  415. jonasw Ge0rG, asking to be sure, do you have the power to move pages? :>
  416. Wiktor SRV Records must be extended with xmpps-client too
  417. Wiktor well, a little bit more work than I anticipated but it's do-able :)
  418. ludo has left
  419. Ge0rG Wiktor: yes I do
  420. jonasw Ge0rG, itym jonasw
  421. Ge0rG jonasw: yes I do
  422. jonasw Ge0rG, nevermind.
  423. Ge0rG the inverted highlighting of poezio really leads to low contrast
  424. jonasw I turned it off for that reason
  425. jonasw you want my irssi theme
  426. Ge0rG jonasw: I'm not sure I do.
  427. jonasw /theme irssi
  428. Ge0rG I'm always very hesitant to change themes.
  429. Dave Cridland has left
  430. Dave Cridland has left
  431. Yagiza has left
  432. Yagiza has joined
  433. Alex has joined
  434. Dave Cridland has left
  435. ludo has joined
  436. Link Mauve jonasw, would you be ok with merging it upstream?
  437. jonasw Link Mauve, didn’t I already?
  438. Dave Cridland has left
  439. Link Mauve Oh right, indeed it’s there.
  440. Holger has left
  441. Holger has left
  442. Holger has left
  443. Dave Cridland has left
  444. Andrew Nenakhov has joined
  445. Andrew Nenakhov has left
  446. Andrew Nenakhov has joined
  447. ludo has left
  448. jubalh has joined
  449. jubalh has left
  450. Dave Cridland has left
  451. Tobias has joined
  452. blabla has left
  453. Dave Cridland has left
  454. Dave Cridland has left
  455. blabla has left
  456. ludo has joined
  457. Maranda has joined
  458. jubalh has joined
  459. jubalh has left
  460. daniel has left
  461. Dave Cridland has left
  462. Dave Cridland has left
  463. LNJ has joined
  464. Yagiza has left
  465. Yagiza has joined
  466. tux has joined
  467. Dave Cridland has left
  468. ludo has left
  469. LNJ has left
  470. LNJ has joined
  471. LNJ has left
  472. LNJ has joined
  473. Dave Cridland has left
  474. Dave Cridland has left
  475. Dave Cridland has left
  476. Dave Cridland has left
  477. Dave Cridland has left
  478. Dave Cridland has left
  479. blabla has joined
  480. Dave Cridland has left
  481. Dave Cridland has left
  482. Dave Cridland has left
  483. daniel has left
  484. Dave Cridland has left
  485. Dave Cridland has left
  486. dwd has left
  487. Kev has left
  488. dwd has left
  489. Andrew Nenakhov has left
  490. Andrew Nenakhov has joined
  491. daniel has left
  492. Dave Cridland has left
  493. Holger has left
  494. jubalh has joined
  495. jubalh has left
  496. Tobias has joined
  497. ludo has joined
  498. Tobias has left
  499. ludo has left
  500. ludo has joined
  501. had-hoc has left
  502. ludo has left
  503. Dave Cridland has left
  504. efrit has joined
  505. Valerian has left
  506. Valerian has joined
  507. ludo has joined
  508. intosi has left
  509. Dave Cridland has left
  510. efrit has left
  511. ludo has left
  512. Nekit has left
  513. Nekit has joined
  514. Valerian has left
  515. Dave Cridland has left
  516. daniel has left
  517. intosi has joined
  518. jubalh has joined
  519. Maranda has joined
  520. lumi has joined
  521. Dave Cridland has left
  522. marmistrz has left
  523. Dave Cridland has left
  524. Dave Cridland has left
  525. Dave Cridland has left
  526. ludo has joined
  527. jubalh has left
  528. Dave Cridland has left
  529. Dave Cridland has left
  530. daniel has left
  531. Dave Cridland has left
  532. daniel has joined
  533. winfried has joined
  534. winfried has joined
  535. Dave Cridland has left
  536. Dave Cridland has left
  537. ludo has left
  538. lskdjf has joined
  539. alexis has joined
  540. Dave Cridland has left
  541. Dave Cridland has left
  542. Dave Cridland has left
  543. Dave Cridland has left
  544. jubalh has joined
  545. jubalh has left
  546. Dave Cridland has left
  547. Dave Cridland has left
  548. Valerian has joined
  549. Dave Cridland has left
  550. Dave Cridland has left
  551. Dave Cridland has left
  552. la|r|ma has joined
  553. ThibG has joined
  554. Dave Cridland has left
  555. ThibG Hi, I was looking at XEP-0333 as I was under the impression that it was the preferred way to synchronize state between XMPP clients.
  556. ThibG But after reading it I'm pretty convinced this is not a great way to do it, as it requires sending such state to the recipients, as the “Security Considerations” section already points out
  557. Kev XEP 333's not good for synchronising state between your own clients, no. Only for sending markens back to the sender (and I'm not convinced it's great for that either).
  558. Zash And I'm pretty sure you can do 80% of that using chatstates and receipts :)
  559. vanitasvitae has left
  560. ThibG Chatstates and receipts have similar issues 🙂
  561. Alex has left
  562. Dave Cridland has left
  563. ThibG Anyway, I was wondering if there is a better XEP out there for synchronizing such state?
  564. alexis has left
  565. alexis has joined
  566. Dave Cridland has left
  567. alexis has left
  568. alexis has joined
  569. ta has joined
  570. jonasw ThibG, no, but the question comes up regularly
  571. Zash ThibG: What exactly do you want to sync and between what?
  572. Kev Which state are we talking about in this case?
  573. Kev Unread markers?
  574. ThibG yeah
  575. Kev I have a model for how we do that, which I discuss briefly in bind2.
  576. Zash *your own* unread state?
  577. ThibG Yes, your own unread state
  578. Kev But there are still more parts needed. If you need this Now, I suggest the best thing is to store the most recent read messages for each contact in PIP, and go from there. It's not perfect, but it'll do.
  579. Zash Yeah, Kev had ideas for that
  580. Dave Cridland has left
  581. Dave Cridland has left
  582. Dave Cridland has left
  583. ThibG I don't “need this Now”, it's just that it's a pain having multiple clients and having notifications for messages I have already read. I was looking for a XEP to implement in clients, but guess I'll wait
  584. Dave Cridland has left
  585. daniel has left
  586. Kev I think you generally don't really want to know what's read, but what's unread, and that needs the cooperation of the archive.
  587. jonasw ThibG, if the clients send chat markers, it should work. some clients send, but ignore inbound chat markers, so you might have a chance there. at least for some cases.
  588. Kev Well, s/needs/is easiest done/
  589. Kev jonasw: I think Chat Markers for this is very nearly the worst possible approach ):
  590. Dave Cridland has left
  591. jubalh has joined
  592. Kev I think the PIP approach is mostly workable, but not great, and the cooperation of the archive approach is best, but probably a little way of.
  593. Kev s/of\./off./
  594. Dave Cridland has left
  595. ThibG jonasw, it works when the clients send chat markers, right. But it requires telling the recipient what you have read and what you haven't, which you might not want to do.
  596. jonasw yeah
  597. ThibG Also, the XEP advises against sending them if the recipient doesn't advertise support for it
  598. SamWhited has left
  599. Kev And it requires your archive saving markers, which it probably won't, and your client querying MAM back to find all the last read markers for your conversations, which you also probably don't want to do.
  600. ThibG And most clients respect that, so the synchronisation depends on what the recipient supports 😕
  601. Kev I'm sure it's possible to come up with a worse mechanism for solving this problem, but I think it'd require some amount of creativity.
  602. jonasw ThibG, do they? I’d advise clients to ignore that and send always.
  603. ThibG jonasw, yeah, Dino and Conversations at least seem to respect that
  604. Alex has joined
  605. ThibG Kev, got your point
  606. Kev :)
  607. jonasw I think conversations wanted to move to ignore that at some point. but I may misremember.
  608. Holger ThibG: Really? So this would only work while the recipient is online?
  609. Holger ThibG: Conversations even adds a <store/> hint to make this work for offline recipients.
  610. ThibG hm
  611. Holger I agree this is a mess, but I don't see we have anything better to offer right now.
  612. Dave Cridland has left
  613. Dave Cridland has left
  614. Kev Holger: I think my PIP suggestion is better Right Now, albeit unspecced.
  615. Kev At least, I don't think there's a XEP for it. I remember writing this down a while back.
  616. jubalh has joined
  617. jubalh has left
  618. jubalh has joined
  619. Dave Cridland has left
  620. Nekit has left
  621. Nekit has joined
  622. Holger What was PIP again?
  623. Guus harhar. I'm working on a bug that's caused by a client falling for the good old "Are you there?" -"No!" joke.
  624. Holger Anyway I meant we have no better standard solution, of course. I can easily imagine better non-standard ones :-)
  625. Dave Cridland has left
  626. daniel has left
  627. Kev Private PEP.
  628. Guus (ping got responded to with an error, which didn't prevent a timeout)
  629. Kev (223)
  630. Zash PIP, PEP, POP, is there a PAP?
  631. Dave Cridland has left
  632. intosi PAP and CHAP.
  633. intosi But only in a PPP context ;)
  634. jonasw PEAP?
  635. Zash And PUP
  636. Holger Kev: Ah so nothing non-standard on the server side.
  637. intosi Acronym creators were probably on PCP.
  638. Dave Cridland has left
  639. Kev Holger: I think you can do something that's a usable stopgap with only 223 on the server, yes.
  640. Kev But it's significantly less good than doing it properly.
  641. Holger Yup, I see.
  642. daniel has left
  643. ThibG Holger, ok so the thing is the sender needs to set the message as “markable” for read markers to be issued, so if the person you're conversing with doesn't do it, you don't have synchronized state…
  644. daniel has left
  645. Dave Cridland has left
  646. daniel has left
  647. Dave Cridland has left
  648. Holger ThibG: Ah right, I was thinking of the previous step, doing service disco to decide whether to set "markable" (#5.2), which assumes the recipient to be online and doesn't cope with multiple devices.
  649. Holger ThibG: But your step is the relevant one here, yes. Still I think you could just issue markers no matter whether markable was set.
  650. Kev Server devs: How hard is it for you to do magic based on pubsub nodes?
  651. Zash Define magic
  652. jonasw Kev, xep 400?
  653. Kev e.g. how hard is it for you to do something when something is pushed to a specific node?
  654. jonasw eh
  655. jonasw XEP 0398
  656. Kev Yes, something like 398.
  657. Zash Kev: It Depends™
  658. Zash But can be easy
  659. Kev I'm pondering writing a XEP for unread-sync based on PIP, and defining additional magic that the server can do to make it more useful.
  660. jonasw please feature that magic and make it a MUST when the feature is available. I hate nothing more than having to infer whether a server does a thing or not
  661. Kev It's not the perfect protocol for doing it, but it would mean clients could get going with something Right Now, and as servers support it they'd gain the additional niceness.
  662. jonasw except that e.g. prosody still doesn’t have PIP.
  663. Zash There's plugins for Prosody that syncs the nickname and avatar nodes with the vcard
  664. Kev I thought that was imminent/there now?
  665. Zash So, that kind of thing is dobale
  666. jonasw i think persistent PEP was there, but not PIP
  667. Zash So, that kind of thing is doable
  668. Zash MattJ has claimed to be working on it
  669. Kev Dave Cridland: Openfire?
  670. Kev Ejabberd anyone?
  671. Zash It's possible to make nodes private from the inside in the newer pubsub code, if somewhat verbose.
  672. Dave Cridland Lacking context, but if that's does Openfire do persistent PEP, then yes, of course.
  673. Kev No, it was can you do magic like 398?
  674. jonasw Dave Cridland, it’s whether it can do private PEP with publish-options assertions
  675. Kev I'm pondering writing another XEP that does magic when something is published to a particular PIP node.
  676. Dave Cridland Hmmm. 398?
  677. Kev vcard/PEP avatar magic.
  678. Holger No problem to implement in ejabberd (there's a publish event), just not sure I like such magic nodes.
  679. Kev Just 'can you hook code onto publishes to a particular node and/or would it be prohibitive?'.
  680. Holger Maybe I do.
  681. Dave Cridland Oh. I don't think so. Guus would know for sure. But I don't think we have hooks.
  682. Kev I don't mean user-facing hooks, I just mean for Server Features, if that helps.
  683. Kev Holger: I'm just pondering whether speccing something that isn't perfect protocol, but achieves the right result and lets client implement Right Now and still mostly work before servers are there is preferable to waiting forever for supporting the perfect protocol.
  684. Kev I quite like magic nodes, FWIW, as long as the magic is additional, rather than transforming the behaviour of the node.
  685. Guus waitwhat?
  686. Guus I know nothing!
  687. Nekit has left
  688. Nekit has joined
  689. Guus we have no API hooks specific for Pubsub that I'm aware of. We do have generic stanza interceptors.
  690. marmistrz has left
  691. alexis has left
  692. alexis has joined
  693. Holger Kev: Yes, sounds good to me. I think 🙂
  694. Holger Kev: But if it works too well, nobody will ever implement the perfect protocol!
  695. Guus Holger, you're wrong. Implementation available here: https://github.com/kelseyhightower/nocode
  696. Holger :-)
  697. Kev Holger: Yes, I'm suggesting we never do the perfect protocol, we just get the perfect* features.
  698. Zash As part of this, what if the server makes it such that clients don't join MUCs, but the account does.
  699. Kev That is needed for this to work for MUCs, yes.
  700. Zash This general "make it work, not make it perfect" thing
  701. jonasw Zash, I’m still confused how a client is supposed to know what to do with those type="groupchat" messages and MUC-related presences it is suddenly getting.
  702. Zash jonasw: It doesn't get those unless it joins rooms.
  703. jonasw Zash, how is the "account" joined then?
  704. Zash jonasw: Server sees you attempting to join a room, drops that and sends a join from the bare account jid instead.
  705. Kev So, you know, one step closer to MIX.
  706. Zash And makes a note "this session joined that room"
  707. jonasw Zash, who profits from that change?
  708. Alex has left
  709. Kev jonasw: Anyone who doesn't want problems with dupes. Especially archive-based stuff like unread sync.
  710. jonasw how does this handle s2s interruptions?
  711. daniel has left
  712. Zash jonasw: People who are annoyed by quitjoins. Eaiser to have groupchats in user archives. Users get faster join sync.
  713. ThibG has left
  714. ThibG has joined
  715. Zash When a second client joins, it simply serves locally cached room state back and makes a note that that session is also interested in that room.
  716. jonasw makes sense
  717. Zash Oh and it keeps local room state on the server.
  718. jonasw I might like this more than MIX, except for the still present abuse of resources.
  719. ThibG has left
  720. jonasw Zash, but how does it cope when the s2s link to the MUC service is broken/the MUC service fails and restarts without state/…
  721. Zash In theory, one could evolve this into a compat layer for having MUC clients in future MIX channels,
  722. jonasw those conditions where clients nowadays rejoin after a ping timed out or they got an error back or something like that
  723. Zash jonasw: Badly, I guess. Still a hacky PoC stage
  724. Zash jonasw: Doesn't even handle anyone leaving :)
  725. Kev I think the resync is going to hurt with this MUC stuff though.
  726. Zash It already hurts.
  727. Kev Because unlike MIX it's not clear how you connect with a client to a MUC that your account's already joined.
  728. ThibG has joined
  729. Zash Kev: The server handles it and sends you the room state from a local cache.
  730. Zash MUC clients shouldn't notice anything different
  731. ThibG has left
  732. Zash I guess Ge0rG is correct in this being basically a bouncer.
  733. jonasw yeah
  734. alexis has left
  735. alexis has joined
  736. Zash So it gets all the client problems, except those that relate to connection issues to the server :)
  737. Kev Yeah, but you're getting a lot more work on the server than the server support in MIX.
  738. Wiktor has left
  739. ThibG has joined
  740. ThibG has left
  741. moparisthebest which is great if nothing else has to change and you get 100% backwards compatibility, right?
  742. Zash I'm not sure which would be more work at this point, haven't been able to read the entire MIX spec yet.
  743. Zash I've got something half-working that can be tested to see if it's worth the trouble. Why I called it a hacky proof of concept :)
  744. ThibG has joined
  745. jubalh has joined
  746. Kev I think you end up doing the same amount of work, for something that still has issues.
  747. jubalh has left
  748. pep. Ge0rG: re CSI/MUC messages, is there any case of messages being processed by the server already? I'm not fond of the "mention" bit. Also you need to define it, it can mean lots of things nowadays with fancy new IMs solutions out there, @everyone, @here, @channel and whatnots
  749. Zash -xep attention
  750. Bunneh Zash: Attention (Standards Track, Draft, 2008-11-13) See: https://xmpp.org/extensions/xep-0224.html
  751. xnyhps has joined
  752. Zash Kev: Doing something that (partially) works now tends to be more rewarding than something that has to wait, in this case for MIX to become stable and implemented.
  753. moparisthebest Kev, but most importantly, 100% backwards compat, and work *only* on the user's server, rather than on all clients, all servers, and all mix components
  754. Andrew Nenakhov has left
  755. moparisthebest did anyone make that Wiktor guy a wiki account?
  756. Kev I'm not sold.
  757. Andrew Nenakhov has joined
  758. Zash I'm a terrible sales person.
  759. moparisthebest so of the mythical MIX server components that are done, which of them have backwards compatibility with MUC ?
  760. alexis has left
  761. Tobias has left
  762. moparisthebest because if not, they are a non-starter
  763. alexis has joined
  764. moparisthebest for example when would xsf@muc.xmpp.org switch over?
  765. Guus moparisthebest : who's "wictor"?
  766. MattJ moparisthebest, pretty sure my opinion is in the minority, but I see MUC and MIX serving different use-cases, and I don't necesarily feel that all MUCs must switch over
  767. jonasw Guus, Wiktor asked for a MUC account earlier
  768. jonasw Guus, Wiktor asked for a Wiki account earlier
  769. jonasw MattJ, +1
  770. jonasw MIX feels like a not-so-great model for the average support group chat
  771. Zash moparisthebest: I think Ge0rG dealt with the wiki
  772. Guus I didn't see that. He does not appear to have an account now
  773. Guus Do we have his contact details?
  774. ThibG has left
  775. Guus email?
  776. jonasw Guus, ask Ge0rG
  777. Zash MattJ: How do you feel about a account-based MUC join module? Useful or hack that will haunt us forever?
  778. Guus Ge0rG?
  779. daniel has left
  780. moparisthebest MattJ, I mean the situation with muc on multi-client but especially phones isn't great, if mix can't replace muc and fix that forever I don't see a point
  781. daniel has joined
  782. Kev I'm not sure why it can't.
  783. ThibG has joined
  784. Kev And you can add basic MIX on top of MUC fairly straightforwardly.
  785. moparisthebest well one reason is it's been years and no one has implemented anything but a tiny part with no muc compatibility
  786. moparisthebest I'm just solidly with Zash here, running code that works *now* is the way to go, vs duke nukem forever code that might be better in the future
  787. Kev We've not got the spec right for showing how straightforward these concepts are yet, and I think that's a part of why there's limited adoption.
  788. Kev But we'll get there.
  789. Zash And I'm not saying this will solve all problems. I just wanna know how useful this hack I made is.
  790. Kev I don't think there's anything that stops hacks on MUC now to make it better. I'm not sold that it can actually solve everything fully without essentially becoming MIX>
  791. ThibG has left
  792. Kev Which, at its core, is largely just about less overloaded addressing and presence semantics.
  793. moparisthebest while that might be true, it doesn't need to solve everything, perfect is the enemy of good
  794. ThibG has joined
  795. jonasw moparisthebest, crude hacks is what got us into the carbons/mam mess though
  796. moparisthebest is it better with them as crude hacks or before when multi-device was useless?
  797. jonasw better, but also still bad
  798. jonasw in a different way though
  799. jonasw if we had went with XMPP2 routing/addressing right away, things might’ve been much better.
  800. Ge0rG Guus: https://wiki.xmpp.org/web/Special:RecentChanges
  801. Guus Ge0rG argh, I somehow missed that.
  802. Guus tx
  803. moparisthebest jonasw, crying over spilt milk? hehe
  804. moparisthebest it's easy to say such things in hindsight
  805. moparisthebest STARTLS would never have been a thing in any protocol either
  806. Zash Kev: Small steps are easier to take than large ones
  807. Maranda has joined
  808. Ge0rG Zash: you shouldn't use the bare JID, I think. Rather have one uuid per nickname
  809. Kev I think the Best thing to do is write a MUC layer on top of MIX, but in the short term it works to write a MIX layer on top of MUC. Implementation-wise.
  810. pep. jonasw, I don't think "all joins and parts to MUCs are synced on all devices" is a "simple" default case :P
  811. pep. (reading that wiki page)
  812. jonasw pep., for the user, I think so
  813. jonasw mind that most people won’t be joining things like xmpp@ but instead having group chats with their family and coworkers etc.
  814. pep. May be a default use-case, but it's not that simple, judging by the discussion on the list :p
  815. jonasw it’s simple to do as long as we don’t need the second one :)
  816. jonasw and it’s also simpler than the second one regarding the amout of state which needs to be kept
  817. pep. How can I use bookmarks as dumb JID list in all that?
  818. pep. Do I _have to_ use the syncing stuff
  819. jonasw pep., add that dump jid list thing
  820. jonasw on the protocol level: just without autojoin
  821. pep. yes, I just want a dumb list that I can access across all devices
  822. pep. hmm, I don't like the priority assumptions on that list
  823. pep. Where do I put my thing
  824. jonasw pep., not sure
  825. jonasw between the two I think
  826. winfried has left
  827. winfried has left
  828. pep. The thing is that it directly conflicts with the autojoin feature some wants
  829. pep. And I'm sure I'll have to patch most of the "modern" apps to do as I want
  830. pep. Fun(tm)
  831. MattJ pep., enlighten me, what is the autojoin feature some want?
  832. pep. Sync the state across devices
  833. MattJ Ok
  834. Zash Which state?
  835. MattJ Joined/not joined
  836. pep. Say if autojoin is set to true, the channel is joined on every device, if autoset is false, don't join, or leave the channel on all devices
  837. moparisthebest I don't like that because I have huge channels I only want to be joined to on my desktop, not my phone
  838. pep. moparisthebest, yeah that's another concern and it's being talked about on the ML
  839. MattJ moparisthebest, as already discussed, it doesn't mean you can't have that
  840. MattJ It's already been discussed to death on the mailing list
  841. moparisthebest then I have no objections :)
  842. pep. I just don't want this syncing being done _at all_ across my devices, huge channels or not
  843. moparisthebest I agree in general it would be nice
  844. MattJ pep., then you just don't set autojoin, it's simple
  845. moparisthebest just with the ability to override
  846. MattJ Negotiate with your client devs :)
  847. pep. MattJ, no, not with what's being said. If I don't set autojoin clients would leave the channel
  848. pep. If I understand correctly. And that's an issue
  849. Ge0rG I'm still waiting for someone to show me a well-designed MUC join dialog/UI that nicely abstracts semi-autojoin
  850. pep. semi-autojoin?
  851. MattJ Ge0rG, join room from client as normal -> "also join on other devices? yes/no"?
  852. Ge0rG Kev: my gut feeling is that the server-side MUC bouncer will solve 90% of today's problems with MUC, making it good enough™
  853. pep. Ge0rG, isn't that MUC bouncer called MAM?
  854. Alex has joined
  855. Ge0rG MattJ: "also join on: [ ] Desktop [X] Mobile [...]"
  856. jjrh has left
  857. MattJ Please no
  858. Zash What about tags?
  859. MattJ Gaaaaah!
  860. pep. Zash, "also join on: [ ] Desktop [X] Mobile [...]" ?
  861. pep. :P
  862. Kev Ge0rG: Of course, MUC solving 90% of problems already is the reason for not bothering to fix it.
  863. Ge0rG MattJ: so it would add a bookmark on success, and set the bookmark's autojoin depending on your choice, and set local autojoin accordingly?
  864. Zash Like, roster groups. Tag with whatever you want. Make your client autojoin based on that.
  865. jonasw Zash, now
  866. jonasw *no
  867. Ge0rG Kev: MUC is solving 90% of the problems we had in 2002.
  868. jonasw Zash, adding semantics to roster groups seems like bad
  869. MattJ Ge0rG, the way I see it, any sensible client maintains a local (persistent) list of rooms it is currently joined to
  870. Zash jonasw: That's not what I said.
  871. Ge0rG MattJ: good luck matching that list against three sets of remote bookmarks.
  872. jonasw Zash, so two disticnt set of tags, one for determining whether to join and one to show to the user? :(
  873. Zash jonasw: Could be tags/categories in the current bookmarks.
  874. MattJ Ge0rG, that can't be helped...
  875. jonasw Ge0rG, îtym one set, because any sensible library will abstract that away from you :)
  876. Ge0rG MattJ: what you just proposed is the technical background. I'm interested in designing the transition UI for adding a MUC to any of the lists, or moving a MUC between them
  877. MattJ Ge0rG, I already said
  878. MattJ > 13:44:18 MattJ> Ge0rG, join room from client as normal -> "also join on other devices? yes/no"?
  879. MattJ Ignore my 5min timezone issue
  880. Dave Cridland has left
  881. Ge0rG MattJ: running off grid power?
  882. Zash pep.: "This client auto-joins [ ] All bookmarked rooms [ ] Bookmarked rooms tagged [autojoin-on-mobile]"
  883. Ge0rG MattJ: besides, as there is no notification mechanism for bookmarks currently, it won't work anyway:>
  884. Zash Organizing bookmarks is messy already, can haz tags or something?
  885. jubalh has joined
  886. pep. Zash, yes so when you add a bookmark you still have a similar question to answer
  887. MattJ Ge0rG, we're talking about fixing that, so let's fix it
  888. pep. Tag it or not
  889. jubalh has left
  890. pep. And tag it with what
  891. jonasw Zash, I’m all in for roster-like groups on bookmarks
  892. pep. jonasw, yeah that might be nice
  893. pep. I would still want what Zash said above
  894. Zash jonasw: And then some enterprising client dev can experiment with using that for semantics to see if that's good or bad :)
  895. pep. Have a choice wether the client is going to autojoin or not
  896. jonasw Zash, it’ll be bad, because having an "autojoin-on-mobile" tag in your roster view is ugly
  897. Ge0rG MattJ: so something like this? ``` Groupchat JID: [xmpp@chat.yax.im] Nickname: [Power user ] [+] Advanced options +- [X] Join on other devices +- Password: [ ] +- [ ] Show password [ Cancel ] [ OK ] ```
  898. Zash jonasw: I mean the client could have a free text field for autojoining things with named tags.
  899. Ge0rG Zash: the only kind of tag I see as viable for bookmarks is to put them into roster groups
  900. pep. Ge0rG, with regular people jids?
  901. alexis has left
  902. Ge0rG pep.: yes
  903. alexis has joined
  904. Ge0rG pep.: so I can have my family MUCs in my family group
  905. Zash Do we /need/ to autojoin other clients?
  906. Ge0rG Zash: yes
  907. pep. Ge0rG, that means I'm gonna send presence info to all these mucs?
  908. Ge0rG pep.: no?
  909. pep. ok, how would that work then
  910. Zash Notifying about 'other device joined this room' + MAM might be enough to make a nice UX?
  911. pep. Also how do I know it's a MUC
  912. Zash Show a new "conversation" or whatever ui you use
  913. ta has joined
  914. Ge0rG pep.: you add tags to the bookmarks, and then let the client use these tags in the same way it would use roster tags
  915. Dave Cridland has left
  916. pep. Ok so just a UI thing
  917. Ge0rG pep.: exactly!
  918. pep. sure
  919. Ge0rG Zash: you are probably right.
  920. Ge0rG Zash: but this is a huge step from where we are right now
  921. Yagiza has left
  922. Yagiza has joined
  923. jjrh has left
  924. daniel has left
  925. Dave Cridland has left
  926. alexis has left
  927. alexis has joined
  928. alexis has left
  929. alexis has joined
  930. alexis has left
  931. alexis has joined
  932. alexis has joined
  933. alexis has left
  934. alexis has joined
  935. Dave Cridland has left
  936. ludo has joined
  937. Dave Cridland has left
  938. alexis has joined
  939. waqas has joined
  940. ludo has left
  941. alexis has left
  942. marmistrz has left
  943. SaltyBones has left
  944. Dave Cridland has left
  945. Dave Cridland has left
  946. nyco has joined
  947. nyco test
  948. ralphm Looks to be on
  949. nyco Test
  950. nyco seems to work today
  951. nyco go?
  952. ralphm bangs gavel
  953. ralphm set the topic to XSF Board Meeting | Logs: http://logs.xmpp.org/xsf/ | Agenda https://trello.com/b/Dn6IQOu0/board-meetings
  954. ralphm 0. Welcome + Agenda
  955. ralphm Who do we have?
  956. nyco present
  957. MattJ Me
  958. Guus o/
  959. Guus Martin excused himself earlier.
  960. ralphm OK.
  961. mimi89999 has joined
  962. ralphm Any (additional) points for the agenda?
  963. Dave Cridland has left
  964. MattJ I don't think so
  965. Guus as mailed, on the financial stuff.
  966. alexis has left
  967. Dave Cridland has left
  968. ralphm Ok, we can do that today, I think.
  969. Dave Cridland has left
  970. ralphm 1. Minute taker?
  971. MattJ ...I can do it
  972. ralphm Thanks
  973. ralphm 2. Financials
  974. ralphm As layed out in Guus e-mail there are some things we should discuss w.r.t. our financials.
  975. ralphm He asked a few questions:
  976. ralphm 1) What are our sources of funds, other than sponsors? 2) Who are our sponsors? 3) Are we properly treating our sponsors? If not, how do we improve? 4) How do we safe-guard the proces of collecting funds?
  977. ralphm On 1) I think we can be pretty clear: none right now
  978. Guus did we ever have?
  979. ralphm What we have done in the past is sell hoodies/t-shirts, but never as a way to make money
  980. nyco 1) we can ask for public donations
  981. ralphm more to cover costs around the XMPP Summit / FOSDEM
  982. Dave Cridland has left
  983. nyco 2)3) we need to map the sponsors journey
  984. Guus ralphm, although I didn't think of that, I do agree with your definition of that.
  985. nyco 1) oh gooodies, of course, but the same questions goes on and on: who's gonna take it? how do we follow up and control? etc.
  986. Alex has left
  987. Guus I'm ok with not having a different source of income than sponsors, by the way. 1) was just to make sure I wasn't missing anything.
  988. ralphm 2) I believe, but I don't have information from stpeter, is that we have two active sponsors, right now: Erlang Solutions, Inc. and USSHC, with the latter only in hardware
  989. nyco 1) can donations be automated by any third-party platform?
  990. j.r has left
  991. Guus 2) is where things get a bit awkward. We're listing sponsors on our website that do not seem to exist (as an organisation) anymore.
  992. j.r has joined
  993. ralphm Yes
  994. nyco 2) a cleanup needs to be applied, indeed
  995. MattJ and that is also unfair to people who are actually sponsors (and would discourage new ones)
  996. ralphm I note that I didn't include the FOSDEM/Summit sponsors, because those are different in that respect
  997. nyco 2) we can already remove the stopped and renamed companies, can't we?
  998. Dave Cridland has left
  999. Guus Mattj, that's a concern that I had, which is why I added 3) to my list of questions.
  1000. nyco FOSDEM/Summit is punctal
  1001. nyco s/punctal/punctual
  1002. Guus did we ever check if other sponsors than the ones just listed by Ralph indeed stopped sponsoring?
  1003. Guus Or did we stop collecting money from them, without them actively pulling out?
  1004. Dave Cridland has left
  1005. nyco how can we check that? on the bak account logs?
  1006. ralphm https://xmpp.org/community/sponsorship.html lists our current process, and we're mostly abiding by that
  1007. nyco I know for a fact that ESL remains a sponsor (disclaimer: I used to work for them)
  1008. Guus I'm assuming, but do not know for certain, that our Treasurer would know.
  1009. ThibG has left
  1010. ralphm Guus: sponsorship is a for a limited term (1 year), there's no automatic renewal
  1011. Guus ralphm, ok, that's fair. In that case, I feel that we should explicitly ask for a renewal, each year.
  1012. nyco the renewal should be re-processed by humans at the same date each year, yes I know it is easy to say 😉
  1013. ralphm Guus: agreed
  1014. nyco when?
  1015. Guus as I wrote in my mail - we're not a for-profit organisation, but having some funds at hand can help us greatly.
  1016. nyco January?
  1017. nyco Then we use the FOSDEM to followup and close
  1018. ralphm “Sponsorship applies on a calendar-year basis. Sponsor funds received in the middle of the calendar year shall be pro-rated accordingly.”
  1019. ralphm So I think that maybe December is more appropriate?
  1020. Guus I'd like to propose that we reach out to our old sponsors to see if they are willing to renew for this year.
  1021. Guus (and do again so in December, for next year)
  1022. MattJ Which would make it a good task to add to the list for newly-elected Boards :)
  1023. nyco agree
  1024. ralphm +1 on Guus' motion
  1025. Guus MattJ, I'd prefer to task our Treasurer with this (or an ExOfficer), not Board.
  1026. MattJ +1
  1027. ralphm .
  1028. MattJ I really mean that Board needs to make sure this happens
  1029. ThibG has joined
  1030. Guus ok
  1031. Guus Shall I work with Peter on this?
  1032. MattJ Ideally all sponsorship stuff is handled by a single person, it's easier
  1033. ralphm Agreed
  1034. Guus meh, bus-factor.
  1035. Guus but a single person is better than no person 🙂
  1036. MattJ As long as it's documented, it shouldnt matter
  1037. MattJ Right now we're in a fairly unclear situation
  1038. ralphm Indeed
  1039. Guus I'll talk to Treasurer to get sponsorships renewed.
  1040. Guus let's move to the next item.
  1041. jjrh is anyone a titanium sponsor?
  1042. nyco as MattJ says, can it be documented?
  1043. MattJ jjrh, currently I think the answer is safely 'no'
  1044. nyco titatium is sooo outdated, it's vibranium now...
  1045. Guus documentation seems sensible.
  1046. nyco lightweight is ok
  1047. Zash Go straight for unobtainium
  1048. nyco hehehe
  1049. Guus Ralph, you still with us?
  1050. ralphm yes
  1051. ralphm 3. GDPR
  1052. jubalh has joined
  1053. jubalh has left
  1054. ralphm This an interesting topic.
  1055. Guus (ping jonasw)
  1056. jonasw I’m here
  1057. jonasw but maybe not for long
  1058. Guus I think the XSF looking into this could be helpful to the community
  1059. jonasw (ping pep., Ge0rG, too)
  1060. ralphm I am not aware (because I'm not involved) in IETF efforts around this.
  1061. ralphm aware of
  1062. Guus I also think it's important to explicitly state that this is at best advice, and indemnify ourselves
  1063. Ge0rG What kind of advice should the XSF provide?
  1064. pep. !
  1065. ralphm Given agenda item 2, I'm not sure if we are in position to sponsor a lawyer, FWIW.
  1066. jonasw Ge0rG, https://trello.com/c/t79C3Yds/307-gdpr-advice for example
  1067. Ge0rG The GDPR is an interesting topic indeed. I'm working in a company full of GDPR consultants, so I can get things addressed.
  1068. nyco that would still be awesome
  1069. pep. Ge0rG, that would be awesome, please do
  1070. SaltyBones has joined
  1071. Alex has joined
  1072. Ge0rG pep.: however, they are all at 120% capacity due to commercial clients asking for GDPR advice.
  1073. pep. Yeah it's going to get packed for the following months/year
  1074. Ge0rG Yup.
  1075. pep. People realizing it's time
  1076. nyco plenty of resources are already available, it's a matter of taking the time to process those, and peer-review
  1077. SaltyBones has left
  1078. Ge0rG I suppose the advice will turn out as something like (a) have a ToS / data policy. (b) let the user explicitly accept that (c) no idea for contacts' data
  1079. winfried Ge0rG: I have also a bit knowledge about the GDPR, I can jump in here too
  1080. jonasw Ge0rG, the federation aspect is the key issue here, local service can be solved with ToS as you mention.
  1081. SaltyBones has joined
  1082. jjrh GDPR == General Data protection Regulation?
  1083. Ge0rG winfried: I'm trying to gather inputs for a data protection policy for yax.im, but please see what jonas said
  1084. jonasw jjrh, yes
  1085. pep. We can also get ideas from email providers
  1086. Guus Ge)rG, winfried, jonasw, can you guys sit together and come up with either a sensible bit of information that applies to XMPP usage, or with specific questions to Board, if you need anything from them?
  1087. jonasw Guus, I formulated specific questions
  1088. Ge0rG Guus: I suppose we can
  1089. jonasw in the trello thing
  1090. nyco https://www.eugdpr.org/ https://en.wikipedia.org/wiki/General_Data_Protection_Regulation
  1091. ralphm I am not a lawyer. The most practical advise I can give is 1) get a lawyer, 2) document what data your own service collects and why, the definition of Personal Data is pretty broad and includes things like (indirect) identifiers. 3) Establish policies around retention and deletion of that data.
  1092. Guus jonasw, I've seen them, thanks.
  1093. jonasw and I think they cover our most important issues
  1094. Ge0rG jonasw: do you think the Board can answer those?
  1095. jonasw Ge0rG, no, but what other type of questions could we bring to board?
  1096. jonasw ralphm, yeah, no (1) is basically "turn off your free service because of cost"
  1097. Ge0rG jonasw: "will you pay for a GDPR consultant / lawyer to answer ... ?"
  1098. jonasw Ge0rG, okay, that then ;-)
  1099. nyco agreed with ralphm, I feel like a layer would do better, faster, stronger...
  1100. jonasw Ge0rG, can you get an employee discount on those consultations? ;-)
  1101. winfried Guus goof for me
  1102. ralphm jonasw: I'm pretty sure that not complying with the GDPR will put you back further
  1103. Ge0rG jonasw: I can try to schedule them into the lunch break
  1104. jonasw ralphm, that’s why I said "turn off"
  1105. pep. jonasw, Ge0rG, I'm also interested if it's in a language I can comprehend
  1106. ralphm jonasw: but yeah, I'm not saying it is great
  1107. Ge0rG jonasw: I assume that getting a proper report on those use cases will inevitably cause multiple thousands of EURs of expenses.
  1108. winfried I suggest jonasw Ge0rG and I stick together and make an inventarisation of what to do
  1109. jonasw "yay"
  1110. Ge0rG what winfried said
  1111. jonasw okay, that sounds sane
  1112. pep. I want in
  1113. jonasw we can handle that either here or in xmpp@ maybe?
  1114. jonasw I’d like to avoid yet another muc ;-)
  1115. jonasw I’ll start by translating my notes from the talk I heard a few weeks ago
  1116. ralphm I think this venue is as good as any
  1117. winfried +1
  1118. Ge0rG just not during Board meeting?
  1119. winfried Ge0rG: exact
  1120. ralphm Right
  1121. ralphm I guess that's it for now.
  1122. ralphm 4. AOB
  1123. Guus To be clear: you guys will be working on finding out if there's generic advise (more precise than 'get a lawyer') that the XSF can give to server operators?
  1124. ralphm Didn't see any
  1125. Guus AOB I had feedback from peter on the bank account / bus factor thingy
  1126. ralphm And?
  1127. Guus I've added it to https://trello.com/c/yNLDp6Xt/297-answer-peters-email-on-bus-factor-for-bank-account
  1128. MattJ There's an open card about the membership survey.. sorry it's lagging, but I can send out an email to board@ with my current draft for us to bash before next week's meeting
  1129. Guus I've also talked to the Secretary, who is willing to help.
  1130. jonasw Guus, I think it’ll be more of an collection of things in the GDPR you absolutely HAVE TO look at
  1131. Dave Cridland has left
  1132. MattJ As in, we can spend a week bashing it, so we can make some concrete decisions in the next meeting
  1133. Guus my preference on the bus thing is do 1, not 2, from Peters options.
  1134. SaltyBones has left
  1135. Guus (and have Alex as the co-signer)
  1136. Guus can we vote on that, or do you guys need more time to read up on that?
  1137. ralphm I'm ok with both 1 and 2
  1138. Guus I prefer not to do 2
  1139. nyco I have no opinion
  1140. ralphm That's not a valid choice
  1141. nyco 3
  1142. ralphm I think it would be good to think about these options and decide our direction next week.
  1143. MattJ Sounds good to me
  1144. Guus ok
  1145. ralphm So that everybody can form an opinion
  1146. Guus MattJ, on that draft: please send it.
  1147. ralphm indeed
  1148. Dave Cridland has left
  1149. ralphm 5. Date of Next
  1150. ralphm +1W
  1151. ralphm 6. Close
  1152. ralphm Thanks all
  1153. ralphm bangs gavel
  1154. nyco thx all
  1155. Guus wooa, that was fast
  1156. Guus one last remark, if you induldge me
  1157. ralphm set the topic to XSF Discussion | Logs: http://logs.xmpp.org/xsf/ | Agenda https://trello.com/b/Dn6IQOu0/board-meetings
  1158. Guus https://trello.com/c/sBcxZrGZ/299-plan-and-organise-a-meeting-for-board-prios is not going to happen.
  1159. Guus we're postponing it for weeks now.
  1160. Guus let's archive this, and move on
  1161. nyco I am waiting for answer since weeks now
  1162. nyco I can't schedule
  1163. Guus that's what I mean: there's no progress on this. We're three months in our tenure.
  1164. Guus and we're having other stuff being blocked by this.
  1165. nyco rather than postpone it, it would be nice that everyone answers
  1166. Guus I'm not asking for postponement, I'm asking for it to not happen, and be removed from our Trello board. I've been doing that for a couple of meetings, each time that was responded to with 'lets see next week'.
  1167. Guus sadly, todays meeting was gaveled off already.
  1168. Guus I will, however, motion this again next week. I strongly feel that we should move forward.
  1169. winfried jonasw Ge0rG pep. can we make an appointment for the GDPR discussion? I have to leave now.
  1170. jonasw winfried, sure
  1171. ThibG has left
  1172. jonasw I’m probably the most flexible of all of us, so I’ll let you sort it out. saturday night and tomorrow between 10:00 and 14:00Z won’t work for me, otherwise I can probably arrange most things.
  1173. jonasw (and no wednesdays)
  1174. Ge0rG winfried: I prefer 0800Z to 1500Z on workdays.
  1175. Dave Cridland has left
  1176. nyco has left
  1177. winfried Tomorrow 1300UTC?
  1178. SaltyBones has left
  1179. Ge0rG winfried: 👍
  1180. jonasw nooo
  1181. jonasw that’s exactly in the time frame I opted out
  1182. Ge0rG jonasw: your message was TLDR :P
  1183. jonasw m(
  1184. Dave Cridland has left
  1185. winfried jonasw: oops, didn't read well...
  1186. jonasw seriously though, taht’s not going to work for me :)
  1187. winfried monday march 26 at 10:00 UTC?
  1188. jonasw winfried, wfm
  1189. Ge0rG 10:00 UTC will be 12:00 CEST after the DST change, right?
  1190. winfried *hmpf*
  1191. Dave Cridland has left
  1192. winfried 9:00 UTC will work for mee too :-P
  1193. pep. Worksforme
  1194. nyco has left
  1195. winfried so it is: monday march 26 at 10:00 UTC this muc
  1196. rion has left
  1197. winfried btw jonasw, good questions on the trello board
  1198. ThibG has joined
  1199. ta has joined
  1200. winfried See you monday!
  1201. Steve Kille has left
  1202. @Alacer has left
  1203. Guus Jonasw, i'm tempted to remove the related card from the Board board, until there's something for board to act on
  1204. @Alacer has joined
  1205. Guus do you see reason to keep it on there?
  1206. Steve Kille has joined
  1207. Ge0rG Guus: please keep it for documentation purposes.
  1208. Ge0rG Guus: also in case the GDPR-SIG dissolves prior to providing results
  1209. Steve Kille has left
  1210. Guus The board process is convoluted enough, without acting as an archive 🙂
  1211. Dave Cridland has left
  1212. Steve Kille has joined
  1213. Ge0rG somebody™ could move the questions to the wiki, then
  1214. Steve Kille has left
  1215. Guus Ge0rG, not that arching a card does not delete it
  1216. Guus it's still referable by URL
  1217. Dave Cridland has left
  1218. Ge0rG Guus: ah, then I retract my objections
  1219. Guus now archived: https://trello.com/c/t79C3Yds/307-gdpr-advice#
  1220. flow I wonder if bookmarks2 shouldn't rename autojoin to no-autojoin. Isn't the common case that I want to join the MUC I bookmarked?
  1221. marmistrz has joined
  1222. j.r has joined
  1223. Ge0rG flow: say what?
  1224. Ge0rG boolean variables containing a negation are one of the worst things you can do in logic.
  1225. Ge0rG `if (!no_autojoin) { WTF! }`
  1226. flow Ok, then stick with autojoin but default to true
  1227. Ge0rG flow: autojoin has a bunch of problems, but this one isn't it.
  1228. rion has joined
  1229. flow Ge0rG, I think sometimes those details are important
  1230. flow If we give people the imression that you want to autojoin explicitly, while my use case is cleary that I want autojoin implicitly
  1231. Ge0rG flow: okay, you are right.
  1232. Ge0rG flow: we've had a discussion regarding proper autojoin-UX some hours ago. Feel free to scroll up
  1233. j.r has joined
  1234. Ge0rG flow: http://logs.xmpp.org/xsf/2018-03-22/#13:49:11
  1235. flow Ge0rG, I saw that, but didn't closley follow
  1236. flow UX is another matter. what does whatsapp do?
  1237. MattJ It doesn't support multi-device
  1238. Dave Cridland has left
  1239. MattJ unless you count their hacky desktop proxied thing
  1240. flow Ahh right, that's the thing about whatsapp
  1241. flow but hangouts does, and I've never seen an autojoin option
  1242. flow IIRC there is only a "mute notification" option
  1243. Ge0rG flow: the change you propose is all about UX
  1244. MattJ Yeah
  1245. flow Ge0rG, I'm pretty sure it is about protocol design
  1246. Ge0rG flow: it is about the default value for an option, influencing the UX
  1247. flow only if you let it to, implementers could simply choose a different default
  1248. Ge0rG flow: by saying "this option should be true by default" you imply a UX change. Better we discuss that
  1249. jonasw Guus, feel free to remove
  1250. Dave Cridland has left
  1251. lumi has joined
  1252. flow Ge0rG, I'm not implying an UX design. I just think that defaults should cover the common case and wanted to raise attention that I believe autojoin=true is the common case to start the discussion
  1253. pep. jonasw, I guess I should start working on that EULA XEP as well
  1254. Dave Cridland has left
  1255. Ge0rG flow: I'd suggest to move the discussion to standards@, but unfortunately I haven't read up on that XEP yet myself
  1256. Dave Cridland has left
  1257. Dave Cridland has left
  1258. Dave Cridland has left
  1259. waqas has left
  1260. waqas has joined
  1261. Dave Cridland has left
  1262. Dave Cridland has left
  1263. waqas has left
  1264. tim@boese-ban.de has left
  1265. jjrh has left
  1266. Dave Cridland has left
  1267. jjrh has left
  1268. Dave Cridland has left
  1269. Dave Cridland has left
  1270. jjrh has left
  1271. dwd MLS BOF occurring at IETF, BTW - probably relevant to most folks here.
  1272. Zash Mmmmm, stream URL?
  1273. Ge0rG acronym galore! /o\
  1274. dwd Linked to from the IETF agenda, which I don't have to hand, but I reckon Google might know.
  1275. jjrh has left
  1276. Zash Hm, not linked
  1277. Dave Cridland has left
  1278. Tobias mls@jabber.ietf.org
  1279. jjrh has left
  1280. jjrh has left
  1281. dwd Meetecho on http://www.meetecho.com/ietf101/mls/
  1282. dwd (Should give audio and the jabber room, I think)
  1283. Dave Cridland has left
  1284. dwd Just audio on http://ietf101streaming.dnsalias.net/ietf/ietf1013.m3u
  1285. Zash Thanks
  1286. Zash meetecho wanted me to switch browsers
  1287. dwd Yeah, it doesn't work on Lynx.
  1288. SaltyBones has left
  1289. Dave Cridland has left
  1290. alexis has left
  1291. dwd has left
  1292. Dave Cridland has left
  1293. j.r has joined
  1294. Dave Cridland has left
  1295. winfried has joined
  1296. Dave Cridland has left
  1297. j.r has left
  1298. Steve Kille has left
  1299. Steve Kille has joined
  1300. Dave Cridland has left
  1301. Lance has joined
  1302. nyco has left
  1303. ralphm has left
  1304. dwd has left
  1305. Dave Cridland has left
  1306. Dave Cridland has left
  1307. waqas has joined
  1308. jubalh has joined
  1309. jubalh has left
  1310. ralphm has left
  1311. lumi has joined
  1312. Guus has left
  1313. ludo has joined
  1314. Guus has left
  1315. ralphm has left
  1316. dwd has left
  1317. Guus has left
  1318. Dave Cridland has left
  1319. ludo has left
  1320. ralphm has left
  1321. Dave Cridland has left
  1322. Holger has left
  1323. tux has joined
  1324. intosi has left
  1325. Dave Cridland has left
  1326. ta has joined
  1327. ludo has joined
  1328. Kev On the topic of the GDPR, does the XSF itself need to do any work here?
  1329. Ge0rG Kev: you mean regarding data stored by the XSF?
  1330. Zash Not strictly, I guess.
  1331. Kev I do.
  1332. Zash Hm, how do MUCs such as this one relate to GDPR?
  1333. Zash And mailing lists?
  1334. Zash *That* is something the IETF and other standards orgs probably wanna find out about too.
  1335. dwd Almost certainly.
  1336. moparisthebest I would *think* whatever applies to email would apply to xmpp, and whatever applies to mailing lists would apply to muc? maybe?
  1337. Kev And the wiki, which contains historical employment data, etc.
  1338. Ge0rG Kev: So we need a data protection office who will remove all PII from the wiki upon request
  1339. dwd I'll see if I can find out what the IETF are doing.
  1340. Kev I'm not in a position to assert what we need, just asking for Board to confirm that we're doing whatever it is that we need to be doing :)
  1341. moparisthebest it contains data on people who put the data there themselves and can remove it themselves right?
  1342. Kev Presumably, and possibly. I have no idea what the GDPR's stance on any of this is.
  1343. jonasw winfried, Ge0rG, you’re aware of the DST change in Europe this week which puts our meeting at 12:00 CEST?
  1344. Ge0rG jonasw: I am
  1345. Guus has left
  1346. winfried I am
  1347. ludo has left
  1348. jonasw good :)
  1349. jonasw Zash, this muc announces itself as publicly logged IIRC. this probably activates article 9 (2) (e) which means that the XSF is not liable even if I publicly talk about my sex life here. well, not liable w.r.t. GDPR at least.
  1350. jonasw same goes for mailing lists etc
  1351. jonasw the tricky part is with things which are supposedly private
  1352. winfried Kev dwd we should check first if the XSF is subject to the GDPR
  1353. jonasw Kev, and yeah, the wiki stuff is also covered by that I think
  1354. sezuan has left
  1355. Kev winfried: That was my question.
  1356. moparisthebest another person told me xmpp in general is fine because GDPR said you can use/send things that are required to do what the user expects, or something
  1357. moparisthebest this again was not a lawyer
  1358. pep. or something. Seems legit
  1359. moparisthebest well I paraphrased :)
  1360. jonasw moparisthebest, that’s not true if Article 9 (1) applies!
  1361. winfried Registered in the US, not explicitly targeting EU citizens... I should reread the articles on it and check the WP 29 opinions before answering that one...
  1362. moparisthebest but really, if email is ok, xmpp is ok, would EU have created a law banning email?
  1363. pep. moparisthebest, who knows. Wasn't there something about git history as well?
  1364. moparisthebest otherwise I guess all email/XMPP servers will have to move to non-EU places, and soft-ban EU people...
  1365. dwd moparisthebest, Well. Maybe.
  1366. dwd moparisthebest, They could easily have come up with a set of laws that means they have inadvertantly affected normal email use.
  1367. pep. https://law.stackexchange.com/questions/24623/gdpr-git-history < for fun
  1368. winfried moparisthebest jonasw I think XMPP is *generally* ok, but we must check all (edge) cases carefully before shouting anything
  1369. jjrh has left
  1370. marc has left
  1371. valo has left
  1372. lovetox has joined
  1373. valo has joined
  1374. moparisthebest dwd, yea that's what I'm semi concerned about, wouldn't put it past politicians
  1375. Zash If the politicians can't email anymore, then the thing will get fixed pretty fast :)
  1376. moparisthebest from a high level overview, it seems like this legislation was squarely targeted at walled gardens, where these regulations would be simple to implement
  1377. lumi has joined
  1378. Dave Cridland has left
  1379. Zash Compare roaming. Roaming affected EU MEPs pretty hard, since they went between Brussels, Strassburg and their home all the damn time.
  1380. Tobias Zash, no..they'll just use FAX
  1381. Ge0rG Zash: except that EU MEPs never see their phone bills
  1382. Zash Sure they do
  1383. Dave Cridland has left
  1384. Ge0rG Zash: I bet they don't. Otherwise it wouldn't have taken a decade between the first iphone and the removal of roaming fees.
  1385. jjrh has left
  1386. Zash Ask your MEPs
  1387. Ge0rG Zash: they all have a business phone provided by the respective government.
  1388. nyco has left
  1389. ludo has joined
  1390. ludo has left
  1391. winfried has joined
  1392. Guus has left
  1393. winfried has joined
  1394. jubalh has joined
  1395. tux has left
  1396. ludo has joined
  1397. SaltyBones Finally no roaming in Europe => Ze Germans are complaining that it took too long.
  1398. Ge0rG SaltyBones: I hate the mobile ISP oligopoly, with a passion.
  1399. dwd Anyone interested in reviewing MLS specs from here BTW?
  1400. dwd has left
  1401. Tobias dwd, you mean the XMPP adoption for it?
  1402. moparisthebest Ge0rG, that's what jmp.chat is hoping to fix :) one day...
  1403. Zash State teleco monopolies weren't all bad
  1404. Dave Cridland has left
  1405. Ge0rG Zash: oh really?
  1406. Ge0rG Zash: you have examples for them not being bad?
  1407. Ge0rG (Sweden doesn't count)
  1408. Zash Ge0rG: How do you do emergency calls in the middle of nowhere?
  1409. moparisthebest I dial 911 and then my android phone reboots
  1410. mimi89999 has joined
  1411. Ge0rG Zash: sometimes you can't, because of lack of coverage.
  1412. moparisthebest and sometimes the 911 handling code is never tested and crashes
  1413. Dave Cridland has left
  1414. moparisthebest (this is a somewhat common problem...)
  1415. moparisthebest smartphones! technology! yay! :'(
  1416. Ge0rG Zash: the German ex-state monopolist is successively switching DSL connections from regular analog POTS to VoIP. In case of a power outage, you can't call the emergency any more.
  1417. jjrh There are solutions for this like UPS's
  1418. jjrh if you're going to replace someones POTS line this should be a requirement
  1419. Ge0rG jjrh: it's not. they are. No UPS.
  1420. Dave Cridland has left
  1421. Steve Kille has left
  1422. Dave Cridland has left
  1423. jjrh yeah I believe it - but it should be a requirement by law. power the modem/router and a PoE switch (or ata). It's a safety thing.
  1424. ludo has left
  1425. jjrh 911 also needs a automated system to test 911 service - aka dial 811, and for the next 60 seconds you can dial 911 to test
  1426. jubalh has joined
  1427. Steve Kille has joined
  1428. ThibG has joined
  1429. moparisthebest yea that would be nice
  1430. moparisthebest especially for testing if your android phone is one that'll crash :)
  1431. moparisthebest pre-emergency
  1432. Dave Cridland has left
  1433. jjrh exactly - all sorts of situations really
  1434. Zash Ge0rG: Back in the olden days, there was copper cable that went everywhere. Later, there was near 100% GSM coverage. Now, with whatever G number we're on, if you are outside major cities, good luck.
  1435. LNJ has left
  1436. Dave Cridland has left
  1437. alexis has left
  1438. Tobias has joined
  1439. Tobias has left
  1440. jonasw jjrh, that’d be a good thing indeed
  1441. winfried has left
  1442. MattJ unless you dialled 811 in an emergency situation :)
  1443. Zash Imagine the RoI of covering hundreds ouf thousands of km² with coverage, when like three people live there.
  1444. Dave Cridland has left
  1445. jjrh has left
  1446. Steve Kille has left
  1447. Dave Cridland has left
  1448. daniel has left
  1449. Dave Cridland has left
  1450. Yagiza has left
  1451. jjrh has left
  1452. Dave Cridland has left
  1453. jjrh has left
  1454. ThibG has left
  1455. Zash and less than 1 person per km²
  1456. Dave Cridland has left
  1457. Maranda has joined
  1458. Ge0rG Zash: you wanted me to tell about the benefits of formerly-state-owned telco monopolies.
  1459. Zash Ge0rG: No, they suck.
  1460. fippo ge0rg: they pay quite good salaries.
  1461. Zash Ge0rG: Was better before the "former"
  1462. Ge0rG Zash: the German former-state-monopoly is required to proive phone lines to _any_ address. RoI doesn't play any role there. But they are not required to proivde Internet connectivity, so there are still places where all you can get is either ISDN (64kbit/s with a per-minute fee) or something like 2mbit/s DSL
  1463. Dave Cridland has left
  1464. SaltyBones has left
  1465. SaltyBones has left
  1466. Zash Ge0rG: No idea if that is the case here (anymore)
  1467. marmistrz has left
  1468. iiro.laiho has joined
  1469. moparisthebest or satellite Ge0rG ? (is that an option there)
  1470. Dave Cridland has left
  1471. dwd Interesting talk last night on satellite broadband, BTW.
  1472. dwd Although I basically understood none of it.
  1473. Ge0rG moparisthebest: you never used a sat link, did you?
  1474. Ge0rG moparisthebest: you never used a sat link, did you?
  1475. Dave Cridland has left
  1476. moparisthebest Ge0rG, no but as I understand it, throughput is fine, but latency is awful
  1477. moparisthebest still better than 64kbps dialup though right?
  1478. dwd Lots of stuff on latency too. Short end of satellite is 12ms, which surprised me. (Longer end is 480ms, it mostly depends on the orbit choice).
  1479. SaltyBones has joined
  1480. Zash Further north you basically need polar orbits to get any coverage at all AFAIK
  1481. moparisthebest non-equator orbit requires fuel and is really expensive right?
  1482. moparisthebest it's been a long time since I read anything about it
  1483. Zash Everything requires fuel
  1484. Zash You benefit less from the earth already rotating in the general direction you want
  1485. Zash Duno about exact differences
  1486. Dave Cridland has left
  1487. Ge0rG moparisthebest: dialup has better latency, and bandwidth on most sat links is limited, so you pay per gigabyte
  1488. Alex has left
  1489. Ge0rG The "affordable" ones are equatorial, so you end up with 1s rtt, and the low orbit ones typically only offer very low bandwidth, and cost an arm and a leg
  1490. moparisthebest and with dialup you can't download a gigabyte within an entire month so sat still sounds better :)
  1491. dwd Well. Russia launches at around 42 degrees, as I recall, to avoid launch failures hitting China.
  1492. LNJ has left
  1493. j.r has left
  1494. j.r has joined
  1495. moparisthebest yea I was under the impression all affordable ones like for homes were equatorial
  1496. moparisthebest and I guess that doesn't work too far north
  1497. moparisthebest maybe, I don't really know
  1498. dwd Well, hard to get a geostationary orbit anywhere but equatorial.
  1499. Valerian has left
  1500. Andrew Nenakhov Geostationary orbit can't be not equatorial. If orbit has tilt and rotation period equals 24h it is called geosynchronous orbit
  1501. Andrew Nenakhov Projection of such orbits on surface draws big 8-shaped traces
  1502. Dave Cridland has left
  1503. jonasw could probably feed that into The ONE
  1504. ludo has joined
  1505. Zash The sun does something like that too iirc
  1506. lskdjf has joined
  1507. Alex has joined
  1508. Dave Cridland has left
  1509. Alex has left
  1510. Andrew Nenakhov has left
  1511. Andrew Nenakhov has joined
  1512. Alex has joined
  1513. Dave Cridland has left
  1514. Andrew Nenakhov has left
  1515. Andrew Nenakhov has joined
  1516. LNJ has left
  1517. ludo has left
  1518. dwd ANyone up for reviewing https://datatracker.ietf.org/doc/draft-ietf-mile-xmpp-grid/ ? Basically using PubSub for incident management (crybersecurity incidents, really).
  1519. Ge0rG dwd: is that used anywhere? My employer is very interested in cyber, and I'm very interested in jabber.
  1520. dwd Ge0rG, It's early days, but there is a load of interest.
  1521. Zash Is "cyber" still used?
  1522. Ge0rG Last time I reviewed a cyber related xep it was horrible.
  1523. dwd Ge0rG, This one got serious work from PSA, and looks sane to me.
  1524. jonasw oh, PSA is at mozilla these days?
  1525. dwd jonasw, Yes, but mostly doing W3C work currently.
  1526. jonasw that’s a funny author list. A Pope and a Saint.
  1527. jonasw > In SACM
  1528. jonasw close!
  1529. Ge0rG That's great
  1530. dwd So XMPP-Grid is developed in MILE, since it has the simpler use-cases, but it's also being looked at closely in SACM, which is Security Assessment and Continuous Monitoring.
  1531. Dave Cridland has left
  1532. dwd I'm confused by (Americans?) saying JSON with the emphasis on the ON, and not pronouncing it like "Jason".
  1533. moparisthebest I've always said jace like mace on on like, turn the light on
  1534. SamWhited I think it goes both ways here; I hear both pretty often at least, not sure if it's a regional thing or not
  1535. moparisthebest then again I can probably count on 1 hand the number of times I've spoken not typed JSON
  1536. moparisthebest still not as bad as when I had to say lighttpd out loud without prep though
  1537. SamWhited You mnean lie-tuh-tuh-puh-duh?
  1538. marmistrz has joined
  1539. SamWhited mean, even.
  1540. marmistrz has joined
  1541. Dave Cridland has left
  1542. moparisthebest more like light http... lie http..., look it's spelled like l-i-g-h-t-t-p-d
  1543. moparisthebest nginx is another fun one, what's with web servers?
  1544. SamWhited ligh tuh-tuh-pud?
  1545. SamWhited Everyone knows that's pronounced in-jinx. Obviously.
  1546. Zash Laj-ty
  1547. Dave Cridland has left
  1548. Lance has left
  1549. Dave Cridland has left
  1550. dwd has left
  1551. Dave Cridland has left
  1552. Dave Cridland has left
  1553. Guus has left
  1554. jjrh has left
  1555. dwd has left
  1556. Dave Cridland has left
  1557. ludo has joined
  1558. Andrew Nenakhov has left
  1559. Andrew Nenakhov has joined
  1560. vanitasvitae has left
  1561. Andrew Nenakhov has joined
  1562. dwd has left
  1563. jjrh has left
  1564. Andrew Nenakhov has left
  1565. ludo has left
  1566. Andrew Nenakhov has joined
  1567. Dave Cridland has left
  1568. Valerian has joined
  1569. Dave Cridland has left
  1570. Dave Cridland has left
  1571. Dave Cridland has left
  1572. Maranda has joined
  1573. rion has left
  1574. Ge0rG If we have MIX messages in MAM on both the MIX and the user's server, who's responsible for stanza ids?
  1575. jonasw Ge0rG, both?
  1576. jonasw stanza ids can have a from IIRC
  1577. jonasw the attribute’s called @by
  1578. Ge0rG How am I supposed to sync that mess in my client, then?
  1579. jonasw always ask the MIX server, be happy.
  1580. Zash While trying not to cry.
  1581. jonasw (and use the stanza-id from the MIX server)
  1582. jonasw I don’t quite get the point of duplicating the acrhive across the network, especially since I’m not sure whether the s2s issues are fully sorted out yet
  1583. Ge0rG Create a separate table for M:N relationship between messages and their ids?
  1584. jonasw Ge0rG, no, use the MIX stanza-ID for MIX messages, and your servers stanza ID for all other.
  1585. Ge0rG jonasw: they aren't
  1586. jonasw annotate (or figure out) which archive to query for each message type
  1587. jonasw of course, that’s tricky depending on your archive model
  1588. jonasw I’ll add that to the design consideraitons for the jabbercat archive
  1589. Ge0rG jonasw: Hm. How am I supposed to query my server for "everything after MIX ID x"?
  1590. jonasw not?
  1591. jonasw you’d look at the last non-MIX message obviously. or you take the stanza-id from your servers archive from that MIX message
  1592. Ge0rG But I'm supposed to ask my server when reconnecting?
  1593. jonasw ask your server for what?
  1594. Ge0rG My head just exploded.
  1595. jonasw I’m not going to mop that up.
  1596. Zash How about we fix the mess so we can finally have everything the users archive?
  1597. jonasw -EPARSE
  1598. Zash in
  1599. rion has joined
  1600. Zash Packetloss between brain and poezio
  1601. jonasw Zash, fix the general issue that split brain conditions will always occur and/or specify proper syncing in MIX :-)
  1602. Zash jonasw: s2s-smacks?
  1603. Zash Or have one archive query the other?
  1604. jonasw not sufficient for longer partitions.
  1605. LNJ has left
  1606. Zash Or cry?
  1607. jonasw the latter would work
  1608. jonasw but that’s not specified anywhere
  1609. Zash Does it need to?
  1610. Zash And, is that what Matrix is supposed to be?
  1611. jonasw it would be good to have that writetn down in MIX so that noone is surprised like "oh, we need to do that for things to work?"
  1612. Zash And where's the blockchain?
  1613. jonasw the blockchain is illegal now
  1614. Zash Gooooood
  1615. jonasw yeah, it made my day yesterday
  1616. Zash Does that make git illegal too?
  1617. Ge0rG Zash: no. Git will become illegal on May 25th
  1618. Zash "By submitting patches, you realize that nothing can ever be truly deleted."
  1619. moparisthebest s/submitting patches/using the internet/
  1620. moparisthebest but no, EU will just legislate it away magically
  1621. Ge0rG My questions regarding MIX were provoked by flow's mail
  1622. Ge0rG moparisthebest: just stop bashing the EU. In the US of A, Zuck is playing the innocent while sitting on millions of data records he obtained illegally
  1623. moparisthebest has left
  1624. Zash Wow. My current level of sleepyness and the length of that email are not friends.
  1625. moparisthebest Ge0rG, illegally or that idiot users gave to him willingly?
  1626. Ge0rG moparisthebest: illegally. In Germany it's illegal to collect PII without consent, and Facebook is profiling me despite me not having an account.
  1627. Zash Wait how does the EU pass laws now?
  1628. moparisthebest seems to me this GDPR business is creating more problems than anything it's solving
  1629. Zash Don't they pass directives that countries are supposed to adapt?
  1630. Ge0rG moparisthebest: it's mainly creating problems for people who think they can trade *my* data without restrictions
  1631. moparisthebest Ge0rG, lol don't get me started on germany's dumb PII laws, for medical trials we need date of birth, that's illegal to collect in germany, however, it is legal to collect how many days old you are today, march 22nd, 2018
  1632. moparisthebest what genious politician came up with that one?
  1633. Ge0rG moparisthebest: data is like oil. If you spill it, somebody else has to pay millions to clean the mess
  1634. jonasw what email are we talking about
  1635. Zash jonasw: MIX review I think
  1636. jonasw oh, so not from right now
  1637. Ge0rG moparisthebest: you should fire your lawyer
  1638. jonasw I liked the start and was distracted
  1639. Ge0rG jonasw: https://mail.jabber.org/pipermail/standards/2018-March/034668.html
  1640. Zash I could use that email2epub thing right about ... tomorrow.
  1641. jonasw too many unread emails in threads which concern me
  1642. Zash Was there a thing that lists current CfEs?
  1643. jonasw Zash, no, CFEs aren’t tracked
  1644. jonasw XEP-0092 and XEP-0048 are closed, the others are still open
  1645. jonasw eh
  1646. jonasw incorrect, second
  1647. Zash The Others
  1648. jonasw XEP-{0092,0122,0131,0141,0229} are open.
  1649. ludo has joined
  1650. jonasw XEP-{0048,0066} are closed
  1651. valo has joined
  1652. ludo has left
  1653. Zash Don't think I touched the >100 ones
  1654. jonasw SHIM is a dependency of PubSub IIRC
  1655. jonasw (SHIM being XEP-0131)
  1656. Zash And what does that tell you aobut xep60 :)
  1657. Zash And what does that tell you about xep60? :)
  1658. jonasw it grew for way too long?
  1659. Zash s/touched/implemented/ might be more accurate
  1660. Alex has left
  1661. goffi has left
  1662. rion has left
  1663. mimi89999 has left
  1664. mimi89999 has left
  1665. Neustradamus has joined
  1666. Andrew Nenakhov has left
  1667. Andrew Nenakhov has joined
  1668. Andrew Nenakhov has left
  1669. Andrew Nenakhov has joined
  1670. Zash minOccurs='1' but no max?
  1671. Zash (yes yes, non-normative schema)
  1672. jonasw I wish we had a way to express normative schema
  1673. Kev We do, we just say 'this schema is normative'
  1674. jonasw Kev, yeah, but a lot of things we do can’t be expressed with XML schemas easily
  1675. Kev Ah. You mean a schema that is capable of expressing the normative text, rather than a way of expressing that the schema is normative.
  1676. Kev I think.
  1677. jonasw yeah
  1678. jonasw that’s what I meant.
  1679. jere has joined
  1680. Kev As you were.
  1681. mimi89999 has joined
  1682. mimi89999 has left
  1683. mimi89999 has joined
  1684. Ge0rG So we would be just one step away from implementing the protocol code right from the XEP? Yay!
  1685. Kev Oh, good call, we can express the schema through C++.
  1686. Kev Result.
  1687. Andrew Nenakhov has joined
  1688. jonasw I wonder whether a specialized XML Schema variant (re-using the scalar types, but re-doing all the complex type stuff) would make sense.
  1689. pep. I remember Link Mauve actually thinking about that for a while for https://hg.linkmauve.fr/xmpp-parsers, having some macro with a DSL to generate the code for the parsers :-°
  1690. jonasw Zash, the more I think about it, the more it seems that having the users server sync the archive from the MIX server is the way to go, *iff* we want to have the users server have a copy of that archive at all.
  1691. Zash jonasw: That would work for MUC+MAM too.
  1692. jonasw yeah
  1693. jonasw simplifies things
  1694. jonasw for the client anyways
  1695. ludo has joined
  1696. jonasw Zash, have you checked mentally whether that fits with prosodys model of $date-$uid archive stanza IDs?
  1697. Ge0rG Just replace direct messaging with a MAM subscription and you are done.
  1698. Zash Having to query MUC-MAMs is somewhat messy
  1699. Zash jonasw: That's not Prosodys model. That's my NIH'd "I don't like databases" database.
  1700. flow jonasw, that, but I wonder if MAM should get an overhaul
  1701. Zash jonasw: Prosody itself doesn't know or care about that.
  1702. jonasw Zash, okay.
  1703. jonasw Zash, that still leaves my question though :)
  1704. jonasw flow, that sounds awful.
  1705. jonasw what would you change?
  1706. Zash jonasw: The storage API is just (user, suggested-id, stanza, ...) → (id)
  1707. Valerian has left
  1708. Valerian has joined
  1709. flow I know it is a senstive topic, but given the recent discussions about MAM syncing I started looking into prior art
  1710. Zash The idea being that the storage driver might use the ID you want it to, or might need to pick its own.
  1711. Kev I'm not sure that MAM needs an overhaul other than ripping the config stuff into its own XEP (which is just editing), and ensuring we can fill holes.
  1712. Kev (And we can fill holes, and we have code that works, but people seem to be dead set on believing we don't for some reason, so we might have to tweak the spec)
  1713. flow i'm actually not sure *what* I would change, but I have some ideas
  1714. jonasw flow, drop them on standards@?
  1715. jonasw I still need to process your MIX mail though
  1716. Zash jonasw: Does one archive subscribing to another prevent it from making up new IDs?
  1717. Kev The biggest thing that MAM needs is to be based on XMPP 2 routing rules for its archiving, I think.
  1718. flow probably, but first I'd like to look if JID hiding in MIX could be made optional
  1719. flow and if the overall MIX thingy can be made simpler
  1720. jonasw Zash, no, but if you bulk fetch messages it could get weird
  1721. Zash jonasw: How?
  1722. Kev I need to reply to flow's MIX mail, but I'd quite like to swap all of the current 369 document into my head first. I understand the design, but don't know what words we've got to describe it.
  1723. jonasw Zash, if MAM has a guarantee on being in timestamp order, you’d need to backfill at the appropriate places
  1724. Zash jonasw: Ohglob
  1725. Zash jonasw: That messes things up :|
  1726. Kev flow: I think MIX *is* pretty simple, but I think we've somehow made it sound complicated despite this.
  1727. jonasw flow, as long as MIX doesn’t fall back to what MUC does with that /resource-as-nickname "abuse", I’m probably fine with it
  1728. ludo has left
  1729. jonasw Zash, thought so. welcome to the struggles clients face :)
  1730. daniel has left
  1731. flow Kev, the question is not if it is simple, but if it can be made simpler (without loosing functionality)
  1732. Kev And I'm not convinced that the JID hiding is actually significantly complex, it's just one indirection lookup.
  1733. Kev Although it was me who was pushing for not having semi-anonymous (in xep45 terms) MIXs at all, but the Summit was very clear that this is a required feature.
  1734. flow I sense that it's a controversial feature
  1735. SamWhited I think it's a required feature, but I don't see why it has to be tightly coupled with MIX…
  1736. SamWhited It could be some other XEP that comes later and isn't specific to MIX.
  1737. Kev It seems like that's true, but I don't think it is.
  1738. Valerian has left
  1739. Valerian has joined
  1740. Zash So what abstract model should MAM be based on?
  1741. Kev It would be if we were talking about fully-anonymous(fully-pseudonymous) rooms, but for the semi- model I think it does need fairly tight coupling.
  1742. jonasw what is the use-case for semi-anon as compared to fully-anon though?
  1743. SamWhited As long as the MIX service is still the thing issuing the semi-anon identities it can be publishing a mapping into nodes that only the admins can read.
  1744. Kev We've coped with this level of indirection in MUC for years and other than that we got the pseudonymous JIDs wrong, I don't think it's been a significant barrier to entry to anyone.
  1745. Kev jonasw: The usual public MUC where you don't want people to start spamming each other, but you do want sensible moderation.
  1746. jonasw Kev, which part of moderation requires semi-anon?
  1747. Kev Anything that involves knowing who you're moderating?
  1748. Kev Anyway, it's late and I'm shattered, so I'm going to pick MIX up again in the morning. NN folks.
  1749. jonasw Kev, why do you need to know?
  1750. jonasw affiliations (speaking in MUC terms) could be mapped by the MUC service. e.g. if I say /ban kevins%proxy@jid, the service would translate that to "ban kevins@actual.jid" and would enforce that
  1751. Zash You can already ban and stuff via nickname, so ... I'm too tired to have any idea of what you are talking about
  1752. jonasw you can’t ban via nickname
  1753. jonasw if your client allows that it is racy
  1754. jonasw (maybe not racy; but at least the client does the nickname->real jid lookup)
  1755. Zash Full-anon MUCs must work like that tho
  1756. jonasw are there full-anon MUCs?
  1757. Zash ... No
  1758. ludo has joined
  1759. LNJ has left
  1760. Ge0rG So what you want is to tell the service "ban this nickname" and it will ban the user's real JID without ever exposing it to the MUC owner.
  1761. Andrew Nenakhov has left
  1762. Andrew Nenakhov has joined
  1763. jonasw Ge0rG, yeah
  1764. jonasw except that I wouldn’t use nicknames in MIX but the proxy JIDs
  1765. jonasw in MUC that wouldn’t work because of the inherent race condition
  1766. jonasw (I send "ban X", my link is slow, in the meantime X leaves and another person accidentally also called X joins)
  1767. Zash Is it kicks in MUC that are on nicknames?
  1768. jonasw Zash, yes
  1769. j.r has joined
  1770. ludo has left
  1771. Zash jonasw: Altho that's not as permanent as affiliation changes
  1772. Zash Races could be mitigated by not allowing anyone else to use a recently used nickname (for x time)
  1773. jonasw Zash, that’s a bad mitigation
  1774. Zash Why?
  1775. jonasw because my link may lag for x+1 time after I sent the kick
  1776. jonasw without a way for me to rectify it in time
  1777. jonasw and ebcause I don’t know their real jid I can’t re-invite them
  1778. Valerian has left
  1779. marc has left
  1780. remko has left
  1781. Ge0rG I'm sure we can live with that improbable problem
  1782. marmistrz has left
  1783. jonasw (won’t be a problem with MIX)
  1784. ThibG has joined
  1785. jubalh has joined
  1786. Guus has left
  1787. ludo has joined
  1788. pep. I think waqas mentioned prosody *had* an implementation of full-anon MUCs
  1789. LNJ has joined
  1790. marc has joined
  1791. ludo has left
  1792. marc has left
  1793. j.r has left
  1794. j.r has joined
  1795. marc has joined
  1796. lskdjf has joined
  1797. Maranda has joined
  1798. jjrh has left
  1799. lskdjf has joined
  1800. marmistrz has joined
  1801. ludo has joined
  1802. jjrh has left
  1803. jjrh has left
  1804. marc has left
  1805. tux has joined
  1806. jere has joined
  1807. SaltyBones has left
  1808. efrit has joined
  1809. jubalh has left
  1810. waqas has left
  1811. marc has joined
  1812. Guus has left
  1813. j.r has joined
  1814. waqas has joined
  1815. Dave Cridland has left
  1816. waqas pep.: Yes, we used to, and it wouldn't be that hard to add again
  1817. pep. I'd like that back, way more than semi-anon. I don't really get why semi-anon survived and not full-anon
  1818. iiro.laiho has left
  1819. ludo has left
  1820. pep. Though as SamWhited it doesn't have to be in that XEP? it can be dealt with another XEP. SamWhited, were you thinking of something like burner jids?
  1821. pep. Is this used anywhere yet btw?
  1822. pep. as SamWhited said*
  1823. waqas I don't have context of what Sam said
  1824. waqas I don't believe burner JIDs are needed for just anon MUC
  1825. pep. 05:58:01 Kev> Although it was me who was pushing for not having semi-anonymous (in xep45 terms) MIXs at all, but the Summit was very clear that this is a required feature. 05:58:28 SamWhited> I think it's a required feature, but I don't see why it has to be tightly coupled with MIX… 05:59:01 SamWhited> It could be some other XEP that comes later and isn't specific to MIX.
  1826. waqas (beyond what Prosody already has for semi-anonymous)
  1827. j.r has left
  1828. pep. waqas, sure, but they could be used instead of implementing full-anon mucs on any server, and would also be useful not just for mucs
  1829. j.r has joined
  1830. ludo has joined
  1831. waqas As long as MIX clarifies that the JIDs may be missing or may not be real JIDs, and leaves the door open. Because if it's defined in a XEP, you still want interop with clients who were written before that new XEP happened.
  1832. j.r has joined
  1833. j.r has joined
  1834. j.r has left
  1835. pep. (don't pay attention to my UTC+9 timezone)
  1836. j.r has joined
  1837. waqas "Go to sleep"? ^^
  1838. LNJ has left
  1839. j.r has joined
  1840. j.r has joined
  1841. Zash Mental or physical timezone?
  1842. pep. none of these. I just have to move that machine back, someday
  1843. pep. And also maybe change the timezone
  1844. Andrew Nenakhov > "Go to sleep"? ^^ 7:23 is a good time to get up
  1845. pep. Or maybe in the opposite order
  1846. ludo has left
  1847. SamWhited has left
  1848. Dave Cridland has left
  1849. jjrh has left
  1850. Guus has left
  1851. jjrh has left
  1852. jere has joined
  1853. Dave Cridland has left
  1854. Andrew Nenakhov has left
  1855. Andrew Nenakhov has joined
  1856. Andrew Nenakhov has left
  1857. ludo has joined
  1858. jjrh has left
  1859. jjrh has left
  1860. Andrew Nenakhov has joined
  1861. Dave Cridland has left
  1862. j.r has joined
  1863. j.r has joined
  1864. ludo has left
  1865. Guus has left
  1866. Zash has left
  1867. lskdjf has left
  1868. tux has joined
  1869. Dave Cridland has left
  1870. winfried has joined
  1871. valo has joined
  1872. waqas has left
  1873. Syndace has joined
  1874. ludo has joined
  1875. Dave Cridland has left
  1876. ThibG has left
  1877. ThibG has joined
  1878. lovetox has left
  1879. ludo has left
  1880. marc has left
  1881. marc has joined
  1882. Dave Cridland has left