XSF Discussion - 2021-03-31


  1. LNJ has left
  2. adiaholic has left
  3. rmlang has left
  4. lskdjf has left
  5. rmlang has joined
  6. rmlang has left
  7. govanify has left
  8. govanify has joined
  9. rmlang has joined
  10. rmlang has left
  11. rmlang has joined
  12. rmlang has left
  13. rmlang has joined
  14. stp has left
  15. rmlang has left
  16. rmlang has joined
  17. rmlang has left
  18. rmlang has joined
  19. Andrzej has left
  20. Andrzej has joined
  21. adiaholic has joined
  22. adiaholic has left
  23. paul has left
  24. rmlang has left
  25. adiaholic has joined
  26. rmlang has joined
  27. ajeremias has left
  28. adiaholic has left
  29. adiaholic has joined
  30. Lance has left
  31. adiaholic has left
  32. neshtaxmpp has joined
  33. adiaholic has joined
  34. neshtaxmpp has left
  35. BASSGOD has left
  36. adiaholic has left
  37. Andrzej has left
  38. Andrzej has joined
  39. BASSGOD has joined
  40. adiaholic has joined
  41. govanify has left
  42. govanify has joined
  43. millesimus has left
  44. adiaholic has left
  45. eta has left
  46. alameyo has left
  47. millesimus has joined
  48. alameyo has joined
  49. Andrzej has left
  50. BASSGOD has left
  51. millesimus has left
  52. BASSGOD has joined
  53. adiaholic has joined
  54. stp has joined
  55. govanify has left
  56. govanify has joined
  57. Syndace has left
  58. millesimus has joined
  59. Syndace has joined
  60. govanify has left
  61. govanify has joined
  62. BASSGOD has left
  63. BASSGOD has joined
  64. adiaholic has left
  65. BASSGOD has left
  66. stp has left
  67. adiaholic has joined
  68. stp has joined
  69. govanify has left
  70. govanify has joined
  71. BASSGOD has joined
  72. eric has left
  73. eric has joined
  74. govanify has left
  75. govanify has joined
  76. BASSGOD has left
  77. arc has left
  78. arc has joined
  79. arc has left
  80. arc has joined
  81. Yagiza has joined
  82. neshtaxmpp has joined
  83. BASSGOD has joined
  84. Zash has left
  85. serge90 has joined
  86. arc has left
  87. arc has joined
  88. arc has left
  89. arc has joined
  90. neshtaxmpp has left
  91. BASSGOD has left
  92. ti_gj06 has joined
  93. Andrzej has joined
  94. BASSGOD has joined
  95. karoshi has joined
  96. stp has left
  97. BASSGOD has left
  98. adiaholic has left
  99. adiaholic has joined
  100. BASSGOD has joined
  101. adiaholic has left
  102. chronosx88 has left
  103. rmlang has left
  104. adiaholic has joined
  105. Andrzej has left
  106. govanify has left
  107. govanify has joined
  108. BASSGOD has left
  109. adiaholic has left
  110. adiaholic has joined
  111. arc has left
  112. arc has joined
  113. BASSGOD has joined
  114. ti_gj06 has left
  115. adiaholic has left
  116. emus has joined
  117. adiaholic has joined
  118. govanify has left
  119. govanify has joined
  120. david has left
  121. arc has left
  122. arc has joined
  123. david has joined
  124. aidalgol has left
  125. arc has left
  126. arc has joined
  127. adiaholic has left
  128. govanify has left
  129. govanify has joined
  130. dwd has joined
  131. adiaholic has joined
  132. ti_gj06 has joined
  133. Tobias has joined
  134. paul has joined
  135. andy has joined
  136. millesimus has left
  137. millesimus has joined
  138. govanify has left
  139. govanify has joined
  140. Andrzej has joined
  141. arc has left
  142. neshtaxmpp has joined
  143. wurstsalat has joined
  144. govanify has left
  145. govanify has joined
  146. Andrzej has left
  147. Andrzej has joined
  148. BASSGOD has left
  149. BASSGOD has joined
  150. menel has joined
  151. aidalgol has joined
  152. nyco has joined
  153. nyco has left
  154. nyco has joined
  155. BASSGOD has left
  156. nyco has left
  157. goffi has joined
  158. Andrzej has left
  159. BASSGOD has joined
  160. Zash has joined
  161. mathijs has left
  162. mathijs has joined
  163. Andrzej has joined
  164. Lance has joined
  165. croax has joined
  166. neshtaxmpp has left
  167. pjn has left
  168. pjn has joined
  169. Andrzej has left
  170. adiaholic has left
  171. adiaholic has joined
  172. BASSGOD has left
  173. adiaholic has left
  174. xecks has joined
  175. adiaholic has joined
  176. millesimus has left
  177. BASSGOD has joined
  178. chronosx88 has joined
  179. bean has joined
  180. peetah has left
  181. peetah has joined
  182. millesimus has joined
  183. lovetox has left
  184. lovetox has joined
  185. LNJ has joined
  186. emus has left
  187. Andrzej has joined
  188. ajeremias has joined
  189. debacle has joined
  190. alameyo has left
  191. adiaholic has left
  192. millesimus has left
  193. adiaholic has joined
  194. BASSGOD has left
  195. lskdjf has joined
  196. millesimus has joined
  197. adiaholic has left
  198. millesimus has left
  199. BASSGOD has joined
  200. adiaholic has joined
  201. chronosx88 has left
  202. chronosx88 has joined
  203. jcbrand Has anyone here though about or come up with a way to identify messages from bots? Seems like one can just include a special tag and namespace for it. Is there anything like that in the wild already?
  204. jonas’ jcbrand, bots should publish a bot identity in disco#info and clients should use that
  205. jonas’ jcbrand, https://xmpp.org/registrar/disco-categories.html#client
  206. jcbrand so you should send a disco query for every single message in a MUC?
  207. jcbrand not really practical in certain use-cases
  208. jonas’ '115 caches
  209. jonas’ or if that’s not feasible because MUC, you can just query when the participant enters the MUC
  210. jonas’ and cache the information until they leave it
  211. jcbrand You can really see that XMPP was designed without ever thinking about web clients
  212. jonas’ attaching such metadata to each and every message is incredible overhead
  213. Zash Hats
  214. jcbrand oh, I like that thanks Zash
  215. jcbrand We already have hats
  216. Zash <hat>🤖️</hat>
  217. jcbrand problem solved
  218. Zash 😀
  219. jonas’ ... *sigh*
  220. jcbrand lol
  221. jonas’ web making everything terrible again.
  222. jcbrand enjoy your ivory tower
  223. jonas’ jcbrand, to be clear, I’m not blaming *you*
  224. jonas’ I’m blaming the web.
  225. millesimus has joined
  226. flow jcbrand, out of curiosity: why doesn't the approach suggested by jonas’ work for web clients?
  227. Zash jcbrand, isn't this MUC being web-unfriendly rather than XMPP itself?
  228. jcbrand jonas’ yeah sorry, I don't want to be hostile, but the anti-web attitude in the XMPP community does grate a little sometimes. No big deal tho
  229. adiaholic has left
  230. jonas’ jcbrand, fair. Let me state for the record that I am really glad for your work on converse.js, because despite the web being terrible, XMPP-IM needs a web client which is *not* terrible and you seem to be doing a fairly great job at that.
  231. adiaholic has joined
  232. Ge0rG what jonas’ said, 👍 for jcbrand
  233. jcbrand aw shucks, thanks guys
  234. Zash It's really the anti-everything-except-the-web attitude of the web that irks me.
  235. jcbrand Sure, I get that
  236. jonas’ web-pacman
  237. jonas’ web-pacman.gif
  238. ajeremias has left
  239. jcbrand flow: my knee-jerk response is that in various situations you can't cache/store everything across sessions like you can with desktop clients
  240. Zash jonas’, now I need you to drop everything and make that gif. you may edit the systemd-om-nom-nom.gif 😉
  241. jonas’ jcbrand, but hypothetically, if you did the disco#info on the first message from a participant and cached that for a session (or until that participant leaves), that would be feasible and good enough, wouldn’t it?
  242. marek has left
  243. marek has joined
  244. jcbrand jonas’: yes, but that is then not XEP-0115 compatible right?
  245. jonas’ I’m not sure '115 even works in MUCs
  246. Zash In theory you could cache caps-hash → disco response forever
  247. jonas’ if it did, you could sometimes skip disco#info lookups if your session has already seen the hash though if '115 worked
  248. jcbrand Yes, but in web clients you can't
  249. jcbrand Zash: Yes, but in web clients you can't
  250. jonas’ even that can do a lot (e.g. if the bot only hops into the room briefly and you don’t know the real JID)
  251. jcbrand You say that including a tag is wasteful, but in a MUC with an occasional bot post and lots of posts by other users, it seems wasteful to me to do a disco-info for each new poster
  252. jcbrand it could be a tag on the presence, not the messages themselves
  253. jcbrand But it's ok, the hats thing will work for my current use-case and for the open Jabber network doing a disco query for each new occupant is probably also fine
  254. jcbrand not each new occupant but each new message author
  255. flow jcbrand, you probably can re-use the disco#info information for other purposes too, so I am not sure if it is that wasteful
  256. jcbrand Unless you want to identify bots in your occupants list...
  257. millesimus has left
  258. millesimus has joined
  259. jcbrand seems very chatty to me. On a desktop client you can cache all this fairly aggressively, but on web you need to do potentially hundreds or thousands of disco info queries for every session
  260. jcbrand On web there is IndexedDB which doesn't have a size limit, so in theory you can use that and then your webapp is more like a desktop app, but having integrated that into Converse (via localForage), I've seen that writes are suuuuper slow.
  261. jcbrand And you can't use IndexedDB in all cases
  262. jcbrand I have some ideas on how to improve performance on Converse (basically batching writes), but haven't had the time to iron out the kinks
  263. adiaholic has left
  264. Ge0rG jcbrand: what about localStorage?
  265. jcbrand localStorage has a 5MB limit, so if you have lots of MUCs it fills up pretty quickly
  266. jcbrand Now you could regularly delete older messages, but then you lose your OMEMO history
  267. jcbrand So far that has made me reluctant to aggressively get rid of older messages
  268. Zash I can't actually use Converse.js anymore, it runs into those limits in a few minutes 😕
  269. jcbrand If it wasn't for OMEMO then it would be much easier
  270. Zash Not while joining all MUCs anyway
  271. jcbrand Zash: If you're up for it, you can try the master branch with IndexedDB
  272. jcbrand performance has improved a lot recently
  273. jcbrand Still quite a bit slower than localStorage, but usable IMO (although not usable in some use-cases like having it integrated into an existing resource-hungry site)
  274. jcbrand I might even make IndexedDB the default in the 8.0.0 release (especially if I can get the batched writes to work well)
  275. millesimus has left
  276. stp has joined
  277. adiaholic has joined
  278. neshtaxmpp has joined
  279. jcbrand One advantage that disco has over hats is that hats are per MUC, so you have to assign them for every new MUC the bot enters
  280. Zash Hm, reminds me of the issue of MUC-component wide affiliations and such.
  281. Syndace has left
  282. Syndace has joined
  283. jcbrand yeah, would be great to have
  284. jcbrand is any of this fixed or improved by MIX?
  285. jcbrand Not that I expect MIX to supplant MUC any time soon
  286. BASSGOD has left
  287. adiaholic has left
  288. adiaholic has joined
  289. eric > eric: for which > screen size is certainly still a problem for KDE apps, like with plasma mobile the wifi setup dialog, no one had tested it with WPA2 Enterprise, the OK/Cancel buttons were off-screen, I had to hook it up to a monitor to set it up moparisthebest:
  290. pasdesushi has joined
  291. lovetox has left
  292. adiaholic has left
  293. adiaholic has joined
  294. BASSGOD has joined
  295. APach has left
  296. APach has joined
  297. pasdesushi has left
  298. pasdesushi has joined
  299. pasdesushi has left
  300. pasdesushi has joined
  301. pasdesushi has left
  302. pasdesushi has joined
  303. lovetox has joined
  304. pasdesushi has left
  305. pasdesushi has joined
  306. pasdesushi has left
  307. pasdesushi has joined
  308. BASSGOD has left
  309. pasdesushi has left
  310. BASSGOD has joined
  311. ajeremias has joined
  312. BASSGOD has left
  313. eric has left
  314. adiaholic has left
  315. adiaholic has joined
  316. eric has joined
  317. millesimus has joined
  318. adiaholic has left
  319. pasdesushi has joined
  320. stp has left
  321. pasdesushi has left
  322. BASSGOD has joined
  323. adiaholic has joined
  324. stp has joined
  325. Wojtek has joined
  326. alameyo has joined
  327. BASSGOD has left
  328. pasdesushi has joined
  329. pasdesushi has left
  330. pasdesushi has joined
  331. pasdesushi has left
  332. pasdesushi has joined
  333. pasdesushi has left
  334. aidalgol has left
  335. pasdesushi has joined
  336. alameyo has left
  337. pasdesushi has left
  338. pasdesushi has joined
  339. pasdesushi has left
  340. pasdesushi has joined
  341. pasdesushi has left
  342. BASSGOD has joined
  343. Guus has joined
  344. lovetox has left
  345. paul has left
  346. paul has joined
  347. paul has left
  348. paul has joined
  349. adiaholic has left
  350. paul has left
  351. paul has joined
  352. paul has left
  353. paul has joined
  354. BASSGOD has left
  355. Guus has left
  356. adiaholic has joined
  357. xecks has left
  358. xecks has joined
  359. Aleksej has joined
  360. BASSGOD has joined
  361. purplebeetroot has joined
  362. BASSGOD has left
  363. karoshi has left
  364. xecks has left
  365. xecks has joined
  366. karoshi has joined
  367. BASSGOD has joined
  368. Andrzej has left
  369. Andrzej has joined
  370. eta has joined
  371. adiaholic has left
  372. pasdesushi has joined
  373. pasdesushi has left
  374. pasdesushi has joined
  375. pasdesushi has left
  376. pasdesushi has joined
  377. Andrzej has left
  378. purplebeetroot has left
  379. adiaholic has joined
  380. pasdesushi has left
  381. Andrzej has joined
  382. adiaholic has left
  383. xecks has left
  384. xecks has joined
  385. Maranda has left
  386. Maranda has joined
  387. BASSGOD has left
  388. Wojtek has left
  389. adiaholic has joined
  390. BASSGOD has joined
  391. adiaholic has left
  392. xecks has left
  393. xecks has joined
  394. adiaholic has joined
  395. mathijs has left
  396. mathijs has joined
  397. xecks has left
  398. xecks has joined
  399. nyco has joined
  400. ti_gj06 has left
  401. lovetox has joined
  402. nyco has left
  403. pasdesushi has joined
  404. Kev has left
  405. peetah has left
  406. peetah has joined
  407. Kev has joined
  408. pasdesushi has left
  409. andrey.g has joined
  410. Andrzej has left
  411. Andrzej has joined
  412. Wojtek has joined
  413. xecks has left
  414. xecks has joined
  415. Andrzej has left
  416. fuana has joined
  417. xecks has left
  418. xecks has joined
  419. pasdesushi has joined
  420. BASSGOD has left
  421. Guus has joined
  422. pasdesushi has left
  423. pasdesushi has joined
  424. fuana has left
  425. emus has joined
  426. pasdesushi has left
  427. pasdesushi has joined
  428. BASSGOD has joined
  429. fuana has joined
  430. Guus has left
  431. pasdesushi has left
  432. andy has left
  433. Andrzej has joined
  434. andy has joined
  435. bean has left
  436. bean has joined
  437. bean has left
  438. bean has joined
  439. pasdesushi has joined
  440. pasdesushi has left
  441. pasdesushi has joined
  442. pasdesushi has left
  443. pasdesushi has joined
  444. chronosx88 has left
  445. chronosx88 has joined
  446. chronosx88 has left
  447. chronosx88 has joined
  448. pasdesushi has left
  449. ajeremias has left
  450. ajeremias has joined
  451. pasdesushi has joined
  452. pasdesushi has left
  453. pasdesushi has joined
  454. andy has left
  455. pasdesushi has left
  456. rmlang has joined
  457. fuana has left
  458. moparisthebest I thought web apps could request more localStorage space nowadays?
  459. moparisthebest eric: ah, no, but in general there are many more bugs than things that actually work in Linux phone land so I'm just waiting it out :)
  460. BASSGOD has left
  461. Sam Reminder that XMPP Office Hours for this week are today, not Friday! "Soprani.ca: bridging us all together" by Stephen Paul Weber (singpolyma) on Wednesday, 31st March 17:00 UTC
  462. BASSGOD has joined
  463. emus has left
  464. Maranda has left
  465. Wojtek has left
  466. BASSGOD has left
  467. fuana has joined
  468. paul has left
  469. paul has joined
  470. paul has left
  471. paul has joined
  472. emus has joined
  473. pasdesushi has joined
  474. Steve Kille has left
  475. Steve Kille has joined
  476. pasdesushi has left
  477. BASSGOD has joined
  478. fuana has left
  479. eevvoor has joined
  480. test1 has joined
  481. mathijs has left
  482. mathijs has joined
  483. BASSGOD has left
  484. Ge0rG has left
  485. Ge0rG has joined
  486. Wojtek has joined
  487. andy has joined
  488. BASSGOD has joined
  489. ti_gj06 has joined
  490. test1 has left
  491. pasdesushi has joined
  492. Maranda has joined
  493. fuana has joined
  494. adiaholic has left
  495. pasdesushi has left
  496. pasdesushi has joined
  497. adiaholic has joined
  498. BASSGOD has left
  499. pasdesushi has left
  500. pasdesushi has joined
  501. pasdesushi has left
  502. pasdesushi has joined
  503. pasdesushi has left
  504. pasdesushi has joined
  505. arcxi has left
  506. arcxi has joined
  507. pasdesushi has left
  508. pasdesushi has joined
  509. arcxi has left
  510. arcxi has joined
  511. pasdesushi has left
  512. pasdesushi has joined
  513. pasdesushi has left
  514. pasdesushi has joined
  515. BASSGOD has joined
  516. ti_gj06 has left
  517. pasdesushi has left
  518. pasdesushi has joined
  519. ti_gj06 has joined
  520. adiaholic has left
  521. fuana has left
  522. fuana has joined
  523. pasdesushi has left
  524. Tobias has left
  525. Tobias has joined
  526. Andrzej has left
  527. Andrzej has joined
  528. adiaholic has joined
  529. emus has left
  530. chronosx88 has left
  531. chronosx88 has joined
  532. Sam Office Hours for this week (about jmp.chat) is starting now! https://socialcoop.meet.coop/sam-pku-dud-niv
  533. fuana has left
  534. adiaholic has left
  535. emus has joined
  536. adiaholic has joined
  537. test1 has joined
  538. test1 has left
  539. adiaholic has left
  540. mathijs has left
  541. mathijs has joined
  542. lskdjf has left
  543. adiaholic has joined
  544. paul has left
  545. BASSGOD has left
  546. paul has joined
  547. test1 has joined
  548. lskdjf has joined
  549. pasdesushi has joined
  550. rmlang has left
  551. test1 has left
  552. BASSGOD has joined
  553. test1 has joined
  554. test1 has left
  555. pasdesushi has left
  556. fuana has joined
  557. lskdjf has left
  558. lskdjf has joined
  559. BASSGOD has left
  560. lskdjf has left
  561. lskdjf has joined
  562. rmlang has joined
  563. pasdesushi has joined
  564. pasdesushi has left
  565. pasdesushi has joined
  566. BASSGOD has joined
  567. pasdesushi has left
  568. pasdesushi has joined
  569. pasdesushi has left
  570. pasdesushi has joined
  571. BASSGOD has left
  572. Wojtek has left
  573. rmlang has left
  574. pasdesushi has left
  575. pasdesushi has joined
  576. rmlang has joined
  577. flow Ge0rG, why are groupchat messages in an user archive a bad idea?
  578. Wojtek has joined
  579. Ge0rG flow: because the client needs to support that, be aware that those come from a MUC, and treat them differently. I think that the MUC MAM approach has worked better.
  580. Ge0rG Most clients today will probably do weird things when receiving groupchat messages from MAM
  581. pasdesushi has left
  582. fuana has left
  583. pasdesushi has joined
  584. lskdjf has left
  585. lskdjf has joined
  586. lovetox has left
  587. flow Ge0rG, thanks for the reply. But I've to admit that this appears to be more like a client issue
  588. pasdesushi has left
  589. pasdesushi has joined
  590. lskdjf has left
  591. lskdjf has joined
  592. Zash There's also the problem with how a MUC will send one message for each joined resource, which complicates server processing.
  593. Zash Way simpler for the MUC to do it, as it already knows when processing that it's a single message, before it broadcasts it.
  594. BASSGOD has joined
  595. Ge0rG flow: a MUC will only send messages to you while at least one client is connected. If you only have one client, you will only receive from MAM what you already had before. If you have two clients, you will receive a random subset of the room history with no way to know where there are holes
  596. Zash There are scenarios where it's desirable that the user only sees history from when they're joined, but it does get weird and should probably be dealt with on the basis of affiliation.
  597. pasdesushi has left
  598. Ge0rG It's getting even more weird with MIX MAM, and I've been telling that for years.
  599. Kev BTW, saying “no-one does this” isn’t correct :)
  600. pasdesushi has joined
  601. Zash This is the point where I mention that experiment I did in rewriting outgoing MUC joins so that they come from the bare JID?
  602. Kev But you’re right that it doesn’t work terribly well.
  603. Ge0rG Kev: I'm eager to read your implementation and interop story on the ML
  604. pasdesushi has left
  605. Zash Ge0rG, what about MIX MAM ?
  606. Ge0rG Zash: you could convert that from a 20% implementation to an 80% implementation, and I'd actually test it
  607. Ge0rG Zash: s2s isn't flawless, it will cause holes in MAM
  608. Zash What's those 60% then?
  609. pasdesushi has joined
  610. lovetox has joined
  611. test1 has joined
  612. Andrzej has left
  613. Andrzej has joined
  614. fuana has joined
  615. pasdesushi has left
  616. pasdesushi has joined
  617. Ge0rG Zash: tracking outgoing presence, leaving rooms, nickname management, bookmark sync
  618. Andrzej has left
  619. ti_gj06 has left
  620. Kev If we have a MAM meta-search that searches each archive, we could probably get away without having mix history in personal archives.
  621. fuana has left
  622. Zash Ge0rG, but how will I be motivated to work on it without at least someone testing it?
  623. pasdesushi has left
  624. Ge0rG Zash: well, how am I supposed to test it if it breaks everything?
  625. Zash Someone needs to go push the stalemate resolution button!
  626. pasdesushi has joined
  627. BASSGOD has left
  628. Zash And there's like 3 different bookmarks methods atm, that seems fun to deal with
  629. fuana has joined
  630. BASSGOD has joined
  631. Zash Ge0rG, track what outgoing presence?
  632. adiaholic has left
  633. Ge0rG Zash: room joins from clients?
  634. Zash That part should work afaik
  635. adiaholic has joined
  636. pasdesushi has left
  637. Ge0rG What about error handling?
  638. Zash That goes under "leave"
  639. Zash which is under TODO
  640. pasdesushi has joined
  641. Zash I think it even dedups additional joins, tho I'm not sure that's optimal.
  642. fuana has left
  643. test1 has left
  644. Ge0rG Zash: it's a server module in a state I can't possibly deploy on a production server, and I'm only using one single room from my other server
  645. rmlang has left
  646. adiaholic has left
  647. Zash Should set up that bleeding edge Prosody instance for client devs ... one day.
  648. Ge0rG Yeah, crash me!
  649. pasdesushi has left
  650. Wojtek has left
  651. Kev What rules would be needed? Just rewrite anything going to/from a MUC so that the user part is bare?
  652. Kev Determining it’s a MUC by the first thing that’s sent being a presence with muc in it?
  653. Ge0rG Kev: you need to implement a bouncer that will multiplex the room between all your clients
  654. Kev Oh yeah, that.
  655. Kev So, basically imprementing MIX-PAM, in other words.
  656. Zash Pretty much
  657. Ge0rG Kev: kinda sorta
  658. Ge0rG Well, it's probably not so much to implement, and doesn't need to persist anything. But it might have to do sophisticated things with room history generation on join
  659. Zash Keep track of joined rooms, joined resources to deal with rewriting in- and outgoing stanzas. Then subject and participants which lets you add new local resources and send them a synthesized join presence flood.
  660. adiaholic has joined
  661. Kev So, it’s much worse that just implementing MIX-PAM.
  662. Zash No, it's better because it works with MUC, which is what Everyone™ is using today.
  663. Zash With zero changes required of clients
  664. Kev I mean it’s much worse to implement.
  665. Ge0rG And with a manageable overhead on the server
  666. Zash Sure, it's MUC
  667. winfried has left
  668. Kev You know what it is like implementing, actually?
  669. fuana has joined
  670. Kev It’s basically implementing FMUC.
  671. Kev Which is a MUC implementation that can join another MUC.
  672. winfried has joined
  673. Zash FMUC-on-your-JID
  674. Zash Because we need more things-on-your-JID! 😀
  675. Kev It’s the bastard child of MIX-PAM and FMUC.
  676. Ge0rG And implementing it will give a significant immediate benefits
  677. Ge0rG Mobile clients don't need to self ping any more
  678. Zash Now the server will need to self-ping! 😀
  679. ti_gj06 has joined
  680. Ge0rG You'd get reasonable push integration
  681. Ge0rG Less presence flooding of rooms
  682. Ge0rG Zash: the server knows about its s2s, so it only need to self ping after s2s went down
  683. Zash Could probably do the presence versioning thing, closer to the user.
  684. adiaholic has left
  685. Ge0rG Zash: needs new protocol
  686. Zash Hm?
  687. Ge0rG Kev: that solution is 100% transparent to existing implementations both on the client and on the MUC
  688. Zash In theory you could do the same thing but have it speak MIX
  689. Kev In theory you can do anything with enough monkeys and typewriters, yes :)
  690. Zash No idea if MUC-MIX translation is easier on the users' server or the MIX host.
  691. Kev MIX. Much :)
  692. BASSGOD has left
  693. Andrzej has joined
  694. Zash Ge0rG, FWIW I think it's okay to leave the door open for storing groupchat messages in the users local archive, but Something Needs To Be Done first.
  695. pasdesushi has joined
  696. Ge0rG Zash: yes, a new XEP needs to be written.
  697. Ge0rG No place in 313 for this
  698. Kev Is it worth having to bump the namespace for the sake of changing the SHOULD to the MUST?
  699. Zash Ugh
  700. Ge0rG I remember having to explain to another developer not to do it like written in the XEP
  701. Ge0rG Kev: which one?
  702. pasdesushi has left
  703. BASSGOD has joined
  704. Kev MAM.
  705. Zash Let's not bump any namespaces
  706. Kev I think changing a SHOULD to a MUST would require that.
  707. adiaholic has joined
  708. BASSGOD has left
  709. Zash SHOULD NOT then?
  710. Zash or perhaps a PLZ DONT
  711. pasdesushi has joined
  712. adiaholic has left
  713. chronosx88 has left
  714. adiaholic has joined
  715. Ge0rG Kev: there are 14 SHOULD and a dozen should.
  716. pasdesushi has left
  717. Ge0rG So which one are you talking about?
  718. fuana has left
  719. fuana has joined
  720. Zash The one closest to the word 'groupchat' I would have presumed?
  721. pasdesushi has joined
  722. Ge0rG So... > A server ~SHOULD~ MUST also include messages of type 'groupchat' that have a <body> I really hope that's not the intention
  723. adiaholic has left
  724. Kev You proposed onlist changing into MUST NOT store gcs.
  725. Kev I think.
  726. BASSGOD has joined
  727. Ge0rG Kev: last time I checked, MUST NOT was the opposite of MUST, so please excuse my confusion. But yes, I suggested that.
  728. Ge0rG As an escalation of "SHOULD NOT", but I like strong words.
  729. chronosx88 has joined
  730. Ge0rG I also looked up that the first time I wrote "MAM subscription" on list was in 2015, and probably even earlier in here.
  731. fuana has left
  732. Syndace has left
  733. Syndace has joined
  734. Zash This is a wordification of what future (currently unreleased) Prosody will do, if nothing changes before the next major release: - **Do not** store messages of type headline since these are supposed to be for transient notifications, most often PEP events. - **Do store** messages of type error, since if you sent a message it is of interest to know that delivery failed. - **Do not** store messages of type groupchat, as MUCs will send one message per joined resource and most often provides their own MAM. - Follow \[XEP-0334: Message Processing Hints\] advising for or against storage. - **Do store** messages with a `<body>` and/or `<subject>` element, as these carry messages for users. - **Do store** encrypted messages for the same reason as with `<body>`, as indicated by \[XEP-0380: Explicit Message Encryption\]. - **Do store** messages with \[XEP-0184: Message Delivery Receipts\] requests, and the receipts themselves, as if something is important enough to need such a receipt it is probably important enough to archive. - **Do store** messages with \[XEP-0333: Chat Markers\], for the same reasons as with receipts. - **Do store** MUC invites, both mediated and direct. - **Do store** messages with an \[XEP-0353: Jingle Message Initiation\] payload, as users will want to know if they had missed calls. - Anything not covered by this point is either something new that may or may not warrant adding to the archive or something that should not be archived.
  735. Kev And I don’t think you’re even the first person to suggest mamsub ;)
  736. pasdesushi has left
  737. adiaholic has joined
  738. BASSGOD has left
  739. alameyo has joined
  740. marek has left
  741. marek has joined
  742. flow Ge0rG, I like you response on the ML, but you may want to consider adding reasons against groupchat messages in a user archive. I think your mail contains none, and the reasons are good. I feel we often discuss on the mailing list stating "everyone knows that X is a bad idea", without actually providing any reasons/arguments why it is so. And that probably deters people from participating.
  743. adiaholic has left
  744. Ge0rG flow: thanks! I'm not going to be at a proper computer for the next days, so feel free to summarize, link or copy paste what we discussed here today
  745. xsf has left
  746. Andrzej has left
  747. fuana has joined
  748. BASSGOD has joined
  749. pasdesushi has joined
  750. alameyo has left
  751. xsf has joined
  752. Yagiza has left
  753. adiaholic has joined
  754. lskdjf has left
  755. BASSGOD has left
  756. pasdesushi has left
  757. adiaholic has left
  758. fuana has left
  759. lskdjf has joined
  760. Andrzej has joined
  761. lskdjf has left
  762. lskdjf has joined
  763. lskdjf has left
  764. lskdjf has joined
  765. fuana has joined
  766. lskdjf has left
  767. lskdjf has joined
  768. Andrzej has left
  769. sebastian has left
  770. Andrzej has joined
  771. sebastian has joined
  772. BASSGOD has joined
  773. adiaholic has joined
  774. Andrzej has left
  775. lskdjf has left
  776. DebXWoody has left
  777. adiaholic has left
  778. adiaholic has joined
  779. Kev If you were to do dedupe on the server, or whatever, you could also achieve reasonable groupchats in the archive behaviour.
  780. Kev And probably for less work than trying to implement the MUC-PAM discussed earlier.
  781. Zash That's a big and messy if tho
  782. Kev Unlike finding a way to do dudupe and everything else involved in MUC-PAM? :)
  783. Kev I’m just giving another reason that I think MUST NOT would be excessive.
  784. Zash Just Unfork Stuff™
  785. Zash Kev, I agree tho, if you do go and solve that and other issues, storing groupchats in the users archive is probably okay.
  786. andrey.g has left
  787. adiaholic has left
  788. BASSGOD has left
  789. mathijs has left
  790. mathijs has joined
  791. chronosx88 has left
  792. chronosx88 has joined
  793. Ge0rG Kev: also please solve reliable s2s while you are at it. And World Peace. Whatever is easier.
  794. adiaholic has joined
  795. chronosx88 has left
  796. chronosx88 has joined
  797. lskdjf has joined
  798. Zash You know what, let's flip that default
  799. mdosch has left
  800. mdosch has joined
  801. Ge0rG Kev: you need additional protocol to get MUC messages into the user account, even when no client is connected, which is surprisingly close to MUC-PAM
  802. Ge0rG Without that, you get invisible holes in MUC history, which is the opposite of what xmpp needs
  803. fuana has left
  804. DebXWoody has joined
  805. BASSGOD has joined
  806. eevvoor has left
  807. adiaholic has left
  808. fuana has joined
  809. papatutuwawa has joined
  810. adiaholic has joined
  811. fuana has left
  812. deuill has left
  813. chronosx88 has left
  814. chronosx88 has joined
  815. pasdesushi has joined
  816. BASSGOD has left
  817. adiaholic has left
  818. ti_gj06 has left
  819. BASSGOD has joined
  820. pasdesushi has left
  821. adiaholic has joined
  822. BASSGOD has left
  823. Tobias has left
  824. adiaholic has left
  825. Tobias has joined
  826. flow not sure if we MUST keywordify here, it appears a simple "we found that user archives with type=groupchat messages cause trouble if not taken special care of, and clients may want to consider ignoring type=groupchat messages in a user archive"
  827. flow could be sufficient
  828. fuana has joined
  829. bean has left
  830. BASSGOD has joined
  831. nad200 has joined
  832. adiaholic has joined
  833. jcbrand has left
  834. Kev Makes sense to me.
  835. adiaholic has left
  836. Tobias has left
  837. adiaholic has joined
  838. fuana has left
  839. adiaholic has left
  840. Ge0rG I still think that servers shouldn't send all the MUC garbage to a client
  841. eric has left
  842. Kev has left
  843. Kev has joined
  844. goffi has left
  845. deuill has joined
  846. Kev has left
  847. Kev has joined
  848. adiaholic has joined
  849. emus has left
  850. Lance has left
  851. adiaholic has left
  852. BASSGOD has left
  853. nad200 has left
  854. BASSGOD has joined
  855. nad200 has joined
  856. Kev has left
  857. Kev has joined
  858. nad200 has left
  859. Lance has joined
  860. adiaholic has joined
  861. nad200 has joined
  862. Kev has left
  863. Kev has joined
  864. adiaholic has left
  865. Kev has left
  866. Kev has joined
  867. Andrzej has joined
  868. debacle has left
  869. papatutuwawa has left
  870. LNJ has left
  871. edhelas has left
  872. edhelas has joined
  873. moparisthebest Looks like XMPP infringes on this patent in the USA, </stream:stream> illegal: > The claimed invention is a system where at least one robot “generates a goodbye command that terminates a communication session” with another robot and “relinquishes control.” https://www.eff.org/deeplinks/2021/03/stupid-patent-month-telehealth-robots-say-goodbye
  874. Syndace has left
  875. Syndace has joined
  876. deuill has left
  877. Andrzej has left
  878. deuill has joined
  879. wurstsalat has left
  880. andy has left
  881. nad200 has left
  882. Nekit has left
  883. croax has left
  884. karoshi has left
  885. Nekit has joined
  886. Ge0rG Is it April Fool's already?
  887. moparisthebest Unfortunately no
  888. paul has left
  889. fuana has joined
  890. fuana has left
  891. fuana has joined
  892. fuana has left
  893. fuana has joined
  894. adiaholic has joined
  895. adiaholic has left
  896. alameyo has joined
  897. Andrzej has joined
  898. fuana has left
  899. fuana has joined
  900. fuana has left
  901. fuana has joined
  902. alameyo has left
  903. Andrzej has left
  904. Aleksej has left
  905. govanify has left
  906. govanify has joined
  907. fuana has left
  908. adiaholic has joined
  909. southerntofu has left
  910. lskdjf has left
  911. adiaholic has left
  912. adiaholic has joined
  913. ajeremias has left
  914. adiaholic has left