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