XSF Discussion - 2020-08-25


  1. LNJ has left
  2. LNJ has joined
  3. alexis has left
  4. Lance has left
  5. bear has left
  6. Lance has joined
  7. alexis has joined
  8. bear has joined
  9. neshtaxmpp has left
  10. emus has left
  11. Lance has left
  12. j.r has joined
  13. mukt2 has joined
  14. Lance has joined
  15. j.r has left
  16. Wojtek has left
  17. mukt2 has left
  18. stpeter has joined
  19. stpeter has left
  20. Lance has left
  21. bear has left
  22. Lance has joined
  23. bear has joined
  24. Lance has left
  25. alexis has left
  26. alexis has joined
  27. krauq has left
  28. krauq has joined
  29. neshtaxmpp has joined
  30. Lance has joined
  31. alexis has left
  32. alexis has joined
  33. Lance has left
  34. j.r has joined
  35. Half-Shot has left
  36. uhoreg has left
  37. Rixon 👁🗨 has left
  38. uhoreg has joined
  39. Half-Shot has joined
  40. Rixon 👁🗨 has joined
  41. neshtaxmpp has left
  42. LNJ has left
  43. neshtaxmpp has joined
  44. j.r has left
  45. adiaholic_ has joined
  46. Lance has joined
  47. Yagiza has joined
  48. Lance has left
  49. stpeter has joined
  50. stpeter has left
  51. neshtaxmpp has left
  52. j.r has joined
  53. neshtaxmpp has joined
  54. bear has left
  55. adiaholic_ has left
  56. j.r has left
  57. krauq has left
  58. bear has joined
  59. krauq has joined
  60. neshtaxmpp has left
  61. neshtaxmpp has joined
  62. Seve has joined
  63. neshtaxmpp has left
  64. neshtaxmpp has joined
  65. murabito has left
  66. murabito has joined
  67. krauq has left
  68. krauq has joined
  69. stpeter has joined
  70. stpeter has left
  71. mukt2 has joined
  72. adiaholic_ has joined
  73. Lance has joined
  74. Tobias has joined
  75. mukt2 has left
  76. Lance has left
  77. mimi89999 has left
  78. mimi89999 has joined
  79. lorddavidiii has joined
  80. DebXWoody has joined
  81. adiaholic_ has left
  82. adiaholic_ has joined
  83. Nano4BeingYou has joined
  84. Lance has joined
  85. bear has left
  86. lovetox has joined
  87. adiaholic_ has left
  88. adiaholic_ has joined
  89. Daniel Well technically it's probably incitement. Which is illegal. But INAL and nobody is going to sue over that.
  90. lovetox has left
  91. Maranda has left
  92. winfried has left
  93. winfried has joined
  94. adiaholic_ has left
  95. adiaholic_ has joined
  96. Maranda has joined
  97. Mikaela has joined
  98. adiaholic_ has left
  99. adiaholic_ has joined
  100. jcbrand has joined
  101. sonny has left
  102. karoshi has joined
  103. sonny has joined
  104. stpeter has joined
  105. stpeter has left
  106. winfried has left
  107. winfried has joined
  108. winfried has left
  109. winfried has joined
  110. sonny has left
  111. sonny has joined
  112. winfried has left
  113. winfried has joined
  114. winfried has left
  115. winfried has joined
  116. sonny has left
  117. sonny has joined
  118. marc has joined
  119. eevvoor has joined
  120. eevvoor has left
  121. eevvoor has joined
  122. lorddavidiii has left
  123. lskdjf has joined
  124. sonny has left
  125. sonny has joined
  126. eevvoor has left
  127. eevvoor has joined
  128. goffi has joined
  129. amuza@riseup.net has joined
  130. Lance has left
  131. lorddavidiii has joined
  132. marc has left
  133. sonny has left
  134. sonny has joined
  135. sonny has left
  136. sonny has joined
  137. adiaholic_ has left
  138. adiaholic_ has joined
  139. adiaholic_ has left
  140. adiaholic_ has joined
  141. sonny has left
  142. winfried has left
  143. winfried has joined
  144. Steve Kille has left
  145. sonny has joined
  146. Steve Kille has joined
  147. adiaholic_ has left
  148. adiaholic_ has joined
  149. neshtaxmpp has left
  150. sonny has left
  151. sonny has joined
  152. sonny has left
  153. neshtaxmpp has joined
  154. sonny has joined
  155. sonny has left
  156. eevvoor has left
  157. eevvoor has joined
  158. sonny has joined
  159. neshtaxmpp has left
  160. Lance has joined
  161. sonny has left
  162. sonny has joined
  163. alameyo has left
  164. Lance has left
  165. Nekit has left
  166. debacle has joined
  167. sonny has left
  168. sonny has joined
  169. Nekit has joined
  170. emus has joined
  171. dwd lovetox, You're not allowed to send data to the FBI; it would be illegal under the GDPR.
  172. sonny has left
  173. dwd moparisthebest, But, a GDPR Subject Access Request over XMPP would be legit and require a response within a fixed time period of a month (and without "undue delay").
  174. dwd moparisthebest, (This case isn't a DSAR, of course, as the FBI is not a Data Subject here)/
  175. stpeter has joined
  176. stpeter has left
  177. sonny has joined
  178. sonny has left
  179. sonny has joined
  180. sonny has left
  181. marc has joined
  182. sonny has joined
  183. eevvoor has left
  184. sonny has left
  185. lovetox has joined
  186. sonny has joined
  187. sonny has left
  188. sonny has joined
  189. alexis has left
  190. Dele Olajide has joined
  191. alexis has joined
  192. sonny has left
  193. sonny has joined
  194. debacle has left
  195. sonny has left
  196. sonny has joined
  197. lovetox has left
  198. Nano4BeingYou has left
  199. sonny has left
  200. sonny has joined
  201. sonny has left
  202. !XSF_Martin has left
  203. !XSF_Martin has joined
  204. sonny has joined
  205. j.r has joined
  206. Lance has joined
  207. adiaholic_ has left
  208. adiaholic_ has joined
  209. sonny has left
  210. j.r has left
  211. Half-Shot has left
  212. uhoreg has left
  213. Rixon 👁🗨 has left
  214. uhoreg has joined
  215. Half-Shot has joined
  216. Rixon 👁🗨 has joined
  217. Nekit has left
  218. lovetox has joined
  219. adiaholic_ has left
  220. adiaholic_ has joined
  221. Lance has left
  222. dwd has left
  223. krauq has left
  224. alexis has left
  225. debacle has joined
  226. krauq has joined
  227. winfried has left
  228. winfried has joined
  229. stpeter has joined
  230. stpeter has left
  231. sonny has joined
  232. larma has left
  233. larma has joined
  234. adiaholic_ has left
  235. adiaholic_ has joined
  236. sonny has left
  237. sonny has joined
  238. eevvoor has joined
  239. alexis has joined
  240. winfried has left
  241. winfried has joined
  242. sonny has left
  243. sonny has joined
  244. sonny has left
  245. sonny has joined
  246. emus has left
  247. emus has joined
  248. alexis has left
  249. sonny has left
  250. sonny has joined
  251. sonny has left
  252. sonny has joined
  253. alexis has joined
  254. sonny has left
  255. amuza@riseup.net has left
  256. LNJ has joined
  257. LNJ has left
  258. alexis has left
  259. LNJ has joined
  260. Maranda has left
  261. Maranda has joined
  262. sonny has joined
  263. emus has left
  264. emus has joined
  265. Alex Memberbot is still online for our member meeting today. If you are a XSF member and have not voted yet then please do so. Thanks.
  266. alexis has joined
  267. jonas’ Alex, Thanks! I won’t be able to attend in-person, but I already voted :)
  268. emus has left
  269. emus has joined
  270. MattJ Just voted :)
  271. sonny has left
  272. sonny has joined
  273. sonny has left
  274. sonny has joined
  275. alexis has left
  276. Lance has joined
  277. floretta has left
  278. alexis has joined
  279. Lance has left
  280. alexis has left
  281. alexis has joined
  282. stpeter has joined
  283. stpeter has left
  284. alexis has left
  285. alexis has joined
  286. lovetox has left
  287. lovetox has joined
  288. neshtaxmpp has joined
  289. lovetox has left
  290. murabito has left
  291. ikeameatballs has joined
  292. ikeameatballs has left
  293. neshtaxmpp has left
  294. adiaholic_ has left
  295. adiaholic_ has joined
  296. neshtaxmpp has joined
  297. mukt2 has joined
  298. neshtaxmpp has left
  299. lovetox has joined
  300. neshtaxmpp has joined
  301. Mikaela has left
  302. neshtaxmpp has left
  303. neshtaxmpp has joined
  304. Nano4BeingYou has joined
  305. murabito has joined
  306. floretta has joined
  307. Mikaela has joined
  308. Lance has joined
  309. bear has joined
  310. alameyo has joined
  311. Lance has left
  312. alexis has left
  313. lovetox has left
  314. lovetox has joined
  315. lovetox has left
  316. lovetox has joined
  317. DebXWoody has left
  318. mukt2 has left
  319. stpeter has joined
  320. stpeter has left
  321. Shell has joined
  322. lovetox has left
  323. lovetox has joined
  324. sonny has left
  325. sonny has joined
  326. mimi89999 has left
  327. Nano4BeingYou has left
  328. mimi89999 has joined
  329. Wojtek has joined
  330. eta btw, I've been thinking about ways to solve s2s connection issues (and push notifications) with MUC/XEP-0045 in ways that are mostly invisible to the clients participating in the MUC. I wrote up a 1,900 word very rough form of a XEP, and will probably look at converting that into a "proper" ProtoXEP soon :)
  331. eta the basic idea is to have the user's server perform MUC Self-Ping on the users' behalf and intelligently handle rejoining & history replay for the client, removing the need for the client to support such logic
  332. eta MUC servers must implement Unique and Stable Stanza IDs for the catchup to work, and are strongly advised to implement MAM and the optimization parts of MUC Self-Ping (but these aren't hard requirements)
  333. jonas’ eta, that doesn’t solve all of the issues
  334. jonas’ unfortunately
  335. moparisthebest eta: is that prosody mod_minimix ?
  336. jonas’ but it improves the situation
  337. eta jonas’, do tell
  338. eta what issues remain?
  339. eta moparisthebest, no, it's something different
  340. sonny has left
  341. jonas’ eta, ah, well, if you force servers to do MAM catchup and replay on behalf of their users, that’s good
  342. jonas’ otherwise this won’t quite work
  343. Zash jonas’, wanna write down all the issues on the wiki or such?
  344. jonas’ Zash, -EBUSY
  345. Zash -WSADFACE
  346. eta jonas’, so how I've spec'd it is that if your client conforms to this new XEP it just gets a "room oops happened, please do MAM resync" message and handles MAM itself
  347. jonas’ I just came back from the police department (which was already closed) and that kind of stole more of my time than I had budgeted for
  348. eta if your client doesn't advertise support, the server will do MAM for you and forward the messages
  349. jonas’ eta, ah, that’s not at all "invisible to clients" then
  350. jonas’ and not much of an improvement over self-ping, is it?
  351. jonas’ why not always let the server do MAM?
  352. eta jonas’, because paging
  353. jonas’ I don’t folloo
  354. jonas’ I don’t follow
  355. eta let's say you're disconnected for an extended period and miss out on like 1000 lines of history
  356. jonas’ yeah
  357. eta now the server will perform MAM to filter through that to see if any of those lines contain your nickname (for push purposes)
  358. eta but it won't want to buffer all 1000 and send them to you, because that drains the server's resources unnecessarily
  359. jonas’ but if a client doesn’t support it, the server still has to do it, right?
  360. eta yeah, so there's a limit
  361. jonas’ I don’t like that
  362. jonas’ don’t hide issues if you can’t hide them completely
  363. Zash Will perform MAM ... when?
  364. Zash Periodically?
  365. jonas’ Zash, after MUC self-ping errored
  366. eta Zash, upon reconnect
  367. Zash Polling? Hmmmm, not sure if like
  368. eta Zash, polling is required
  369. undefined has joined
  370. lovetox has left
  371. eta copy-paste
  372. jonas’ ok, well
  373. eta "Fundamentally, due to the way s2s links work (i.e. they get suspended on lack of activity), we'll always need to perform some kind of polling to make sure we're still in a MUC. Doing things like the server proactively saying it's back and clients should rejoin is *good*, but it'll never cover all cases due to the nature of networking. Therefore, it's probably a good idea to have a user-configurable polling interval that defaults to something like "10 minutes since last activity observed to/from the MUC" that people can tweak if they really care about knowing about disruption earlier."
  374. jonas’ I shall write stuff down later
  375. eta Zash, also this is a strict improvement upon the status quo, right
  376. jonas’ no
  377. eta clients currently have to poll anyways
  378. eta it's better if the server does it once than having all connected resources do it
  379. jonas’ if you hide message loss (the > 1000 messages situation), that’s not an improvement
  380. eta jonas’, it's not hidden
  381. jonas’ how is it not hidden?
  382. eta jonas’, you either support the XEP, in which case you get an explicit "do a MAM resync" notification, or you don't, in which case you just get kicked
  383. jonas’ if the client does not advertise support, servers will simply not send all of the history, but fake as if the client had been in the room all the time.
  384. eta no, they won't
  385. eta it kicks you in that case
  386. jonas’ hue?
  387. undefined has left
  388. jonas’ what about the MAM stuff you said earlier then?
  389. eta so it tries to do a catchup
  390. jonas’ ah, and if that’s too much, you get kicked
  391. jonas’ makes sense
  392. eta yeah
  393. eta and then you just do whatever retry logic you currently do
  394. sonny has joined
  395. eta (except it'll tell you that it kicked you for this reason, so you can instarejoin knowing that you're actually still in the MUC and just need to do MAM)
  396. Zash current retry logic: none
  397. MattJ Count me as interested, I've long thought we need to fix this on the server side, but haven't been able to put in the time to spec anything up
  398. eta I mean I'll write this up into a proper protoXEP at some point soon once I figure out how to do that
  399. eta the current doc is somewhat incoherent
  400. MattJ Step 1: obtaint markdown-to-xep
  401. MattJ Step 1: obtain markdown-to-xep
  402. eta if there are no glaring issues with it, I'll probably forge ahead with trying to write prosody modules
  403. eta oh yeah, the other thing I forgot to mention is
  404. jonas’ eta, ok, that makes much more sense.
  405. eta this XEP has bookmarks2 as a hard dependency
  406. MattJ :)
  407. jonas’ eta, I’ll be happy to help you through the XEP process -- let me know if you need any technical help in getting this in the right format
  408. jonas’ speaking of right format: MattJ, do you have it on your todo list to clean up the new mam-forked XEPs?
  409. eta basically the flow is without a bookmarks2 entry for a room, you don't get any server fanciness
  410. MattJ jonas’, what needs cleanup specifically?
  411. eta so to engage the fanciness, you join normally, then add a bookmarks2 entry
  412. jonas’ MattJ, they are lacking some RECOMMENDED/REQUIRED sections IIRC
  413. eta (at which point the fun state machine specified in the XEP kicks into action and joins another resource that the server controls)
  414. MattJ Ok, that wasn't on my todo but I can look into it
  415. MattJ Probably not for a couple of weeks though
  416. jonas’ MattJ, I see, thanks nontheless
  417. jonas’ nothing too urgent anyways
  418. eta once the fun durable mode is engaged, you never get kicked out of the XEP unless (a) someone actually /kick-ed you or (b) the server gave up retrying to get you back in (usually after like a day)
  419. eta once the fun durable mode is engaged, you never get kicked out of the MUC unless (a) someone actually /kick-ed you or (b) the server gave up retrying to get you back in (usually after like a day)
  420. eta in both cases, something is shoved in the bookmarks2 entry to say "this MUC is broken", which disengages the fanciness until you remove that by manually rejoining and re-adding the bookmarks2 entry
  421. jonas’ eta, I’m sure I can read that in the document later on, but what happens if the user sends a message while they are not fully connected?
  422. eta jonas’, what do you mean by "not fully connected"
  423. jonas’ eta, the server is currently in the process of retrying to get you connected
  424. jonas’ eta, the server is currently in the process of retrying to get you connected to the MUC
  425. eta jonas’, you get an error of type "wait"
  426. eta the one smoking gun might be if current clients decide to rejoin the MUC in this case, which would suck a lot
  427. eta well, actually, no it really wouldnt'
  428. eta well, actually, no it really wouldn't
  429. jonas’ that depends on the specific condition, but a server could easily eat rejoins away in such cases.
  430. alexis has joined
  431. adiaholic_ has left
  432. adiaholic_ has joined
  433. eta jonas’, it kinda does
  434. eta if you attempt to rejoin whilst in the `Reconnecting` state, what happens is it marks you as "waiting to rejoin", eats your presence, and sends you a "experiencing connection issues" message (for conformant clients)
  435. eta if it manages to get you to join, it forwards you the recipient list and then does the "intelligent catchup" process
  436. eta actually wait, no, it wouldn't do that because you'd be expected to do MAM anyway, so scratch that
  437. MattJ Bonus points for a state diagram :)
  438. eta https://theta.eu.org/xmpp/upload/3OHj4KIs8L9tD3JW/7543125f-08d5-411e-9732-722daa038bd5.png
  439. eta MattJ, 👀️
  440. MattJ Bonus points awarded, achievement unlocked!
  441. eta the nice thing is, if this XEP actually becomes a thing the UX will probably be better than something like matrix
  442. eta because you'll get an explicit "experiencing connection issues" display in your client's UI
  443. eta (which I think is a lot nicer than just sending and not getting any messages back until s2s reconnects and everything floods back in)
  444. eta also, there's no requirement to implement a bloody complicated MIX server
  445. eta like all you need on the conference service side of things is MUC, unique and stable stanza IDs, (MUC Self-Ping optimization, MAM)
  446. jonas’ it makes MUC better, but it doesn’t solve other problems of MUC ;)
  447. eta so I can write my transports and have them work :p
  448. jonas’ in fact, this is something MIX also still needs to solve, so I think that work is valuable
  449. eta jonas’, what are the other problems though?!
  450. eta oh, MIX
  451. eta nvm
  452. jonas’ no, your proposed thing
  453. eta okay, what other problems are there
  454. jonas’ try to address a specific resource of a participant in a MUC
  455. eta what's the usecase for that?
  456. jonas’ the entire multi-session nick hack which isn’t written down anywhere normative
  457. jonas’ eta, sending IQs
  458. eta ah
  459. eta oh yeah, re nicks, you can't specify one on join any more
  460. eta it forces it to be your bookmarks2 one if you have one in bookmarks2
  461. jonas’ I need to step away for a bit, I’m having a hard time to concentrate on anything
  462. eta sure
  463. eta I take your point that there are other problems with MUC though :p
  464. eta (but there can be more specs for that)
  465. stpeter has joined
  466. stpeter has left
  467. sonny has left
  468. sonny has joined
  469. mukt2 has joined
  470. Wojtek has left
  471. Lance has joined
  472. larma has left
  473. larma has joined
  474. sonny has left
  475. eevvoor has left
  476. edhelas there's always other problems with MUC :p
  477. eevvoor has joined
  478. Daniel What do we need muc for anyway?
  479. MattJ Are you going to say... XEP-0033? :)
  480. Andrzej has joined
  481. Zash YES
  482. Daniel For smaller groups I can certainly see the appeal
  483. Andrzej has left
  484. Andrzej has joined
  485. Zash Would be interesting to see that
  486. mukt2 has left
  487. lorddavidiii has left
  488. krauq has left
  489. krauq has joined
  490. mimi89999 has left
  491. edhelas chatrooms without MUC 🤔
  492. edhelas it's a bit the difference between mailing lists and chain-answered-emails
  493. Zash exactly that
  494. moparisthebest a, somewhat major server implemented XEP-0033 recently (jmp.chat/cheogram.com) but no support in Conversations (or most/all clients?) yet
  495. Lance has left
  496. eta ah yes
  497. eta group emails
  498. eta that very functional solution that never results in people getting confused ever
  499. edhelas can't wait for XMPP Chatrooms over SMTP
  500. Holger From 0313's changelog: > Split preferences protocol into a separate document Which document did they go into?
  501. Zash Holger: New ones, via the inbox. (Council voted it)
  502. Holger Ah, thx.
  503. Zash Dunno if Editor has processed them yet
  504. lovetox has joined
  505. jonas’ they haven’t been voted into existence yet
  506. jonas’ Zash is on-list on them
  507. Zash Oh right
  508. jonas’ *hinthint* if you vote properly within the next few minutes, they might make today’s editor window *hinthint*
  509. Lance has joined
  510. mimi89999 has joined
  511. bear has left
  512. neshtaxmpp has left
  513. marc has left
  514. marc has joined
  515. sonny has joined
  516. govanify has left
  517. govanify has joined
  518. DebXWoody has joined
  519. winfried has left
  520. winfried has joined
  521. DebXWoody has left
  522. sonny has left
  523. sonny has joined
  524. DebXWoody has joined
  525. lovetox has left
  526. sonny has left
  527. Steve Kille has left
  528. amuza@riseup.net has joined
  529. marc has left
  530. bear has joined
  531. sonny has joined
  532. winfried has left
  533. winfried has joined
  534. Steve Kille has joined
  535. jonas’ has left
  536. jonas’ has joined
  537. sonny has left
  538. sonny has joined
  539. Wojtek has joined
  540. alexis has left
  541. sonny has left
  542. marc has joined
  543. Wojtek has left
  544. sonny has joined
  545. krauq has left
  546. Wojtek has joined
  547. neshtaxmpp has joined
  548. sonny has left
  549. Dele Olajide has left
  550. krauq has joined
  551. alexis has joined
  552. neshtaxmpp has left
  553. lovetox has joined
  554. mukt2 has joined
  555. sonny has joined
  556. Wojtek eta - out of curiosity - why not push for MIX addotion, instaed of putting another patch on a MUC?
  557. eta Wojtek, I think MIX is overengineered
  558. Wojtek and yet another patch on (kinda broken) MUC is better?
  559. moparisthebest only one can be used without all servers upgrading at once
  560. eta ^
  561. eta MIX isn't backwards-compatible with MUC
  562. eta MUC is a very simple standard, and I like that
  563. jonas’ Wojtek, MIX also has exactly the same issue
  564. jonas’ (not quite exactly, but well)
  565. alexis has left
  566. jonas’ eta, MIX does have a MUC compatibility layer which I’d deem "good enough" for a soft transition
  567. eta jonas’, okay, but also
  568. Wojtek eta: XEP-0408?
  569. eta MIX creates an ecosystem split where half the users still have a crap experience
  570. moparisthebest in tigase's defense they *actually* put in the work and seem to have made a seemingly working implementation, I'll have to update https://www.moparisthebest.com/mix/
  571. eta even with a compatibility layer
  572. jonas’ eta, that’s life.
  573. eta jonas’, no, but it doesn't have to be this way
  574. krauq has left
  575. krauq has joined
  576. jonas’ eta, yes, hence I’d actually suggest putting energy into MIX -- but I don’t blame *you*, because the work you’re doing we need for MIX, too
  577. jonas’ we discussed about that in this very room just the other day
  578. eta yeah, I saw :)
  579. eta Wojtek, okay, point taken
  580. Wojtek eta, MUC may be a simple standard yet time and time again there are problems with it and (weird ways) to fix that...
  581. jonas’ MUC is by no means a simple standard
  582. Wojtek @jonas’ what same issue?
  583. jonas’ Wojtek, dealing with s2s outages
  584. jonas’ clients need to know about it to sync their archive with the remote MAM (if we go for remote-archives-only) and/or servers need to sync the user’s MAM and do magic if we allow for user-local archives
  585. Andrzej eta, MUC is simple? try to make it scalable, consistent, etc. you will learn that it is not so simple
  586. eta it's simple if you're a transport developer :>
  587. jonas’ eta, MUC is a very long document as it stands already. Aside from that, there are hacks upon hacks which aren’t even *documented* there (like the whole multi-session nick stuff, or IQ routing in MUC in general)
  588. Wojtek @jonas’ if we *don't* allow you mean? beacause with local archive each time there is a new message it's delivered to local archive which eliminates issue with s2s outages
  589. eta and MIX solves this problem?
  590. jonas’ Wojtek, no, if we *do* allow.
  591. jonas’ Wojtek, that’s not correct. what if the s2s between MIX and user server is down?
  592. jonas’ eta, yes, because MSN (multi-session nicks) as well as IQ routing (by having each resource addressable) are both well-defined in MIX
  593. Wojtek then your local archive won't get the message, but you also won't be able to query it ;-)
  594. jonas’ Wojtek, yeah, so you have message loss (bad)
  595. Wojtek but I get it now
  596. Wojtek still, I don't recall fallback to query remote server if `urn:xmpp:mix:pam:2#archive` was advertised
  597. jonas’ it’s a rather tricky thing to solve. It’s not just that servers do MAM syncs among each other. To ensure correct order of message delivery, servers will also have to do replay from MAM as well as queue "live" messages
  598. jonas’ Wojtek, sorry, I lack context, what does `urn:xmpp:mix:pam:2#archive` mean and who would fallback to what?
  599. Wojtek "Archive of MIX channel messages MAY be performed by the participant's server. When this is done, the capability is advertized to MIX clients using the 'urn:xmpp:mix:pam:2#archive' feature. If archive is provided it **MUST always be used**, so that where a message is sent to the participant's server and discarded because there are no active clients, it will still be archived. This means that when archiving is provided, the messages will be available in the local archive and can be picked up by clients when they come online. "
  600. sonny has left
  601. Andrzej @jonas’ simples solution for s2s issues would be stream management over s2s, or force MIX to add stable-id of a last message which was sent, so that users server MAM could fill that and deliver "lost" messages as a normal MIX message with `<delay/>` element in them
  602. eta Andrzej, my proposed solution does the stable-id thing, sorta
  603. jonas’ Andrzej, no, stream-management is not sufficient
  604. jonas’ stream management will have limits because servers won’t queue forever.
  605. jonas’ Wojtek, the text you quoted is exactly the problematic part. It claims that the user’s archive is the gold standard, but in fact it’ll have gaps without additional measures.
  606. jonas’ Andrzej, what you propose is one of the ways to do it, but then the user server becomes quite complex. It needs to do MAM queries, backfill the local archive (which it may not be able to even to, because it’d have to insert into MAM at an earlier point, violating one of the MAM guarantees!), it has to buffer all "live" messages from the MIX to be able to replay MAM first in order to provide in-order delivery of all stanzas from the MIX.
  607. jonas’ and it needs to do that across all pubsub-nodes the user has subscribed to on the MIX, too
  608. Andrzej @jonas’ we will have gaps, but it was discussed at the summit and the simples solution to add to the message stable-id of a previous message was suggested (by Kev if I recall)
  609. jonas’ and then the client would be responsible for filling the gap in its local archive?
  610. Andrzej @jonas’ why it needs to insert those new entries in the past? just add them at the end with `<delay/>` element in them
  611. mukt2 has left
  612. Andrzej then MAM would be just log of a messages which you have received and delay timestamps would allow clients to assign those messages in proper order
  613. jonas’ which clients don’t do generally
  614. jonas’ and I’m also not sure if that’d be acceptable
  615. eta Wojtek, XEP-0408 doesn't really say much
  616. Wojtek I know that it's the problem, but it says that if there is local archive the user *MUST* use it (so no queryign from MIX MAM)
  617. jonas’ Wojtek, hence the debate about that particular text :)
  618. jonas’ eta, needs implementations. but conceptually, it can easily work.
  619. eta okay, so MIX removes some hacks that you need to make MUC work
  620. eta I mean I don't think the problems with MUC are bad enough to justify scrapping it entirely
  621. eta or rather, to justify the ecosystem split having 2 competing standards would cause
  622. jonas’ that is your opinion and you can have it :)
  623. Wojtek :-)
  624. eta indeed!
  625. eta if people want to implement MIX though, go ahead! part of why XMPP is great is precisely that people can have different ideas
  626. Wojtek and having many things of doing something is kinda "XMPP way" ;-)
  627. Andrzej eta, for mobile devices (ie. iOS) using MUC requires a lot of hacks
  628. jonas’ though I *do* find it amusing, that the often-complained-about required user-server support for MIX is now coming for MUC ;)
  629. Wojtek for me it seems that MUC is basically mutating into MIX, in stages...
  630. eta Andrzej, are a lot of hacks bad though? :p
  631. Wojtek YES :-P
  632. eta Andrzej, I mean the followup XEP I was going to write is a spec for doing push notifications
  633. eta if the server has a resource constantly joined to the MUC, it can receive messages, match them against a set of rules / regexes, and then forward the message to the client
  634. Andrzej eta, with filtering I hope?
  635. jonas’ eta, what about E2EE?
  636. eta Andrzej, yeah, I want to essentially rip off matrix's push rules system
  637. mukt2 has joined
  638. eta jonas’, you'd have to either (a) send every message or (b) include a separate <mentions/> element or w/e
  639. eta and deal with the privacy implications of (b)
  640. Wojtek > if the server has a resource constantly joined to the MUC, it can receive messages, match them against a set of rules / regexes, and then forward the message to the client so, basically permanent member subscription? like in... MIX? ;-)
  641. eta although *no* messenger can deal with the e2ee problem :)
  642. Andrzej eta, if you want to write something like that please check https://xeps.tigase.net//docs/push-notifications/filters as this could be useful
  643. lskdjf has left
  644. eta Andrzej, issue I have with that is, what does "mentioned" mean
  645. eta do I get a notification any time someone says "details"? ;P
  646. Mikaela has left
  647. moparisthebest it means you can silently eat the mobile battery of everyone you are in a channel with of course :)
  648. lskdjf has joined
  649. Andrzej mentioned means that your nickname was mentioned in a message
  650. eta Andrzej, no, sure, but how are you matching
  651. eta if your test is `string.contains(nick)` it's going to break for me :)
  652. Andrzej contains and check if before and after there is no alphanumeric character
  653. eta ah, good
  654. eta that aside, though, yeah, that XEP looks very similar
  655. eta Wojtek, yeah, exactly like in MIX :p
  656. Andrzej I was suggesting to consider just requirements from our XEP (and syntax if that would be useful)
  657. eta like I don't think MUC's current semantics are ideal at all
  658. eta Wojtek, the difference is my proposed XEP doesn't require the MUC service to support much more
  659. Andrzej but requires local server to keep a persistent session for you
  660. eta yeah
  661. Andrzej with S2S issues, reconnections, MUC restarts, etc. this can be problematic
  662. eta Andrzej, that's what the whole XEP is about
  663. eta you could even extend it to have local archiving semantics similar to your MIX implementation
  664. eta it just won't do that initially because that's a bit of a hard sell for some server operators
  665. eta generally my problem with MIX is it doesn't really obey Postel's Law (https://en.wikipedia.org/wiki/Robustness_principle): it requires there to be a shiny new MIX service out there to get any of the benefits
  666. eta whereas trying to patch MUC on the server side will improve experience for ~90% of users without them having to change client or MUC service
  667. eta that said, for non federating environments, MIX is unquestionably better
  668. Mikaela has joined
  669. Wojtek and then you end up in a situaiton when some server support that and some not and some user will have different experience than others... and then everyone complain again that it's impossible to have more-or-less consisten experience with XMPP and jump on the matrix badwagon
  670. moparisthebest not sure that's the right law, it requires a flag-day, which never ends up happening
  671. debacle has left
  672. moparisthebest https://en.wikipedia.org/wiki/Flag_day_(computing)
  673. eta Wojtek: well no, you make it part of the compliance tester
  674. eta also I mean, MIX has the same issue!
  675. eta (in fact it's worse)
  676. moparisthebest huh TIL that flag day was also Postel's https://tools.ietf.org/html/rfc801 :)
  677. sonny has joined
  678. Wojtek compliance server is run by a private person and not XSF… and it's kinda arbitrary - it requires XEP-0215 yet compliance suite doesn't mention this particular XEP...
  679. jonas’ it also doesn’t say XMPP or XSF compliance ;)
  680. Daniel The compliance tester is just 4 month ahead of time
  681. eta Wojtek: well, I mean I'd be interested to hear your solution here
  682. eta fragmentation is definitely an issue, but I'm not sure there is an obvious magic bullet
  683. mukt2 has left
  684. lorddavidiii has joined
  685. mukt2 has joined
  686. sonny has left
  687. neshtaxmpp has joined
  688. papatutuwawa has left
  689. papatutuwawa has joined
  690. debacle has joined
  691. lovetox eta, the idea to make it dependend on bookmarks2 seems like a sure way implementation gets delayed very long
  692. lovetox there is no server that supports bookmarks2 in a way that client would want to use it
  693. eta lovetox: but bookmarks2 defines a private XML conversion path
  694. eta lovetox: oh? what are the issues with bookmarks2?
  695. lovetox hm? i didnt say there where issues with bookmarks2, only that no server supports it
  696. eta ah
  697. lovetox and bookmarks2 in turn depends on other XEPs that servers dont support
  698. jonas’ does it?
  699. lovetox like the recent "max" change in pubsub
  700. Wojtek > it also doesn’t say XMPP or XSF compliance ;) yet it seems that everyone considers it as such ;-) and eta proposed using it as a mean to promote XEPs :-)
  701. krauq has left
  702. Wojtek > The compliance tester is just 4 month ahead of time hence "arbitrary" - you can do with compliance tester whatever you want as it's not XMPP/XSF :-)
  703. eta Wojtek: hey, feel free to make a Siskin compliance tester :p
  704. Wojtek Siskin is client, not server ;-)
  705. eta Wojtek: no, but the other tester is "the Conversations compliance tester", because it tests whether the server works well with Conversations
  706. Zash "A thing that tests whether servers are tuned for Siskin"
  707. eta Wojtek: like, more compliance testers would be great!
  708. eta I'm not saying Daniel's one has to be the One True Tester
  709. Wojtek eta yet you proposed to promote certain specification via compliance tester
  710. Andrzej so is it really a "compliance tester" or "compatibility tester"?
  711. krauq has joined
  712. Yagiza has left
  713. eta Wojtek: well, okay, that's assuming Conversations uses said specification
  714. Zash Andrzej: I was just going to say ... the later.
  715. eta Wojtek: perhaps I'm a bit too optimistic in that regard :p
  716. Zash You could even fork it, tune it to your own clients requirements.
  717. sonny has joined
  718. sonny has left
  719. Zash Or make an ultimate every client compatibility tester
  720. Andrzej has left
  721. Andrzej has joined
  722. eta Wojtek: my point is just that the conversations compliance tester seemed to do a relatively okay job of driving AV call adoption by servers
  723. Zash (along with a client needing it and users wanting the call feature)
  724. eta true :p
  725. alameyo has left
  726. alameyo has joined
  727. sonny has joined
  728. sonny has left
  729. eta curses at xef/xeps
  730. eta > element header: validity error : Element header content does not follow the DTD, expecting (title , abstract , legal , number , status , lastcall* , interim* , type , sig , approver* , dependencies , supersedes , supersededby , shortname , schemaloc* , registry? , discuss? , expires? , author+ , revision+ , councilnote?), got (title abstract legal number status type sig approver dependencies supersedes supersededby author shortname revision ) </header>
  731. Andrzej has left
  732. eta oh my god
  733. eta they have to be in the correct order
  734. eta that's ridiculous
  735. xsf has left
  736. xsf has joined
  737. bear has left
  738. sonny has joined
  739. Zash Praise schema validation!
  740. jonas’ eta, I recommend using xep-template.xml
  741. eta jonas’, ...now you tell me
  742. jonas’ I told you to ask :D
  743. eta copies & pastes
  744. eta I've already written an intro, which is good
  745. jonas’ eta, next time, ping me directly, I’m happy to help before things become an annoyance
  746. eta not having to refer to XEP-0001 all the damn time is nice though :)
  747. Zash But have you considered implementing an elaborate document processing pipeline that turns plain text into xep-xml?!
  748. jonas’ GPT-3?
  749. Zash Oh no
  750. Andrzej has joined
  751. jonas’ hmmm
  752. moparisthebest *spits out machine generated XEP* hmm looks alot like matrix
  753. Zash You're holding it upsidedown?
  754. jonas’ requests OpenAI beta access
  755. moparisthebest I turned it upside down and now it just looks like a blockchain
  756. jonas’ let’s see if they give it to me
  757. sonny has left
  758. sonny has joined
  759. Alex lets kick off our member meeting
  760. Zash !
  761. moparisthebest \o/
  762. Alex bangs the gavel
  763. jonas’ oh right! and I’m even around!
  764. Alex here is our Agenda for today: https://wiki.xmpp.org/web/Meeting-Minutes-2020-08-25
  765. Alex 1) Call for Quorum
  766. Alex as you can see 34 members voted via Memberbot, so we have a quorum
  767. Alex 2) Items Subject to a Vote
  768. Alex new and returning members, you can see all applicants on this page: https://wiki.xmpp.org/web/Membership_Applications_Q3_2020
  769. Alex 3) Opportunity for XSF Members to Vote in the Meeting
  770. Alex anyone here who has not voted yet and wants to do so now?
  771. sonny has left
  772. Alex looks like none
  773. Alex I will shutdown the bot then and start working on the results
  774. Andrzej has left
  775. sonny has joined
  776. lovetox has left
  777. lovetox has joined
  778. Guus 🥁
  779. thorsten has left
  780. Alex 4) Announcement of Voting Results
  781. Alex when you reload the page at: https://wiki.xmpp.org/web/Meeting-Minutes-2020-08-25#Announcement_of_Voting_Results you can see the results
  782. Alex all new and returning members are accepted. Congrats to everone, and welcome to our new members
  783. stpeter has joined
  784. stpeter has left
  785. Alex 5) ny Other Business?
  786. jonas’ None from me
  787. Guus None here
  788. jonas’ except: congratulations to everyone and thanks to our Secretary for the duty
  789. Alex 6) Formal Adjournment
  790. Alex I motion that we adjourn
  791. Zash +1
  792. Alex bangs the gavel
  793. Alex thanks everyone
  794. Guus Thanks Alex !
  795. moparisthebest 🔨️ thanks Alex
  796. Zash Thanks Alex. Congrats to all.
  797. Alex will update the memberlist and mailing list tomorrow morning
  798. Alex Thanks to Dave for updating Memberbot. Was running very smoothly this time ;-)
  799. sonny has left
  800. sonny has joined
  801. lovetox has left
  802. jonas’ has left
  803. winfried has left
  804. winfried has joined
  805. Andrzej has joined
  806. sonny has left
  807. eevvoor has left
  808. bear has joined
  809. sonny has joined
  810. DebXWoody has left
  811. jonas’ has joined
  812. neshtaxmpp has left
  813. winfried has left
  814. winfried has joined
  815. sonny has left
  816. Andrzej has left
  817. adiaholic_ has left
  818. adiaholic_ has joined
  819. Andrzej has joined
  820. Andrzej has left
  821. Andrzej has joined
  822. adiaholic_ has left
  823. adiaholic_ has joined
  824. Nekit has joined
  825. jonas’ has left
  826. jonas’ has joined
  827. marc has left
  828. jonas’ Special congrats to (!)!XSF_Martin and Holger :)
  829. Martin Thanks 😃
  830. Martin has left
  831. MattJ The irony is that the original "XSF Martin" that caused you to switch to that nick... I'm pretty sure he was never a member of the XSF :)
  832. jonas’ not?
  833. jonas’ but he was in board, right?
  834. eta . o O ( I should join the XSF )
  835. MattJ jonas’: yes
  836. jonas’ ok, that explains my assumptions (and I suppose also mdosch’s)
  837. eta how do clients typically advertise support for some XEP?
  838. jonas’ eta, XEP-0030
  839. APach has left
  840. eta jonas’, right, so the server is expected to do the whole entity caps dance and disco#info query it?
  841. jonas’ yes, servers do that anyways tho
  842. jonas’ for PEP
  843. eta oh, okay, so that's something we can build on
  844. jonas’ so just state that the client has to implement XEP-0115 and go ahead
  845. eta adds more dependencies
  846. marc has joined
  847. sonny has joined
  848. sonny has left
  849. thorsten has joined
  850. thorsten has left
  851. Andrzej has left
  852. thorsten has joined
  853. sonny has joined
  854. sonny has left
  855. eta right, after 20 minutes of XML wrangling I've managed to make a TOC
  856. eta actual spec content still to follow >_>
  857. eta (well, there's an intro, requirements, and MUC failure modes section)
  858. Andrzej has joined
  859. sonny has joined
  860. neshtaxmpp has joined
  861. marc has left
  862. mukt2 has left
  863. lovetox has joined
  864. sonny has left
  865. werdan has joined
  866. sonny has joined
  867. neshtaxmpp has left
  868. sonny has left
  869. sonny has joined
  870. sonny has left
  871. lorddavidiii has left
  872. lorddavidiii has joined
  873. krauq has left
  874. krauq has joined
  875. Mikaela has left
  876. Andrzej has left
  877. alexis has joined
  878. goffi has left
  879. alexis has left
  880. werdan has left
  881. neshtaxmpp has joined
  882. alexis has joined
  883. sonny has joined
  884. alexis has left
  885. sonny has left
  886. lovetox has left
  887. debacle has left
  888. Tobias has left
  889. neshtaxmpp has left
  890. lorddavidiii has left
  891. karoshi has left
  892. sonny has joined
  893. Andrzej has joined
  894. winfried has left
  895. winfried has joined
  896. neshtaxmpp has joined
  897. winfried has left
  898. winfried has joined
  899. sonny has left
  900. sonny has joined
  901. sonny has left
  902. sonny has joined
  903. alexis has joined
  904. sonny has left
  905. dwd has joined
  906. bear has left
  907. alexis has left
  908. mukt2 has joined
  909. neshtaxmpp has left
  910. mukt2 has left
  911. thorsten has left
  912. sonny has joined
  913. emus has left
  914. emus has joined
  915. alexis has joined
  916. Andrzej has left
  917. Seve has left
  918. alexis has left
  919. alexis has joined
  920. Daniel has left
  921. Andrzej has joined
  922. Daniel has joined
  923. alexis has left
  924. jcbrand has left
  925. Andrzej has left
  926. Andrzej has joined
  927. Lance has left
  928. papatutuwawa has left
  929. Wojtek has left
  930. Daniel has left
  931. Daniel has joined
  932. Andrzej has left
  933. bear has joined
  934. mukt2 has joined