XSF Discussion - 2022-04-27


  1. adiaholic has joined
  2. adiaholic has left
  3. restive_monk has joined
  4. adiaholic has joined
  5. krauq has left
  6. krauq has joined
  7. adiaholic has left
  8. libre has left
  9. libre has joined
  10. djorz has left
  11. libre has left
  12. arc has left
  13. arc has joined
  14. libre has joined
  15. restive_monk has left
  16. lskdjf has left
  17. millesimus has left
  18. millesimus has joined
  19. restive_monk has joined
  20. libre has left
  21. libre has joined
  22. libre has left
  23. libre has joined
  24. libre has left
  25. libre has joined
  26. libre has left
  27. libre has joined
  28. daags has joined
  29. qwestion has left
  30. arc has left
  31. arc has joined
  32. neshtaxmpp has joined
  33. Steve Kille has left
  34. adiaholic has joined
  35. Steve Kille has joined
  36. Steve Kille has left
  37. Steve Kille has joined
  38. libre has left
  39. libre has joined
  40. libre has left
  41. libre has joined
  42. libre has left
  43. neshtaxmpp has left
  44. neshtaxmpp has joined
  45. libre has joined
  46. Half-Shot has left
  47. homebeach has left
  48. Matthew has left
  49. uhoreg has left
  50. Half-Shot has joined
  51. Matthew has joined
  52. homebeach has joined
  53. uhoreg has joined
  54. libre has left
  55. libre has joined
  56. adiaholic has left
  57. libre has left
  58. Sam has left
  59. alacer has left
  60. alacer has joined
  61. neshtaxmpp has left
  62. adiaholic has joined
  63. libre has joined
  64. Yagiza has joined
  65. arc has left
  66. arc has joined
  67. harry837374884 has left
  68. harry837374884 has joined
  69. libre has left
  70. libre has joined
  71. Half-Shot has left
  72. homebeach has left
  73. Matthew has left
  74. uhoreg has left
  75. Half-Shot has joined
  76. Matthew has joined
  77. homebeach has joined
  78. uhoreg has joined
  79. libre has left
  80. libre has joined
  81. libre has left
  82. libre has joined
  83. arc has left
  84. arc has joined
  85. Toxi has left
  86. Toxi has joined
  87. alacer has left
  88. alacer has joined
  89. alacer has left
  90. arc has left
  91. arc has joined
  92. arc has left
  93. arc has joined
  94. adiaholic has left
  95. adiaholic has joined
  96. sbach has left
  97. sbach has joined
  98. sbach has left
  99. sbach has joined
  100. arc has left
  101. arc has joined
  102. adiaholic has left
  103. adiaholic has joined
  104. Menel has joined
  105. restive_monk has left
  106. Seve has joined
  107. sbach has left
  108. sbach has joined
  109. adiaholic has left
  110. sbach has left
  111. sbach has joined
  112. adiaholic has joined
  113. mimi89999 has left
  114. raghavgururajan has left
  115. mimi89999 has joined
  116. neshtaxmpp has joined
  117. arc has left
  118. arc has joined
  119. restive_monk has joined
  120. karoshi has joined
  121. Tobias has joined
  122. adiaholic has left
  123. arc has left
  124. arc has joined
  125. adiaholic has joined
  126. adiaholic has left
  127. adiaholic has joined
  128. mdosch has left
  129. mdosch has joined
  130. adiaholic has left
  131. adiaholic has joined
  132. Tobias has left
  133. Tobias has joined
  134. Tobias has left
  135. Tobias has joined
  136. adiaholic has left
  137. adiaholic has joined
  138. marc0s has left
  139. marc0s has joined
  140. COM8 has joined
  141. COM8 has left
  142. arc has left
  143. arc has joined
  144. harry837374884 has left
  145. harry837374884 has joined
  146. adiaholic has left
  147. adiaholic has joined
  148. restive_monk has left
  149. arc has left
  150. arc has joined
  151. intosi has joined
  152. adiaholic has left
  153. adiaholic has joined
  154. wurstsalat has joined
  155. ti_gj06 has joined
  156. atomicwatch has joined
  157. marc0s has left
  158. marc0s has joined
  159. sbach has left
  160. sbach has joined
  161. sonny has joined
  162. marc0s has left
  163. marc0s has joined
  164. mh has left
  165. jcbrand has joined
  166. mh has joined
  167. libre has left
  168. L29Ah has left
  169. L29Ah has joined
  170. sbach has left
  171. sbach has joined
  172. intosi has left
  173. intosi has joined
  174. konstantinos has joined
  175. restive_monk has joined
  176. melvo has left
  177. antranigv has joined
  178. marc has joined
  179. Paganini has left
  180. Kev has joined
  181. adiaholic has left
  182. adiaholic has joined
  183. marc0s has left
  184. marc0s has joined
  185. arc has left
  186. arc has joined
  187. marc0s has left
  188. marc0s has joined
  189. djorz has joined
  190. adiaholic has left
  191. tykayn has joined
  192. marc has left
  193. APach has left
  194. Dele Olajide has joined
  195. marc has joined
  196. yushyin has left
  197. Dele has joined
  198. Dele has left
  199. arc has left
  200. arc has joined
  201. jgart has left
  202. msavoritias has joined
  203. yushyin has joined
  204. djorz has left
  205. adiaholic has joined
  206. debacle has joined
  207. L29Ah has left
  208. L29Ah has joined
  209. arc has left
  210. arc has joined
  211. djorz has joined
  212. adiaholic has left
  213. paul has left
  214. paul has joined
  215. arc has left
  216. Fishbowler has left
  217. Fishbowler has joined
  218. arc has joined
  219. intosi has left
  220. intosi has joined
  221. intosi has left
  222. intosi has joined
  223. Titi has joined
  224. djorz has left
  225. Alex has left
  226. Ingolf has left
  227. Alex has joined
  228. arc has left
  229. arc has joined
  230. Fishbowler has left
  231. Fishbowler has joined
  232. xnamed has joined
  233. tykayn has left
  234. msavoritias I think what moparisthebest said is correct. Basically i see it going like this: 1. User enables the feature. Client says something like: "We cant quarantee the messages are not screenshoted or forwarded or the feature bypassed in some way. The deleting will be done best effort". The user bob enables the ephemeral messages with user alice. And from here we have 2 scenarios that we need to warn the user about. 1. Alice's client sends back that it doesnt support the feature. So we say to the user this cant be enabled here because it wont work. I feel like this is the best responce to send to the user since we know for sure in this scenario. 2. Alice's client sends back that it supports the feature. At a later date/time she switches to her desktop client that doesnt support the feature. I think two things should be clear here: a. We shouldnt expect the users to know when or if their client supports or not the feature. b. We should communicate to the user that their contact changed to a client not supporting the xep which meant the spec cant be honored. Personally here i see the only good choice from a client perspective to be to disable the feature. That probably does get us to a MIX or OMEMO situation as you said pep. in which you have to wait for a lot of clients to implement it before we can use it. I am not sure how else it can be done though. Personally i wouldnt want to ignore and keep it enabled when somebody switched to an unsupported client. Maybe it can be done as it was mentioned to get a list of the devices in the begining and query from there if they support it.
  235. marc0s has left
  236. marc0s has joined
  237. jonas’ > Alice's client sends […] It may not even be online (and most likely isn't if it's an iOS device).
  238. goffi has joined
  239. tykayn has joined
  240. L29Ah has left
  241. arc has left
  242. lovetox has left
  243. harry837374884 has left
  244. arc has joined
  245. intosi has left
  246. msavoritias Also true. So querying doesnt even work. Also Alice may start using new clients. Maybe it should just be when the client get message that doesnt have the timer field he disables the feature because he cant trust the client anymore.
  247. inky has left
  248. restive_monk has left
  249. mjk has joined
  250. restive_monk has joined
  251. konstantinos has left
  252. adiaholic has joined
  253. lovetox has joined
  254. debacle has left
  255. lskdjf has joined
  256. adiaholic has left
  257. debacle has joined
  258. intosi has joined
  259. intosi has left
  260. intosi has joined
  261. pasdesushi has joined
  262. inky has joined
  263. millesimus > 1. User enables the feature. Client says something like: "We cant quarantee the messages are not screenshoted or forwarded or the feature bypassed in some way. The deleting will be done best effort". I'd suggest the clients say something like: "Ephemeral messages are a technical way of asking your chat partner to delete the messages. If you ask them directly, there is no way to control their behaviour; and it's the same with ephemeral messages." Ephemeral messages are no security feature, but they are way less awkward then asking your chat partner to delete the messages.
  264. Dele Olajide has left
  265. Dele Olajide has joined
  266. Dele Olajide has left
  267. Dele Olajide has joined
  268. restive_monk has left
  269. Guus has left
  270. Guus has joined
  271. lovetox has left
  272. Dele Olajide has left
  273. Dele Olajide has joined
  274. Andrzej has joined
  275. Andrzej has left
  276. Andrzej has joined
  277. lovetox has joined
  278. konstantinos has joined
  279. marc0s has left
  280. marc0s has joined
  281. intosi has left
  282. ti_gj06 has left
  283. stp has joined
  284. Andrzej has left
  285. marc0s has left
  286. marc0s has joined
  287. intosi has joined
  288. Wojtek has joined
  289. Ingolf has joined
  290. Andrzej has joined
  291. mjk > b. We should communicate to the user that their contact changed to a client not supporting the xep which meant the spec cant be honored. It still can, counter-intuitively! :) A supporting client may come online a minute after the conversation is done, fetch archive, see no TTLs and go "welp, no can do, Imma keepin this forever!"
  292. restive_monk has joined
  293. arc has left
  294. antranigv has left
  295. antranigv has joined
  296. arc has joined
  297. lovetox has left
  298. tykayn has left
  299. stp has left
  300. adiaholic has joined
  301. restive_monk has left
  302. adiaholic has left
  303. raucao has left
  304. arc has left
  305. raucao has joined
  306. arc has joined
  307. arc has left
  308. intosi has left
  309. COM8 has joined
  310. COM8 has left
  311. arc has joined
  312. marc0s has left
  313. marc0s has joined
  314. marc0s has left
  315. marc0s has joined
  316. debacle has left
  317. Maranda has left
  318. Mjolnir Archon has left
  319. brunrobe has left
  320. marc0s has left
  321. marc0s has joined
  322. Menel has left
  323. Half-Shot has left
  324. homebeach has left
  325. Matthew has left
  326. uhoreg has left
  327. Half-Shot has joined
  328. Matthew has joined
  329. homebeach has joined
  330. uhoreg has joined
  331. restive_monk has joined
  332. lovetox has joined
  333. Menel has joined
  334. brunrobe has joined
  335. restive_monk has left
  336. Ingolf has left
  337. marc0s has left
  338. marc0s has joined
  339. marc0s has left
  340. marc0s has joined
  341. debacle has joined
  342. Andrzej has left
  343. lovetox has left
  344. Maranda has joined
  345. Mjolnir Archon has joined
  346. gooya has joined
  347. lovetox has joined
  348. arc has left
  349. arc has joined
  350. adiaholic has joined
  351. ti_gj06 has joined
  352. marc0s has left
  353. marc0s has joined
  354. marc0s has left
  355. marc0s has joined
  356. atomicwatch has left
  357. atomicwatch has joined
  358. marc0s has left
  359. marc0s has joined
  360. marc0s has left
  361. marc0s has joined
  362. marc0s has left
  363. marc0s has joined
  364. restive_monk has joined
  365. arc has left
  366. Toxi has left
  367. adiaholic has left
  368. arc has joined
  369. adiaholic has joined
  370. atomicwatch has left
  371. atomicwatch has joined
  372. harry837374884 has joined
  373. adiaholic has left
  374. Maranda[x] has left
  375. Maranda[x] has joined
  376. arc has left
  377. bean has joined
  378. harry837374884 has left
  379. harry837374884 has joined
  380. adiaholic has joined
  381. arc has joined
  382. Toxi has joined
  383. COM8 has joined
  384. COM8 has left
  385. adiaholic has left
  386. arc has left
  387. arc has joined
  388. adiaholic has joined
  389. sonny has left
  390. adiaholic has left
  391. harry837374884 has left
  392. harry837374884 has joined
  393. ti_gj06 has left
  394. emus has joined
  395. adiaholic has joined
  396. restive_monk has left
  397. adiaholic has left
  398. adiaholic has joined
  399. lovetox has left
  400. konstantinos has left
  401. վարյա has joined
  402. konstantinos has joined
  403. sonny has joined
  404. վարյա has left
  405. վարյա has joined
  406. adiaholic has left
  407. Sam has joined
  408. adiaholic has joined
  409. վարյա has left
  410. վարյա has joined
  411. lovetox has joined
  412. Half-Shot has left
  413. homebeach has left
  414. Matthew has left
  415. uhoreg has left
  416. Half-Shot has joined
  417. Matthew has joined
  418. homebeach has joined
  419. uhoreg has joined
  420. harry837374884 has left
  421. adiaholic has left
  422. harry837374884 has joined
  423. վարյա has left
  424. վարյա has joined
  425. konstantinos has left
  426. restive_monk has joined
  427. konstantinos has joined
  428. adiaholic has joined
  429. վարյա has left
  430. վարյա has joined
  431. mjk has left
  432. mjk has joined
  433. Half-Shot has left
  434. homebeach has left
  435. Matthew has left
  436. uhoreg has left
  437. Half-Shot has joined
  438. Matthew has joined
  439. homebeach has joined
  440. uhoreg has joined
  441. restive_monk has left
  442. վարյա has left
  443. վարյա has joined
  444. adiaholic has left
  445. sonny has left
  446. robertooo has left
  447. antranigv has left
  448. վարյա has left
  449. վարյա has joined
  450. antranigv has joined
  451. Half-Shot has left
  452. homebeach has left
  453. Matthew has left
  454. uhoreg has left
  455. Half-Shot has joined
  456. Matthew has joined
  457. homebeach has joined
  458. uhoreg has joined
  459. antranigv has left
  460. antranigv has joined
  461. Half-Shot has left
  462. homebeach has left
  463. Matthew has left
  464. uhoreg has left
  465. Half-Shot has joined
  466. Matthew has joined
  467. homebeach has joined
  468. uhoreg has joined
  469. antranigv has left
  470. antranigv has joined
  471. sonny has joined
  472. adiaholic has joined
  473. Menel has left
  474. robertooo has joined
  475. Toxi has left
  476. Toxi has joined
  477. antranigv has left
  478. twisted firestarter has left
  479. konstantinos has left
  480. Wojtek has left
  481. arc has left
  482. arc has joined
  483. Guus has left
  484. Guus has joined
  485. վարյա has left
  486. վարյա has joined
  487. adiaholic has left
  488. վարյա has left
  489. վարյա has joined
  490. antranigv has joined
  491. adiaholic has joined
  492. վարյա has left
  493. վարյա has joined
  494. xecks has left
  495. xecks has joined
  496. kurisu has left
  497. L29Ah has joined
  498. antranigv has left
  499. վարյա has left
  500. վարյա has joined
  501. mjk has left
  502. mjk has joined
  503. Guus has left
  504. Guus has joined
  505. arc has left
  506. Guus has left
  507. Guus has joined
  508. վարյա has left
  509. վարյա has joined
  510. arc has joined
  511. վարյա has left
  512. վարյա has joined
  513. adiaholic has left
  514. adiaholic has joined
  515. arc has left
  516. arc has joined
  517. վարյա has left
  518. վարյա has joined
  519. Half-Shot has left
  520. homebeach has left
  521. Matthew has left
  522. uhoreg has left
  523. Half-Shot has joined
  524. Matthew has joined
  525. homebeach has joined
  526. uhoreg has joined
  527. libre has joined
  528. libre has left
  529. վարյա has left
  530. վարյա has joined
  531. libre has joined
  532. libre has left
  533. libre has joined
  534. arc has left
  535. restive_monk has joined
  536. stp has joined
  537. arc has joined
  538. վարյա has left
  539. վարյա has joined
  540. վարյա has left
  541. վարյա has joined
  542. վարյա has left
  543. վարյա has joined
  544. southerntofu has joined
  545. arc has left
  546. arc has joined
  547. Half-Shot has left
  548. homebeach has left
  549. Matthew has left
  550. uhoreg has left
  551. Half-Shot has joined
  552. Matthew has joined
  553. homebeach has joined
  554. uhoreg has joined
  555. Dele Olajide has left
  556. marc0s has left
  557. marc0s has joined
  558. marc0s has left
  559. marc0s has joined
  560. վարյա has left
  561. վարյա has joined
  562. adiaholic has left
  563. raghavgururajan has joined
  564. chipmnk has left
  565. վարյա has left
  566. վարյա has joined
  567. harry837374884 has left
  568. neshtaxmpp has left
  569. neshtaxmpp has joined
  570. adiaholic has joined
  571. վարյա has left
  572. վարյա has joined
  573. Dele Olajide has joined
  574. adiaholic has left
  575. վարյա has left
  576. վարյա has joined
  577. adiaholic has joined
  578. harry837374884 has joined
  579. tykayn has joined
  580. Calvin has joined
  581. վարյա has left
  582. վարյա has joined
  583. վարյա has left
  584. վարյա has joined
  585. adiaholic has left
  586. marc0s has left
  587. marc0s has joined
  588. marc0s has left
  589. marc0s has joined
  590. libre has left
  591. Calvin has left
  592. Calvin has joined
  593. adiaholic has joined
  594. marc0s has left
  595. marc0s has joined
  596. edhelas Would it be interesting to expose the account creation date ?
  597. edhelas For spam purpose it could be interesting
  598. edhelas But also for clients to know when the user joined the network
  599. moparisthebest edhelas, so the server is injecting it then ?
  600. edhelas Of course the servers can lie about it
  601. Zash Lies, on the Internet? UNPOSSIBLE
  602. millesimus has left
  603. millesimus has joined
  604. pep. edhelas, I'd rather not encourage that :/
  605. Guus has left
  606. Guus has joined
  607. Guus has left
  608. Guus has joined
  609. վարյա has left
  610. վարյա has joined
  611. lovetox has left
  612. restive_monk has left
  613. wladmis has left
  614. Calvin has left
  615. Daniel has left
  616. Daniel has joined
  617. wladmis has joined
  618. adiaholic has left
  619. lovetox has joined
  620. Link Mauve edhelas, some servers don’t have this information.
  621. gooya has left
  622. restive_monk has joined
  623. Guus has left
  624. Guus has joined
  625. վարյա has left
  626. վարյա has joined
  627. kurisu has joined
  628. marc0s has left
  629. marc0s has joined
  630. adiaholic has joined
  631. L29Ah has left
  632. Menel has joined
  633. arc has left
  634. arc has joined
  635. restive_monk has left
  636. վարյա has left
  637. վարյա has joined
  638. վարյա has left
  639. վարյա has joined
  640. atomicwatch has left
  641. BASSGOD has left
  642. arc has left
  643. arc has joined
  644. Andrzej has joined
  645. վարյա has left
  646. վարյա has joined
  647. adiaholic has left
  648. adiaholic has joined
  649. Dele Olajide has left
  650. L29Ah has joined
  651. վարյա has left
  652. վարյա has joined
  653. BASSGOD has joined
  654. adiaholic has left
  655. atomicwatch has joined
  656. L29Ah has left
  657. վարյա has left
  658. վարյա has joined
  659. adiaholic has joined
  660. BASSGOD has left
  661. վարյա has left
  662. վարյա has joined
  663. Dele Olajide has joined
  664. Calvin has joined
  665. վարյա has left
  666. Paganini has joined
  667. marc0s has left
  668. marc0s has joined
  669. վարյա has joined
  670. Half-Shot has left
  671. homebeach has left
  672. Matthew has left
  673. uhoreg has left
  674. Half-Shot has joined
  675. Matthew has joined
  676. homebeach has joined
  677. uhoreg has joined
  678. TheCoffeMaker Regarding the ephemeral messages ... What will happend with CC if like exposed msavoritias we have a mix of client supporting or not that feature?
  679. TheCoffeMaker Regarding the ephemeral messages ... What will happend with CC, if like exposed msavoritias, we have a mix of client supporting or not that feature?
  680. marc0s has left
  681. marc0s has joined
  682. marc0s has left
  683. marc0s has joined
  684. marc0s has left
  685. marc0s has joined
  686. marc0s has left
  687. marc0s has joined
  688. վարյա has left
  689. վարյա has joined
  690. pep. In the current spec, the message is still being sent, because the goal isn't to break compatibility with existing clients, the goal is medium to long term to have clients switch their default logging policy: either using this feature, or by having users bully clients to change their default storage policy (because it's a thing that works, unfortunately.. free software projects aren't the most democratic), rendering this spec obsolete.
  691. TheCoffeMaker 👌
  692. libre has joined
  693. restive_monk has joined
  694. libre has left
  695. adiaholic has left
  696. Guus has left
  697. Guus has joined
  698. crypt has joined
  699. twisted firestarter has joined
  700. gooya has joined
  701. BASSGOD has joined
  702. վարյա has left
  703. վարյա has joined
  704. konstantinos has joined
  705. adiaholic has joined
  706. վարյա has left
  707. վարյա has joined
  708. Guus has left
  709. Guus has joined
  710. gooya has left
  711. gooya has joined
  712. Guus has left
  713. Guus has joined
  714. Steve Kille has left
  715. վարյա has left
  716. վարյա has joined
  717. վարյա has left
  718. վարյա has joined
  719. stp has left
  720. konstantinos has left
  721. twisted firestarter has left
  722. վարյա has left
  723. վարյա has joined
  724. adiaholic has left
  725. վարյա has left
  726. վարյա has joined
  727. վարյա has left
  728. վարյա has joined
  729. Steve Kille has joined
  730. վարյա has left
  731. վարյա has joined
  732. wladmis has left
  733. wladmis has joined
  734. Guus has left
  735. Guus has joined
  736. stp has joined
  737. arc has left
  738. arc has joined
  739. djorz has joined
  740. arc has left
  741. Andrzej has left
  742. xnamed has left
  743. marc0s has left
  744. marc0s has joined
  745. վարյա has left
  746. վարյա has joined
  747. arc has joined
  748. BASSGOD has left
  749. arc has left
  750. arc has joined
  751. restive_monk has left
  752. adiaholic has joined
  753. Maranda[x] has left
  754. Maranda[x] has joined
  755. jgart has joined
  756. gooya has left
  757. վարյա has left
  758. վարյա has joined
  759. gooya has joined
  760. Dele Olajide has left
  761. վարյա has left
  762. վարյա has joined
  763. Andrzej has joined
  764. Fishbowler has left
  765. Fishbowler has joined
  766. Steve Kille has left
  767. moparisthebest > free software projects aren't the most democratic What? They are the *most* democratic, don't like something, you fork it and everyone that agrees with you switches to your fork?
  768. Ingolf has joined
  769. gooya has left
  770. ti_gj06 has joined
  771. gooya has joined
  772. neshtaxmpp has left
  773. neshtaxmpp has joined
  774. վարյա has left
  775. վարյա has joined
  776. Sam Voting with your wallet or labor isn't the same as democratic.
  777. Sam I dunno why all free software should be democratic or not though, there are lots of different governance models.
  778. moparisthebest Forcing a maintainer to implement or maintain something they don't want certainly isn't democratic
  779. harry837374884 has left
  780. moparisthebest It's free software, that's the entire point, you do what you want with it
  781. վարյա has left
  782. վարյա has joined
  783. վարյա has left
  784. վարյա has joined
  785. վարյա has left
  786. վարյա has joined
  787. Sam Of course not, who said it was?
  788. Alex has left
  789. xnamed has joined
  790. pep. moparisthebest: no they're not democratic for most, you vote with your skills
  791. marc0s has left
  792. marc0s has joined
  793. moparisthebest Skills anyone is free to aquire
  794. Sam That's obvious nonsense; who the hell has time to go to school when you're busy holding down a job that takes all your time?
  795. restive_monk has joined
  796. Sam Either way, even if you could, that's still not what democratic means and both the original statement and your reply to it just don't make sense.
  797. moparisthebest Who said anything about school
  798. gooya has left
  799. Seve has left
  800. Sam You said anyone could aquire the skills. Most people can't afford to go to school, or spend a ton of time practicing or reading up on software.
  801. վարյա has left
  802. վարյա has joined
  803. pep. Everyone doesn't have equal access to education indeed, nor has the time for it because $job
  804. MattJ Relevant: https://postmeritocracy.org/
  805. moparisthebest pep.: So those people should force others to do their whim or?
  806. pep. It's an exchange
  807. marc has left
  808. marc has joined
  809. pep. As a developer I also benefit from people using my software. Of course I have limited resources and priorities but these priorities can change depending on user input
  810. վարյա has left
  811. վարյա has joined
  812. Seve has joined
  813. marc0s has left
  814. marc0s has joined
  815. moparisthebest > As a developer I also benefit from people using my software. In what way?
  816. Kev MattJ: I hadn't (I think) seen that, thanks.
  817. վարյա has left
  818. վարյա has joined
  819. pep. moparisthebest: directly, being somewhat socially rewarded as the thing is useful, getting thanks, feedback, and various contributions that aren't especially code. indirectly, maybe these users are developers themselves and I'm using their software, etc.
  820. xnamed has left
  821. ti_gj06 has left
  822. pep. MattJ: yeah that's a good example. I don't remember exactly what's in it but I remember stumbling upon it a while back
  823. moparisthebest Only if the changes benefit you though, no developer would make changes that helped others but hurt them
  824. pep. It depends
  825. pep. What do you value most. Your own (software) comfort or do you value more collective goals
  826. moparisthebest I still think everyone that uses software can and should know how to program
  827. xnamed has joined
  828. moparisthebest Just like everyone who drives a car should be able to change the oil and change the tire etc
  829. moparisthebest If you are too lazy and/or busy fine but you are the one that will suffer, your choice
  830. pep. There are many features implemented in XMPP that I don't like and I'm still gonna advocate for it, even though at a personal level it's not benefiting me
  831. Guus Mumble mumble everyone that has kids should know how to raise them grumble
  832. raghavgururajan has left
  833. ti_gj06 has joined
  834. վարյա has left
  835. վարյա has joined
  836. harry837374884 has joined
  837. tykayn has left
  838. moparisthebest Honestly this kind of willfull ignorance is how the desire for ephemeral messages even exists: Ignorant user: I want to be able to unsay something on the internet Anyone with basic knowledge: sorry that's not possible Ignorant user: wwwwaaaaaaaa I want it just do it for me
  839. վարյա has left
  840. վարյա has joined
  841. gooya has joined
  842. moparisthebest From MattJ 's link: > We have an ethical responsibility to refuse to work on software that will negatively impact the well-being of other people.
  843. moparisthebest The more I think about it I'm wondering if it's unethical to even hint to a user that we'll try to delete their messages when we know it's not possible?
  844. վարյա has left
  845. վարյա has joined
  846. Daniel I actually think it's not about unsaying something on The Internet but about unsaying something on your own phone.
  847. Zash No responsibility without compensation!
  848. Zash points at MIT license and then proceeds to fall asleep on the couch
  849. moparisthebest You can always delete from your own device
  850. moparisthebest Conversations even implements this, no XEP required
  851. Alex has joined
  852. pep. Conversations defaults to "Never delete"
  853. pep. Every single client out there defaults to that, I think
  854. Daniel Yes. But an auto delete automates this and does this on a per chat and a per message basis
  855. Ingolf has left
  856. Zash We already have message retractions. Don't we have some time-delay thing, AMP or whatsitcalled?
  857. pep. Daniel: an autodelete?
  858. moparisthebest pep.: where's your PRs to change the default? And/or forks
  859. Daniel > Conversations defaults to "Never delete" > Every single client out there defaults to that, I think It's not about defaults. I don't think that if Conversations were to implement ephemeral messages it would default them to something other than never
  860. Zash Or just think of it as time-delayed message retraction, with exactly the same blbubrbl somethig words
  861. pep. moparisthebest: from a quick ask around, they're all gonna be refused
  862. lovetox moparisthebest, you think of the use case that you want to delete something because you want nobody to see it out of shame or whatever
  863. restive_monk has left
  864. lovetox but in my work for example i often just delete messages, to not confuse people because i said something wrong
  865. moparisthebest pep.: Then fork, and ask your contacts to switch
  866. lovetox and dont want to write 3 messages to take it back
  867. pep. moparisthebest: lol
  868. moparisthebest lovetox: we already have that right?
  869. pep. Not sure if serious
  870. moparisthebest That spec doesn't lie to users that no one will ever see the original
  871. pep. "Fork all clients and make your users switch"
  872. lovetox and pep. spec say that?
  873. lovetox i doubt it highly :)
  874. moparisthebest That spec doesn't mislead users into thinking that no one will ever see the original
  875. lovetox and thats already again the wrong argument
  876. lovetox no user reads XEPs
  877. lovetox XEPs are standards for implementing features by developers
  878. lovetox not Users reading what the client does or not does
  879. adiaholic has left
  880. moparisthebest Right, but if we have an ethical obligation to avoid doing things to hurt users, do we not have an ethical obligation to reject XEPs that hurt users?
  881. adiaholic has joined
  882. lovetox we dont have a ethical obligation to hurt users
  883. lovetox what are you talking about
  884. lovetox XSF needs to provide standards for clear use cases
  885. moparisthebest To avoid hurting users
  886. lovetox no ..
  887. Half-Shot has left
  888. homebeach has left
  889. Matthew has left
  890. uhoreg has left
  891. Half-Shot has joined
  892. Matthew has joined
  893. homebeach has joined
  894. uhoreg has joined
  895. lovetox to give devs a way to implement something
  896. lovetox and not everyone needs to invent something themself
  897. pep. If we have an ethical obligation to avoid doing things to hurt users, why do we have specs for military usage
  898. gooya has left
  899. moparisthebest Why did we deprecate xhtml-im and _xmppconnect etc? Because they hurt users right?
  900. Daniel > If we have an ethical obligation to avoid doing things to hurt users, why do we have specs for military usage I don't think we have that obligation
  901. վարյա has left
  902. pep. I wasn't the one to say it :p
  903. վարյա has joined
  904. moparisthebest pep.: military helps users that's why :)
  905. pep. Hah
  906. lovetox moparisthebest, _xmppconnect, because its not secure, no client who implements the spec can do it in a secure way, so its not sound
  907. moparisthebest pep.: Ukraine shouldn't have military? How would that work out?
  908. moparisthebest lovetox: so same with ephemeral messages then?
  909. lovetox every client can implement message deletion and educate its users in a honest way
  910. lovetox so no not at all the same
  911. moparisthebest With server side mam and multiple clients they can't
  912. lovetox and thats the point
  913. lovetox at the one side you have something that cannot be done technically
  914. pep. moparisthebest: military is controlled by the state, and no, the state isn't here to protect people, that's generally one of the biggest source of oppression
  915. lovetox on the other side *you* think that people going to do bad things
  916. lovetox and you think you need to save users
  917. moparisthebest The only honest thing a client can do is say "I can delete my own messages locally and that's it"
  918. crypt This is a fascinating topic that goes beyond the ephemeral message proposal. Unlike proprietary clients that share the same feature-set across devices (Signal, Telegram, WhatsApp), current XMPP clients don't have feature parity. It seems just like how your XMPP server informs your client of what XEPs it supports, clients also need to announce to each other the features they provide. With this mechanism in place, **clients can show or hide features to each other based on feature discovery**. Another benefit to this... users can deactivate features they don't wish to announce.
  919. lovetox moparisthebest, you can say "we will ask the other client to delete the message"
  920. lovetox and thats all people want :)
  921. վարյա has left
  922. moparisthebest lovetox: as devs we know that's all they can have, I think they actually want something else
  923. վարյա has joined
  924. Link Mauve crypt, this is already how it works, mostly.
  925. lovetox but thats not the problem of the xsf, its the problem of client devs
  926. lovetox there can well be a messenger that is a walled garden and enforces what the user wants
  927. lovetox and they then need a protocol for it
  928. Link Mauve I’m not aware of any client hiding features based on user preferences, but some clients have plugin which lead to extending the features advertised.
  929. moparisthebest lovetox: XSF doesn't make XEPs we know are impossible to implement though
  930. lovetox but its not impossible, you fighting a strawman, the xep does not say "This standard guarantees that all messages are deleted forever"
  931. Daniel > moparisthebest, you can say "we will ask the other client to delete the message" It's more like "we are going to announce our retention policy to the other party and suggest that it might be a good idea to adopt a similar one" > and thats all people want :)
  932. lovetox if it would say this, of course i would be with you
  933. pep. I specifically did not want to say this
  934. crypt > Link Mauve: > 2022-04-27 12:19 (CDT) > I’m not aware of any client hiding features based on user preferences, but some clients have plugin which lead to extending the features advertised. Would be great to disable calls, for example, if I so choose.
  935. Link Mauve Sure.
  936. Link Mauve You might have to open an issue to your client(s) bugtracker if you want this though.
  937. վարյա has left
  938. վարյա has joined
  939. Zash Pretty sure I've seen a setting to disable advertising of software used (XEP-0091?)
  940. Zash Pretty sure I've seen a setting to disable advertising of software used (XEP-0092)
  941. Link Mauve I’d like https://github.com/dino/dino/pull/1180 to be merged someday. :<
  942. crypt But it's the general idea I'm trying to make. I like disappearing messages on other chat apps. If two clients support it, then those people should use it if it's available.
  943. Link Mauve I always have to ask my contacts “how did you install Dino? On which Ubuntu version?” while I could just do a /version and get the answer otherwise…
  944. moparisthebest pep.: my concrete objections to the spec as is are: 1. Needs to say what to do when ephemeral no longer is sent (like another client that doesn't support) 2. Needs to suggest a minimum TTL, like 1s probably would never be reasonable right? 0s wouldn't make sense at all (unless used for 3) 3. Needs to have a way to opt out defined, might be #1, might be TTL 0, might be something else If those 3 were addressed I'd pass it. Additionally I'd prefer stronger language suggestions for clients to tell users that this is really simply a suggestion and nothing more, but won't block on this
  945. gooya has joined
  946. arc has left
  947. arc has joined
  948. crypt But we won't know it's available on the users' XMPP client unless they talk through feature discovery. The dev for the client would display an icon if the feature is available between you two.
  949. Wojtek has joined
  950. crypt This would be the most user friendly approach to have disappearing messages or anything that comes next.
  951. restive_monk has joined
  952. Sam has left
  953. Link Mauve crypt, the main issue with that is what to do with contacts who use more than one client, or whose client is offline atm.
  954. Link Mauve It’s not specific to ephemeral messages though.
  955. crypt > Link Mauve: > 2022-04-27 12:31 (CDT) > crypt, the main issue with that is what to do with contacts who use more than one client, or whose client is offline atm. > It’s not specific to ephemeral messages though. I agree. We have to think bigger picture.
  956. lovetox something that is also a problem is MAM
  957. lovetox say i delete a message from my client
  958. Zash Problems!
  959. Zash https://cerdale.zash.se/s/a7R6KUAQVxO4u6v809h4nf7q/6a7dd1ad-dd16-4c32-8a2b-242dc325e2e3.png
  960. lovetox a month later i install on another machine, it downloads MAM, and all messages are again in my client
  961. Zash (from https://what-if.xkcd.com/140/ )
  962. lovetox altough i could delete it instantly because of TTL run out hm
  963. lovetox but this should be mentioned probably in the spec
  964. restive_monk has left
  965. moparisthebest lovetox, I thought TTL was supposed to run from receipt
  966. tykayn has joined
  967. crypt There will always be a case where one client supports one feature another doesn't. What is an elegant way to solve this? Once, you have that you can dive into specific scenarios.
  968. lovetox yeah but i have the receipe date in the mam message
  969. lovetox say i receive a mam message from a year ago with a catchup, and TTL is 1 hour
  970. crypt There will always be a case where one client supports one feature another doesn't. What is an elegant way to solve this? Once you have that, you can dive into specific scenarios.
  971. lovetox then i know it has run out
  972. moparisthebest but if that's your only client then you miss messages
  973. moparisthebest the XEP needs to spell out all the edge cases so no one is left guessing what should be done
  974. crypt People shouldn't have to ask each other which client, which version are you using.
  975. moparisthebest crypt, I think that was just for troubleshooting issues
  976. crypt > moparisthebest: > 2022-04-27 12:39 (CDT) > crypt, I think that was just for troubleshooting issues I already do this now with friends a bit in just normal usage.
  977. crypt They ask: _How do I delete messages after X days?_
  978. crypt I have to tell them their client may not support it.
  979. gooya has left
  980. crypt Disappearing messages actually would take care of that if both users agree to 1 week retention.
  981. վարյա has left
  982. վարյա has joined
  983. lovetox has left
  984. marc0s has left
  985. marc0s has joined
  986. marc0s has left
  987. marc0s has joined
  988. lovetox has joined
  989. crypt FYI - those friends I'm referring to are ones I'm trying to switch over to XMPP that are familiar with these advanced chat features
  990. crypt FYI - those friends I'm referring to are ones I'm trying to switch over to XMPP that are familiar with these advanced chat features on clients like WhatsApp, Telegram, etc.
  991. crypt FYI - those friends I'm referring to are ones I'm trying to switch over to XMPP that are familiar with these advanced chat features on mobile apps like WhatsApp, Telegram, etc.
  992. moparisthebest have you explained to them that these "advanced chat features" don't actually exist on these other platforms and that they've simply been lied to ?
  993. moparisthebest that's the correct thing to do
  994. վարյա has left
  995. վարյա has joined
  996. marc0s has left
  997. marc0s has joined
  998. crypt > moparisthebest: > 2022-04-27 12:53 (CDT) > have you explained to them that these "advanced chat features" don't actually exist on these other platforms and that they've simply been lied to ? > that's the correct thing to do I tell we only have basic chat, call, and video functionality. Archive settings depend on the client you're using.
  999. Sam has joined
  1000. crypt > moparisthebest: > 2022-04-27 12:53 (CDT) > have you explained to them that these "advanced chat features" don't actually exist on these other platforms and that they've simply been lied to ? > that's the correct thing to do I tell them we only have basic chat, call, and video functionality. Archive settings depend on the client you're using.
  1001. crypt I tell them exactly what to expect.
  1002. moparisthebest crypt, right but whatsapp/telegram/signal/etc "disappearing messages" are just a lie on their platforms too right?
  1003. moparisthebest so you shouldn't tell them "xmpp is limited here" you should tell them "xmpp is the only one telling you the truth"
  1004. վարյա has left
  1005. վարյա has joined
  1006. վարյա has left
  1007. վարյա has joined
  1008. BASSGOD has joined
  1009. crypt I just inform them what the can and cannot do. Works best.
  1010. crypt I just inform them what they can and cannot do. Works best.
  1011. moparisthebest so you leave them ignorant about their previous chat platforms and with the impression XMPP lags behind in features? seems bad
  1012. Tobias has left
  1013. Tobias has joined
  1014. Tobias has left
  1015. Tobias has joined
  1016. mjk "Didappearimg messages" is security though PITA. Because it'a PITA to screenshot or photograph and then OCR the messages that are about to be deleted :D
  1017. BASSGOD has left
  1018. Half-Shot has left
  1019. homebeach has left
  1020. Matthew has left
  1021. uhoreg has left
  1022. Half-Shot has joined
  1023. Matthew has joined
  1024. homebeach has joined
  1025. uhoreg has joined
  1026. moparisthebest you mean trivial right?
  1027. marc0s has left
  1028. marc0s has joined
  1029. mjk No, really, most people won't bother. But there's always a sufficiently motivated adversary with a scanner & tesseract combo ready to go :D
  1030. moparisthebest No one is going to bother with OCR for sure
  1031. debacle has left
  1032. moparisthebest But anyone can screenshot easily
  1033. marc0s has left
  1034. papatutuwawa has joined
  1035. marc0s has joined
  1036. mjk Not if the app & os collude against that. The only way would be patching the proprietary binary, or something like that
  1037. վարյա has left
  1038. mjk Or modify the os
  1039. վարյա has joined
  1040. pep. Then one just need to take a photo of the screen
  1041. mjk So, a pain in the ass for a normie
  1042. mathieui mjk: other messengers have desktop or web versions
  1043. pep. Then one just needs to take a photo of the screen
  1044. mathieui Signal can't prevent me from taking a screenshot of my desktop
  1045. moparisthebest mjk, why would that be a pain in the ass for anyone ever ?
  1046. crypt > moparisthebest: > 2022-04-27 12:57 (CDT) > so you leave them ignorant about their previous chat platforms and with the impression XMPP lags behind in features? seems bad I sell them on the benefits of using XMPP.
  1047. moparisthebest you need any camera or a mirror ?
  1048. վարյա has left
  1049. վարյա has joined
  1050. moparisthebest and to press 1 button
  1051. mjk mathieui: hmm. Right, yeah, that would make it trivial, if they have a desktop, that is
  1052. BASSGOD has joined
  1053. restive_monk has joined
  1054. mjk moparisthebest: perhaps im judging based on myself :D
  1055. pep. > lovetox> altough i could delete it instantly because of TTL run out hm > but this should be mentioned probably in the spec It's mentioned in the spec already.
  1056. pep. "TTL" in the spec is a delay not a timestamp
  1057. pep. And it's explained why
  1058. msavoritias Why are we trying to find scenarios to discredit this spec though? To my knowledge there wasnt this much animosity agaist other specs. Like http upload or OMEMO
  1059. pep. Oh there was :p
  1060. Zash You weren't around then I take it?
  1061. pep. But yeah this one particularly
  1062. mjk HTTP is evil, down with http!
  1063. crypt > msavoritias: > 2022-04-27 01:06 (CDT) > Why are we trying to find scenarios to discredit this spec though? To my knowledge there wasnt this much animosity agaist other specs. > Like http upload or OMEMO I sense this, too.
  1064. pep. mjk: ^5
  1065. crypt It's a feature, not an ethical dilemma.
  1066. msavoritias Oh crap so there was? Please dont tell me the discussions were this ridiculous with the stickers xep too.
  1067. msavoritias Yep. We cant guarantee anything with xmpp anyway.
  1068. msavoritias If we go that route. Everything is best effort
  1069. MattJ msavoritias, the difference is that those can be actually implemented
  1070. Link Mauve msavoritias, no discussion happened with stickers AFAIK.
  1071. Link Mauve I’d like to fix it to be usable eventually.
  1072. MattJ Ephemeral messages cross into a weird territory
  1073. mjk msavoritias: Like how stickers on xmpp won't ever be profitable because you can pirate them in a open ecosystem?
  1074. Zash Ghost messages!?!
  1075. msavoritias Link Mauve: i half way expected it :P
  1076. xecks has left
  1077. xecks has joined
  1078. msavoritias mjk: no more like who wants this useless thing and its something only for clients. Sometimes i am surprised with the backlash i see
  1079. crypt Think of it as both parties agreeing to a message retention setting. Nothing more. The technicals of how to make work on different clients is the real issue.
  1080. Link Mauve msavoritias, probably more because no one implemented it so far.
  1081. վարյա has left
  1082. restive_monk has left
  1083. վարյա has joined
  1084. Andrzej has left
  1085. Andrzej has joined
  1086. L29Ah has joined
  1087. Tobias has left
  1088. Tobias has joined
  1089. MattJ Matthew, uhoreg: out of curiosity, what's the story on ephemeral messages in Matrix? Not implemented, right? I think similar challenges would apply, and I suspect any solutions would also probably look similar in both protocols (at a high level).
  1090. Ingolf has joined
  1091. mjk > more like who wants this useless thing and its something only for clients. Well, I'm not really seeing any of that in this case :)
  1092. msavoritias Link Mauve: makes sense. I would like to get involved with it at some time. I am one of the few who would like it
  1093. msavoritias mjk: i know :) was referring to the stickers part
  1094. mjk Right
  1095. ti_gj06 has left
  1096. Link Mauve https://linkmauve.fr/file_share/DlBQ25o9e3YzgA41ZM9qKM23/UI_EmotionIcon59.png
  1097. Link Mauve Me too. ^^
  1098. Link Mauve msavoritias, I implemented a sticker selector in poezio, see our release notes: https://bouah.net/2022/04/updates-from-the-poezio-ecosystem/
  1099. Link Mauve I eventually want to use XEP-0449 instead, but there are things to fix before it is ready.
  1100. msavoritias Link Mauve: ah that looks nice :) I will install poezio to test it out one of these days
  1101. uhoreg MattJ: there is some support for setting message retention limits in a room-wide basis, but there's poor client support, so I don't know how much it's actually used. There's also some attempt at making individual ephemeral (regardless of the room settings), driven by location sharing, but I don't really know where it's at. I don't think a satisfactory solution has been found yet.
  1102. MattJ I think with an open ecosystem it's always going to fall apart at "poor client support", since the default behaviour for any client that doesn't implement the spec is to undermine the whole thing (i.e. just display and store the message forever). Unless you don't send to such clients, which requires servers to jump through hoops and also provides a poor experience to the end user.
  1103. վարյա has left
  1104. վարյա has joined
  1105. վարյա has left
  1106. վարյա has joined
  1107. uhoreg IIRC, the message retention limit feature was mostly intended as a way for servers to avoid having to store *everything*, rather than as a privacy feature. (Though I wasn't involved in the development of that feature, so I could be wrong.)
  1108. msavoritias Agreed. But as with MIX or OMEMO or even the group calls client support is always gonna be a problem. We should aim at clients supporting this not at how hight bar it is
  1109. serge90 has joined
  1110. Sam has left
  1111. Sam has joined
  1112. arc has left
  1113. Andrzej has left
  1114. Andrzej has joined
  1115. mjk Link Mauve: why it is only now that I learn of existence of Xmpp-chan (or whatever is her name)?! > https://bouah.net/2022/04/poezio-sticker-vp8.webm
  1116. Link Mauve Miho!
  1117. mjk Ah, thanks. Low-res display ^^'
  1118. Link Mauve Ow, this VP8 encoding is awful!
  1119. Link Mauve Intel, come on…
  1120. mjk I'll take a look at the vp9 one on a proper 'puter later
  1121. xnamed has left
  1122. վարյա has left
  1123. վարյա has joined
  1124. Link Mauve There is also an AV1 version, which is obviously the best of the three. :)
  1125. Sam has left
  1126. mjk Ooh
  1127. phoebos has joined
  1128. gooya has joined
  1129. վարյա has left
  1130. վարյա has joined
  1131. MattJ msavoritias, the consequences of clients not supporting group calls is "oh well, group calls don't work". The consequences of ephemeral messages not being implemented (or not being implemented correctly due to accident or malice) is "the sensitive ephemeral messages get stored, potentially forever". That's why it's different.
  1132. mjk > Miho! Some obscure encoding of 5222, or am I seeing too deeply into it? :)
  1133. Link Mauve mjk, ask edhelas, I think he was the one who met her first.
  1134. mjk Ah, ty
  1135. Tobias has left
  1136. msavoritias MattJ: sure. But the cliend as stated can give a sufficient message. At some point you have to treat the user as not an idiot and able to make their own decisions. I would hate for xmpp to become like signal where user is not asked for anything because they are treated as stupid.
  1137. Tobias has joined
  1138. sbach has left
  1139. sbach has joined
  1140. sbach has left
  1141. sbach has joined
  1142. Andrzej has left
  1143. Andrzej has joined
  1144. moparisthebest msavoritias, I fully agree, which is why it's probably best to teach users that once you send something you lose all control, and only send to people you trust to delete after X if that's what they want
  1145. moparisthebest rather than treat the users like idiots and tell them we'll try to delete after X when we absolutely know it won't happen
  1146. mjk strongly suggests pep. to sneak a(n improved) version of this proto-xep under the name _Log retention duration coordination specification_
  1147. moparisthebest mjk, literally that would be better
  1148. mjk I know :))
  1149. moparisthebest the name is misleading and therefore harmful as-is
  1150. pep. If that's all it takes..
  1151. Sam has joined
  1152. moparisthebest pep., did you see my 3 concrete protocol objections above though?
  1153. moparisthebest I can send to standards@ too but email grrr
  1154. pep. I'm not on the laptop right now
  1155. pep. Will have a look later
  1156. marc0s has left
  1157. marc0s has joined
  1158. moparisthebest +1 (XMPP is great lol)
  1159. msavoritias moparisthebest: i agree.
  1160. tykayn has left
  1161. tykayn has joined
  1162. xnamed has joined
  1163. Tobias has left
  1164. harry837374884 has left
  1165. Tobias has joined
  1166. Andrzej has left
  1167. Andrzej has joined
  1168. Tobias has left
  1169. վարյա has left
  1170. Tobias has joined
  1171. վարյա has joined
  1172. Tobias has left
  1173. Tobias has joined
  1174. sbach has left
  1175. sbach has joined
  1176. Ingolf has left
  1177. sbach has left
  1178. sbach has joined
  1179. Andrzej has left
  1180. ti_gj06 has joined
  1181. COM8 has joined
  1182. COM8 has left
  1183. վարյա has left
  1184. վարյա has joined
  1185. վարյա has left
  1186. վարյա has joined
  1187. marc0s has left
  1188. marc0s has joined
  1189. adiaholic has left
  1190. վարյա has left
  1191. վարյա has joined
  1192. crypt > msavoritias: > 2022-04-27 01:30 (CDT) > Agreed. But as with MIX or OMEMO or even the group calls client support is always gonna be a problem. > We should aim at clients supporting this not at how hight bar it is I'm already seeing _Group Video Chat_ requests for Conversations in GitHub. How are clients going to deal with this new "advanced feature" in the future? How will users know their chatting with someone whose client also supports it?
  1193. ti_gj06 has left
  1194. adiaholic has joined
  1195. վարյա has left
  1196. վարյա has joined
  1197. crypt This is my point about clients being able to announce and discover which features are supported with the people they're connected to.
  1198. pep. Seriously though if renaming the thing is going to get it more accepted among developers.. I'm happy to do it. It's still exactly the same to me in the UI though :x
  1199. marc0s has left
  1200. marc0s has joined
  1201. marc0s has left
  1202. marc0s has joined
  1203. phoebos has left
  1204. վարյա has left
  1205. harry837374884 has joined
  1206. վարյա has joined
  1207. adiaholic has left
  1208. marc0s has left
  1209. marc0s has joined
  1210. marc0s has left
  1211. marc0s has joined
  1212. crypt Client feature parity is impossible. Feature discoverablity between clients is doable.
  1213. Zash Time-shifted feature discovery is HARD.
  1214. inky has left
  1215. վարյա has left
  1216. վարյա has joined
  1217. crypt moparisthebest was on to something when he said you would have to have different keys for each client that did or didn't support something.
  1218. Zash As in, I accidentally my phone and buy a new one and end up with an app with different features. You try sending something while I'm out shopping. Then what?
  1219. crypt That feature would be limited to that key/client.
  1220. marc0s has left
  1221. վարյա has left
  1222. վարյա has joined
  1223. marc0s has joined
  1224. Zash Then I complain that I'm losing messages and XMPP sucks and can never become popular!!!!!1
  1225. crypt Desktop client can only do this for the JID, the mobile client for the JID can do this + X.
  1226. adiaholic has joined
  1227. debacle has joined
  1228. crypt I'll let smarter people than me figure the rest out.
  1229. adiaholic has left
  1230. marc0s has left
  1231. marc0s has joined
  1232. emus has left
  1233. վարյա has left
  1234. moparisthebest crypt, there's this knob between security and usability though, the "features per omemo key" is on the secure but un-usable side, normal users will find their messages missing
  1235. moparisthebest if you're curious what the extreme end of that spectrum looks like it's https://github.com/maqp/tfc "just carry around 3 different computers and a custom made octocoupler and have your contacts do the same"
  1236. adiaholic has joined
  1237. inky has joined
  1238. mjk has left
  1239. marc0s has left
  1240. marc0s has joined
  1241. mjk has joined
  1242. crypt Has anyone proposed ideas for how clients will support group chats besides asking the other person if their client support it? I'm curious how this conversation is going.
  1243. adiaholic has left
  1244. crypt Has anyone proposed ideas for how clients will support group chats besides asking the other person if their client also supports it? I'm curious how this conversation is going.
  1245. lovetox ? why would i care if a other client supports group chat
  1246. lovetox or are you talking about some adhoc groupchat with2 friends?
  1247. Yagiza has left
  1248. crypt I mispoke. Group video chats. A feature currently requested.
  1249. adiaholic has joined
  1250. tykayn has left
  1251. crypt Hard enough to coordinate on a meeting time. Checking that everyone's client supports it will be a nightmare.
  1252. Link Mauve crypt, depends how it is negociated, Jitsi Meet uses XEP-0298, Dino uses XEP-272.
  1253. Link Mauve Both are incompatible.
  1254. Link Mauve In its disco#info, Dino advertises urn:xmpp:jingle:muji:0.
  1255. Link Mauve Jitsi Meet goes through a less common way, embedding a bunch of extensions in its presence.
  1256. adiaholic has left
  1257. Zash If you're all online at the same time then there's no problem, that already works and has worked for 20 years
  1258. Zash Harder to know what features will be available in the future since you can't easily transmit information backwards in time.
  1259. crypt My query is in relation to how clients on different platforms will support group video chat and how the users will know the people they invite can also join.
  1260. Link Mauve crypt, if your contacts are online, you get that in their disco#info caps (or in Jitsi Meet’s case in their presence).
  1261. phoebos has joined
  1262. crypt It's related to disappearing messages and any other new client features yet to be implemented.
  1263. Link Mauve The different platforms don’t matter on XMPP, the protocol is here to unify that.
  1264. Link Mauve crypt, how is it?
  1265. Link Mauve Muji has been around since 2009, COIN since 2011, both have been implemented by various clients over the years.
  1266. Toxi has left
  1267. adiaholic has joined
  1268. mjk has left
  1269. mjk has joined
  1270. adiaholic has left
  1271. Wojtek has left
  1272. andrew has left
  1273. pep. Is there any document on a deterministic way to generate a MUC JID for n accounts? So that whoever creates it it's always the same
  1274. emus has joined
  1275. Half-Shot has left
  1276. homebeach has left
  1277. Matthew has left
  1278. uhoreg has left
  1279. Half-Shot has joined
  1280. Matthew has joined
  1281. homebeach has joined
  1282. uhoreg has joined
  1283. marc0s has left
  1284. marc0s has joined
  1285. Mikaela has left
  1286. pep. https://www.numerama.com/tech/939175-detranges-coupures-de-fibre-optique-en-france-la-coincidence-interroge.html la gauche frappe à nouveau ?
  1287. pep. oops! Wrong channel :D
  1288. pep. I was wondering why the bot wasn't showing the title.
  1289. Toxi has joined
  1290. ti_gj06 has joined
  1291. adiaholic has joined
  1292. tykayn has joined
  1293. mjk > Is there any document on a deterministic way to generate a MUC JID for n accounts? So that whoever creates it it's always the same Since Conversations seem to judt generate a uuid, probably not, so invent one! echo $jids | sort | uniq | sha256sum?
  1294. mjk > Is there any document on a deterministic way to generate a MUC JID for n accounts? So that whoever creates it it's always the same Since Conversations seem to just generate a uuid, probably not, so invent one! echo $jids | sort | uniq | sha256sum?
  1295. pep. it's not a uuid no it's a random pronouceable word, it's a lot better to handle :p
  1296. mjk Ah, some separators are needed, maybe look for those in the U+0001-U+001F range
  1297. msavoritias has left
  1298. pep. (It's not visible in Conversations but it is in many other clients)
  1299. BASSGOD has left
  1300. mjk Oh, right, I'm confusing with something
  1301. mjk Gajim recently reimplemented the algo
  1302. pep. poezio reuses the part generating the names, I found it nice :)
  1303. mjk Yea
  1304. adiaholic has left
  1305. pep. How does Matrix do it?
  1306. BASSGOD has joined
  1307. վարյա has joined
  1308. Kev has left
  1309. atomicwatch has left
  1310. andrew has joined
  1311. tykayn has left
  1312. Calvin has left
  1313. Menel has left
  1314. chipmnk has joined
  1315. Tobias has left
  1316. Toxi has left
  1317. Toxi has joined
  1318. andrew has left
  1319. ti_gj06 has left
  1320. andrew has joined
  1321. crypt I just had a wild idea, for disappearing messages at least... why not create a new conversation with that person that follows those rules? Sort of Telegram's secret chat. You can have a normal chat and secret chat with the same contact. That way you're not trying to add/change an existing conversation thread. And if the person's other client doesn't support it, they won't see the more restrictive conversation.
  1322. wurstsalat has left
  1323. wgreenhouse has left
  1324. Seve has left
  1325. mh has left
  1326. crypt I just had a wild idea, for disappearing messages at least... why not create a new conversation with that person that follows those rules? Sort of Telegram's secret chat. You can have a normal chat and secret chat with the same contact. That way you're not trying to add/change an existing conversation thread. And if the person's other client doesn't support it, they won't see or have access to the more restrictive conversation.
  1327. Toxi has left
  1328. Toxi has joined
  1329. BASSGOD has left
  1330. mh has joined
  1331. crypt I just had a wild idea, for disappearing messages at least... why not create a new conversation with that person that follows those rules? Sort of like Telegram's secret chat. You can have a normal chat and secret chat with the same contact. That way you're not trying to add/change an existing conversation thread. And if the person's other client doesn't support it, they won't see or have access to the more restrictive conversation.
  1332. crypt I just had a wild idea, for disappearing messages at least... why not create a new conversation with that person that follows those rules? Sort of like Telegram's secret chat. You can have a normal chat and secret chat with the same contact. That way you're not trying to change an existing conversation thread's settings. And if the person's other client doesn't support it, they won't see or have access to the more restrictive conversation.
  1333. marc has left
  1334. bean has left
  1335. crypt I just had a wild idea, for disappearing messages at least... why not create a new conversation with that person that follows those rules? Sort of like Telegram's secret chat. You can have a normal chat and secret chat with the same contact. That way you're not trying to change an existing conversation thread's settings. And if the person's other client (yes, on mobile... no, on desktop) doesn't support it, they won't see or have access to the more restrictive conversation.
  1336. debacle has left
  1337. BASSGOD has joined
  1338. wgreenhouse has joined
  1339. pep. hmm I'm thinking having a deterministic way to generate a room address may be an issue because not everybody is allowed to create a room on a MUC.
  1340. pep. Why can't we have nice things
  1341. MattJ pep. [22:02]: > How does Matrix do it? I'm far from expert, but I think you want to be looking in the direction of https://github.com/matrix-org/matrix-spec-proposals/pull/2199
  1342. pep. MattJ, thanks, otherwise I also got some advice on mastodon! https://post.lurk.org/@pep/108206073908492448
  1343. pep. Maybe there could be a MUC extension saying "if a user sends an affiliation list to the JID they're trying to join, they can create it and become owner, and the MUC sends mediated invites" But it feels slightly too easy to use to bypass regular MUC ACLs
  1344. pep. That is, the JID would need to match the JID generated from the given affiliation list
  1345. pep. Giving a read at the matrix thing
  1346. pep. Wait it hasn't been merged? That means canonical DMs aren,t a thing yet?
  1347. pep. heh, indeed it's not a thing, the PR says
  1348. Zash It that because thete's no 1:1 messaging?
  1349. Zash It that because there's no 1:1 messaging?
  1350. pep. Well as I understand it, 1:1 messaging happens in a room, but one needs to figure out the room address still
  1351. pep. So what, one generates it and invites the other?
  1352. marc0s has left
  1353. marc0s has joined
  1354. BASSGOD has left
  1355. Zash They closed it, opened another... different room...
  1356. վարյա has left
  1357. վարյա has joined
  1358. Zash Then invited someone else into a DM
  1359. pep. I guess that's what happens
  1360. crypt > Link Mauve: > 2022-04-27 03:06 (CDT) > crypt, if your contacts are online, you get that in their disco#info caps (or in Jitsi Meet’s case in their presence). I believe you're referring to this. I'll read up on it. Thanks! https://xmpp.org/extensions/xep-0115.xml
  1361. pep. But the permission issue is annoying. Not sure how to get over it
  1362. Zash What if someone pre-calculates your address and joins there before you?
  1363. Steve Kille has joined
  1364. pep. That's an issue only if they are allowed to, but yeah
  1365. Steve Kille has left
  1366. Steve Kille has joined
  1367. Zash What we do now seems simple, random localpart at the creators local MUC
  1368. Zash Invite others.
  1369. pasdesushi has left
  1370. pasdesushi has joined
  1371. pep. "yeah but", as you said above, you close it, open another etc. you end up with many rooms
  1372. pep. Though.. there might be cases where one does not want to use a particular MUC server.. how to deal with this. (Because of technical issues, or CoC or..)
  1373. papatutuwawa has left
  1374. BASSGOD has joined
  1375. lovetox has left
  1376. goffi has left
  1377. lovetox has joined
  1378. crypt XEP-0115: Entites Capabilities is awesome ❤️ It's exactly what I was describing and it's already here! > It is often desirable for an XMPP application (commonly but not necessarily a client) to take different actions depending on the capabilities of another application from which it receives presence information. Examples include: > Showing a different set of icons depending on the capabilities of other entities.
  1379. crypt XEP-0115: Entites Capabilities is awesome ❤️ It's exactly what I was describing and it's already here! > It is often desirable for an XMPP application (commonly but not necessarily a client) to take different actions depending on the capabilities of another application from which it receives presence information. Examples include: > > Showing a different set of icons depending on the capabilities of other entities.
  1380. վարյա has left
  1381. BASSGOD has left
  1382. crypt XEP-0115: Entites Capabilities is awesome ❤️ It's exactly what I was describing and it's already here! > It is often desirable for an XMPP application (commonly but not necessarily a client) to take different actions depending on the capabilities of another application from which it receives presence information. Examples include: > > - Showing a different set of icons depending on the capabilities of other entities. - Not sending XHTML-IM (XEP-0071) [1] or other rich content to plaintext clients such as cell phones. - Allowing the initiation of a Voice over IP (VoIP) session only to clients that support Jingle (XEP-0166) [2] and Jingle RTP Sessions (XEP-0167) [3]. - Not showing a "Send a File" button if another user's client does not support SI File Transfer (XEP-0096) [4]. - Filtering Publish-Subscribe (XEP-0060) [5] notifications based on advertised subscriber interests.
  1383. crypt XEP-0115: Entites Capabilities is awesome ❤️ It's exactly what I was describing and it's already here! > It is often desirable for an XMPP application (commonly but not necessarily a client) to take different actions depending on the capabilities of another application from which it receives presence information. Examples include: > > - Showing a different set of icons depending on the capabilities of other entities. > - Not sending XHTML-IM (XEP-0071) [1] or other rich content to plaintext clients such as cell phones. > - Allowing the initiation of a Voice over IP (VoIP) session only to clients that support Jingle (XEP-0166) [2] and Jingle RTP Sessions (XEP-0167) [3]. > - Not showing a "Send a File" button if another user's client does not support SI File Transfer (XEP-0096) [4]. > - Filtering Publish-Subscribe (XEP-0060) [5] notifications based on advertised subscriber interests.
  1384. crypt XEP-0115: Entites Capabilities is awesome ❤️ It's exactly what I was describing and it's already here! > It is often desirable for an XMPP application (commonly but not necessarily a client) to take different actions depending on the capabilities of another application from which it receives presence information. Examples include: > > - **Showing a different set of icons depending on the capabilities of other entities.** > - Not sending XHTML-IM (XEP-0071) [1] or other rich content to plaintext clients such as cell phones. > - Allowing the initiation of a Voice over IP (VoIP) session only to clients that support Jingle (XEP-0166) [2] and Jingle RTP Sessions (XEP-0167) [3]. > - Not showing a "Send a File" button if another user's client does not support SI File Transfer (XEP-0096) [4]. > - Filtering Publish-Subscribe (XEP-0060) [5] notifications based on advertised subscriber interests.
  1385. pasdesushi has left
  1386. L29Ah has left
  1387. վարյա has joined
  1388. crypt XEP-0115: Entites Capabilities is awesome ❤️ It's exactly what I was describing with announce and discovery and it's already here! > It is often desirable for an XMPP application (commonly but not necessarily a client) to take different actions depending on the capabilities of another application from which it receives presence information. Examples include: > > - **Showing a different set of icons depending on the capabilities of other entities.** > - Not sending XHTML-IM (XEP-0071) [1] or other rich content to plaintext clients such as cell phones. > - Allowing the initiation of a Voice over IP (VoIP) session only to clients that support Jingle (XEP-0166) [2] and Jingle RTP Sessions (XEP-0167) [3]. > - Not showing a "Send a File" button if another user's client does not support SI File Transfer (XEP-0096) [4]. > - Filtering Publish-Subscribe (XEP-0060) [5] notifications based on advertised subscriber interests.
  1389. crypt XEP-0115: Entites Capabilities is awesome ❤️ It's exactly what I was describing with client announce and discovery and it's already here! > It is often desirable for an XMPP application (commonly but not necessarily a client) to take different actions depending on the capabilities of another application from which it receives presence information. Examples include: > > - **Showing a different set of icons depending on the capabilities of other entities.** > - Not sending XHTML-IM (XEP-0071) [1] or other rich content to plaintext clients such as cell phones. > - Allowing the initiation of a Voice over IP (VoIP) session only to clients that support Jingle (XEP-0166) [2] and Jingle RTP Sessions (XEP-0167) [3]. > - Not showing a "Send a File" button if another user's client does not support SI File Transfer (XEP-0096) [4]. > - Filtering Publish-Subscribe (XEP-0060) [5] notifications based on advertised subscriber interests.
  1390. L29Ah has joined
  1391. marc0s has left
  1392. marc0s has joined
  1393. Calvin has joined
  1394. Steve Kille has left
  1395. BASSGOD has joined
  1396. Kev has joined
  1397. Kev has left
  1398. Kev has joined
  1399. Kev has left
  1400. crypt How can we tell if our client supports XEP-0115? Is it already widely used?
  1401. pep. Most if not all do
  1402. pep. Check the project doap file in the repo otherwise
  1403. chipmnk has left
  1404. xnamed has left
  1405. lovetox has left
  1406. xnamed has joined
  1407. karoshi has left
  1408. adiaholic has joined
  1409. BASSGOD has left
  1410. Half-Shot has left
  1411. homebeach has left
  1412. Matthew has left
  1413. uhoreg has left
  1414. Half-Shot has joined
  1415. Matthew has joined
  1416. homebeach has joined
  1417. uhoreg has joined
  1418. adiaholic has left
  1419. BASSGOD has joined
  1420. crypt > pep.: > 2022-04-27 05:30 (CDT) > Check the project doap file in the repo otherwise Thank you! Found support for XEP-0115 in Conversations: https://github.com/iNPUTmice/Conversations/blob/master/conversations.doap
  1421. djorz has left
  1422. moparisthebest has left
  1423. crypt Also found it Monal IM, which my friends use (but not as good as Conversations).
  1424. moparisthebest has joined
  1425. crypt Also found it on Monal IM, which my friends use (but not as good as Conversations).
  1426. xnamed has left
  1427. BASSGOD has left
  1428. crypt What's the difference between status "complete" and "supported"? Both Dino and Gajim list XEP-0115 with status "complete".
  1429. crypt What's the difference between status "complete" and "supported"? Both Dino and Gajim list XEP-0115 with status "complete". Conversations and Monal IM have status "supported".
  1430. xecks has left
  1431. adiaholic has joined
  1432. pep. "supported" isn't valid. https://linkmauve.fr/ns/xmpp-doap#
  1433. pep. “Can be 'complete', 'partial', 'planned', 'deprecated', 'removed' or 'wontfix'.”
  1434. inky has left
  1435. inky has joined
  1436. crypt pep.: hahaha - you're right!
  1437. BASSGOD has joined
  1438. adiaholic has left
  1439. djorz has joined
  1440. xecks has joined
  1441. adiaholic has joined
  1442. crypt It seems if clients don't fully support XEP-0115 future "advanced features" could never be discoverable between friends. You'll only hear about X new feature through the app developer in a point upgrade. I guess that's normal.
  1443. Matthew > <@_xmpp_MattJ=2fxsf=40muc.xmpp.org:matrix.org> Matthew, uhoreg: out of curiosity, what's the story on ephemeral messages in Matrix? Not implemented, right? I think similar challenges would apply, and I suspect any solutions would also probably look similar in both protocols (at a high level). https://github.com/matrix-org/matrix-spec-proposals/blob/matthew/msc2228/proposals/2228-self-destructing-events.md is the exploding msgs spec for Matrix, which we should implement this year
  1444. harry837374884 has left
  1445. harry837374884 has joined
  1446. Matthew (we’re not using it for ephemeral data like location sharing in the end)
  1447. adiaholic has left
  1448. krauq has left
  1449. krauq has joined
  1450. stp has left
  1451. emus has left
  1452. Sergi TsZ has joined
  1453. andrey.g has joined
  1454. Sergi TsZ Hi i need help
  1455. Sergi TsZ does XMPP store E2E keys online like Matrix?
  1456. adiaholic has joined
  1457. mjk has left
  1458. adiaholic has left
  1459. վարյա has left
  1460. վարյա has joined
  1461. moparisthebest has left
  1462. moparisthebest has joined
  1463. adiaholic has joined