jdev - 2023-01-22


  1. Beherit has left

  2. PapaTutuWawa has left

  3. Beherit has joined

  4. Trung has left

  5. nicoco has left

  6. gregory has left

  7. SouL has left

  8. gregory has joined

  9. spiral has left

  10. john-machine has left

  11. gregory has left

  12. gregory has joined

  13. john-machine has joined

  14. spiral has joined

  15. john-machine has left

  16. adx has left

  17. john-machine has joined

  18. marc0s has left

  19. antranigv has joined

  20. marc0s has joined

  21. Beherit

    okay, my close friends decided to not use xmpp apps any more. Besides multiple issues, the core on was push notifications on android. I wanted to recommend to devs to review creation of awarness towards batteryoptimization deactivation. its a problem people usually dont understand

  22. jubalh has left

  23. Alex has left

  24. gregory has left

  25. gregory has joined

  26. moparisthebest

    Beherit: like, not getting notifications or?

  27. dezant has joined

  28. moparisthebest

    Beherit: if that's what you meant, normal people who use normal phones and install XMPP applications through normal app stores shouldn't need to disable battery optimizations, assuming their server supports push notifications, and it should or they will have a bad time

  29. wurstsalat has left

  30. moparisthebest

    Disabling battery optimizations is for weirdos like me who don't have Google play services and install through f-droid

  31. john-machine has left

  32. Mx2 has joined

  33. john-machine has joined

  34. Millesimus has left

  35. Millesimus has joined

  36. gregory has left

  37. gregory has joined

  38. Millesimus has left

  39. rubi has left

  40. rubi has joined

  41. Beherit has left

  42. rubi

    disabling battery optimization doesnt work on all devices anyway: https://dontkillmyapp.com/

  43. jgart has left

  44. rubi

    also huawei devices don't have google play services either, and their devices ignore battery optimization settings

  45. Millesimus has joined

  46. EOF has left

  47. EOF has joined

  48. rubi has left

  49. rubi has joined

  50. rubi has left

  51. rubi has joined

  52. rubi has left

  53. rubi has joined

  54. rubi has left

  55. rubi has joined

  56. rubi has left

  57. rubi has joined

  58. rubi has left

  59. rubi has joined

  60. kapad has left

  61. marc0s has left

  62. Millesimus has left

  63. marc0s has joined

  64. rubi has left

  65. rubi has joined

  66. gregory has left

  67. gregory has joined

  68. rubi has left

  69. rubi has joined

  70. rubi has left

  71. rubi has joined

  72. rubi has left

  73. jackhill

    do you know if huawei runs their own push notification service?

  74. rubi has joined

  75. rubi has left

  76. thomaslewis has joined

  77. Millesimus has joined

  78. spiral has left

  79. Millesimus has left

  80. rubi has joined

  81. rubi has left

  82. rubi has joined

  83. spiral has joined

  84. rubi has left

  85. rubi has joined

  86. thomaslewis has left

  87. Millesimus has joined

  88. rubi has left

  89. rubi has joined

  90. spiral has left

  91. selurvedu has left

  92. rubi has left

  93. selurvedu has joined

  94. gregory has left

  95. spiral has joined

  96. Millesimus has left

  97. gregory has joined

  98. rubi has joined

  99. soulcaramel has left

  100. Mx2 has left

  101. Schimon_ has joined

  102. john-machine has left

  103. john-machine has joined

  104. marc0s has left

  105. marc0s has joined

  106. Millesimus has joined

  107. gregory has left

  108. gregory has joined

  109. mirux has joined

  110. snow has left

  111. Millesimus has left

  112. marc0s has left

  113. marc0s has joined

  114. u has joined

  115. sponji has joined

  116. sponji has left

  117. sponji has joined

  118. sponji has left

  119. sponji has joined

  120. sponji has left

  121. sponji has joined

  122. sponji has left

  123. sponji has joined

  124. sponji has left

  125. sponji has joined

  126. sponji has left

  127. sponji has joined

  128. sponji has left

  129. sponji has joined

  130. sponji has left

  131. sponji has joined

  132. sponji has left

  133. sponji has joined

  134. sponji has left

  135. sponji has joined

  136. sponji has left

  137. Millesimus has joined

  138. sponji has joined

  139. sponji has left

  140. antranigv has left

  141. antranigv has joined

  142. sponji has joined

  143. sponji has left

  144. sponji has joined

  145. sponji has left

  146. sponji has joined

  147. sponji has left

  148. sponji has joined

  149. sponji has left

  150. sponji has joined

  151. sponji has left

  152. sponji has joined

  153. sponji has left

  154. sponji has joined

  155. sponji has left

  156. paul has joined

  157. sponji has joined

  158. sponji has left

  159. sponji has joined

  160. sponji has left

  161. sponji has joined

  162. sponji has left

  163. sponji has joined

  164. thomaslewis has joined

  165. sponji has left

  166. sponji has joined

  167. sponji has left

  168. sponji has joined

  169. Millesimus has left

  170. SouL has joined

  171. Millesimus has joined

  172. jgart has joined

  173. u has left

  174. u has joined

  175. selurvedu has left

  176. u has left

  177. MSavoritias (fae,ve) has joined

  178. gregory has left

  179. gregory has joined

  180. u has joined

  181. mirux has left

  182. mirux has joined

  183. rubi has left

  184. rubi has joined

  185. SouL has left

  186. marc0s has left

  187. marc0s has joined

  188. marc0s has left

  189. marc0s has joined

  190. SouL has joined

  191. thomaslewis has left

  192. antranigv has left

  193. antranigv has joined

  194. rubi has left

  195. rubi has joined

  196. rubi has left

  197. rubi has joined

  198. Alex has joined

  199. SouL has left

  200. atomicwatch has joined

  201. atomicwatch has left

  202. atomicwatch has joined

  203. SouL has joined

  204. jubalh has joined

  205. marc0s has left

  206. marc0s has joined

  207. marc0s has left

  208. marc0s has joined

  209. TheCoffeMaker has left

  210. Trung has joined

  211. stefan has joined

  212. marc0s has left

  213. marc0s has joined

  214. TheCoffeMaker has joined

  215. marc0s has left

  216. marc0s has joined

  217. goffi has joined

  218. Kev has joined

  219. Kev has left

  220. marc0s has left

  221. marc0s has joined

  222. goffi has left

  223. goffi has joined

  224. spectrum has left

  225. gregory has left

  226. gregory has joined

  227. antranigv has left

  228. Trung has left

  229. gregory has left

  230. gregory has joined

  231. me9 has joined

  232. Beherit has joined

  233. marc0s has left

  234. marc0s has joined

  235. marc0s has left

  236. marc0s has joined

  237. me9 has left

  238. Vaulor has left

  239. Vaulor has joined

  240. adx has joined

  241. menel has left

  242. marc0s has left

  243. marc0s has joined

  244. wurstsalat has joined

  245. gregory has left

  246. moparisthebest has left

  247. gregory has joined

  248. lovetox has left

  249. lovetox has joined

  250. raghavgururajan has joined

  251. Beherit

    > moparisthebest: > 2023-01-22 02:54 (GMT+01:00) > Beherit: if that's what you meant, normal people who use normal phones and install XMPP applications through normal app stores shouldn't need to disable battery optimizations, assuming their server supports push notifications, and it should or they will have a bad time Then I dont know whats the problem

  252. Beherit

    their servers are fine

  253. moparisthebest has joined

  254. gregory has left

  255. Beherit

    there is defibitively a huawei phone in that group I was talking about

  256. Beherit

    I refered to that issue already

  257. Beherit has left

  258. Beherit has joined

  259. flow

    huawei phones should gernally work fine if there is a proper XMPP push mechanism in place

  260. u has left

  261. gregory has joined

  262. jubalh has left

  263. john-machine has left

  264. gregory has left

  265. jubalh has joined

  266. gregory has joined

  267. larma has joined

  268. john-machine has joined

  269. gregory has left

  270. gregory has joined

  271. PapaTutuWawa has joined

  272. gregory has left

  273. gregory has joined

  274. MSavoritias (fae,ve) has left

  275. Mario Sabatino has joined

  276. nicoco has joined

  277. MSavoritias (fae,ve) has joined

  278. gregory has left

  279. gregory has joined

  280. MSavoritias (fae,ve) has left

  281. gregory has left

  282. gregory has joined

  283. MSavoritias (fae,ve) has joined

  284. Kev has joined

  285. Kev has left

  286. Trung has joined

  287. antranigv has joined

  288. norayr has left

  289. antranigv has left

  290. gregory has left

  291. techmetx11 has left

  292. gregory has joined

  293. sonny has left

  294. gregory has left

  295. gregory has joined

  296. antranigv has joined

  297. sonny has joined

  298. antranigv has left

  299. antranigv has joined

  300. MSavoritias (fae,ve) has left

  301. gregory has left

  302. gregory has joined

  303. soulcaramel has joined

  304. Beherit

    Just saying that there seems to be issues still

  305. Beherit

    Another thing are passwort / lost accounts when switching phones commonly. But thats a server side thing

  306. gregory has left

  307. jubalh has left

  308. gregory has joined

  309. kapad has joined

  310. SouL has left

  311. rubi has left

  312. rubi has joined

  313. john-machine has left

  314. SouL has joined

  315. Vaulor has left

  316. gregory has left

  317. gregory has joined

  318. Vaulor has joined

  319. MSavoritias (fae,ve) has joined

  320. gregory has left

  321. techmetx11 has joined

  322. gregory has joined

  323. larma has left

  324. john-machine has joined

  325. me9 has joined

  326. john-machine has left

  327. john-machine has joined

  328. antranigv has left

  329. jubalh has joined

  330. gregory has left

  331. gregory has joined

  332. MSavoritias (fae,ve) has left

  333. MSavoritias (fae,ve) has joined

  334. john-machine has left

  335. Vaulor has left

  336. Vaulor has joined

  337. Martin

    That's more a user thing. 😂

  338. gregory has left

  339. antranigv has joined

  340. gregory has joined

  341. menel has joined

  342. john-machine has joined

  343. antranigv has left

  344. antranigv has joined

  345. Beherit

    No, its not working if servers do not offer password reset for normal users

  346. antranigv has left

  347. antranigv has joined

  348. antranigv has left

  349. menel

    That depends on the server admin. There are servers with reset, and there are some that don't have it

  350. atomicwatch has left

  351. adx has left

  352. Beherit

    I know, thats also why I introduced the password reset key in the providers project.

  353. antranigv has joined

  354. MSavoritias (fae,ve)

    Yeah. That should be standard for public servers

  355. antranigv has left

  356. atomicwatch has joined

  357. atomicwatch has left

  358. antranigv has joined

  359. antranigv has left

  360. Beherit

    It should be standard for servers recommended to newbies etc

  361. MSavoritias (fae,ve)

    Yeah

  362. nik has joined

  363. atomicwatch has joined

  364. Beherit

    I basically wanted to express that onboarding and essential working setups is not a thing of the past yet.

  365. Yagizа has joined

  366. nik has left

  367. MattJ

    Not on public servers, indeed

  368. SouL has left

  369. MattJ

    That's why I don't recommend public servers to most people, and why I work on Snikket which solves all the problems you've mentioned, and more

  370. SouL has joined

  371. snow has joined

  372. john-machine has left

  373. Trung

    Beherit, if you don't want to run your own server, move your friends to mine: https://chat.trung.fun

  374. john-machine has joined

  375. nik has joined

  376. atomicwatch has left

  377. Beherit

    > MattJ: > 2023-01-22 03:41 (GMT+01:00) > That's why I don't recommend public servers to most people, and why I work on Snikket which solves all the problems you've mentioned, and more Yes I see that. But we shouldn't deprecate the federated idea because of all this.

  378. Beherit

    MattJ: you actually offer hosted services?

  379. Beherit

    Trung: I dont run my own

  380. menel

    Snikket is still federated. https://snikket.org/hosting/

  381. Zash

    "Public server" as in having registration open to more or less anyone.

  382. Zash

    Orthogonal to whether it participates in the open federation.

  383. menel has left

  384. menel has joined

  385. nik has left

  386. Trung

    Beherit, you don't have to. Not everybody has to run a server to use XMPP. You can get onboard with the Snikket team or on my domain. All is well.

  387. moparisthebest

    But everyone who can run a server should

  388. Holger

    Maybe 'everyone' who can commit to maintaining a server in the long run 'should' do so, but that's usually hard to predict.

  389. Holger

    At least until we have a good account migration story.

  390. adx has joined

  391. Beherit

    I dont know if I should setup snikket now. The game with my close friend is lost anyway for the next years and I dont have interest to deal with their frequent incompetence on some stuff. Holger: yeah, I pay for my free of costs public servers indeed

  392. atomicwatch has joined

  393. Beherit

    I also donated and paid for conversations even I dont use it directly + Quicksy, which worked pretty fine indeed

  394. moparisthebest

    To be clear I meant "for their friends and family", running a public one is indeed a commitment

  395. Holger

    It's a commitment for friends & family as well, no?

  396. jackhill

    moparisthebest: heh, well in my experience anything, even for one other person becomes mission critical quickly. 😁

  397. jackhill

    At least if you own your own domain, you can switch hosting providers while keeping addresses

  398. nik has joined

  399. moparisthebest

    Yes that's fine though, it's a few people you know personally and you can get it sorted quickly

  400. jackhill

    Maybe off topic, but that's a nice thing about phone numbers: portability with no @domain part.

  401. rom1dep

    I'm amazed by how broken threads turned out to be in matrix-land, is there any ongoing willingness/effort towards implementing/revamping threading in XMPP?

  402. moparisthebest

    rom1dep: cheogram has implemented threading

  403. rom1dep

    oh really?

  404. moparisthebest

    Cheogram Android, a conversations fork

  405. Zash

    jackhill, reminds me of https://en.wikipedia.org/wiki/Telephone_number_mapping

  406. goffi has left

  407. jackhill

    rom1dep: video demo of cheogram demo video for the thread UI branch: https://kumi.tube/w/1LQQp5Uia4u8Pdojxen1y8

  408. rom1dep

    I gave it a look the other day after inquiring about ad-hoc commands and it didn't strike me as having such fancy features… is there a place/blog where I can read about it?

  409. rom1dep

    ah, thanks jackhill :)

  410. jackhill

    Treads still pre-release I think

  411. jackhill

    Threads still pre-release I think

  412. rom1dep

    after the first 15seconds it seems like what nheko's doing

  413. jackhill

    Zash: thanks, I wasn't aware of that

  414. rom1dep

    (which, amongst element, neochat and nheko is what makes the most sense to me)

  415. goffi has joined

  416. nik has left

  417. gregory has left

  418. gregory has joined

  419. rom1dep

    I like this UX. I don't think it's necessary to have a feature for "creating threads" explicitly, they could arise automatically as the consequence of replying to a message.

  420. rom1dep

    and about that, anyone's working on contextual replies/citations where clicking on the cited message scrolls back to it?

  421. nik has joined

  422. MattJ

    Beherit [15:08]: > MattJ: you actually offer hosted services? Yes

  423. MattJ

    rom1dep: yes to that too

  424. rom1dep

    in snikket?

  425. MattJ

    Probably after Conversations 3 🙂

  426. rom1dep

    with reactions

  427. MattJ

    I just meant to say that people are working on it

  428. goffi has left

  429. rom1dep

    gotcha

  430. goffi has joined

  431. rom1dep

    at least I've seen Daniel committing a lot towards C3 lately

  432. MattJ

    Yes, he has funding to work on it properly at last

  433. rom1dep

    I'm glad he still has the stamina to dive into large refactorings like such

  434. gregory has left

  435. nik has left

  436. atomicwatch has left

  437. sponji has left

  438. PapaTutuWawa has left

  439. gregory has joined

  440. sponji has joined

  441. atomicwatch has joined

  442. antranigv has joined

  443. gregory has left

  444. Trung has left

  445. antranigv has left

  446. Trung has joined

  447. gregory has joined

  448. rom1dep

    > Yes, he has funding to work on it properly at last Oh, it's NLnet at it once again. Good use of taxpayer's money :)

  449. antranigv has joined

  450. Vaulor has left

  451. antranigv has left

  452. Vaulor has joined

  453. PapaTutuWawa has joined

  454. Beherit

    rom1dep: yes, indeed

  455. Trung has left

  456. nik has joined

  457. john-machine has left

  458. menel has left

  459. menel has joined

  460. nik has left

  461. jackhill has left

  462. jackhill has joined

  463. gregory has left

  464. gregory has joined

  465. john-machine has joined

  466. adx has left

  467. Kev has joined

  468. Kev has left

  469. gregory has left

  470. gregory has joined

  471. wurstsalat

    rom1dep: Dino has replies implemented, Movim, too. Gajim will soon follow

    👌️ 1
  472. rom1dep

    > dino(hg-git)[ default master]➤ hg ↓ > pulling from git@github.com:dino/dino.git > importing 26 git commits Time to check that out :)

  473. rom1dep

    looks like it was added 2 weeks back, good job there!

  474. jubalh has left

  475. jubalh has joined

  476. rom1dep

    > rom1dep: Dino has replies implemented, Movim, too. Gajim will soon follow let's see how that looks

  477. rom1dep

    https://upload.tamytro.org/upload/a3849b367f4dd4cedd5ad6f64afa7645b7d4f834/rHaQxfbairFRZbTHYiA6EXy4GgwfiD06Qorzub3i/be07886c-4f77-45b1-bbe9-5f8c3cfc064c.png

  478. rom1dep

    humm, apparently pasting an image in dino doesn't create an attachment :(

  479. jubalh has left

  480. Zash

    or maybe, just maybe, pasting images is restricted in this channel

  481. rom1dep

    is it right on the side of dino to pretend it attached, then?

  482. pep.

    Zash, is it?

  483. Zash

    IIRC that module is loaded here, yeah

  484. pep.

    That is.. it removed <oob>?

  485. pep.

    That is.. it removes <oob>?

  486. pep.

    Anyway, it would be nice if it was explicit I guess. I had no clue (and I guess I'm not the only one)

  487. menel has left

  488. norayr has joined

  489. larma has joined

  490. Zash

    There's a `"{xmpp:prosody.im}muc#roomconfig_unaffiliated_media": false` in disco#info

  491. Zash

    "explicit" would mean what exactly in this case?

  492. MSavoritias (fae,ve)

    Pictures dont work in the description i guess

  493. pep.

    Yeah I guess the disco thing isn't exposed by many clients

  494. pep.

    Maybe it should be

  495. SouL has left

  496. pep.

    So in the meantime in the topic or desc or sth..

  497. MSavoritias (fae,ve)

    Thats actually a good idea. A list of checks with what you are allowed to do in the group

  498. MSavoritias (fae,ve)

    From disco

  499. MattJ

    Funny, that's already a thing

  500. MattJ

    Somewhere

  501. gregory has left

  502. MattJ

    https://xmpp.org/extensions/xep-0045.html#impl-service-traffic

  503. rom1dep

    Conversations' channel details should show something like that below "XEP-0313: MAM → available" for instance

  504. gregory has joined

  505. pep.

    Well for this specific feature, the upload button could be greyed out in dino say, with a thing on hover. I don't know how to expose it in Conversations

  506. MattJ

    I don't see what the big deal is with this one though. The recipient still gets a link. Why would you disable upload?

  507. pep.

    Maybe preventing upload isn't the right thing either.. just that expectations aren't respected

  508. pep.

    A user could think it's borked

  509. pep.

    (And that's actually what just happened here)

  510. MattJ

    Yeah, because we're in a room of XMPP developers 🙂

  511. pep.

    I don't see why XMPP developers should have this expectation :P

  512. pep.

    We're also users, persons with a heart!!

  513. pep.

    We're also users, people with a heart!!

  514. moparisthebest

    Speak for yourself

  515. pep.

    I knew it

  516. rom1dep

    could be the same attachment icon with a warning symbol "content will be shared as a link instead of being embedded"

  517. moparisthebest

    ;)

  518. MattJ

    rom1dep: unless they use Movim or Converse.js which I think will still show it "embedded" 😄

  519. MattJ

    Even if you just send a link

  520. rom1dep

    it's just super misleading that dino sticks to the "embedding" UX while the rest of the world (including user's own clients) sees a URL

  521. MattJ

    Give up, we have more important things to "fix" 🙂

  522. jubalh has joined

  523. Menel

    After all this is a very rare used module in prosody. Its unlikely one finds it In the wild , beside these jabber rooms

  524. pep.

    Weird and unexpected anyway, but yeah I won't die on this hill

  525. rom1dep

    https://upload.tamytro.org/upload/a3849b367f4dd4cedd5ad6f64afa7645b7d4f834/L64XFGQT7aGlHSp0EDhnOw5Xh8dh6eDDeziFcF8l/42a10537-90b5-4e50-a07f-ba4393d319fe.png

  526. rom1dep

    dino did really up its game there

  527. gregory has left

  528. rom1dep

    I remember not long ago when history retrieval would be freezing the client for minutes

  529. SouL has joined

  530. Zash

    There's the issue like https://github.com/dino/dino/issues/590 tho

  531. gregory has joined

  532. Zash

    I.e. the sending client not showing what the MUC reflects back.

  533. xnamed has left

  534. thomaslewis has joined

  535. xnamed has joined

  536. hearty has left

  537. thomaslewis has left

  538. larma has left

  539. hearty has joined

  540. larma has joined

  541. me9 has left

  542. larma has left

  543. larma has joined

  544. thomaslewis has joined

  545. xnamed has left

  546. Schimon_ has left

  547. techmetx11 has left

  548. thomaslewis has left

  549. gregory has left

  550. norayr has left

  551. larma

    Zash, looking at XEP 0045, I don't think Dino's behavior is wrong here

  552. larma

    Zash, looking at XEP 0045, I don't think Dinos behavior is wrong here

  553. gregory has joined

  554. Zash

    Not wrong, but non-cooperative with server-side stuff like these

  555. pep.

    (and also mod_pastebin? :P)

  556. Zash

    'these' as in mod_pastebin, mod_muc_restrict_media, mod_swedish_chef :)

  557. lovetox

    Zash i heard of that prosody feature also the first time now

  558. lovetox

    so how do you think client devs will discover that?

  559. lovetox

    i would expect at least that someone would open some feature request on our tracker to support that

  560. larma

    Zash, maybe, if you want this kind of cooperation, maybe spec it properly.

  561. larma

    0045 describes that the service can discard non-body content and if it does so, it should make a whitelist of supported namespaces discoverable. Blacklist is not supported. And any modifications of the body are also not supported.

  562. Zash

    Where does it say that? That would be news to me.

  563. larma

    which part?

  564. lovetox

    i second that, white/black list of namespaces Oo

  565. Zash

    Modifying body

  566. pep.

    What Matt linked earlier?

  567. pep.

    https://xmpp.org/extensions/xep-0045.html#impl-service-traffic ?

  568. Zash

    The service sends back the message. Up until recently, basically all clients would show what the MUC sent back.

  569. lovetox

    i read this the first time, amazing

  570. pep.

    Only using an allowlist seems quite restrictive

  571. lovetox

    pep., i think it makes sense

  572. lovetox

    if you want to restrict something, you want to have a whitelist, because the blacklist is potentially ininite

  573. lovetox

    if you want to restrict something, you want to have a whitelist, because the blacklist is potentially infinite

  574. larma

    https://xmpp.org/extensions/xep-0045.html#bizrules-message > A MUC service SHOULD pass extended information (e.g., an XHTML version of the message body) through to occupants unchanged; however, a MUC service MAY disallow message specific extensions

  575. pep.

    lovetox, if you want to allow anything but, you have to literally allow everything but, and you can't know 'everything'

  576. pep.

    larma, ah

  577. pep.

    Ah, through "Allowable traffic" again

  578. larma

    Whay you are effectively doing is "silently rejecting the incoming message and then sending a new message on the users behalf". However rejecting should typically cause an error message to be sent to the sender and generating a new message seems entirely out of spec for me.

  579. Zash

    And way too many occurrences of "body" to find if it disallows modifying it

  580. larma

    it's not explicit, it only speaks about reflecting the message with modified from

  581. dezant has left

  582. dezant has joined

  583. larma

    But given that for all other elements than body it's explicityly defined they need to be be passed unchanged, it is very stretch to assume it is intended to be allowed for body

  584. larma

    The proper solution to mod_pastebin defintely would be: Return an error message with description "Message to large, maybe upload to paste.example.org?"

  585. Zash

    SHOULD means doing the opposite is allowed if you have good reason, right? So you must be prepared to deal with it.

  586. lovetox

    i think its probably like with most things in XEPs, nobody thought of the use case, else they would have explicitly forbid or allowed it

  587. lovetox

    and now you go and interpret things into the XEP which probably are not there

  588. lovetox

    either way

  589. larma

    "I must be prepared" doesn't mean I must give perfect UX for it or allow the server to arbitrarily change my local database

  590. lovetox

    Zash, i dont see how you would care how Dino shows the Sending bit

  591. lovetox

    client can display that as it wants ..

  592. Zash

    I care because I used it and I liked being able to paste logs and patches into the chat without it taking up 3 screens.

  593. Zash

    Now I have to do roundabout things involving uploads.

  594. Zash

    Plus there's the thing Biboumi does with breaking multi-line messages into many.

  595. lovetox

    ah you used the the feature to shorten your own messages

  596. lovetox

    i understand

  597. larma

    Zash, sounds like you want a totally different client feature from Dino: "If outgoing message is large, ask user to send the text as a file instead"

  598. Zash

    Sure, that'd be great

  599. Zash

    But the thing is, the server sends you back what it sent everyone else, and it's nice to have a shared view of the chat.

  600. larma

    That would be totally fine with me and much more liked than "overwrite my local state of what the user sent with whatever the server sends"

  601. MattJ

    larma: returning an error and telling someone to use an external site kinda defeats the convenience of the module

  602. MattJ

    That's basically what IRC did 30 years ago

  603. moparisthebest

    With muc, what comes from the muc is the source of truth, if it didn't come from the muc it shouldn't be in your local state

  604. Zash

    Adding upload support to anonymous hosts is also ... uncomfortable.

  605. moparisthebest

    Expect maybe with a *send pending* flag

  606. larma

    MattJ, I hope XMPP is not IRC 30 years ago

  607. Zash

    Haven't people been asking for this reflection for 1:1 chats?

  608. MattJ

    You're proposing it, as I understand things 🙂

  609. moparisthebest

    Muc is slightly better IRC from 24 years ago right?

  610. lovetox

    but its also not nice, if a user sends a message, and gets back a pastebin link in its local history, how will the user search his historyß

  611. lovetox

    but its also not nice, if a user sends a message, and gets back a pastebin link in its local history, how will the user search his history?

  612. Zash

    IRC explicitly doesn't sent you back what you sent.

  613. gregory has left

  614. MattJ

    Which also leads to other things, like different people seeing different ordering

  615. Zash

    I'd also like to point out that mod_pastebin is almost as old as Prosody, and predates my involvement by years.

  616. lovetox

    effectively the pastbin link will become invalid, and then history is lost

  617. Zash

    or, at least a year?

  618. larma

    You only want the mod_pastebin thing in the case when users send log files or other text files as text instead as file

  619. MattJ

    Right, that's what it was written for

  620. larma

    which is a client issue if users do that

  621. MattJ

    Because reactive "please don't do that" was happening at least a few times per weej

  622. MattJ

    Because reactive "please don't do that" was happening at least a few times per week

  623. MattJ

    Then every XMPP client has this bug

  624. MattJ

    When will you fix it?

  625. larma

    As soon as servers announce their message size limit I guess

  626. gregory has joined

  627. MattJ

    Done 😇

  628. MattJ

    It's in disco

  629. dezant has left

  630. pep.

    Can I haz per-user length plz

  631. dezant has joined

  632. Zash

    Done 5 years ago

  633. pep.

    I was told it's not gonna work with MAM etc.

  634. antranigv has joined

  635. larma

    https://larma.de:5281/upload/7-ZZ_73EcNvSqnJe/Screenshot%20from%202023-01-22%2020-01-06.png

  636. Zash

    Isn't a Slack snippet a regular message prefixed and suffixed with ``` ?

  637. Millesimus has left

  638. antranigv has left

  639. larma

    Zash, no, snippet is a file

  640. larma

    Zash, no, snippet is a text file

  641. Zash

    Also, mod_pastebin does that, oob tag and everything. But since it leaves the first line, every client ignores it.

  642. Millesimus has joined

  643. larma

    The first few lines are displayed inline as a preview, to open the full text file you have to click additionally

  644. lovetox

    nice slack feature

  645. larma

    Slack does it client-side though

  646. lovetox

    so message-limit in muc is announced already in disco?

  647. Zash

    Also, what's the difference between the server overwriting your local state from mod_pastebin vs me sending a message correction from a different client?

  648. Zash

    ``` "{https://modules.prosody.im/mod_pastebin}max_characters": "1584", "{https://modules.prosody.im/mod_pastebin}max_lines": "12", ```

  649. lovetox

    i would say, the data is lost if its put into pastebin

  650. lovetox

    as i said, the link will become invalid

  651. lovetox

    the content will be lost

  652. lovetox

    i would expect my client to store the full message locally

  653. lovetox

    as file or whatever

  654. lovetox

    i think its funny that this discussion is done now a decade after pastebin mod

  655. moparisthebest

    Why? The pastebin is ran by the same server serving the muc

  656. larma

    Zash, now make this a XEP and put a proper namespace on it

  657. lovetox

    i think it served its purpose, but we can do better

  658. moparisthebest

    MAM limits can be identical

  659. larma

    moparisthebest, my local history is way longer than the MAM history in most rooms I am

  660. Zash

    I write code, not XEPs!

  661. moparisthebest

    larma: sounds like you want to write a XEP for a more IRC like muc v0.5 where the Source of truth isn't the muc, and it doesn't relay messages you sent to it

  662. moparisthebest

    But then you gotta have carbons, in order isn't preserved, it's a big step back

  663. moparisthebest

    Biboumi can't work

  664. larma

    The XEP is for exposing server message limits to the client

  665. xnamed has joined

  666. moparisthebest

    "error: this muc only supports one line per message" from biboumi I guess?

  667. larma

    so that a client knows before sending a message that the server doesn't like the message as is

  668. gregory has left

  669. larma

    and can decide to do *something* instead

  670. moparisthebest

    So all transports would need new XEPs to define crazy rules for clients to format messages

  671. gregory has joined

  672. larma

    moparisthebest, no I want a disco field max_lines_per_message=1 instead

  673. moparisthebest

    That's that I said? Each transport would need a XEP with formatting rules and all clients would have to implement them all before it would work

  674. larma

    legacy clients will still send multiline messages and biboumi will still split them, but clients understanding the limits can expose them to the user

  675. larma

    or whatever

  676. larma

    This is not about formatting

  677. larma

    This is about what clients can send to the server so that it is reflected unchanged

  678. moparisthebest

    Sounds far worse than the current system, where transports mangle the message however they need, and clients display what the muc actually sent

  679. antranigv has joined

  680. antranigv has left

  681. antranigv has joined

  682. antranigv has left

  683. larma

    Don't agree. Because transports won't be able to do it properly in all cases. The sending user knows how he wants stuff to be displayed at the recipient, so if what the send is what is received by others, no issues will occur.

  684. snow has left

  685. moparisthebest

    I think your proposal vs the current state of muc causes an impossible situation for all client devs (having to adapt to new remote service rules at the speed of changes by those remote services, that's way faster than Debian releases for instance), plus terrible ux for users

  686. larma

    I don't remember which transport was it (maybe biboumi) that split messages which are too long (not by number of lines, but number of chars) into multiple messages, but do that with python code where it totally matters if someone injects a newline at wrong place

  687. moparisthebest

    Now each user has to understand what transport they are connected to, and constantly get back "no, now it's too many lines, no, now too long of lines, etc etc"

  688. larma

    moparisthebest, huh? The way I'm thinking this, everything would work as is for old clients. Only new clients will tell the user "the recipient only supports up to 2000 chars per message, do you want to send a text file instead?" or someting like that.

  689. pep.

    breaking news, UX over transports is crap

  690. moparisthebest

    IRC has a line length limit indeed

  691. larma

    If you want UX over transports to improve, we need to get information about the transports (and its limits) to the clients and not hide it from them

  692. lovetox

    i think both sides are right, we need more info to provide better UX, but on the other side we should also deal with a MUC rewriting a body

  693. moparisthebest

    It's stupid to have XMPP users split their lines for IRC when the component can just do it

  694. moparisthebest

    I don't want to have to remember which MUCs are IRC and which aren't

  695. larma

    you seem to think your client can't be intelligent

  696. larma

    I'm not saying users have to do it

  697. moparisthebest

    Same thing, why should my client need to know about biboumi inner details

  698. larma

    e.g. the sending client can do it for you *and* tell you that it will do so *before* you send the message

  699. larma

    that's not biboumi inner deails

  700. xnamed has left

  701. Dele Olajide has joined

  702. larma

    that's really just three limits: - max chars per message - max chars per line - max lines per message

  703. moparisthebest

    Right now it gets done for you and you are told it's been done for you

  704. larma

    but only after the fact

  705. moparisthebest

    Except for all clients, by the muc

  706. larma

    when you already sent out crippled text

  707. moparisthebest

    Which is best case

  708. moparisthebest

    You think any user ever is going to press "oh no please don't just send this and let me manually fix it" ?

  709. moparisthebest

    If you want this terrible ux, write a XEP so MUC can give it to you

  710. moparisthebest

    Ie a flow like you send it, muc responds with "sorry I'll have to mangle it like so: "

  711. moparisthebest

    And the client can choose whether to send that or not

  712. larma

    Think of the following my client can do: - Display a note "The individual lines of this message will be seen as individual messages by the recipient" - Insert a line break after the max-chars-per-line limit in the input field so user will see where the line-break would be - Tell the user that the message is too large and should be sent as a file instead

  713. larma

    All of this would greatly improve UX

  714. larma

    moparisthebest, I *never* want the service to mangle with my messages

  715. moparisthebest

    Encoding all logic to what's acceptable for all remote protocols in each client is the path to insanity, it changes too much

  716. larma

    I understand there are reasons why the server would want to do it, and I want the client to know these reasons before so it can prevent it from happening

  717. larma

    nothing more, nothing less

  718. xnamed has joined

  719. larma

    I was literally saying 3 numbers that already cover 99% of the known cases

  720. moparisthebest

    larma: I'm saying it wouldn't, it would respond "I can't send the message that way for these reasons, I could send it reformated this way: $proposal"

  721. larma

    I was literally saying 3 variables that already cover 99% of the known cases. Why you wouldn't want my client to know these?

  722. moparisthebest

    That cover IRC and mod_pastebin only you mean

  723. larma

    which are 99% of the known cases

  724. larma

    why not just fix the issues we have instead of overly complicating things?

  725. moparisthebest

    What about msn, aim, icq, Google $protocol-of-the-week, signal, WhatsApp, Facebook, tiktok, I mean I could literally go on forever

  726. larma

    I'm thinking of these three limits plus information if they are soft or hard (where soft limit means "you can send, but server gonna do things" and heard means "server will reject/error"

  727. larma

    I'm thinking of these three limits plus information if they are soft or hard (where soft limit means "you can send, but server gonna do things" and heard means "server will reject/error")

  728. moparisthebest

    I think your proposal is vastly overcomplicating things for all clients forever, mine would let MUCs opt in

  729. larma

    Clients can entirely ignore my proposal and would continue to work as is

  730. PapaTutuWawa has left

  731. larma

    It's entirely optional allowing clients to optimize UX where they see possibilities.

  732. larma

    No harm done

  733. moparisthebest

    These 3 are easy but then when nicoco introduces 99999 more for slidge

  734. larma

    Then clients may decide to not implement those.

  735. larma

    All done.

  736. larma

    Status quo preserved with no additional work

  737. spectrum has joined

  738. moparisthebest

    But all clients need to display what the muc says they sent, not what the client thinks they sent

  739. larma

    moparisthebest, all clients can display anything they want. That's totally up to them (and that is also the status quo)

  740. moparisthebest

    I don't think so, that's why Dino is broken and no other clients are

  741. larma

    Also when it comes to slidge: we're already discussing how slidge will communicate the possible reactions to the client because some networks don't support all reactions. The client should know the limits or UX will be worse.

  742. larma

    Dino works perfectly well for me 🙂

  743. moparisthebest

    With muc what the muc sends is the source of truth, a client that guesses what it'll send is incorrect

  744. larma

    "source of truth" to whom?

  745. moparisthebest

    If you don't like it, propose some negotiation where the muc doesn't do this

  746. moparisthebest

    Per the spec

  747. PapaTutuWawa has joined

  748. larma

    what if the MUC sends different messages to different participants

  749. larma

    what's the truth then?

  750. moparisthebest

    What the muc says

  751. larma

    it says different things

  752. larma

    so there are multiple truth?

  753. moparisthebest

    What it says to you

  754. larma

    who is me?

  755. moparisthebest

    Your client

  756. larma

    What if my clients receives different things in multiple requests?

  757. rom1dep

    I think it would be useful for the MUC to return in a human-readable way why and how the message was rewritten (so the user gets to know what happened and why it happened), but I think it's insane to expect a formal description of all constraints, rules and limitations any past, present and future MUC/gateway/protocol may be subjecting arbitrary messages to.

  758. moparisthebest

    Then the truth is different for each client :)

  759. larma

    moparisthebest, that's not how "truth" works

  760. moparisthebest

    (that's actually the situation you have now right? Only the sending Dino has incorrect history)

  761. rom1dep

    larma: if different clients show different messages, as a naive user, I consider them (or the protocol) broken

  762. moparisthebest

    Sure it is, something something observing something changes it bla bla

  763. larma

    truth is: user A wants to send message B to users C and D in the MUC. If user C receives message E instead, that doesn't change the truth what user A wanted to send.

  764. rom1dep

    knowing how other get to see my messages is pretty fundamental

  765. larma

    And as the sending client I happen to know for sure what message B is.

  766. moparisthebest

    Right, but we don't care about what user a wanted to send, we care about what was sent

  767. larma

    I disagree

  768. larma

    that's literally why we sign and e2ee messages.

  769. rom1dep

    > truth is: user A wants to send message B to users C and D in the MUC. If user C receives message E instead, that doesn't change the truth what user A wanted to send. that doesn't change what A wanted to send, but then it can create a lot of confusion and qui-proquo

  770. gregory has left

  771. moparisthebest

    The truth is what was sent, and for the sending client only to have a different view (than even his other Dinos) is pretty clearly wrong

  772. rom1dep

    I think it's a pretty universal assumption that all participants within a same discussion get to see the same content

  773. larma

    moparisthebest, it totally is wrong, that's why I want to change that, but not by letting the server rewite my messages

  774. larma

    why can't we just try to make sure that the message user A sends is what is shown to users C and D?

  775. rom1dep

    larma, I think it's fine that the server rewrites the messages if the client is provided enough context. You can display the rewritten message as other sees it, with a warning & reason for rewriting and a way to show the original if needed

  776. snow has joined

  777. gregory has joined

  778. moparisthebest

    So propose a negotiated change to the spec, but when that new thing isn't negotiated, fix Dino to display what the muc sent

  779. larma

    It's only fine if the user knows how stuff would be rewritten before he sends the message in which case the client can also just do it for him

  780. larma

    moparisthebest, that's not how this works here

  781. moparisthebest

    I mean or keep Dino broken for current behavior unlike all other clients, your playhouse your rules

  782. pep.

    moparisthebest, if Dino wants to have this information and use it, let it have it?

  783. moparisthebest

    Absolutely, that's the new spec thing we just talked about?

  784. pep.

    yeah I guess. I don't really understand what you're ranting about :)

  785. rom1dep

    larma: I think it's very ambitious to expect the client to be able to do that. You would have to share the same processing logic on the client and server otherwise you would have no guarantee that your client did a good rewrite job. I don't see how that can be solved generically and safely

  786. moparisthebest

    But currently, if I send a message the muc rewrite, I see the message everyone else sees, on the sending client, all my other joined clients, and other people's clients *except* if the sending client is Dino and then I see something else, to me that's a crystal clear Dino bug

  787. rom1dep

    yup

  788. larma

    If we don't find other solutions what I'd rather want to do: - Add proper inline preview for text files, if the server replaces the message with a link to a file like mod_pastebin, check if the file content's match the sent message and then display the message as a inline text file preview. This way, all Dinos will see the message the same way. - For the Biboumi splitting case, detect the message reflected being split into multiple and make sure to not display any content twice.

  789. rom1dep

    larma: what if the constraint isn't about message length, but about e.g. forbidden characters for protocols not supporting e.g. UTF (like e.g. SMS), how would you go about exchanging this info with the server? It's an endless complexity pit

  790. rom1dep

    larma: even in case 1, it's potentially very important for the user to know what the pastebin link is

  791. larma

    Don't other clients display the link as file because it has an oob tag?

  792. larma

    Let's be precise: I want Dinos on both sides of the MUC to display the same or mostly similar message, but still make sure that misbehaving servers can't arbitrarily change my outgoing message history. Whatever that means.

  793. rom1dep

    > Let's be precise: I want Dinos on both sides of the MUC to display the same or mostly similar message, but still make sure that misbehaving servers can't arbitrarily change my outgoing message history. Whatever that means. > misbehaving servers what if it's a feature?

  794. Zash

    E2EE?

  795. jubalh has left

  796. moparisthebest

    If it helps you aren't sending the message, you are just asking the muc to send it on behalf of the username you are currently connected with

  797. larma

    Zash, in the end, yes probably

  798. larma

    Have messages in public MUCs signed is certainly an interesting option

  799. moparisthebest

    The muc sends it, and it can change it if it wants

  800. moparisthebest

    It'd deanonymize people worse than avatars currently do

  801. Dele Olajide has left

  802. pep.

    larma said public MUC for a reason

  803. larma

    moparisthebest, if you want so, I might be jsut asking the MUC to send it, but I ask it to send it *exactly as I sent it*

  804. moparisthebest

    That's not what the XEP says... At least not last time I looked at it lol

  805. larma

    > A MUC service SHOULD pass extended information (e.g., an XHTML version of the message body) through to occupants unchanged; however, a MUC service MAY disallow message specific extensions

  806. moparisthebest

    You can't arbitrarily impose "MUCs MUST not alter messages" after 2+ decades of them doing it without negotiation

  807. larma

    It's not a MUST, it's a SHOULD

  808. moparisthebest

    SHOULD is not MUST, and that doesn't mention body

  809. larma

    I'm asking the MUC to send it exactly as is, but the MUC of course can ignore that and send it diffrently

  810. larma

    still that's what I'm asking for

  811. larma

    Certainly the XEP authors thought "the muc should send the XHTML body unchanged, but it's very much desired that it changes the normal body"

  812. moparisthebest

    New negotiation for a muc to do that seems fine

  813. moparisthebest

    Thoughts don't matter, only text and running code... Well really only running code

  814. larma

    You seem to misunderstand. I don't want to add complexity to MUCs, I want to add complexity to *my* client exclusively.

  815. TheCoffeMaker has left

  816. moparisthebest

    Why does muc reply with what was sent if clients weren't supposed to use it

  817. xnamed has left

  818. rom1dep

    but would leak into MUC wouldn't it? Or how would it signify to dino what its conditions and means for message rewrites are about?

  819. larma

    moparisthebest, because of ordering. Same as for presence.

  820. moparisthebest

    larma: they don't need to send the body for ordering

  821. larma

    Now please don't tell me that you think that servers are supposed to change a joining user's presence status text just because they can.

  822. jubalh has joined

  823. xnamed has joined

  824. dezant has left

  825. moparisthebest

    If the spec doesn't say MUST NOT then sure

  826. moparisthebest

    Perhaps a muc hosted in Germany and a user joins with a holocaust denial presence

  827. moparisthebest

    Remember when clients failed to log in if the server didn't take their bind preference

  828. TheCoffeMaker has joined

  829. jubalh has left

  830. larma

    I guess we have different understanding of what the RFC2119 terms are supposed to mean

  831. antranigv has joined

  832. larma

    If something is SHOULD NOT and you are doing it anyways, you are to blame if it causes problems.

  833. antranigv has left

  834. larma

    because apparently, you did not understand the full implications before implementing

  835. larma

    aka, changing the body may cause the sending client and the receiving client to have different understanding of what was sent and you have to understand and accept that before doing so

  836. jubalh has joined

  837. moparisthebest

    You cannot rely on SHOULD behavior, that's why it's not a MUST

  838. xnamed has left

  839. larma

    I'm not relying on SHOULD behavior. Is Dino crashing, deleting your hard drive or doing anything else than just displaying a history of the messages you sent mangled with the history of messages from others you received?

  840. larma

    I'm not relying on SHOULD behavior. Is Dino crashing, deleting your hard drive or doing anything else than just displaying a history of the messages you sent merged with the history of messages from others you received?

  841. larma

    You seem to wrongly expect that Dino displays the messages as the MUC seees them, but Dino displays the messages it sent merged with the messages it received from others. Which is by the way exactly what it does in 1:1 chats

  842. larma

    You seem to wrongly expect that Dino displays the messages as the MUC seees them, but Dino displays the messages it sent merged with the messages it received from others. Which is by the way also exactly what it does in 1:1 chats, so it's being 100% consistent here.

  843. larma

    You are basically asking Dino to change it's behavior to better reflect what others wanted to reach when they decided to do something they shouldn't even be doing.

  844. larma

    You are basically asking Dino to change its behavior to better reflect what others wanted to reach when they decided to do something they shouldn't even be doing.

  845. kapad has left

  846. MSavoritias (fae,ve) has left

  847. john-machine has left

  848. moparisthebest

    That's just how the spec and all other clients work 🤷‍♂️

  849. jubalh has left

  850. larma has left

  851. Maranda[x] has left

  852. spiral has left

  853. xnamed has joined

  854. moparisthebest has left

  855. jubalh has joined

  856. moparisthebest has joined

  857. xnamed has left

  858. raghavgururajan has left

  859. Maranda[x] has joined

  860. marc has left

  861. marc has joined

  862. Maranda has joined

  863. atomicwatch has left

  864. Kev has joined

  865. Kev has left

  866. atomicwatch has joined

  867. norayr has joined

  868. marc0s has left

  869. marc0s has joined

  870. wurstsalat

    https://xmpp.org/extensions/xep-0382.html comes to my mind. But client's would have to send it like that in the first place

  871. gregory has left

  872. gregory has joined

  873. jubalh has left

  874. spiral has joined

  875. marc0s has left

  876. marc0s has joined

  877. EOF has left

  878. marc0s has left

  879. marc0s has joined

  880. Kev has joined

  881. xnamed has joined

  882. Kev has left

  883. Kev has joined

  884. Kev has left

  885. EOF has joined

  886. marc0s has left

  887. marc0s has joined

  888. atomicwatch has left

  889. atomicwatch has joined

  890. Yagizа has left

  891. edhelas has left

  892. edhelas has joined

  893. Mjolnir Archon has joined

  894. kapad has joined

  895. EOF has left

  896. EOF has joined

  897. EOF has left

  898. lovetox

    em larma, MUC does rewrite presence the client sends

  899. lovetox

    last i remember you sending a join presence to a muc, it can return the presence with a different nick

  900. EOF has joined

  901. homebeach has left

  902. Matrix Traveler (bot) has left

  903. Millesimus has left

  904. lovetox

    or at least i think that was an option for the muc, and im not imagining that

  905. spiral has left

  906. homebeach has joined

  907. Matrix Traveler (bot) has joined

  908. snow has left

  909. spiral has joined

  910. marc0s has left

  911. lovetox

    > The service MAY rewrite the new occupant's roomnick (e.g., if roomnicks are locked down or based on some other policy). > > The service MUST allow the client to enter the room, modify the nick in accordance with the lockdown policy, and include a status code of "210" in the presence broadcast that it sends to the new occupant.

  912. Alex has left

  913. lovetox

    i dont say i know what the initial authors of the MUC XEP intended, but to me the XEP always read like the Server is the source of truth, everything we send is just a "request" and we will receive later if it was accepted or not.

  914. lovetox

    and in this mode, its

  915. lovetox

    but i think nobody ever thought of rewriting the body, so we are left now guessing if this was intended or not

  916. gregory has left

  917. gregory has joined

  918. EOF has left

  919. Trung has joined

  920. Millesimus has joined

  921. EOF has joined

  922. Mario Sabatino has left

  923. mirux has left

  924. Menel

    Prosody is rewriting the body since 1989, so In think it is ok. Regardless of what was an intent. Its more important what's written and what's done in real life. Dino is also not wrong in showing what it wants. I don't think there is specified what the client *must* show. So its less important to argue if something if it is wrong, (I think none are wrong) but to decide if and what to do, without searching the answer in the XEP. Because is isn't there.

  925. EOF has left

  926. EOF has joined

  927. soulcaramel has left

  928. Trung has left

  929. soulcaramel has joined

  930. EOF has left

  931. PapaTutuWawa has left

  932. moparisthebest

    +1 Menel

  933. soulcaramel has left

  934. soulcaramel has joined

  935. EOF has joined

  936. goffi has left

  937. Trung has joined

  938. Trung has left

  939. Beherit has left

  940. Millesimus has left

  941. Dele Olajide has joined

  942. snow has joined

  943. atomicwatch has left

  944. stefan has left

  945. Millesimus has joined

  946. Trung has joined

  947. Trung has left

  948. Trung has joined

  949. edhelas has left

  950. edhelas has joined

  951. Millesimus has left

  952. Trung has left

  953. lovetox has left

  954. Maranda[x] has left

  955. Millesimus has joined

  956. Maranda[x] has joined

  957. gregory has left

  958. techmetx11 has joined

  959. gregory has joined

  960. Dele Olajide has left

  961. adx has joined