XSF Discussion - 2022-04-26


  1. emus has left
  2. antranigv has left
  3. millesimus has joined
  4. antranigv has joined
  5. restive_monk has joined
  6. arc has left
  7. arc has joined
  8. neshtaxmpp has left
  9. adiaholic has joined
  10. BASSGOD has left
  11. BASSGOD has joined
  12. arc has left
  13. thilo.molitor has joined
  14. arc has joined
  15. gooya has left
  16. thilo.molitor has left
  17. thilo.molitor has joined
  18. thilo.molitor has left
  19. marc0s has left
  20. marc0s has joined
  21. adiaholic has left
  22. lskdjf has left
  23. adiaholic has joined
  24. Vaulor has left
  25. millesimus has left
  26. adiaholic has left
  27. millesimus has joined
  28. thilo.molitor has joined
  29. adiaholic has joined
  30. arc has left
  31. arc has joined
  32. adiaholic has left
  33. adiaholic has joined
  34. Ingolf has joined
  35. matkor has left
  36. adiaholic has left
  37. adiaholic has joined
  38. antranigv has left
  39. adiaholic has left
  40. Kev has left
  41. Steve has left
  42. Steve Kille has joined
  43. Kev has joined
  44. Kev has left
  45. arc has left
  46. arc has joined
  47. Kev has joined
  48. BASSGOD has left
  49. arc has left
  50. arc has joined
  51. antranigv has joined
  52. Skull Fucker has joined
  53. libre has joined
  54. adiaholic has joined
  55. libre has left
  56. libre has joined
  57. adiaholic has left
  58. antranigv has left
  59. adiaholic has joined
  60. antranigv has joined
  61. adiaholic has left
  62. BASSGOD has joined
  63. jgart has left
  64. jgart has joined
  65. sbach has left
  66. sbach has joined
  67. adiaholic has joined
  68. lovetox has left
  69. restive_monk has left
  70. Ingolf has left
  71. restive_monk has joined
  72. raghavgururajan has joined
  73. adiaholic has left
  74. alex11 has left
  75. chipmnk has left
  76. sbach has left
  77. sbach has joined
  78. gooya has joined
  79. Skull Fucker has left
  80. adiaholic has joined
  81. alacer has left
  82. alacer has joined
  83. libre has left
  84. libre has joined
  85. adiaholic has left
  86. adiaholic has joined
  87. libre has left
  88. libre has joined
  89. BASSGOD has left
  90. gooya has left
  91. BASSGOD has joined
  92. arc has left
  93. arc has joined
  94. Yagiza has joined
  95. antranigv has left
  96. antranigv has joined
  97. arc has left
  98. arc has joined
  99. jgart has left
  100. xnamed has left
  101. Menel has joined
  102. libre has left
  103. libre has joined
  104. raghavgururajan has left
  105. xnamed has joined
  106. Seve has joined
  107. Vaulor has joined
  108. Tobias has joined
  109. marc0s has left
  110. marc0s has joined
  111. atomicwatch has joined
  112. neshtaxmpp has joined
  113. Tobias has left
  114. Tobias has joined
  115. Menel has left
  116. Menel has joined
  117. antranigv has left
  118. antranigv has joined
  119. lovetox has joined
  120. Half-Shot has left
  121. homebeach has left
  122. Matthew has left
  123. uhoreg has left
  124. Half-Shot has joined
  125. Matthew has joined
  126. homebeach has joined
  127. uhoreg has joined
  128. Menel has left
  129. Menel has joined
  130. Menel has left
  131. Menel has joined
  132. Menel has left
  133. Menel has joined
  134. Maranda[x] has left
  135. rion has left
  136. rion has joined
  137. Half-Shot has left
  138. homebeach has left
  139. Matthew has left
  140. uhoreg has left
  141. Half-Shot has joined
  142. Matthew has joined
  143. homebeach has joined
  144. uhoreg has joined
  145. Maranda[x] has joined
  146. restive_monk has left
  147. rion has left
  148. Ingolf has joined
  149. restive_monk has joined
  150. arc has left
  151. yushyin has left
  152. restive_monk has left
  153. Half-Shot has left
  154. homebeach has left
  155. Matthew has left
  156. uhoreg has left
  157. Half-Shot has joined
  158. Matthew has joined
  159. homebeach has joined
  160. uhoreg has joined
  161. antranigv has left
  162. antranigv has joined
  163. antranigv has left
  164. antranigv has joined
  165. matkor has joined
  166. marc0s has left
  167. marc0s has joined
  168. restive_monk has joined
  169. arc has joined
  170. Paganini has left
  171. jgart has joined
  172. adiaholic has left
  173. antranigv has left
  174. libre has left
  175. konstantinos has joined
  176. libre has joined
  177. wurstsalat has joined
  178. yushyin has joined
  179. antranigv has joined
  180. karoshi has joined
  181. yushyin has left
  182. adiaholic has joined
  183. Maranda[x] has left
  184. antranigv has left
  185. emus has joined
  186. arc has left
  187. arc has joined
  188. Menel has left
  189. Titi has joined
  190. Steve Kille has left
  191. Kev has left
  192. Kev has joined
  193. adiaholic has left
  194. Steve Kille has joined
  195. Maranda[x] has joined
  196. Half-Shot has left
  197. homebeach has left
  198. Matthew has left
  199. uhoreg has left
  200. Half-Shot has joined
  201. Matthew has joined
  202. homebeach has joined
  203. uhoreg has joined
  204. adiaholic has joined
  205. arc has left
  206. arc has joined
  207. marc0s has left
  208. marc0s has joined
  209. libre has left
  210. debacle has joined
  211. yushyin has joined
  212. djorz has joined
  213. yushyin has left
  214. msavoritias has joined
  215. L29Ah has left
  216. adiaholic has left
  217. adiaholic has joined
  218. antranigv has joined
  219. tykayn has joined
  220. karoshi has left
  221. adiaholic has left
  222. yushyin has joined
  223. stp has joined
  224. restive_monk has left
  225. karoshi has joined
  226. djorz has left
  227. L29Ah has joined
  228. arc has left
  229. Titi has left
  230. Titi has joined
  231. arc has joined
  232. stp has left
  233. bean has joined
  234. marc has joined
  235. Ingolf has left
  236. Ingolf has joined
  237. jgart has left
  238. adiaholic has joined
  239. restive_monk has joined
  240. restive_monk has left
  241. pasdesushi has joined
  242. yushyin has left
  243. yushyin has joined
  244. Half-Shot has left
  245. homebeach has left
  246. Matthew has left
  247. uhoreg has left
  248. Half-Shot has joined
  249. Matthew has joined
  250. homebeach has joined
  251. uhoreg has joined
  252. restive_monk has joined
  253. adiaholic has left
  254. matkor has left
  255. Half-Shot has left
  256. homebeach has left
  257. Matthew has left
  258. uhoreg has left
  259. Half-Shot has joined
  260. Matthew has joined
  261. homebeach has joined
  262. uhoreg has joined
  263. debacle has left
  264. adiaholic has joined
  265. stp has joined
  266. BASSGOD has left
  267. Maranda[x] has left
  268. adiaholic has left
  269. marc0s has left
  270. marc0s has joined
  271. Half-Shot has left
  272. homebeach has left
  273. Matthew has left
  274. uhoreg has left
  275. Half-Shot has joined
  276. Matthew has joined
  277. homebeach has joined
  278. uhoreg has joined
  279. antranigv has left
  280. Maranda[x] has joined
  281. antranigv has joined
  282. adiaholic has joined
  283. BASSGOD has joined
  284. L29Ah has left
  285. mjk has joined
  286. intosi has joined
  287. Alex has joined
  288. petrescatraian has joined
  289. Andrzej has joined
  290. intosi has left
  291. intosi has joined
  292. papatutuwawa has joined
  293. petrescatraian has left
  294. Andrzej has left
  295. arc has left
  296. arc has joined
  297. arc has left
  298. arc has joined
  299. adiaholic has left
  300. rion has joined
  301. adiaholic has joined
  302. lskdjf has joined
  303. Toxi has left
  304. Toxi has joined
  305. karoshi has left
  306. goffi has joined
  307. arc has left
  308. arc has joined
  309. Andrzej has joined
  310. Ingolf has left
  311. debacle has joined
  312. matkor has joined
  313. adiaholic has left
  314. L29Ah has joined
  315. karoshi has joined
  316. Alex has left
  317. marc0s has left
  318. marc0s has joined
  319. adiaholic has joined
  320. marc0s has left
  321. marc0s has joined
  322. alacer has left
  323. stp has left
  324. alacer has joined
  325. xecks has left
  326. Ingolf has joined
  327. Alex has joined
  328. marc0s has left
  329. xecks has joined
  330. marc0s has joined
  331. ti_gj06 has joined
  332. lovetox has left
  333. Steve Kille has left
  334. Steve Kille has joined
  335. adiaholic has left
  336. antranigv has left
  337. L29Ah has left
  338. ti_gj06 has left
  339. ti_gj06 has joined
  340. Wojtek has joined
  341. adiaholic has joined
  342. L29Ah has joined
  343. lovetox has joined
  344. adiaholic has left
  345. antranigv has joined
  346. neshtaxmpp has left
  347. neshtaxmpp has joined
  348. sonny has left
  349. arc has left
  350. arc has joined
  351. Dele Olajide has joined
  352. arc has left
  353. arc has joined
  354. Menel has joined
  355. Dele Olajide has left
  356. Dele Olajide has joined
  357. Dele Olajide has left
  358. Dele Olajide has joined
  359. papatutuwawa has left
  360. lovetox has left
  361. Dele Olajide has left
  362. Dele Olajide has joined
  363. Dele Olajide has left
  364. adiaholic has joined
  365. intosi has left
  366. intosi has joined
  367. Ingolf has left
  368. arc has left
  369. arc has joined
  370. lovetox has joined
  371. antranigv has left
  372. antranigv has joined
  373. Fishbowler has left
  374. Fishbowler has joined
  375. papatutuwawa has joined
  376. arc has left
  377. ti_gj06 has left
  378. adiaholic has left
  379. edhelas has left
  380. Half-Shot has left
  381. homebeach has left
  382. Matthew has left
  383. uhoreg has left
  384. Half-Shot has joined
  385. Matthew has joined
  386. homebeach has joined
  387. uhoreg has joined
  388. Andrzej has left
  389. Andrzej has joined
  390. arc has joined
  391. adiaholic has joined
  392. Andrzej has left
  393. Andrzej has joined
  394. marc0s has left
  395. marc0s has joined
  396. marc0s has left
  397. marc0s has joined
  398. matkor has left
  399. L29Ah has left
  400. Menel has left
  401. Dele has joined
  402. Dele has left
  403. Dele has joined
  404. matkor has joined
  405. Dele Olajide has joined
  406. Dele Olajide has left
  407. Dele Olajide has joined
  408. Dele Olajide has left
  409. Dele Olajide has joined
  410. Dele has left
  411. Dele Olajide has left
  412. arc has left
  413. arc has joined
  414. lovetox has left
  415. Dele Olajide has joined
  416. L29Ah has joined
  417. lovetox has joined
  418. intosi has left
  419. neshtaxmpp has left
  420. neshtaxmpp has joined
  421. xnamed has left
  422. xnamed has joined
  423. melvo has left
  424. adiaholic has left
  425. Menel has joined
  426. krauq has left
  427. arcxi has left
  428. adiaholic has joined
  429. arcxi has joined
  430. krauq has joined
  431. adiaholic has left
  432. Alex has left
  433. ti_gj06 has joined
  434. Alex has joined
  435. gooya has joined
  436. Syndace has left
  437. Syndace has joined
  438. Menel has left
  439. lovetox has left
  440. Dele Olajide has left
  441. restive_monk has left
  442. Dele Olajide has joined
  443. Andrzej has left
  444. lovetox has joined
  445. L29Ah has left
  446. Calvin has joined
  447. Menel has joined
  448. L29Ah has joined
  449. raghavgururajan has joined
  450. arc has left
  451. arc has joined
  452. neshtaxmpp has left
  453. neshtaxmpp has joined
  454. Menel has left
  455. intosi has joined
  456. adiaholic has joined
  457. Calvin has left
  458. stp has joined
  459. Ingolf has joined
  460. restive_monk has joined
  461. Yagiza has left
  462. Menel has joined
  463. Andrzej has joined
  464. Andrzej has left
  465. Half-Shot has left
  466. homebeach has left
  467. Matthew has left
  468. uhoreg has left
  469. Half-Shot has joined
  470. Matthew has joined
  471. homebeach has joined
  472. uhoreg has joined
  473. neshtaxmpp has left
  474. neshtaxmpp has joined
  475. Yagiza has joined
  476. Dele Olajide has left
  477. Alex has left
  478. Matthew has left
  479. Half-Shot has left
  480. homebeach has left
  481. uhoreg has left
  482. Half-Shot has joined
  483. Matthew has joined
  484. homebeach has joined
  485. uhoreg has joined
  486. harry837374884 has left
  487. Alex has joined
  488. Ingolf has left
  489. Paganini has joined
  490. harry837374884 has joined
  491. libre has joined
  492. Matthew has left
  493. Half-Shot has left
  494. homebeach has left
  495. uhoreg has left
  496. Half-Shot has joined
  497. Matthew has joined
  498. homebeach has joined
  499. uhoreg has joined
  500. stp has left
  501. ti_gj06 has left
  502. arc has left
  503. antranigv has left
  504. arc has joined
  505. Calvin has joined
  506. Andrzej has joined
  507. Wojtek has left
  508. antranigv has joined
  509. restive_monk has left
  510. ti_gj06 has joined
  511. Matthew has left
  512. Half-Shot has left
  513. homebeach has left
  514. uhoreg has left
  515. Half-Shot has joined
  516. Matthew has joined
  517. homebeach has joined
  518. uhoreg has joined
  519. papatutuwawa has left
  520. antranigv has left
  521. mjk has left
  522. mjk has joined
  523. restive_monk has joined
  524. Dele Olajide has joined
  525. matkor has left
  526. Dele Olajide has left
  527. TheCoffeMaker has left
  528. Dele Olajide has joined
  529. TheCoffeMaker has joined
  530. xnamed has left
  531. restive_monk has left
  532. xnamed has joined
  533. ti_gj06 has left
  534. restive_monk has joined
  535. alex11 has joined
  536. arc has left
  537. arc has joined
  538. adiaholic has left
  539. Andrzej has left
  540. restive_monk has left
  541. Vidak has left
  542. phoebos has joined
  543. papatutuwawa has joined
  544. phoebos has left
  545. xecks has left
  546. xecks has joined
  547. restive_monk has joined
  548. adiaholic has joined
  549. Andrzej has joined
  550. pasdesushi has left
  551. adiaholic has left
  552. restive_monk has left
  553. restive_monk has joined
  554. Alex has left
  555. harry837374884 has left
  556. adiaholic has joined
  557. Toxi has left
  558. Toxi has joined
  559. stp has joined
  560. restive_monk has left
  561. harry837374884 has joined
  562. Calvin has left
  563. Wojtek has joined
  564. edhelas has joined
  565. melvo has joined
  566. arc has left
  567. ti_gj06 has joined
  568. arc has joined
  569. adiaholic has left
  570. mjk has left
  571. mjk has joined
  572. adiaholic has joined
  573. stp has left
  574. adiaholic has left
  575. stp has joined
  576. adiaholic has joined
  577. stp has left
  578. marc0s has left
  579. marc0s has joined
  580. stp has joined
  581. marc0s has left
  582. marc0s has joined
  583. Andrzej has left
  584. Andrzej has joined
  585. Friendly Resident Cynic has left
  586. stp has left
  587. Andrzej has left
  588. Andrzej has joined
  589. antranigv has joined
  590. matkor has joined
  591. Andrzej has left
  592. Andrzej has joined
  593. marc0s has left
  594. marc0s has joined
  595. Alex has joined
  596. Tobias has left
  597. stp has joined
  598. Tobias has joined
  599. melvo has left
  600. konstantinos has left
  601. konstantinos has joined
  602. Dele Olajide has left
  603. djorz has joined
  604. adiaholic has left
  605. sonny has joined
  606. adiaholic has joined
  607. stp has left
  608. stp has joined
  609. ti_gj06 has left
  610. ti_gj06 has joined
  611. adiaholic has left
  612. melvo has joined
  613. stp has left
  614. ti_gj06 has left
  615. ti_gj06 has joined
  616. adiaholic has joined
  617. lovetox has left
  618. wladmis has left
  619. wladmis has joined
  620. gooya has left
  621. gooya has joined
  622. adiaholic has left
  623. wladmis has left
  624. wladmis has joined
  625. libre has left
  626. pasdesushi has joined
  627. libre has joined
  628. lovetox has joined
  629. L29Ah has left
  630. jgart has joined
  631. thilo.molitor has left
  632. adiaholic has joined
  633. Steve Kille has left
  634. Andrzej has left
  635. Andrzej has joined
  636. emus has left
  637. Andrzej has left
  638. Andrzej has joined
  639. chipmnk has joined
  640. karoshi has left
  641. Steve Kille has joined
  642. Andrzej has left
  643. Andrzej has joined
  644. Andrzej has left
  645. Andrzej has joined
  646. Andrzej has left
  647. Andrzej has joined
  648. karoshi has joined
  649. emus has joined
  650. debacle has left
  651. adiaholic has left
  652. marc0s has left
  653. marc0s has joined
  654. adiaholic has joined
  655. Andrzej has left
  656. lovetox has left
  657. adiaholic has left
  658. papatutuwawa has left
  659. adiaholic has joined
  660. intosi has left
  661. restive_monk has joined
  662. Paganini has left
  663. Paganini has joined
  664. debacle has joined
  665. lovetox has joined
  666. Maranda[x] has left
  667. Maranda[x] has joined
  668. Alex has left
  669. restive_monk has left
  670. Andrzej has joined
  671. thilo.molitor has joined
  672. larma has left
  673. larma has joined
  674. L29Ah has joined
  675. karoshi has left
  676. Tobias has left
  677. Tobias has joined
  678. Alex has joined
  679. debacle has left
  680. stp has joined
  681. karoshi has joined
  682. karoshi has left
  683. libre has left
  684. libre has joined
  685. libre has left
  686. libre has joined
  687. wladmis has left
  688. wladmis has joined
  689. libre has left
  690. melvo has left
  691. melvo has joined
  692. karoshi has joined
  693. libre has joined
  694. arc has left
  695. arc has joined
  696. libre has left
  697. karoshi has left
  698. karoshi has joined
  699. libre has joined
  700. krauq has left
  701. karoshi has left
  702. arc has left
  703. karoshi has joined
  704. arc has joined
  705. papatutuwawa has joined
  706. adiaholic has left
  707. karoshi has left
  708. karoshi has joined
  709. karoshi has left
  710. krauq has joined
  711. restive_monk has joined
  712. Dele Olajide has joined
  713. Andrzej has left
  714. Andrzej has joined
  715. Dele Olajide has left
  716. jjrh has left
  717. jjrh has joined
  718. Dele Olajide has joined
  719. karoshi has joined
  720. harry837374884 has left
  721. adiaholic has joined
  722. libre has left
  723. libre has joined
  724. Andrzej has left
  725. Andrzej has joined
  726. restive_monk has left
  727. karoshi has left
  728. Alex has left
  729. Alex has joined
  730. adiaholic has left
  731. karoshi has joined
  732. Half-Shot has left
  733. homebeach has left
  734. Matthew has left
  735. uhoreg has left
  736. Half-Shot has joined
  737. Matthew has joined
  738. homebeach has joined
  739. uhoreg has joined
  740. harry837374884 has joined
  741. adiaholic has joined
  742. Niklas has joined
  743. Niklas has left
  744. wurstsalat has left
  745. arc has left
  746. wurstsalat has joined
  747. arc has joined
  748. arc has left
  749. adiaholic has left
  750. arc has joined
  751. Friendly Resident Cynic has joined
  752. qwestion has joined
  753. wladmis has left
  754. adiaholic has joined
  755. wladmis has joined
  756. robertooo has joined
  757. Andrzej has left
  758. Andrzej has joined
  759. djorz has left
  760. Andrzej has left
  761. Andrzej has joined
  762. robertooo has left
  763. robertooo has joined
  764. adiaholic has left
  765. ti_gj06 has left
  766. Dele has joined
  767. Dele has left
  768. Vidak has joined
  769. Andrzej has left
  770. marc0s has left
  771. marc0s has joined
  772. Dele has joined
  773. marc0s has left
  774. marc0s has joined
  775. marc0s has left
  776. marc0s has joined
  777. arc has left
  778. adiaholic has joined
  779. arc has joined
  780. harry837374884 has left
  781. marc0s has left
  782. marc0s has joined
  783. marc0s has left
  784. marc0s has joined
  785. adiaholic has left
  786. Andrzej has joined
  787. mjk has left
  788. mjk has joined
  789. harry837374884 has joined
  790. adiaholic has joined
  791. petrescatraian has joined
  792. petrescatraian has left
  793. krauq has left
  794. krauq has joined
  795. adiaholic has left
  796. mjk has left
  797. xnamed has left
  798. mjk has joined
  799. Andrzej has left
  800. Dele Olajide has left
  801. Dele has left
  802. Half-Shot has left
  803. Matthew has left
  804. homebeach has left
  805. uhoreg has left
  806. Half-Shot has joined
  807. Matthew has joined
  808. homebeach has joined
  809. uhoreg has joined
  810. adiaholic has joined
  811. libre has left
  812. mjk has left
  813. mjk has joined
  814. libre has joined
  815. Andrzej has joined
  816. jjrh has left
  817. jjrh has joined
  818. adiaholic has left
  819. arc has left
  820. arc has joined
  821. mjk has left
  822. adiaholic has joined
  823. mjk has joined
  824. antranigv has left
  825. adiaholic has left
  826. arc has left
  827. arc has joined
  828. Andrzej has left
  829. L29Ah has left
  830. adiaholic has joined
  831. ralphm jonas’: is that new XEP ephemeral itself, or is it just a broken link?
  832. jonas’ ralphm, thanks for pointing it out, I fixed it
  833. jonas’ (I had forgotten to actually deploy the new stuff to the server)
  834. ralphm 😉
  835. debacle has joined
  836. mjk has left
  837. ralphm FWIW: I think that the concept of ephemeral messages, with all the caveats in the spec, is a mis-feature.
  838. mjk has joined
  839. djorz has joined
  840. jonas’ why do you think so?
  841. Andrzej has joined
  842. adiaholic has left
  843. Menel has left
  844. L29Ah has joined
  845. Menel has joined
  846. Menel has left
  847. Menel has joined
  848. moparisthebest I think it's stupid too but you know it's the next "one thing (tm)" that XMPP is missing
  849. antranigv has joined
  850. Andrzej has left
  851. lovetox i dont see this working ..
  852. lovetox whats with the negotiation .. why?
  853. moparisthebest it's ok all it needs to do is give people a false sense of security
  854. lovetox every user should just choose when his messages going to be removed
  855. moparisthebest signal has it after all
  856. lovetox why negotiate something
  857. Yagiza has left
  858. mjk has left
  859. mjk has joined
  860. Maranda[x] has left
  861. Maranda[x] has joined
  862. Menel has left
  863. marc0s has left
  864. marc0s has joined
  865. marc0s has left
  866. marc0s has joined
  867. libre has left
  868. Wojtek has left
  869. libre has joined
  870. Maranda[x] has left
  871. Maranda[x] has joined
  872. antranigv has left
  873. Menel has joined
  874. arc has left
  875. arc has joined
  876. Menel has left
  877. mjk lovetox: because any participant's message could incriminate any other participant (even without considering >quoting)
  878. mjk The falseness of security sense is up to client UI designers to dispell, I'd hope :)
  879. mjk No need to follow misleading ui of $super_recure_messenger
  880. Menel has joined
  881. Kev has left
  882. Menel has left
  883. gooya has left
  884. adiaholic has joined
  885. Syndace has left
  886. Syndace has joined
  887. Menel has joined
  888. Menel has left
  889. adiaholic has left
  890. Dele Olajide has joined
  891. Maranda[x] has left
  892. Maranda[x] has joined
  893. mjk pep.: some wording feedback, I guess... Better late than never, lol > Provide a way to specify a timer value after which message contents must be deleted from user devices. 'Must' seems a bit too strong here, even not in all-caps. I think something along the lines of 'expected to be' or 'agreed to be' would convey the intention more precisely. > A way to securely ensure that logs won’t be kept by parties included in chats. I'd emphasize that _untrusted_ parties are meant here (iiuc)
  894. marc0s has left
  895. marc0s has joined
  896. arc has left
  897. Menel has joined
  898. arc has joined
  899. pep. mjk, that non-binding must is clarified in the implementation notes
  900. mjk Ok, I'll take a look
  901. pep. Or was it business rules
  902. pep. « Discarded messages shall be removed from memory and disk on a best effort basis. Timers do not have to be exactly exact, the definition of "seen" or "read" not being consistent, and clock issues might also be a thing (use NTP?). This is also a best effort basis. »
  903. Toxi has left
  904. gooya has joined
  905. pep. As for your second comment, hmm.
  906. mh has left
  907. mh has joined
  908. pep. « § Security Considerations Ephemeral messages are not to be considered "secure" in any way. Even within well-meaning entities, requiring that messages be discarded and made impossible to retrieve, requires a lot more scrutiny in the specification and in implementations, and even then, is a really technically challenging task, to say the least. »
  909. moparisthebest should you mention annoying things like apps preventing screenshots from being taken of them etc ?
  910. pep. I think that summarizes it
  911. mjk Yeah, so best effort. I just think it would be better to pre-iterate that in sect. 2, it being read one of the first
  912. pep. moparisthebest, no it's exactly what I don't want this spec to be
  913. moparisthebest I think that's what "the signal" does
  914. pep. Read the security considerations
  915. moparisthebest oh, well then that can be the next "one thing (tm)" preventing xmpp adoption
  916. pep. Yeah I'm not worried about that, there's always something :)
  917. pep. I guess I should put security considerations as the first section really.
  918. mjk :d
  919. mjk :D
  920. pep. With a "I read and it's ok I'm willing to continue" before the rest shows up
  921. mjk Put it in abstract!
  922. adiaholic has joined
  923. alex11 has left
  924. krauq has left
  925. adiaholic has left
  926. libre has left
  927. libre has joined
  928. Dele Olajide has left
  929. adiaholic has joined
  930. bean has left
  931. mh has left
  932. mh has joined
  933. krauq has joined
  934. tykayn has left
  935. adiaholic has left
  936. libre has left
  937. libre has joined
  938. Toxi has joined
  939. Tobias has left
  940. Tobias has joined
  941. marc has left
  942. Maranda[x] has left
  943. Maranda[x] has joined
  944. jonas’ who reads *that*?
  945. adiaholic has joined
  946. papatutuwawa has left
  947. adiaholic has left
  948. Menel has left
  949. ralphm The difference with Signal and WhatsApp are that they are controlled environments. And even then there are cases where a request to delete a message may fail to be honored. I really dislike the false sense of security it gives to the use. Federation, as with the open XMPP network makes this even less useful.
  950. ralphm The difference with Signal and WhatsApp are that they are controlled environments. And even then there are cases where a request to delete a message may fail to be honored. I really dislike the false sense of security it gives to the user. Federation, as with the open XMPP network makes this even less useful.
  951. ralphm But sure it checks a box 🤷
  952. jonas’ is this the right place to point out that not all XMPP deployments are federated or with free choice of apps used?
  953. Guus ralphm: I don't fully agree. There is nothing that prevents you to use XMPP in a controlled environment.
  954. jonas’ ^5 Guus
  955. adiaholic has joined
  956. Guus we're on a roll today, jonas’
  957. msavoritias Isnt the "false sense of security" up to the client? No user is gonna read the XEP. So its up to the client to make it clear. And implement it or not. I mean clients choose to implement or not XEP all the time. Plus there are a lot of XEPs that are tricky to implement due to the extensibility of the protocol like MIX or the new OMEMO. Doesnt mean its not worthwhile
  958. brunrobe has left
  959. Mjolnir Archon has left
  960. Maranda has left
  961. krauq has left
  962. ralphm Yes, iff you have a fully controlled environment, including the federation part, then yes it may work. I still think it is not great. Screenshots, photos of screens, etc.
  963. Tobias has left
  964. jonas’ right, but *that* is definitely outside the XSF' scope
  965. jonas’ (screenshots etc.)
  966. jonas’ so I'd say we go for a spec even if it never ends up in the compliance suites or somesuch because of the inherent issues with federation
  967. ralphm I think it is much more useful to tell users: as soon as you hit enter, you can no longer trust that your message will not end up in places you don't want them.
  968. jonas’ I don't agree
  969. ralphm But having a single spec for the intent is better than everyone reinventing the wheel, badly.
  970. ralphm I get what you're saying, but I have issues with so-called secure messaging systems. They generally fail to communicate the full picture. Whether something is secure depends on your threat model.
  971. pep. Then again all I'm reading here is "I haven't read security considerations"
  972. ralphm Scroll back to my first message
  973. pep. "I still think it is not great. Screenshots, photos of screens, etc."
  974. pep. :/
  975. ralphm (19:18 UTC)
  976. pep. Yeah but you're still talking about screenshots, and that's not related to this spec
  977. arc has left
  978. arc has joined
  979. ralphm It is, people generally don't understand technology. If you present them with a feature that says that says 'delete for all users', or 'this message will self-destruct in 10 seconds', it makes a promise you can't keep.
  980. pep. Anyway if this doesn't go through with the XSF, again, I'll host it somewhere else so that it can be implemented anyway because yes that's a feature people want so maybe someday we can answer the demand instead of staying in our little enterprisy world
  981. krauq has joined
  982. msavoritias has left
  983. ralphm My context also includes vulnerable users. Like young teens.
  984. ralphm pep.: I'm not objecting to the spec, I'm objecting to the feature. That's not on you. Again, having a spec for a feature I don't like is better than not.
  985. pep. Sorry this wasn't really clear because it's been rejected for this exact reason before as well
  986. mjk ralphm: re. false sense if security. What sense of security is meant here, exactly? When you trust your contact and their opsec practices, trust the client software used by both of you and use verified-key e2e encryption, what remains to trust here? Security of secure deletion implementation? I think this is a (majoro point that should be conveyed clearly by client devs in the ui. Like, what exactly is the deletion impl.
  987. atomicwatch has left
  988. mjk ralphm: re. false sense if security. What sense of security is meant here, exactly? When you trust your contact and their opsec practices, trust the client software used by both of you and use verified-key e2e encryption, what remains to trust here? Security of secure deletion implementation? I think this is a (major) point that should be conveyed clearly by client devs in the ui. Like, what exactly is the deletion impl.
  989. pep. But anyway, I'm happy with the feature as it is now. I mean there,s lots of technical holes that I'd like filled, and I need feedback on this, but otherwise I'd be happy that progressively people stop logging stuff forever
  990. pep. Maybe the issue is the name, because there are expectations from other messengers
  991. Link Mauve mjk, a very common usecase is to think you can trust your contact but then it turns out they were the attacker all along.
  992. pep. (Even though a client doesn't have to reuse this name obviously)
  993. jcbrand has left
  994. ralphm mjk: my PoV includes people that cannot make such determinations, because they are a-technical or don't have a developed pre-frontal cortex.
  995. pep. Link Mauve, in this case it's not a technical problem it's a social problem and no amount of technicality is going to fix this
  996. mjk Link Mauve: that shoud apply to communications in general, not deletion specifically :)
  997. Link Mauve Yes to both.
  998. Link Mauve But when you make automated deletion an advertised feature, people will tend to use it in cases where it is ill-suited.
  999. pep. "don't have a developed pre-frontal cortex" what
  1000. Link Mauve The usual nude that will be deleted ten seconds later, which then gets posted widely to the Internet.
  1001. mjk ralphm: fair. :) A sufficient barrier to entry might mitigate this concern, like having to go install a plugin or enable a well-hidden feature...
  1002. pep. Link Mauve, where is it ill-suited to ask the other client to delete your nude? It's only unfortunate that the other client doesn't ""support"" it
  1003. pep. You may have done it anyway if deletion wasn't advertized
  1004. pep. Ask kids who use snapchat
  1005. adiaholic has left
  1006. Link Mauve I only know dealers who use snapchat. ^^'
  1007. mjk "hey kid, wanna see some real free software?"
  1008. pep. Anyway, of course UX is important, and I'm not sure why I'm answering on security concerns here when the whole point of this spec is privacy. Have the client find a way to present it to the user as a non-security feature
  1009. pep. Even just to have all your clients follow the same logging policy I think it's worth it
  1010. Link Mauve Couldn’t that be a PEP node which configures that, if you want to change the logging policy?
  1011. pep. I don't want to change just mine
  1012. Link Mauve Or pretty much any policy which should be synchronised between clients.
  1013. mjk > Have the client find a way to present it to the user as a non-security feature Like, e.g., Conversations does for years in file deletion modal dialog
  1014. lovetox im on the side that XSF should not care about "Users"
  1015. pep. What does this mean exactly? Even though I don't think I agree whatever this means :P
  1016. lovetox The way should be Users tells client dev wishes -> Client dev tells XSF protocol needs
  1017. lovetox XSF is not here for Users, and is not there to shild and protected users from bad client devs
  1018. lovetox otherwise you need to remove all XEPs ever
  1019. konstantinos has left
  1020. pep. It's not here to "shield users from bad client devs" no, whatever that means, but it's here to answer user's expectations. When something is wanted by users in the community, the XSF should probably get onto it
  1021. lovetox Users = Users of Clients
  1022. pep. Sure
  1023. lovetox no, sorry, they dont usually come here and tell what they want
  1024. pep. The XSF doesn't live in a vacuum
  1025. lovetox they create issues on client developer issue trackers
  1026. marc has joined
  1027. lovetox Users dont care about xml which is sent here and there
  1028. pep. Many users gravitate around here, and many people gravitating aroudn the XSF are devs and are able to report user expectations. And I think the XSF should hear this and react.
  1029. lovetox no pep. there is handfull of users of thousands here in the chat
  1030. pep. "and many people gravitating around the XSF [..] are able to report user expectations"
  1031. pasdesushi has left
  1032. lovetox correct, client / server devs report users expectations for features, and XSF makes protocol
  1033. pep. So we're saying the same thing?
  1034. pep. I do think the XSF should care about users. Of course users don't care about the ways it goes on the wire and that's fine
  1035. lovetox the job is to make a protocol, maybe write down common pitfalls and requirements
  1036. mjk > im on the side that XSF should not care about "Users" If anything, I think this is rather an argument _for_ not against the advancement of the xep at hand :3
  1037. lovetox but not to say: Uh we are federated, im not sure 100% of devs implement this 100% secure
  1038. lovetox so lets not even start to make a protocol
  1039. pep. lovetox, yeah but XEPs aren't made in vacuum either. They answer a demand
  1040. Seve has left
  1041. lovetox yeah for sending xml over networks, not to make sure users are not mislead by clientand serve rdevelopers
  1042. pep. I don't understand what you're answering to here
  1043. lovetox to the common answer about epheral messages: Uh but what if client X does not delete the message
  1044. pep. I guess I understand you're defending the spec? But it's still a weird position to me
  1045. lovetox yeah its none of your business
  1046. lovetox *XSF
  1047. lovetox because what if servers store messages although user deactivated it in archiving preferences?
  1048. marc0s has left
  1049. marc0s has joined
  1050. lovetox what if server routes message wrong altough RFC says otherwise
  1051. lovetox what if client does encryption wrong, altough XEP says otherwise
  1052. lovetox like i can make a million errors as developer
  1053. marc has left
  1054. lovetox for none of them any one in the XSF would held be responsible
  1055. pep. Well again, no. The XSF isn't of course responsible of everything devs do, but it should ensure the document it produces are understandable and warn users about common pitfalls, as you said above. And if it's still not clear / hard to do, I'd say the XSF could point to example / reusable implementations
  1056. marc0s has left
  1057. marc0s has joined
  1058. marc0s has left
  1059. marc0s has joined
  1060. lovetox yes, describe whatever is needed
  1061. goffi has left
  1062. pep. Great we agree about this. I still don't agree that the XSF shouldn't care about users. Of course it should. XEPs aren't written just to be pretty (at least I'm not hanging any framed on my walls), they're written to serve a purpose and answer users demand.
  1063. arc has left
  1064. arc has joined
  1065. lovetox with care about users i meant, caring in a way parents care, "i will not publish this XEP because i fear you are not able to comprehend the implications"
  1066. lovetox the argument against this XEP is always the same, BUT what if one client does not respect the deletion wish"
  1067. lovetox and i think its not really a useful argument
  1068. pep. Note that I'm not trying to argue against my own spec here. I think the spec AND the feature are fine as it is and it's possible to implement it in such a way that it's not misleading. PLUS, users are demanding such feature so it's about time we start doing something about it
  1069. mjk well said
  1070. moparisthebest As council I'll pass the spec if it's sound from a technical perspective
  1071. moparisthebest As moparisthebest I'm definitely publishing patches for all clients that implement this to claim to implement it but never actually delete anything >:)
  1072. mjk has left
  1073. mjk has joined
  1074. ralphm pep.: the brains of kids till the age of 23 are not fully developed. This causes them to generally be unable to properly oversee the outcomes of their actions.
  1075. pep. ralphm, so we should be good parents and prevent them from using their phone? instead of telling them it has to be used with caution?
  1076. moparisthebest pep.: correct
  1077. pep. ..
  1078. Sam Yes, children should not have phones.
  1079. moparisthebest And teach them that once you send anything over the internet there is no pulling it back
  1080. pep. What have I started
  1081. mjk has left
  1082. pep. Ok so I guess we should also remove old people's phones because they don't know how to use them
  1083. ralphm pep.: I don't know if you have kids yourself or in your extended family, but yes this is a difficult trade-off.
  1084. pep. And maybe we should also remove poor people's phones because they've got less time to fiddle with them and they are less used to them, they're not getting much training
  1085. pep. What else
  1086. moparisthebest If you don't know how to use something you should indeed not use it
  1087. pep. moparisthebest, I disagree
  1088. pep. You should be able to receive proper training
  1089. mh has left
  1090. mh has joined
  1091. moparisthebest Absolutely, gotta take the initiative and time to learn though
  1092. mjk has joined
  1093. mjk "don't let kids into the internet, they make it dumb!"
  1094. karoshi has left
  1095. mjk (-er)
  1096. pep. moparisthebest, I agree it's really hard nowadays when all we're doing is work in bs jobs..
  1097. qwestion has left
  1098. gooya has left
  1099. emus Folks, is fine to review user expierence but I dont think such a meta discussion helps this topic
  1100. gooya has joined
  1101. emus Internet has many bad ibfluences to people. lets stop with real-time communciation?
  1102. ralphm Disagree
  1103. pep. emus, yeah definitely, way to go :)
  1104. emus ^^
  1105. moparisthebest I don't think anyone said that, my point was simply that people should understand the tools they use, it's dangerous not to
  1106. debacle has left
  1107. pep. I think people should be given the chance to learn the tools they use, rather. I prefer this wording because yours dangerously makes me think that you'd want to limit people who have access to these tools
  1108. libre has left
  1109. moparisthebest Nope I fully agree with you
  1110. libre has joined
  1111. arc has left
  1112. moparisthebest Encourage them to learn their tools even
  1113. arc has joined
  1114. emus I tend to think the same
  1115. mjk And we're back to good (=educational) UI :)
  1116. pep. That's prerequisite yeah (though my comment was a lot more general about society :P)
  1117. ralphm I think it is very useful to discuss these things in this forum. And yes, the world isn't perfect. I personally have tried to teach my teen daughter about the dangers of putting information out there, e.g. on Instagram, Snapchat, etc. She generally understands, but also it is very hard, if not impossible, to make the 'right' judgement calls. Besides lacking the part of their brain responsible for such choices, there are also things like peer pressure and what is considered 'normal'. So she will get it wrong sometimes and I just hope that it'll work out reasonably well. That all said, this doesn't mean that we should just throw up our hands and blindly implement things. Having an opinion on whether a feature is the right thing to do, is just ok. And we can disagree. But the discussion itself is useful.
  1118. emus I missed the beginning. but as there is a proto-xep people can implement it regardless of our discussion right?
  1119. moparisthebest emus: https://xmpp.org/extensions/inbox/ephemeral-messages-v2.html
  1120. ralphm The great thing about XMPP is that yes you can generally do what you want
  1121. pep. There is a protoxep. People can't implement it just yet because it's not technically complete and I was hoping for this step to get feedback, because I haven't managed to get technical feedback on this before.
  1122. emus moparisthebest: yes I know the xep, but thanns
  1123. emus pep.: ok
  1124. pep. (That is, I actually got feedback nowhere.)
  1125. moparisthebest pep.: Technical wise I'm not sure the reason for https://xmpp.org/extensions/inbox/ephemeral-messages-v2.html#example-3
  1126. emus understood
  1127. ralphm Sorry I didn't really get into the protocol itself. I hope you can appreciate my input anyway.
  1128. moparisthebest Or the "they will expire in X from now on" language
  1129. emus thx, but gn8
  1130. moparisthebest Shouldn't each message just have it's own individual timer and that's it?
  1131. pep. moparisthebest, it's to reflect changes when there's an action in the UI. userX configures it as timeX and userY sends new message with timeX
  1132. moparisthebest Also makes the strange <i-want-out/> thing go away, but I might be missing a reason?
  1133. moparisthebest The time is per message though? Shouldn't each message just have a timer?
  1134. pep. i-want-out is because I have no clue how to do, see the TODO
  1135. pep. Please help.
  1136. marc0s has left
  1137. marc0s has joined
  1138. moparisthebest Imho get rid of all that and simply send an "expires after" per message?
  1139. adiaholic has joined
  1140. pep. Getting rid of the negociation is kinda changing the idea of the spec isn't it
  1141. pep. I want to implicate users around me when I do this
  1142. pep. I'm not doing this in isolation. I don't just want my messages to be erased, I want my circles to also benefit from this
  1143. moparisthebest Unclear what you mean
  1144. marc0s has left
  1145. marc0s has joined
  1146. pep. hmm, which part
  1147. marc0s has left
  1148. marc0s has joined
  1149. moparisthebest What are you missing simply by saying "please delete this message after X" sent per message?
  1150. adiaholic has left
  1151. pep. Is it still about the implicit timer thing?
  1152. moparisthebest And, maybe something in disco hinting they might do it
  1153. moparisthebest Yea that part is confusing to me, seems needlessly complicated
  1154. pep. Ok remove the implicit timer thing, I feel there's something more that bothers you but I'm not sure what
  1155. qwestion has joined
  1156. pep. Is it not clear why I need a way to opt-out (once I've opted-in)
  1157. moparisthebest I'm saying don't have a way to opt in or out
  1158. moparisthebest Just a TTL per message only
  1159. Half-Shot has left
  1160. homebeach has left
  1161. Matthew has left
  1162. uhoreg has left
  1163. Half-Shot has joined
  1164. Matthew has joined
  1165. homebeach has joined
  1166. uhoreg has joined
  1167. brunrobe has joined
  1168. pep. Maybe you're missing the point of the spec?
  1169. pep. (naively asking)
  1170. pep. Or maybe you're right but I don't see it
  1171. pep. "This specification encourages a shift in privacy settings wrt. logging policies."
  1172. moparisthebest I might be that's what I'm asking
  1173. pep. I'm not aiming at this being just an isolated user wanting their messages deleted
  1174. moparisthebest Wait is the TTL not actually per message but modifies a per conversation setting?
  1175. pep. Yeah the TTL isn't per-message, it's per-"chat"
  1176. pep. Well, "per-chat-from-now-on"
  1177. moparisthebest That sounds like it should be in pep then no?
  1178. pep. Not sure how to call that
  1179. adiaholic has joined
  1180. pep. Which PEP?
  1181. pep. of the two person in 1:1
  1182. moparisthebest Like a public user setting for their contacts?
  1183. pep. And if they're not in my contacts
  1184. pep. and in MUC?
  1185. moparisthebest Please delete all my messages after X
  1186. pep. Read the spec, this question is already in there
  1187. moparisthebest This can't even work in a muc
  1188. pep. why not
  1189. wurstsalat has left
  1190. Maranda[x] has left
  1191. moparisthebest At least not a public one
  1192. pep. If not I'll make it work
  1193. pep. That's a social issue
  1194. pep. technically it works
  1195. moparisthebest Because you are pep. Now doesn't mean the pep. Who sends the next message is you
  1196. pep. I'm not sure where you're getting at
  1197. pep. I'm not sure what you're getting at
  1198. moparisthebest I don't have your jid
  1199. pep. Why is that needed
  1200. Maranda[x] has joined
  1201. moparisthebest What about instead of all this complicated state management you simply send a TTL per message?
  1202. adiaholic has left
  1203. moparisthebest Seems like the same result, and servers could expire from mam, and you don't need to figure out opting out and all that?
  1204. pep. Well I'm doing this, but not really. The negociation is so that all participating clients behave the same way (if possible)
  1205. pep. Imagine I don't negociate and only I send the TTL. Does that mean I'm going to delete messages I receive from the other as well because I care? What about messages that the other sends that's logged on their device?
  1206. moparisthebest I mean keep the disco feature, but then simply send a TTL per message
  1207. pep. So the disco feature would mean what
  1208. moparisthebest If they send a TTL then you delete it, if not, your choice
  1209. moparisthebest disco is just a pinky promise that you intend to honor the TTL on this client
  1210. pep. "moparisthebest> If they send a TTL then you delete it, if not, your choice" yeah and that's not the spirit of the spec
  1211. moparisthebest I don't understand how that changes anything
  1212. pep. I want this to be a timer for the conversation (on all participating-and-implementing devices), not for one message
  1213. moparisthebest That seems overcomplicated with no use cases not covered by per message TTL ?
  1214. pep. Basically what I hear when you say this is that user will have to go enable the thing themselves
  1215. pep. I mean,
  1216. pep. They'll have to somehow learn about the thing and enable it maybe. Basically only nerds will enable it
  1217. moparisthebest It can be a default, or you can suggest the client sets the TTL for their outgoing messages to the first one received?
  1218. pep. Whereas if all participants in a chat agree on it, that's all the more people that are made aware of it (dialog or status message or whatever)
  1219. pep. I have to admit I'm also not clear on why it's best as a per-chat thing, but I think there's an important difference
  1220. moparisthebest To me this reads like a complicated state machine where you have to read all messages in order to figure out when to delete each message
  1221. moparisthebest Considering sometimes you read mam backwards or have holes, that seems bad
  1222. qwestion has left
  1223. moparisthebest Where as a per message TTL gives you the same experience but is stateless
  1224. pep. I agree that does complicate things but it's also not the same goal.
  1225. pep. And if there's a way to answer this technically I'd be happy to know
  1226. moparisthebest You can keep the same goal with a per message TTL though right?
  1227. pep. Well I'm not sure no
  1228. moparisthebest I *think* I understand your goal now anyway, I didn't initially
  1229. moparisthebest Basically keep the spec the same, but you don't store/calculate TTL seperately from the messages
  1230. pep. Tbh if there could be like, one PEP node negociated for the current chat, that might make things a lot easier..
  1231. moparisthebest You can still use the last messages TTL to show the user and send in your next message etc
  1232. pep. "You can still use the last messages TTL to show the user and send in your next message etc" well in practice that's what happens
  1233. Mjolnir Archon has joined
  1234. Maranda has joined
  1235. moparisthebest The difference being you don't need to replay all history in order to calculate current TTL, only look at the last message
  1236. pep. You don't "calculate" the TTL, it IS sent with every message
  1237. adiaholic has joined
  1238. mjk it is?
  1239. pep. ATM it is yes
  1240. mjk goes re-reading the xml
  1241. mjk it is.
  1242. pep. Anyway.. This protoxep is less of a "hey I know what I'm doing I exactly want this" it's more "I have these goals, how do I achieve them plz"
  1243. pep. And I didn't find a way to get feedback before the protoxep so here it is..
  1244. moparisthebest What do you do if you send me a message with the ephemeral tag and I respond without one?
  1245. pep. If you don't implement the feature then so be it. Otherwise you should send the same back
  1246. pep. And "so be it" if you don't do it anyway
  1247. pep. I can't control your client
  1248. moparisthebest I mean, is that your cancel mechanism?
  1249. moparisthebest "Well they don't want me deleting their messages now" ?
  1250. pep. That's where I'm stuck :/
  1251. adiaholic has left
  1252. pep. How do I opt-out once I've opted-in
  1253. moparisthebest I'd vote either that or a TTL of 0
  1254. moparisthebest But if code has to handle both the same don't bother with both
  1255. pep. "that" isn't good I guess
  1256. pep. "that" isn't good I guess
  1257. pep. Because any non-implementing client would make me stop the TTL
  1258. pep. When MAM and stuff
  1259. pep. So there needs to be a <thing/>
  1260. pep. And it needs to be seen.
  1261. mjk if one of your contact's clients doesn't implement the xep, you shouldn't treat no-ttl as i-want-out, so zero ttl sounds sane
  1262. pep. ttl=0 seems like a hack, but yeah that's the idea of the <i-want-out/>
  1263. moparisthebest Shouldn't non implementing clients make you stop though?
  1264. pep. Maybe @timer should be Option<u32>
  1265. moparisthebest I mean UI should indicate the other client won't listen anymore
  1266. pep. moparisthebest, no, same problem as usual
  1267. pep. Yes
  1268. pep. That's specified
  1269. moparisthebest I don't think 0 is a hack, a real TTL of 0 makes no sense
  1270. pep. Non-implementing clients shouldn't make anybody stop from using specific features because MAM and the like
  1271. pep. But that's annoying I get it
  1272. Titi has left
  1273. mjk a hack in the sense it's a sum type? like option<u32>
  1274. adiaholic has joined
  1275. moparisthebest If you expect your messages to me to be deleted and I suddenly tell you I won't, you certainly shouldn't keep sending assuming I will
  1276. arc has left
  1277. arc has joined
  1278. pep. moparisthebest, so we started chatting both with supporting clients, we agree on a ttl, you've switched clients for 2 messages and it doesn't support the spec, you afk but I keep sending you messages. What should I do?
  1279. pep. Do I stop sending you ttl'd messages?
  1280. pep. Do I send two different messages to your fulljids? :P
  1281. mjk also, with mam, any non-implementing client can retrieve later and store forever. that's always a possibility
  1282. sonny has left
  1283. adiaholic has left
  1284. pep. Yeah, any client you own I don't know about can read these messages. So I'd rather wait for an explicit "nope" than something that can be misunderstood for "I don't implement it"
  1285. moparisthebest pep.: Yea you stop sending them if you need them deleted
  1286. pep. Where that's not my spec is about
  1287. pep. Well that's not my spec is about
  1288. moparisthebest In your example in the xep they'd respond like "hey you switched to a client that won't keep this private can you switch back?"
  1289. pep. "Abstract This specification encourages a shift in privacy settings wrt. logging policies."
  1290. pep. It's fine if a message isn't deleted
  1291. moparisthebest Same as when you are having an OMEMO conversation with someone and they suddenly send a few unencrypted
  1292. pep. This isn't a security spec
  1293. moparisthebest If you aren't trying this spec is useless
  1294. moparisthebest This isn't even some strange edge case, it needs covered
  1295. pep. No because there's no way I know about clients you haven't even told me yet that are going to have access to MAM
  1296. pep. And I'm not going the way "then don't store in MAM"
  1297. pep. Because I want clients to still be usable
  1298. pep. fwiw that's what the old version was doing
  1299. moparisthebest You can't because then you are back to not working on iOS
  1300. mjk > In your example in the xep they'd respond like "hey you switched to a client that won't keep this private can you switch back?" I agree that this would be in line with 'best effort' nature of the spec
  1301. pep. This isn't technically possible
  1302. qwestion has joined
  1303. pep. Or it is but you're willing to go to lengths this spec isn't, because it's not the goal
  1304. mjk i mean, it's up to implementation to notice and warn the user
  1305. moparisthebest If you wanted to try real hard you'd require encryption and sign the promise with keys and only encrypt to keys that promised ?
  1306. pep. Yeah but I'm not doing that
  1307. pep. I just want to change the default storing policies in clients but no implementation will follow me because for some reason I can't understand they all like their logs
  1308. moparisthebest mjk: yes exactly, and I think the implementation then has to show the same warning for "I opt out" and "they aren't sending it anymore" no pep. ?
  1309. pep. (I also do have logs on my poezio and I don't understand why, it's useful sometimes, ok, but not really important)
  1310. moparisthebest You can continue sending ephemeral in your messages of course
  1311. moparisthebest pep.: I have the solution for that
  1312. pep. "If this includes sending to non-supporting clients, and they can be detected, sending clients SHOULD warn the user in some way. Clients MAY warn users anyway if non-supporting clients cannot be detected (e.g., when they don’t get a directed presence)."
  1313. pep. In the spec ^
  1314. moparisthebest I have my conversations set to delete all messages older than a week, not because I want to, but because the database is too slow with too many messages lol
  1315. pep. Maybe I should change that to "You never know what new client is going to have access to MAM so you should warn anyway."
  1316. pep. moparisthebest, :D
  1317. moparisthebest pep.: right so then how does "I opt out" differ from "I have a different client that won't do it" if you show the same message to the user?
  1318. moparisthebest I don't think it does, therefore not getting it should be your opt out message
  1319. pep. When a client says "I opt out", the receiving client can show a status message or something
  1320. pep. "TTL has be removed"
  1321. moparisthebest It should show the same if they switched to a different client?
  1322. pep. Show the same what?
  1323. pep. TTL hasn't be removed for a non-supporting client, it was never supported
  1324. moparisthebest The result is the same
  1325. pep. The result is the same, but I'd warn in different places
  1326. moparisthebest In both cases they know their contact won't delete the messages
  1327. pep. The non-supporting client might have been listening all along and that's fine
  1328. pep. Yes
  1329. pep. Because they've been told when activating the feature
  1330. mjk > "If this includes sending to non-supporting clients, and they can be detected, sending clients SHOULD warn the user in some way. Clients MAY warn users anyway if non-supporting clients cannot be detected (e.g., when they don’t get a directed presence)." > In the spec ^ okay, I admit I don't usually read through the entire discussion subject :D
  1331. moparisthebest Then I'm back to why have an opt out at all
  1332. moparisthebest If you aren't going to show any special warnings
  1333. pep. I just told you I would
  1334. pep. (?!?!?)
  1335. moparisthebest > Because they've been told when activating the feature
  1336. moparisthebest You said one warning at the beginning is all?
  1337. pep. And pep.> When a client says "I opt out", the receiving client can show a status message or something pep.> "TTL has be removed"
  1338. marc0s has left
  1339. moparisthebest And it should show the same when receiving no TTL at all...
  1340. pep. No
  1341. pep. Well I don't think so
  1342. moparisthebest It's the same effect
  1343. marc0s has joined
  1344. pep. In one case the user has been warned that there might be non-supporting devices receiving this. In the other case a client has explicitely asked for the feature to stop. Yes in both cases messages won't be deleted, but no it's not the same thing
  1345. djorz has left
  1346. mjk has left
  1347. mjk has joined
  1348. mjk > it's not the same thing because there's probably a conscious human decision behind the latter
  1349. moparisthebest Maybe they explicitly switched to the unsupporting client?
  1350. moparisthebest I don't think they have a meaningful distinction
  1351. pep. Maybe they did, and maybe they'll tell the sending client to stop, like in human speech
  1352. pep. That's a thing also :P
  1353. pep. Whether the client wants to merge UI for this is ok, but protocol-wise I'll keep that different
  1354. mjk too sleepy for consciou human anything
  1355. pep. It'd still be weird to me that these two are merged
  1356. emus has left
  1357. moparisthebest I think it's dangerous to allow them to handle it differently
  1358. moparisthebest Because inevitably someone will, and that'll be wrong
  1359. pep. Well say we handle them the same way
  1360. pep. That means while not everybody implements it, we can't use the feature
  1361. libre has left
  1362. libre has joined
  1363. pep. That means as long as not everybody implements it, we can't use the feature
  1364. krauq has left
  1365. libre has left
  1366. libre has joined
  1367. krauq has joined
  1368. moparisthebest This is introducing a nullable Boolean into the spec
  1369. moparisthebest And saying "treat null the same as false"
  1370. moparisthebest Instead of just making it non nullable
  1371. pep. Yeah no sorry I don't want to live in a maybe monad
  1372. moparisthebest > That means as long as not everybody implements it, we can't use the feature I'm not following
  1373. moparisthebest The client behaves the same either way
  1374. libre has left
  1375. libre has joined
  1376. pep. If every time you switch devices my client stops sending the TTL, I'm gonna have to reenable it when I know you're on a supporting client. That looks like a pretty shitty user experience to me
  1377. pep. I'm probably stop using it before I even start
  1378. Half-Shot has left
  1379. homebeach has left
  1380. Matthew has left
  1381. uhoreg has left
  1382. Half-Shot has joined
  1383. Matthew has joined
  1384. homebeach has joined
  1385. uhoreg has joined
  1386. pep. I'll probably stop using it before I even start
  1387. gooya has left
  1388. pep. As I said this spec isn't a security spec
  1389. moparisthebest > If every time you switch devices my client stops sending the TTL, I'm gonna have to reenable it when I know you're on a supporting client. Don't do that! Keep sending it
  1390. pep. wat
  1391. adiaholic has joined
  1392. pep. Ok I didn't get what you mean then
  1393. moparisthebest Like you said mam and other clients might come back online etc
  1394. pep. So what changes
  1395. pep. Both clients might have been listening all the time. Because suddenly you decide from one shouldn't change anything to me
  1396. pep. Both clients might have been listening all the time. Because suddenly you decide to write from the other shouldn't change anything to me
  1397. moparisthebest Right, other than you warn the user that they won't be deleting them now
  1398. pep. "now"?
  1399. pep. Both clients were listening from the start
  1400. pep. The sending user has been warned already
  1401. Ingolf has joined
  1402. neshtaxmpp has left
  1403. neshtaxmpp has joined
  1404. pep. Ah, the receiving client may not delete these messages though.. because they don't include the TTL.
  1405. pep. Is that another issue or is it what you were pointing at for all this time
  1406. adiaholic has left
  1407. pep. I mean..
  1408. pep. The client receiving non-TTL'd messages
  1409. djorz has joined
  1410. libre has left
  1411. libre has joined
  1412. mjk has left
  1413. libre has left
  1414. libre has joined
  1415. Half-Shot has left
  1416. homebeach has left
  1417. Matthew has left
  1418. uhoreg has left
  1419. Half-Shot has joined
  1420. Matthew has joined
  1421. homebeach has joined
  1422. uhoreg has joined
  1423. neshtaxmpp has left
  1424. stp has left