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