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


  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


  368. jonasw


  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


  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


  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


  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


  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


  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


  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


  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


  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


  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


  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


  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


  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.


  831. MattJ

    pep., enlighten me, what is the autojoin feature some want?

  832. pep.

    Sync the state across devices

  833. MattJ


  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.


  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


  860. pep.

    Zash, "also join on: [ ] Desktop [X] Mobile [...]" ?

  861. pep.


  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


  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.


  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


  948. ralphm

    Looks to be on

  949. nyco


  950. nyco

    seems to work today

  951. nyco


  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


  957. MattJ


  958. Guus


  959. Guus

    Martin excused himself earlier.

  960. ralphm


  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


  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


  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


  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


  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


  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


  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


  1027. ralphm


  1028. MattJ

    I really mean that Board needs to make sure this happens

  1029. ThibG has joined

  1030. Guus


  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


  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


  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


  1049. Guus

    Ralph, you still with us?

  1050. ralphm


  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


  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


  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


  1118. Ge0rG

    just not during Board meeting?

  1119. winfried

    Ge0rG: exact

  1120. ralphm


  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


  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


  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


  1145. ralphm

    So that everybody can form an opinion

  1146. Guus

    MattJ, on that draft: please send it.

  1147. ralphm


  1148. Dave Cridland has left

  1149. ralphm

    5. Date of Next

  1150. ralphm


  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


  1181. jonasw

    that’s exactly in the time frame I opted out

  1182. Ge0rG

    jonasw: your message was TLDR :P

  1183. jonasw


  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


  1191. Dave Cridland has left

  1192. winfried

    9:00 UTC will work for mee too :-P

  1193. pep.


  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


  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


  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


  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


  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


  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


  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


  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


  1598. Zash


  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


  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


  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


  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


  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


  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


  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