XSF Discussion - 2018-06-11

  1. rtq3 has joined

  2. rtq3 has left

  3. Syndace has left

  4. jere has joined

  5. Syndace has joined

  6. la|r|ma has joined

  7. lskdjf has joined

  8. j.r has joined

  9. Lance has joined

  10. Lance has left

  11. alexis has left

  12. alexis has joined

  13. alexis has left

  14. j.r has joined

  15. alexis has joined

  16. dos has left

  17. jere has joined

  18. ta has left

  19. alexis has left

  20. alexis has joined

  21. alexis has left

  22. alexis has joined

  23. daniel has left

  24. daniel has joined

  25. anjan has left

  26. j.r has joined

  27. dos has joined

  28. j.r has joined

  29. dos has left

  30. j.r has joined

  31. SamWhited has left

  32. tux has left

  33. tux has joined

  34. j.r has joined

  35. rishiraj22 has left

  36. rishiraj22 has joined

  37. anjan has left

  38. alacer has left

  39. alacer has joined

  40. alacer has left

  41. waqas has joined

  42. j.r has joined

  43. j.r has joined

  44. Yagiza has joined

  45. ibikk has joined

  46. moparisthebest has left

  47. SamWhited has left

  48. mimi89999 has left

  49. mimi89999 has left

  50. matlag has left

  51. mimi89999 has joined

  52. lorddavidiii has joined

  53. SaltyBones has left

  54. j.r has joined

  55. lorddavidiii has left

  56. alexis has left

  57. alexis has joined

  58. lorddavidiii has joined

  59. SaltyBones has left

  60. lorddavidiii has left

  61. alexis has joined

  62. lorddavidiii has joined

  63. UsL has left

  64. UsL has joined

  65. SaltyBones has left

  66. alacer has joined

  67. goffi has joined

  68. alacer has left

  69. UsL has joined

  70. j.r has left

  71. j.r has joined

  72. rishiraj22 has left

  73. rishiraj22 has joined

  74. SaltyBones has left

  75. rishiraj22 has left

  76. rishiraj22 has joined

  77. rishiraj22 has left

  78. rishiraj22 has joined

  79. ralphm has left

  80. lnj has joined

  81. alexis has left

  82. alexis has joined

  83. alacer has joined

  84. alexis has left

  85. SaltyBones has left

  86. alexis has joined

  87. Zash has joined

  88. alacer has left

  89. Tobias has joined

  90. blabla has left

  91. igor75 has joined

  92. Guus has left

  93. Guus has left

  94. Ge0rG has left

  95. Wiktor has left

  96. Wiktor has joined

  97. UsL has joined

  98. j.r has joined

  99. andy has joined

  100. SaltyBones has left

  101. Guus has left

  102. Guus has left

  103. Guus has joined

  104. Guus has left

  105. Guus has left

  106. Guus has left

  107. Zash has left

  108. Zash has left

  109. Zash has joined

  110. Guus has left

  111. daniel has left

  112. intosi has left

  113. waqas has left

  114. Tobias has left

  115. Tobias has joined

  116. UsL has left

  117. UsL has joined

  118. jubalh has joined

  119. SaltyBones has left

  120. jubalh has left

  121. jubalh has left

  122. marmistrz has left

  123. jubalh has joined

  124. Dave Cridland has left

  125. Dave Cridland has joined

  126. Ge0rG

    moparisthebest: the ideas of the GDPR are slowly making it into US state legislation... https://www.schneier.com/blog/archives/2018/06/new_data_privac.html

  127. SaltyBones has left

  128. andy has left

  129. andy has joined

  130. Nekit has joined

  131. cookie has left

  132. rishiraj22 has left

  133. rishiraj22 has joined

  134. valo has joined

  135. anjan has joined

  136. Dave Cridland has left

  137. Dave Cridland has joined

  138. rtq3 has joined

  139. cookie has joined

  140. marmistrz has left

  141. SaltyBones has joined

  142. alexis has left

  143. alexis has joined

  144. rtq3 has left

  145. rtq3 has joined

  146. alexis has left

  147. alexis has joined

  148. ralphm has joined

  149. j.r has joined

  150. Nekit has left

  151. muppeth has left

  152. muppeth has joined

  153. Nekit has joined

  154. Ge0rG has left

  155. Nekit has left

  156. Nekit has joined

  157. jubalh has joined

  158. lumi has joined

  159. alexis has left

  160. alexis has joined

  161. rishiraj22 has left

  162. rishiraj22 has joined

  163. Dave Cridland has left

  164. Dave Cridland has joined

  165. Chobbes has joined

  166. Chobbes has joined

  167. alacer has joined

  168. rtq3 has left

  169. rtq3 has joined

  170. rishiraj22 has left

  171. rishiraj22 has joined

  172. mimi89999 has joined

  173. rishiraj22 has left

  174. rishiraj22 has joined

  175. Valerian has joined

  176. ralphm has left

  177. la|r|ma has joined

  178. SaltyBones has left

  179. daniel has left

  180. jubalh has joined

  181. rishiraj22 has left

  182. rishiraj22 has joined

  183. valo has joined

  184. Ge0rG has left

  185. rishiraj22 has left

  186. rishiraj22 has joined

  187. ralphm has joined

  188. Alex has joined

  189. Andrew Nenakhov has left

  190. Andrew Nenakhov has joined

  191. Andrew Nenakhov has left

  192. Andrew Nenakhov has joined

  193. daniel has left

  194. Andrew Nenakhov has left

  195. Andrew Nenakhov has joined

  196. daniel has left

  197. blabla has left

  198. blabla has joined

  199. Andrew Nenakhov has left

  200. Andrew Nenakhov has joined

  201. lskdjf has joined

  202. UsL

    US should do article 13 as well. It's awesome. It'll be the best internet.

  203. efrit has joined

  204. rion has left

  205. zak has joined

  206. Ge0rG

    Damn, 0308 is in Draft.

  207. jonasw

    what did you want to change?

  208. Valerian has left

  209. Valerian has joined

  210. Valerian has left

  211. Ge0rG

    jonasw: the biz rules. - allow modifications from other full JIDs of the same user - say that a correction that doesn't qualify shall be displayed like a normal message

  212. Ge0rG

    jonasw: #2 is what Klaus just adressed on standards@

  213. jonasw

    > A correction MUST only be allowed when both the original message and correction are received from the same full-JID.

  214. jonasw

    oh yes, this needs fixing

  215. jonasw

    whoever thought that was a great idea... possibly due to MUC.

  216. jonasw

    I think that any message which doesn’t qualify for the business rules is displayed normally is kinda implicit

  217. Valerian has joined

  218. rishiraj22 has left

  219. Kev

    > whoever thought that was a great idea MUC, mostly, but we can loosen the words for non-MUC.

  220. jonasw


  221. efrit has left

  222. rainslide has joined

  223. rainslide

    Why not make GDPR support into a plugin?

  224. rishiraj22 has left

  225. vanitasvitae has left

  226. edhelas

    if only

  227. Ge0rG

    rainslide: one can not simply module:load legal compliance.

  228. rainslide

    I don't konw my Chinese forum uses which program, it show me a GDPR just now…

  229. rainslide

    GDPR can be spreaded though software😂

  230. alexis has left

  231. vanitasvitae

    <gdpr xmlns='urn:xmpp:legal:gdpr:0' compliant='true'/>

  232. alexis has joined

  233. MattJ

    "It showed me a GDPR just now" -> "a GDPR" is not a large pop-up

  234. lnj has left

  235. Seve/SouL

    Hey kid, got GDPR?

  236. edhelas

    vanitasvitae thanks for the tip! I'll enable it in my client now

  237. Ge0rG

    GDPR is a software-transmitted disease. A so-called STD.

  238. la|r|ma has joined

  239. daniel has left

  240. alexis has left

  241. alexis has joined

  242. daniel has joined

  243. lskdjf has left

  244. lskdjf has joined

  245. rainslide has left

  246. lskdjf has joined

  247. alexis has left

  248. alexis has joined

  249. alexis has left

  250. alexis has joined

  251. blabla has left

  252. alexis has left

  253. alexis has joined

  254. alexis has left

  255. alexis has joined

  256. pep.

    I guess for now we're at <gdpr xmlns='urn:xmpp:legal:gdpr:0' compliant='maybe' />

  257. Ge0rG

    My employer's website redirects you to `about:blank` if you deny the cookie popup. I was ashamed to find that out.

  258. Ge0rG

    I was even more ashamed when the DPO told me this is by design.

  259. pep.


  260. pep.

    Is it even allowed

  261. Ge0rG

    He said yes. We are not required to make business with people who don't want to be tracked.

  262. pep.


  263. Alex has left

  264. lskdjf has left

  265. rtq3 has left

  266. rainslide has joined

  267. Wiktor

    IANAL but... > More importantly, organizations can't restrict website usability or services based on whether or not consent was granted. Source: http://www.dmnews.com/retail-week/gdpr-cookies-personal-data/article/738977/ > For example, a bank that asks for its customers’ consent to use their payment details for marketing purposes, but denies banking services or increases fees if consent is not granted, would be exerting inappropriate pressure. The GDPR does not absolutely prohibit offering services conditioned on consent to data processing, but per Recital 43, any consent so provided is presumed invalid, and the Working Party notes that “[valid] cases will be highly exceptional.” Source: https://iapp.org/news/a/top-10-operational-responses-to-the-gdpr-part-2-lawful-bases-for-processing/

  268. rishiraj22 has left

  269. rishiraj22 has joined

  270. alexis has left

  271. alexis has joined

  272. pep.

    Just like facebook's policy is not legal because it forces you into accepting their crap processing or nothing

  273. pep.

    But then IANAL either

  274. rtq3 has joined

  275. Wiktor

    yep, let's just prepare a lot of popcorn and see what happens to them :)

  276. rainslide has left

  277. daniel

    > My employer's website redirects you to `about:blank` if popup. I was ashamed to find that out. Isn't the real scandal that you can redirect to about: pages? That seems dangerous

  278. Ge0rG

    Wiktor: I agree with you here, but my two coworkers who have undergone GDPR training disagree.

  279. Ge0rG

    daniel: it's just a regular link

  280. pep.

    daniel, what's the issue with that

  281. pep.

    I can redirect you to file:///home/foo/bar, that doesn't mean I can do anything about it

  282. daniel

    pep.: I can't point my finger at something in particular. But that doesn't _right_

  283. Wiktor

    I know Ge0rG, I'm just trying to find supporting text for all these issues as I'm curious myself (but fortunately I don't have this problem now).

  284. Ge0rG

    pep.: you can check the color value of the link via JavaScript to see if you opened it in the past, and whether the file might exist :P

  285. pep.

    Ge0rG, interesting

  286. pep.

    Ge0rG, hmm, but I won't be able to do that via redirecting you there right

  287. pep.

    Ge0rG, hmm, but I won't be able to do that by redirecting you there right

  288. Wiktor

    Ge0rG: I think this was fixed in 2010: https://developer.mozilla.org/en-US/docs/Web/CSS/Privacy_and_the_:visited_selector

  289. rainslide has joined

  290. Ge0rG

    There are so many things in "the web" that undermine security, we should just bury it all in Lake Karachay

  291. rainslide

    > He said yes. We are not required to make business with people who don't want to be tracked. And they hire them, sometimes.

  292. alexis has left

  293. Ge0rG

    Wiktor: yes, but there is a gazillion of other side channels

  294. Wiktor

    Ge0rG: could you give an example?

  295. pep.

    daniel, what's interesting is the other way around, https://mathiasbynens.github.io/rel-noopener/

  296. alexis has joined

  297. Ge0rG

    Wiktor: https://arstechnica.com/information-technology/2018/05/chrome-and-firefox-leaks-let-sites-steal-visitors-facebook-names-profile-pics/

  298. Wiktor

    ah css mix-blend-mode

  299. Wiktor

    will probably be fixed just like leaking :active

  300. Ge0rG

    Wiktor: https://www.bleepingcomputer.com/news/security/css-code-can-be-abused-to-collect-sensitive-user-data/

  301. Ge0rG

    web security is a huge game of whack-a-mole. And sometimes I'm not sure if we aren't the moles.

  302. alexis has left

  303. Wiktor

    isn't this true for software in general?

  304. alexis has joined

  305. Wiktor

    web is just "used software" and complex software so it has more vulnerabilities discovered

  306. Ge0rG

    Wiktor: software in general is doing okay, but the web is a fractal of insecurity.

  307. Wiktor

    this is just survivorship bias

  308. Ge0rG

    Wiktor: the web browser is an attempt to rebuild the desktop operating system, but with the sole intent to load and execute malicious code from third parties.

  309. Ge0rG

    it doesn't help that all three major web operating system vendors are either in the tracking-users business or paid by this business.

  310. alexis has left

  311. Wiktor

    > sole intent to load and execute malicious code from third parties [citation needed]

  312. lumi has left

  313. Alex has joined

  314. Valerian has left

  315. alexis has joined

  316. Valerian has joined

  317. Wiktor

    the code is as malicious as any other piece of software can be

  318. Valerian has left

  319. Valerian has joined

  320. Wiktor

    do you claim Firefox and Mozilla are in this just because they want you to execute "malicious code from third parties"?

  321. Ge0rG

    Wiktor: do you remember the time when famil members just downloaded random .scr files from the internet because "that screen saver was so awesome"?

  322. Valerian has left

  323. Ge0rG

    Wiktor: firefox ships with JavaScript enabled, so yes.

  324. Wiktor

    yep, that scr could be malicious too

  325. Wiktor

    little evil johnny castaway

  326. Ge0rG

    Wiktor: it took a while for users to learn that, the hard way.

  327. Wiktor

    and now they're learning on the web...

  328. Ge0rG

    Wiktor: but now, they are doing 90% of their work in a web browser, which is designed and optimized to load and execute malicious JavaScript

  329. Ge0rG

    Now please tell me that not all JS is malicious.

  330. alacer has left

  331. Wiktor

    is it?

  332. pep. enables NoScript

  333. pep.

    Ge0rG, not all JS is malicious!

  334. Nekit has joined

  335. Ge0rG

    Wiktor: the typical modern web page has 5kb of JS to animate the menus, which depends on 1MB of jquery, and a dozen or two of different tracking services embedded

  336. Zash

    Not all X!!

  337. Ge0rG

    And any of those tracking service may do anything to your website.

  338. Wiktor

    yes, so what? this is just bad design, last time I read ECMAScript spec it didn't require me to put trackers on my page to achieve "malicious JavaScript" badge

  339. Ge0rG

    Oh, did I mention those pages that allow third-party live bidding platforms to sell code execution rights to shady companies that will redirect you to a "YOU HAVE WON!!!111!" page, delete your back-history and deploy the vibration alert?

  340. rainslide has left

  341. Wiktor

    your computer allows shady things, do you consider it malicious too?

  342. Ge0rG

    Wiktor: "this is just bad design" is a statement that applies to the modern web.

  343. pep.

    Somebody mentioned Intel ME?

  344. Wiktor

    haha, yes, Intel ME

  345. Ge0rG

    Wiktor: which brings me directly back to my initial statement, which you just proved :P

  346. pep.

    And AMD's whatever

  347. Zash

    Computers are teh wurst

  348. Wiktor

    bad design on part of the site developer, you cannot claim that if your observed set is composed only out of white swans that black swans do not exist

  349. Ge0rG

    with I-ME, at least *only Intel* can execute code on my box without me knowing.

  350. pep.

    Zash, potatoes!

  351. Zash

    Let's just all become potato farmers

  352. pep.

    Ge0rG, are you even sure of that

  353. Ge0rG

    Zash: ITYM Teewurst <https://en.wikipedia.org/wiki/Teewurst>.

  354. Ge0rG

    pep.: sure of what?

  355. pep.

    *only Intel*

  356. pep.

    I mean,

  357. pep.

    Intel could proxy to third-parties. Just like these websites allows third-parties in

  358. Ge0rG

    pep.: only Intel and the state actors that coerced them.

  359. pep.

    Intel could proxy to third-parties. Just like these websites allow third-parties in

  360. pep.


  361. pep.

    Sounds better

  362. Ge0rG

    pep.: but at least they need to intercept the laptop shipping to me and inject the payload manually

  363. Ge0rG

    pep.: my laptop doesn't come asking for malware whenever I surf to a news site.

  364. Wiktor

    Intel ME can be updated though ethernet, even when the computer is powered off (but not plugged off the grid)

  365. rainslide has joined

  366. rishiraj22 has left

  367. rishiraj22 has left

  368. rainslide

    > isn't this true for software in general? Maybe true for all general stuffs in large scale.

  369. rishiraj22 has joined

  370. vanitasvitae has left

  371. rainslide

    News next decade: Intel becomes the largest tracker (?)

  372. pep.

    I bet that's already true to some extent

  373. rishiraj22 has left

  374. rishiraj22 has joined

  375. rtq3 has left

  376. alacer has joined

  377. alacer has left

  378. alacer has joined

  379. alexis has left

  380. vanitasvitae has left

  381. alexis has joined

  382. Andrew Nenakhov has left

  383. Andrew Nenakhov has joined

  384. Andrew Nenakhov has left

  385. Andrew Nenakhov has joined

  386. Valerian has joined

  387. Alex has left

  388. rtq3 has joined

  389. rainslide has left

  390. marmistrz has left

  391. daniel has left

  392. lnj has joined

  393. SaltyBones has left

  394. valo has left

  395. valo has joined

  396. dos has joined

  397. lnj has left

  398. Zash has left

  399. j.r has joined

  400. xnyhps has joined

  401. lnj has joined

  402. xnyhps has joined

  403. link2xt has joined

  404. SamWhited has left

  405. rishiraj22 has left

  406. rishiraj22 has joined

  407. Yagiza has left

  408. Yagiza has joined

  409. lskdjf has left

  410. Guus has left

  411. lskdjf has joined

  412. lskdjf has joined

  413. Zash has left

  414. labdsf has joined

  415. la|r|ma has joined

  416. labdsf

    I have read the logs about ephemeral messages from http://logs.xmpp.org/xsf/2018-06-07/

  417. labdsf

    Just in case, I am the author of this protoxep

  418. alexis has left

  419. daniel has left

  420. alexis has joined

  421. daniel has joined

  422. xnyhps has joined

  423. Ge0rG

    hey labdsf, welcome :)

  424. alacer has left

  425. la|r|ma has joined

  426. la|r|ma has joined

  427. labdsf

    so far, the main concern is that nested <ephemeral> contents is hard to implement and does not guarantee anything anyway as some clients will store raw XML?

  428. jonasw

    hi labdsf

  429. jonasw

    labdsf, yes, that is definitely a conceprn

  430. jonasw

    labdsf, yes, that is definitely a concern

  431. Ge0rG

    labdsf: I can't speak for the other Council members; my personal concern is that it is not clear how it is supposed to work in multi-client scenarios.

  432. alexis has joined

  433. alacer has joined

  434. labdsf

    as for the threat model, it is indeed "stolen device" attack only, nothing more, all parts of the conversation trust each other

  435. Ge0rG

    labdsf: I already have a hard time removing messages from server-side MAM after 14 days ;)

  436. labdsf

    Ge0rG, timer setting synchronization part?

  437. labdsf

    or starting of the timer on the recipient side?

  438. alexis has left

  439. Ge0rG

    labdsf: starting of the timer. Also, with a <no-store/> hint, the message will only be delivered to clients that are online at the time of transmission

  440. mimi89999 has joined

  441. labdsf

    it is no-permanent-store in the specification, whatever it means

  442. Ge0rG

    labdsf: so if my mobile is connected at the time, it will get a copy; if it's not connected, it won't.

  443. labdsf

    and it is for plaintext only

  444. alexis has joined

  445. labdsf

    is there any practical difference between no-permanent-store and no-store?

  446. Ge0rG

    No idea.

  447. Ge0rG

    MAM only mentions no-store, in https://xmpp.org/extensions/xep-0313.html#hints

  448. Ge0rG

    labdsf: with the current MAM and XMPP "design", it's not possible to know when all clients have received a given message, so no-permanent-store doesn't make much sense

  449. labdsf

    according to https://xmpp.org/extensions/xep-0334.html#no-permanent-store , no-permanent-store messages should not be stored in MUC

  450. labdsf


  451. Holger

    Yes the idea is "only in the offline spool".

  452. labdsf

    so if no client is offline, it will be stored for offline delivery

  453. Ge0rG

    So it still breaks the multi-client use case.

  454. Holger


  455. Ge0rG

    MattJ had a nice idea to keep a per-client offline spool, backed by the MAM store. That would break as well.

  456. labdsf

    it does not break it completely, but we need a better replacement for offline message delivery than MAM for it to work

  457. labdsf

    so each device can register on the server and have its own message queue

  458. labdsf

    when all devices got the messages, they are removed

  459. Ge0rG

    labdsf: yes, that would be great. Except if you drop your device into a beer keg and messages for that device get stored forever.

  460. Holger

    Ge0rG: I'd burn no-permanent-store with fire, but as you recently told me hints were burnt down altogether anyway.

  461. labdsf

    Ge0rG, unregister it after 2 weeks of inactivity

  462. Ge0rG

    labdsf: not a bad idea

  463. Ge0rG

    But we aren't there yet.

  464. Ge0rG

    Maybe we can fix it with IM-NG

  465. labdsf

    Signal actually has this model, it allows you to register the first device with SMS, then register additional devices using already registered one

  466. labdsf

    device is unregistered after one week

  467. Ge0rG

    I thought Signal has a single-device model?

  468. labdsf


  469. labdsf

    it is WhatsApp that has single-device

  470. Ge0rG

    We need to establish a device-registration XEP.

  471. labdsf

    Signal allows you to register the phone with SMS, then register desktop by scanning its QR code, then shutdown the phone and use desktop

  472. Ge0rG

    Until then, I just use the resource string as a device identifier.

  473. edhelas

    labdsf afaik, you can't shutdown the phone no

  474. Ge0rG

    labdsf: and the desktop is a full device, like the phone is?

  475. labdsf


  476. edhelas

    because the phone is just acting a a proxy for the desktop

  477. labdsf

    edhelas, you are talking about WhatsApp

  478. edhelas

    ah yeah sorry

  479. vanitasvitae has left

  480. labdsf

    Signal is different, you can shutdown the phone

  481. Ge0rG

    What a feature.

  482. labdsf

    WhatsApp starts displaying the message that your phone has disconnected above the "roster"

  483. labdsf

    I think we can postpone implementation of plaintext ephemeral messages or at least disable them by default until we have better Signal-like offline message delivery

  484. Zash

    "Signal-like" means?

  485. labdsf

    multiple queues, one per device

  486. labdsf

    messages are removed as soon as you download them

  487. Zash


  488. labdsf

    or after one week if you don't

  489. Zash

    .... isn't that because it doesn't support multiple devices?

  490. Ge0rG

    labdsf: another point: I can see why you wrapped the <body> into <ephemeral>, but I'm not convinced of this approach. It will interact in non-obvious ways with things like OMEMO

  491. labdsf

    it does, I just described above

  492. lorddavidiii has left

  493. labdsf

    Ge0rG, in case of OMEMO you place <encrypted><payload>...</payload>...</encrypted> inside <ephemeral>

  494. edhelas

    we need to go deeper

  495. Ge0rG

    labdsf: yes; so you need to parse <ephemeral> for everything that's allowed in a <message>, except with a timer attached.

  496. rtq3 has left

  497. rtq3 has joined

  498. Ge0rG

    labdsf: what if I send a Read Marker inside <ephemeral>? Will the conversation show up as un-read after the time?

  499. Ge0rG

    or is there a white-list of tags that are allowed inside of <ephemeral>?

  500. Andrew Nenakhov has left

  501. Andrew Nenakhov has joined

  502. labdsf

    I expect that <ephemeral> is only used when you explicitly send a message

  503. Ge0rG is a corner case specialist.

  504. xnyhps has joined

  505. marmistrz has joined

  506. Ge0rG

    I should get that printed onto my business cards, to give people a fair advance warning.

  507. MattJ sends Ge0rG inside an <ephemeral>

  508. Ge0rG

    MattJ: so what's my TTL, then?

  509. Zash has left

  510. MattJ

    integer overlow

  511. Ge0rG

    MattJ: do you have the eyes of a Shinigami?

  512. MattJ

    integer overflow

  513. Valerian has left

  514. Valerian has joined

  515. Valerian has left

  516. Valerian has joined

  517. rainslide has joined

  518. Kev has left

  519. labdsf

    As mentioned in https://xmpp.org/extensions/inbox/omemo-media-sharing.html we already have https://xmpp.org/extensions/xep-0373.html that does stanza encryption

  520. labdsf

    <ephemeral> is no different from <openpgp> except that content is not encrypted

  521. labdsf

    but then we can have <ephemeral><openpgp><ephemeral>... which will be hard to implement if OpenPGP is a plugin

  522. labdsf

    various plugins trying to wrap the messages in unspecified order will be a problem

  523. Ge0rG

    And then all that is wrapped in <forwarded><sent> to your mobile device.

  524. Ge0rG

    > https://xmpp.org/extensions/inbox/omemo-media-sharing.html Please don't even get me started about `if (message.startsWith("aesgcm://")) { ... }`

  525. Ge0rG

    and what is an "OMEMO message"?

  526. Ge0rG

    daniel: what were you smoking?

  527. Zash has left

  528. Zash has left

  529. Ge0rG

    I mean, I can understand how this results from "we don't need to wrap anything but the <body> into OMEMO".

  530. labdsf

    in any case, if you *receive* an ephemeral read marker, the conversation becomes read and the marker is not stored in logs

  531. Ge0rG

    And there is certain merit in producing working code over good specifications; but now might be a good time to rewind and fix this.

  532. jonasw

    Ge0rG, if this is about encrypting whole stanzas, yeah, let’s do that.

  533. Ge0rG

    labdsf: but then later the conversation needs to become un-read again when the marker times out, right?

  534. jonasw

    but I heard it’s not as easy as you’d think

  535. labdsf

    Ge0rG, no

  536. Ge0rG needs to invent some other interesting corner cases.

  537. labdsf

    it just becomes read forever

  538. Ge0rG

    ephemeral Pubsub posts!

  539. MattJ

    I like the idea of being able to temporarily correct messages

  540. edhelas

    Ge0rG it already exists, it's called PEP with one item per node :p

  541. MattJ

    It's called restarting Prosody

  542. Kev

    MattJ: What about temporarily adding a reference to a message?

  543. Ge0rG

    MattJ: thanks for making me sad.

  544. edhelas

    MattJ +1 :D

  545. MattJ

    Probably making Link Mauve sad, he already implemented persistence :)

  546. Ge0rG

    in trunk?

  547. MattJ

    In trunk

  548. Ge0rG

    I'm running two dozens of half-baked half-broken half-experimental modules on my server, I can't upgrade to trunk!

  549. daniel

    > And there is certain merit in producing working code over good specifications; but now might be a good time to rewind and fix this. If you read the entire xep the introduction clearly states that

  550. Ge0rG

    daniel: touché

  551. Guus has left

  552. pep.

    Ge0rG, I'm sure you can upgrade to trunk and still benefit from another dozen of half-baked half-broken half-experimental modules :P

  553. rion has left

  554. edhelas

    all our projects are not half-baked half-broken half-experimental in the end ?

  555. Ge0rG

    pep.: maybe, but I don't want to introduce even more half-baked-ness.

  556. rainslide has left

  557. Guus has left

  558. rtq3 has left

  559. Guus has left

  560. Guus has left

  561. Guus has left

  562. Zash has left

  563. labdsf

    Ok, so to summarize, I need to 1) add threat model to "security considerations" 2) write "implementation notes" that say plaintext ephemeral messages should be disabled unless the server advertises reliable no-permanent-store offline message delivery mechanism 3) think about moving message contents outside the <ephemeral> if it makes implementation too complicated

  564. Guus has left

  565. labdsf

    Ge0rG, by the way it does not matter whether you place chat state notification inside <ephemeral> or outside of it as long as <ephemeral> is present in the message

  566. rion has left

  567. jere has joined

  568. rishiraj22 has left

  569. labdsf

    what is the procedure to update ProtoXEP? Just sumbit a pull request?

  570. daniel has left

  571. daniel has joined

  572. jonasw

    labdsf, there is not really a procedure. you can submit a PR, yes, I’ll merge the update.

  573. jonasw

    unfortunately. I would prefer if that happened under Experimental, because there *is no procedure* for anything there.

  574. jonasw

    I won’t send an update email for example like I’d do for Experimental XEPs

  575. labdsf


  576. Ge0rG

    jonasw: the XEP was rejected

  577. jonasw

    but the war on whether we want to "have XEPs in Experimental early and develop there" or "ProtoXEPs must be very promising / very good to accept" is not fought out yet

  578. jonasw

    Ge0rG, I am aware

  579. jonasw

    Ge0rG, what are you telling me?

  580. jonasw

    you saying I should reject the update on that ground?

  581. Ge0rG

    so it's hanging around in inbox now, and I suppose it could get the PRs applied and the author could kindly ask the editot to resubmit it for a vote

  582. Ge0rG

    or the Council.

  583. jonasw


  584. daniel has left

  585. jonasw

    that’s what’s effectively happening whenever things in inbox get updated

  586. daniel has joined

  587. Ge0rG

    labdsf: so please make a PR to address all Council issues

  588. Ge0rG

    labdsf: and then let us know

  589. Syndace has joined

  590. daniel has left

  591. daniel has joined

  592. daniel has left

  593. daniel has joined

  594. Guus has left

  595. Guus has left

  596. rishiraj22 has left

  597. Guus has joined

  598. rishiraj22 has left

  599. mikaela has joined

  600. jubalh has left

  601. alacer has left

  602. alacer has joined

  603. Guus has left

  604. Guus has left

  605. Kev

    > but the war on whether we want to "have XEPs in Experimental early and develop there" or "ProtoXEPs must be very promising / very good to accept" is not fought out yet It is, though.

  606. jonasw

    it comes up on the list about once a month, doesn’t it?

  607. Kev

    Usual criteria for Experimental is only "Not obviously wrong", "Confusing as hell" or "duplicating existing stuff for no good reason".

  608. Guus has joined

  609. jonasw

    soo... if I have a XEP which is very confusing and duplicates everything, I’m in? ;-)

  610. Kev

    Certainly noting as much as 'must be very good or very promising' has ever been enforced, of which I'm aware.

  611. SamWhited has left

  612. SamWhited has left

  613. Kev

    Yes, that's exactly what I meant, of course :p

  614. jonasw

    sorry, I had to take that one after I had a similar negation issue the other day on the same topic:)

  615. j.r has joined

  616. Guus has left

  617. Guus has joined

  618. daniel has left

  619. daniel has joined

  620. rishiraj22 has left

  621. rtq3 has joined

  622. rainslide has joined

  623. rishiraj22 has left

  624. daniel has left

  625. daniel has joined

  626. rainslide has left

  627. rishiraj22 has left

  628. j.r has joined

  629. j.r has joined

  630. remko has joined

  631. la|r|ma has joined

  632. la|r|ma has left

  633. rainslide has joined

  634. jubalh has joined

  635. Nekit has joined

  636. rishiraj22 has left

  637. marmistrz has joined

  638. marmistrz has left

  639. lnj has left

  640. lnj has joined

  641. SaltyBones has left

  642. jubalh has joined

  643. rainslide has left

  644. jubalh has joined

  645. rtq3 has left

  646. marmistrz has left

  647. SaltyBones has left

  648. Guus has left

  649. Guus has left

  650. Guus has joined

  651. UsL has joined

  652. UsL has joined

  653. jere has left

  654. Guus has left

  655. Guus has left

  656. Guus has left

  657. Guus has left

  658. Guus has joined

  659. marmistrz has left

  660. Valerian has left

  661. Valerian has joined

  662. marmistrz has left

  663. Syndace has left

  664. Syndace has joined

  665. j.r has joined

  666. andy has left

  667. jere has joined

  668. Guus has left

  669. Guus has left

  670. j.r has joined

  671. marmistrz has left

  672. Valerian has left

  673. Valerian has joined

  674. andrey.g has left

  675. SaltyBones has left

  676. Valerian has left

  677. Valerian has joined

  678. daniel has left

  679. daniel has joined

  680. mikaela has left

  681. jjrh has left

  682. rishiraj22 has left

  683. rishiraj22 has joined

  684. jubalh has joined

  685. rishiraj22 has left

  686. rishiraj22 has joined

  687. SaltyBones has left

  688. rishiraj22 has left

  689. rishiraj22 has joined

  690. moparisthebest has left

  691. Tobias has joined

  692. Tobias has joined

  693. daniel has left

  694. daniel has joined

  695. j.r has left

  696. daniel has left

  697. daniel has joined

  698. ralphm has left

  699. andrey.g has joined

  700. Tobias has left

  701. Tobias has joined

  702. jjrh has left

  703. j.r has joined

  704. daniel has left

  705. daniel has joined

  706. daniel has left

  707. daniel has joined

  708. mikaela has joined

  709. lskdjf has joined

  710. Wiktor has joined

  711. alexis has left

  712. rtq3 has joined

  713. alexis has joined

  714. Ge0rG has left

  715. marmistrz has joined

  716. alexis has left

  717. Yagiza has left

  718. alexis has joined

  719. alexis has left

  720. alexis has joined

  721. ralphm has joined

  722. j.r has left

  723. j.r has joined

  724. daniel has left

  725. daniel has joined

  726. rtq3 has left

  727. rtq3 has joined

  728. daniel has left

  729. daniel has joined

  730. Yagiza has joined

  731. goffi has left

  732. andy has joined

  733. nyco has left

  734. nyco has joined

  735. tux has joined

  736. marmistrz has left

  737. la|r|ma has left

  738. jonasw has left

  739. jonasw has joined

  740. SaltyBones has left

  741. goffi has joined

  742. vanitasvitae has left

  743. rishiraj22 has left

  744. rishiraj22 has joined

  745. Tobias has joined

  746. marmistrz has left

  747. Lance has joined

  748. mikaela has joined

  749. Lance has joined

  750. Tobias has joined

  751. Valerian has left

  752. jubalh has joined

  753. labdsf has left

  754. labdsf has joined

  755. Guus has left

  756. rishiraj22 has left

  757. labdsf

    Ge0rG, we cannot use resource string as device identifier, sadly

  758. jonasw

    labdsf, why?

  759. labdsf

    Gajim by default has $rand part that is regenerated on each connection

  760. jonasw

    yeah, gajim needs fixing then :)

  761. Guus has left

  762. Guus has left

  763. labdsf


  764. Andrew Nenakhov has joined

  765. Guus has left

  766. labdsf

    if all major clients are fixed to use somewhat permanent resources, it may be easy enough to implement offline message queues in prosody

  767. jonasw

    labdsf, MattJ is working on that, kinda

  768. jonasw

    regarding fixing clients, please file issues

  769. Guus has left

  770. goffi

    why a client should have a permanent resource ? I thought it was seen as bad practice at some point. And using resource to identity a client doesn't smells like a good idea.

  771. labdsf

    goffi, we need to understand why is it a bad practice

  772. goffi

    if it's needed, a random ID generated once by client and put in some disco sounds better to me.

  773. labdsf

    my guess is that using non-random is a bad practice, not permanent

  774. labdsf

    because you may want to use to Gajims, for example

  775. Zash

    Fixed strings like "Gajim" or "Conversations" or "mobile" are meh.

  776. goffi

    would be nice to have some input on that, SàT is also using random resource by default (well, actually resource chosed by server).

  777. jonasw

    goffi, like Zash says, a *predictable* string is bad. a string which identifies a client (of a user) uniquely (but unpredictably) is good

  778. jonasw

    so gajim-dg6jqVpjVI6, generated once at account setup, is good

  779. jonasw

    it helps the server re-identify the client right after bind

  780. goffi

    Zash: I actually find handy to have something like "mobile" when I want to access this device directly, why would is it bad ?

  781. lnj has left

  782. Guus has left

  783. Guus has left

  784. jonasw

    goffi, you can detect the mobile-ness of a device via disco#info

  785. jonasw

    parsing the resource string is awful for that

  786. lnj has joined

  787. Zash

    jonasw: lets me guess it and send stuff directly to your phone. also you'll have a bad time if you ever get a second phone

  788. SaltyBones has left

  789. goffi

    jonasw: yes, but if I have several mobiles, and I want to retrieve picture from one in particular ?

  790. jonasw

    goffi, disco#info can have names in it

  791. jonasw

    allow users to set proper disco#info names

  792. jonasw

    (and default them to something sensible)

  793. goffi

    hum, disco#info can be nice indeed

  794. Guus has left

  795. jonasw

    and the name can even be internationalised!

  796. goffi

    in resource too

  797. jonasw


  798. jonasw

    you can only have one resource

  799. jonasw

    but you can have many <identity/> items, one for each language

  800. goffi

    ah ok, I thought you were thinking about non ascii chars.

  801. Guus has left

  802. Syndace has left

  803. Syndace has joined

  804. Guus has left

  805. Guus has left

  806. goffi

    anyway, a XEP or something official givin advices on resource chosing would be a good think.

  807. jonasw


  808. jonasw

    an Informational document would be good

  809. j.r has joined

  810. ta has joined

  811. SaltyBones has left

  812. marmistrz has joined

  813. Neustradamus has left

  814. Guus has left

  815. rishiraj22 has left

  816. alexis has left

  817. alexis has joined

  818. edhelas has left

  819. Ge0rG

    goffi: I've written out the arguments for a prefixed random-on-account-creation resource string numerous times in the past, including the "human readable for debugging" argument

  820. edhelas has joined

  821. alacer has left

  822. alacer has joined

  823. ralphm has left

  824. waqas has joined

  825. jonasw

    Ge0rG, copy & paste your arguments into a XEP template?

  826. goffi

    Ge0rG: where ?

  827. Ge0rG


  828. alexis has left

  829. Ge0rG has left

  830. Ge0rG

    I'm using `yaxim.32bithexrnd` since the first user reported an issue with a second device running yaxim, which was ages ago.

  831. alexis has joined

  832. daniel

    32 bits?

  833. daniel

    That seems like a lot

  834. labdsf

    I would like it to behave like DHCP, server selects a resource for you (or you select random with prefix for the first time), then you request the same resource on reconnection

  835. Ge0rG

    goffi: on standards@, mostly. The last time in the context of bind2, where the `uuid4/uuid4` resource string scheme was proposed.

  836. jonasw

    labdsf, you can have that by not specifying a resource on the first connect

  837. jonasw

    the server has to assign one to you then

  838. SamWhited has left

  839. labdsf

    jonasw, the problem with Gajim is that it does not remember it

  840. jonasw

    sure, gajim needs fixing

  841. alacer has left

  842. rishiraj22 has left

  843. labdsf

    ok, I will file an issue

  844. Ge0rG

    daniel: maybe. I didn't do the math regarding the birthday collision phenomenon

  845. jonasw

    32 bit are just 8 characters of hex. that seems good to me

  846. goffi

    Ge0rG: would be nice to put in a protoXEP, it's hard to follow every discussions in MUC + mailing list + github issues now, specially for devs like me which are working on their free time.

  847. labdsf

    32 bit is what OMEMO uses

  848. jonasw

    I‘d probably do base64 instead.

  849. labdsf

    for device id

  850. jonasw

    goffi, which github issues?

  851. vanitasvitae has left

  852. daniel

    jonasw, i use 3 bytes in base64. thats short enough that an advanced user (doing debugging or what ever) can still remember it

  853. goffi

    jonasw: I think discussions happens there sometimes, if not that's good news

  854. legastero has joined

  855. jonasw

    goffi, not on the xeps repository (not on my watch at least)

  856. jonasw

    if you spot technical discussion there, feel free to alert me or another editor

  857. rtq3 has left

  858. jonasw

    because I find that awful, too, and we agreed to remind people to move the discussions to standards@

  859. goffi

    good then

  860. SaltyBones has joined

  861. Lance has joined

  862. jonasw

    daniel, right

  863. Ge0rG

    daniel: I remember being confused by the special characters in a conversations resource. Also, I wonder if there are case insensitive servers out there

  864. rtq3 has joined

  865. jonasw

    Ge0rG, they’d be in violation of RFC 6122 then

  866. jonasw

    burn them

  867. daniel

    Ge0rG: well if there are they should reread the rfc

  868. jonasw

    Ge0rG, which special characters though? base64 is just a-zA-Z0-9

  869. daniel

    jonasw: plus two more

  870. jonasw

    oh right

  871. jonasw

    (three if you count the padding)

  872. daniel

    With three bytes you don't have padding

  873. Lance has joined

  874. jonasw


  875. Ge0rG

    I'd actually rather use a password generator for the resource

  876. jonasw

    something like "commissions beer respite"?

  877. Ge0rG

    Did I say "passphrase"?

  878. legastero has left

  879. legastero has joined

  880. Guus has left

  881. Guus has left

  882. Guus has joined

  883. tux has joined

  884. legastero has joined

  885. jjrh has left

  886. la|r|ma has joined

  887. la|r|ma has joined

  888. la|r|ma has joined

  889. la|r|ma has joined

  890. la|r|ma has joined

  891. jjrh has left

  892. la|r|ma has joined

  893. la|r|ma has joined

  894. marc has joined

  895. la|r|ma has joined

  896. jjrh has left

  897. la|r|ma has joined

  898. la|r|ma has joined

  899. la|r|ma has joined

  900. la|r|ma has joined

  901. SaltyBones has left

  902. labdsf

    jonasw, you mentioned MattJ is working on something (premanent resources? message queues?), where can I read about it?

  903. mimi89999 has left

  904. Zash

    Can you read minds?

  905. labdsf

    I guess it is offline message queues in prosody

  906. anjan has joined

  907. jjrh has left

  908. edhelas has left

  909. Valerian has joined

  910. Andrew Nenakhov has left

  911. Lance has joined

  912. Ge0rG

    Zash [18:31]: > Can you read minds? Is there an XEP for that?

  913. Lance has joined

  914. Andrew Nenakhov has joined

  915. Guus has left

  916. pep.

    labdsf, there was some mention of that on this channel iirc, and maybe also on prosody@

  917. MattJ

    Ge0rG, https://xmpp.org/extensions/xep-0183.html

  918. jjrh has left

  919. MattJ

    labdsf, there's nothing to read, just reworking the message delivery logic in Prosody. No XEP because no protocol changes (we have all the protocols we already need)

  920. marmistrz has joined

  921. labdsf

    MattJ: What is the change in delivery logic? Will no-permanent-store offline messages be stored for some time for recently seen resources?

  922. rtq3 has left

  923. Guus has left

  924. MattJ


  925. MattJ

    Probably no-permanent-store will be ignored for the most part, in preference to delivering the message to all known devices

  926. labdsf

    I would like to disable MAM completely. As a workaround I have it store messages for a week and in-memory only.

  927. Ge0rG

    Tedd has a very interesting reading of the LMC rules

  928. MattJ

    I really dislike the idea of MAM (I don't run it on my own server)

  929. MattJ

    I wrote the XEP, and intended it to cover multiple use cases, but I should clarify that it's the "store everything forever" thing that people seem to have interpreted it as that I don't like

  930. labdsf

    MattJ: as I understand it, no-store is "deliver to online clients only", no-permanent-store is "no MAM, store for some time in memory for clients that are likely to reconnect in a few days", store is "store in MAM permanetly until it is removed by some internal logic".

  931. MattJ

    The stuff I'm working on auto-deletes messages once they have been received by all devices

  932. MattJ

    Regardless of what hints are in the message

  933. labdsf

    So you sort of ignore no-store and make it work like no-permanent-store

  934. labdsf

    And store does not work because MAM is disabled

  935. Ge0rG

    Funny how everybody involved in xmpp software runs their own custom configuration that's incompatible to the preached best practices and to everybody else's

  936. MattJ

    Ge0rG, you think I'm preaching that people should have MAM enabled and store everything forever? :)

  937. Guus has left

  938. Guus has left

  939. Guus has joined

  940. Ge0rG

    MattJ: you wrote the XEP. And MAM support is demanded by at least one modern client.

  941. MattJ

    labdsf, I'm breaking stanzas into three categories: [deliver to all], [deliver to all online], [deliver to single resource]

  942. Ge0rG

    I'm running my secondary clients with negative priority to avoid them consuming messages when the primary client is offline.

  943. Ge0rG

    MattJ: the preaching statement was not related to you personally, just to what the xsf says

  944. MattJ

    Ge0rG, the XSF preaches? :)

  945. labdsf

    I would like to have two options: with MAM (Telegram-like, local archive acts like cache and can be pruned anytime) / without MAM (client has to store all messages locally)

  946. Zash


  947. labdsf

    the fact that MAM became an offline message delivery mechanism is a bug

  948. labdsf

    especially with OMEMO, when messages are sent with <store/> but cannot be decrypted more than once

  949. labdsf

    and server stores permanently encrypted messages that nobody can decrypt

  950. Ge0rG

    labdsf: congratulations, you just discovered the mess that multi device xmpp is.

  951. rtq3 has joined

  952. MattJ

    labdsf, pretty much agree

  953. MattJ

    which is why I'm taking a step back and rewriting our code like it's 2018

  954. Ge0rG

    If I weren't on mobile I'd give you the link to the presentation listing this and many other issues

  955. Ge0rG

    Per device offline message queues would actually be a reason for me to upgrade prosody to trunk

  956. labdsf

    Ge0rG, but it seems pretty easy to fix (from the protocol point of view, not sure about implementation), just add semi-permanent resources and store messages for some time

  957. Ge0rG

    labdsf: Yeah. Except it was a hard fight to convince a small subset of the xmpp community that permanent resources are a good and not a bad thing

  958. Dave Cridland has left

  959. Dave Cridland has joined

  960. labdsf

    resource is a part of URL, it is there for IoT applications from the start, how non-permanent resource is of any use?

  961. labdsf

    IoT was not that popular buzzword than, but something like that was considered when resources were added I think

  962. labdsf

    you connect a device, assign it a resource and then it is available by permanent URL

  963. rtq3 has left

  964. Ge0rG

    labdsf: don't ask *me* about that

  965. mimi89999 has left

  966. mimi89999 has joined

  967. Dave Cridland has left

  968. lskdjf has left

  969. Dave Cridland has joined

  970. labdsf

    MattJ, if MAM is enabled, messages are stored even if they have been received by all devices I guess?

  971. rishiraj22 has left

  972. labdsf

    one reason for MAM to exist is when you want to connect a new device later

  973. MattJ

    There will be a setting (disabled by default) to control storage of messages for longer periods

  974. labdsf

    Signal solves this problem by synchronizing messages device-to-device, but that would require an entire new specification

  975. MattJ

    e.g. "store for at least 7 days"

  976. Dave Cridland has left

  977. MattJ

    It wouldn't require much more of a specification than one that says clients can optionally enable other clients to speak XEP-0313 to them

  978. Dave Cridland has joined

  979. MattJ

    Even if it only supported a limited subset (give me everything after id X)

  980. MattJ

    Probably a trivial operation for most clients

  981. Lance has joined

  982. Lance has joined

  983. marc has left

  984. Holger

    Is the plan to (re)construct carbons of outgoing messages while delivering per-device offline messages?

  985. Kev has left

  986. rishiraj22 has left

  987. rishiraj22 has joined

  988. alacer has joined

  989. Dave Cridland has left

  990. labdsf


  991. Chobbes has joined

  992. Chobbes has joined

  993. la|r|ma has joined

  994. j.r has joined

  995. rishiraj22 has left

  996. rishiraj22 has joined

  997. pep.

    "so offline messages will be stored for longer than needed and not delivered to the client." how would they not be delivered to the client?

  998. marc has joined

  999. rishiraj22 has left

  1000. pep.

    Are we not delivering everything to every clients nowadays

  1001. Ge0rG

    MattJ: that would make for a nice and secure UX as well. "Conversations on Android asked to obtain your message history. Yes / No"

  1002. rishiraj22 has joined

  1003. rishiraj22 has left

  1004. rishiraj22 has joined

  1005. Holger

    pep.: No idea but presumably the server would only deliver offline messages when a known resource reconnects.

  1006. Holger

    Gajim would just fetch them from MAM of course.

  1007. pep.

    So if I disconnect all my resources and connect with a new one (new client), I'll never receive these only messages? :/

  1008. pep.


  1009. pep.

    *offline messages

  1010. Holger

    pep.: Well dunno about the Prosody plans. But otherwise you'd receive the full MAM archive without any paging whenever you log in with a new resource I guess?

  1011. labdsf

    pep., well, if MAM is not available, and two clients are connected ("Mobile" and "Gajim.foo"), then "Gajim.foo" disconnects, then a message is received, then "Gajim.bar" connects, a message will be stored for "Gajim.foo" and not delivered to "Gajim.bar"

  1012. rion has left

  1013. labdsf

    "Mobile" will receive the message because it was online

  1014. pep.

    And if Mobile wasn't connected

  1015. labdsf

    then "Gajim.bar" will probably receive the message

  1016. pep.

    I like the certainty of that sentence

  1017. Holger

    I wonder whether clients that don't implement MAM get deduplication right ...

  1018. labdsf

    well, according to https://xmpp.org/extensions/xep-0160.html it will be Gajim.bar only

  1019. Zash

    Does anyone get deduplication right?

  1020. labdsf

    "the server delivers the message to the resource that has sent that presence"

  1021. labdsf

    Zash, just remove messages with the same ID, I think Xabber does this

  1022. Holger

    Yes, shouldn't be hard if you rely on stanza IDs. We ran into the dedup mess because we didn't have them until recently.

  1023. j.r has joined

  1024. marc has left

  1025. Holger

    While I'm not convinced you're improving the UX with clients that *don't* support carbons and proper dedup of you start sending them incoming messages received by other clients.

  1026. Holger


  1027. SaltyBones has joined

  1028. tux has left

  1029. Valerian has left

  1030. j.r has joined

  1031. rishiraj22 has left

  1032. rishiraj22 has joined

  1033. mimi89999 has left

  1034. ibikk has left

  1035. Lance has joined

  1036. rishiraj22 has left

  1037. rishiraj22 has joined

  1038. rion has joined

  1039. Kev has left

  1040. rtq3 has joined

  1041. rishiraj22 has left

  1042. rishiraj22 has joined

  1043. SamWhited has left

  1044. labdsf has left

  1045. rishiraj22 has left

  1046. labdsf has joined

  1047. rishiraj22 has joined

  1048. Ge0rG

    labdsf: let me tell you about https://wiki.xmpp.org/web/XEP-Remarks/XEP-0045:_Multi-User_Chat#Matching_Your_Reflected_Message

  1049. Ge0rG

    Zash: yaxim does deduplication right, but it doesn't support MAM.

  1050. labdsf has left

  1051. labdsf has joined

  1052. labdsf

    pep., I have updaet issue https://dev.gajim.org/gajim/gajim/issues/9193 with an expanded example

  1053. Tobias has left

  1054. Tobias has joined

  1055. marc has joined

  1056. Dave Cridland has left

  1057. Dave Cridland has joined

  1058. Dave Cridland has left

  1059. Dave Cridland has joined

  1060. labdsf has left

  1061. Dave Cridland has left

  1062. Dave Cridland has joined

  1063. rishiraj22 has left

  1064. rishiraj22 has joined

  1065. alacer has left

  1066. alacer has joined

  1067. Valerian has joined

  1068. rishiraj22 has left

  1069. rishiraj22 has joined

  1070. rishiraj22 has left

  1071. rishiraj22 has joined

  1072. labdsf has left

  1073. rishiraj22 has left

  1074. rishiraj22 has joined

  1075. Andrew Nenakhov has left

  1076. Andrew Nenakhov has joined

  1077. rishiraj22 has left

  1078. rishiraj22 has joined

  1079. j.r has joined

  1080. rishiraj22 has left

  1081. rishiraj22 has joined

  1082. jjrh has left

  1083. Lance has left

  1084. Lance has joined

  1085. daniel

    labdsf, resources in Conversations are only semi-stable fwiw

  1086. rtq3 has left

  1087. daniel

    i support gajim (and other clients) using semi stable (but randomized) resources but i don’t think relying on them is a good idea

  1088. rishiraj22 has left

  1089. rishiraj22 has joined

  1090. Dave Cridland has left

  1091. nyco has left

  1092. Dave Cridland has joined

  1093. rainslide has joined

  1094. nyco has joined

  1095. efrit has joined

  1096. jjrh has left

  1097. ta has left

  1098. rainslide has left

  1099. Andrew Nenakhov

    I like resources with human-readable parts.

  1100. SamWhited has left

  1101. rion has left

  1102. rishiraj22 has left

  1103. rishiraj22 has joined

  1104. rishiraj22 has left

  1105. rishiraj22 has joined

  1106. rishiraj22 has left

  1107. rishiraj22 has joined

  1108. labdsf has left

  1109. rion has joined

  1110. Yagiza has left

  1111. rishiraj22 has left

  1112. rishiraj22 has joined

  1113. rishiraj22 has left

  1114. rishiraj22 has joined

  1115. Lance has left

  1116. anjan has left

  1117. Lance has joined

  1118. rishiraj22 has left

  1119. rishiraj22 has joined

  1120. anjan has joined

  1121. la|r|ma has joined

  1122. marmistrz has joined

  1123. rishiraj22 has left

  1124. rishiraj22 has joined

  1125. rishiraj22 has left

  1126. labdsf

    daniel: how can we not rely on stable resources to identify clients?

  1127. rishiraj22 has joined

  1128. labdsf

    We can make clients advertise that they have stable resource to avoid storing messages for randomized ones

  1129. jonasw

    MattJ, if you don’t want to mean something "store everything forever", calling it "archive" was probably not smart :)

  1130. labdsf

    But I think it is easier to just fix major clients

  1131. daniel

    i’m not even sure a client can guarantee that…

  1132. jonasw

    daniel, to a local server it can

  1133. Zash

    It can't. Server has final say in what resource is used.

  1134. daniel

    what zash said

  1135. daniel

    even though a client could end the stream if the server doesn’t provide the resource it wants

  1136. daniel

    but that’s borderline insane

  1137. jonasw

    what I meant was: if a users server wants to make use of that property for that users clients, having the client advertise it makes sense. because if the server allows, the client can guarantee it.

  1138. jonasw

    (to the extent that it makes sense, after a disk wipe it obviously can’t)

  1139. labdsf

    There is no problem, if the server implements offline message queues, it has to provide stable resources

  1140. Tobias has joined

  1141. Tobias has joined

  1142. labdsf

    No need to think about the case when server does not

  1143. lnj has left

  1144. daniel

    labdsf, since i missed half the discussion; this is all in an attempt to make self destructible messages work?

  1145. labdsf

    In attempt to make offline messages work without MAM, unrelated work in prosody

  1146. jonasw

    Ge0rG, what did you mean by "password generator" for the random resource thing?

  1147. labdsf

    But that would help make plaintext ephemeral messages usable, which are not in their current state

  1148. rishiraj22 has left

  1149. daniel has left

  1150. Lance has left

  1151. rishiraj22 has joined

  1152. rtq3 has joined

  1153. labdsf

    OMEMO ephemeral messages are already ok I think, I just need to move the payload out of the <ephemeral> tag

  1154. SamWhited has left

  1155. rion has left

  1156. Ge0rG

    jonasw: something like https://github.com/pfleidi/yaxim/blob/master/src/org/yaxim/androidclient/util/XMPPHelper.java#L126 but with a-zA-Z0-9 only

  1157. labdsf

    So the core functionality is advertising ephemeral message support in device bundle and sending OMEMO ephemeral messages

  1158. Ge0rG

    it doesn't *need* to be exactly N bits of entropy

  1159. jonasw

    Ge0rG, soo... how’s that different from get_random_bytes(3) | base46?

  1160. jonasw

    Ge0rG, soo... how’s that different from get_random_bytes(3) | base64?

  1161. jonasw

    except for / and -

  1162. Ge0rG

    jonasw: exactly. / and -

  1163. jonasw

    what’s the isuse with that?

  1164. rishiraj22 has left

  1165. Ge0rG

    jonasw: because you don't want to have a / in your resource when bind2 strikes

  1166. rishiraj22 has joined

  1167. jonasw

    why not?

  1168. labdsf

    That was my proposal before discussion, then it was extented to plaintext and OpenPGP which we have to postpone until no-permanent-store can be supported

  1169. jonasw

    (and then I can still move to urlsafe…)

  1170. daniel

    Conversations uses url safe (- and _) by the way

  1171. jonasw

    Ge0rG, my understanding was that it was supposed to be <server part>/<client part> anyways

  1172. jonasw

    but whatever, I’ll use urlsafe then

  1173. daniel

    not because i’m afraid of bind2 but because it looks nice

  1174. rishiraj22 has left

  1175. rishiraj22 has joined

  1176. daniel

    labdsf, in my experience most clients that implement self destructible messages use omemo anyway

  1177. daniel

    (and are single device only most of the time)

  1178. Ge0rG

    daniel: was C using url-safe b64 from start on?

  1179. daniel


  1180. Ge0rG

    daniel: because I could *bet* I've seen a C with a / in the resource.

  1181. daniel

    (start=when it starting doing the random url part thing)

  1182. Ge0rG

    jonasw: how much would you bet on nobody ever implemeting resource.split("/")[0] and [1]?

  1183. rishiraj22 has left

  1184. rishiraj22 has joined

  1185. jonasw

    Ge0rG, https://github.com/jabbercat/jclib/compare/07c2589edf5b7d0a23124ace78477a38e0145f44...46433e394ba6bbc8d5209a93cdd62b34b4af1043

  1186. jonasw

    Ge0rG, as someone who recently fixed their JID implementation to interpret domain/resource correctly, I say they shall burn in hell

  1187. mrdoctorwho has joined

  1188. Ge0rG

    jonasw: 👍

  1189. jonasw

    Ge0rG, as someone who recently fixed their JID implementation to interpret domain/resource/with/slash correctly, I say they shall burn in hell

  1190. rishiraj22 has left

  1191. labdsf

    daniel: I am in the process of fixing the ProtoXEP to make it clear that everything outside OMEMO should be hidden from the user behind the "i know what I am doing" checkbox, and start writing the code by implementing ephemeral messages for OMEMO in Gajim

  1192. rishiraj22 has joined

  1193. daniel

    right. i’m just trying to provide you with an fyi on what most implementors are probably looking for

  1194. anjan has left

  1195. Ge0rG

    jonasw: so you say you are one of these folks who didn't get it right on the first attempt?

  1196. Tobias has joined

  1197. andy has left

  1198. jonasw

    Ge0rG, yupp. and I shall burn in hell

  1199. rishiraj22 has left

  1200. daniel

    Ge0rG, is this an argument to actually use / in Conversations and thus making this type of resource more common and thus helping to find those bugs much quicker?

  1201. rishiraj22 has joined

  1202. daniel

    if those bugs exists it's better to find them

  1203. jonasw

    daniel, I agree

  1204. daniel

    speaking of fun with jids. is there some sort of migration path to PRECIS? :-)

  1205. rishiraj22 has left

  1206. rishiraj22 has joined

  1207. jonasw

    except crying and trying to figure out why anybody would think that PRECIS was a good idea?

  1208. SamWhited

    PRECIS was a great idea

  1209. alexis has left

  1210. rishiraj22 has left

  1211. rishiraj22 has joined

  1212. jonasw

    SamWhited, good, can you explain to me how it makes sense to /not/ specify a specific unicode version for a standard which is used for data validation?

  1213. daniel

    precis is arguably easier to understand and implement than stringprep

  1214. jonasw

    I’ve been thinking about this for a while now and wasn’t able to figure that out yet

  1215. alexis has joined

  1216. SamWhited

    Do you want to be stuck on Unicode 3.0 forever? Also yah, I've tried implementing both. PRECIS was *way* easier.

  1217. jonasw

    this is bound to give inconsistent results, so we can’t ever do strict validation.

  1218. daniel

    jonasw, it relies on char classes

  1219. daniel

    and those are standardized by unicode

  1220. jonasw

    can’t things move between character clasess in different major releases of unicode?

  1221. SamWhited

    You can do strict validation; it's fine.

  1222. rishiraj22 has left

  1223. rishiraj22 has joined

  1224. SamWhited

    Yah, they can, so before you upgrade versions of Unicode double check and think about the consequences. Chances are it won't matter, or you'll have to provide an upgrade path just like when upgrading any other dependency ever.

  1225. jonasw

    SamWhited, uhm... so... instead of having a well-defined unicode version in the standard, now every developer of every XMPP related library needs to consider this?

  1226. jonasw

    how is this better?

  1227. SamWhited

    Because the standard can't be upgraded easily, our random libraries can.

  1228. jonasw

    so you’re saying we can manage to pull off a coordinated effort to lift the network on a new Unicode version whenever a new release comes out?

  1229. SamWhited

    You don't have to, just be backwards compatible.

  1230. rishiraj22 has left

  1231. rishiraj22 has joined

  1232. SamWhited

    I think my version supports 9 and 10 correctly and I think marcel added a way to make sure they interop, but I'd have to go look

  1233. daniel

    how does interop look like though? it has to be valid in both?

  1234. rishiraj22 has left

  1235. rishiraj22 has joined

  1236. daniel

    or pass through both?

  1237. SamWhited

    daniel: yah, if it's invalid in one fallback to the other, if it's invalid in both it's invalid.

  1238. jonasw

    so with enough time and enough interop, you’ll end up with a thing which just accepts everything.

  1239. jonasw

    and O(n) validation

  1240. SamWhited

    I suppose it depends on the situation though.

  1241. SamWhited

    No you really won't, you still have to follow the spec. Unicode charcters aren't changing left and right every day.

  1242. Ge0rG

    daniel: how is it a good idea to expose a small subset of your users to a weird behavior in the hope to sort it out?

  1243. jonasw

    O(nm) even, with n being the number of unicode standards you (the network) support and m the length of the string

  1244. SamWhited

    This is a rare thing that you *might* have to do if something very bad happens.

  1245. SamWhited

    jonasw: that's fine; it's still pretty fast and that only happens in the failure case and probably very rarely at that. You can probably also just check for any characters you think might cause problems if the performance is a problem.

  1246. jonasw

    I’m less worried about the practical performance and more about the concept itself.

  1247. rtq3 has left

  1248. rishiraj22 has left

  1249. rishiraj22 has joined

  1250. jonasw

    and possible attack vectors which come from ambiguous validation

  1251. SamWhited

    It's not ambiguous, it's very well defined with well defined failure scenarios.

  1252. jonasw

    ---which I haven’t thought through yet, because I’m avoiding the isuse at the moment.

  1253. Tobias has left

  1254. jonasw

    SamWhited, where are the failure scenarios defined?

  1255. jonasw

    i.e. which unicode versions do I have to try for which parts of a JID under which conditions?

  1256. daniel

    well if you are worried about that then there is probably no way to ever migrate to precis in the first place which means you don't have to worry about that

  1257. rishiraj22 has left

  1258. rishiraj22 has joined

  1259. SamWhited

    In the XEPs, they talk about this sort of thing extensively.

  1260. jonasw

    there are PRECIS *XEPs*?

  1261. SamWhited

    err, RFCs, that is

  1262. jubalh has left

  1263. Tobias has joined

  1264. daniel

    because the differences between stringprep and precis are more severe than precis with unicode x and precis with unicode y

  1265. jonasw

    hm, all I found so far was "PRECIS users need to consider the effects of unicode version changes, #notmydepartment" essentially

  1266. jonasw

    but maybe I have looked at the wrong place

  1267. jonasw

    daniel, yeah, that too

  1268. Ge0rG

    And then you are going to end up with users flooded by popup error messages from a client running on an old version of the spec because somebody used a robot face as a MUC nickname

  1269. labdsf has left

  1270. daniel

    true story

  1271. rtq3 has joined

  1272. Ge0rG

    Not all of my corner cases were pulled from thin air

  1273. j.r has joined

  1274. j.r has joined

  1275. Tobias has left

  1276. Tobias has joined

  1277. ThibG has left

  1278. ThibG has joined

  1279. rishiraj22 has left

  1280. rishiraj22 has joined

  1281. rishiraj22 has left

  1282. rishiraj22 has joined

  1283. labdsf has left

  1284. jubalh has joined

  1285. labdsf has left

  1286. lorddavidiii has left

  1287. Wiktor has left

  1288. goffi has left

  1289. rtq3 has left

  1290. rion has joined

  1291. Ge0rG has left

  1292. j.r has left

  1293. j.r has joined

  1294. labdsf has left

  1295. rion has left

  1296. rion has joined

  1297. remko has left

  1298. labdsf has left

  1299. Lance has joined

  1300. moparisthebest has joined

  1301. rion has left

  1302. marc has left

  1303. anjan has joined

  1304. Dave Cridland has left

  1305. rion has joined

  1306. rion has left

  1307. rion has joined

  1308. rtq3 has joined

  1309. rainslide has joined

  1310. Valerian has left

  1311. Valerian has joined

  1312. rainslide has left

  1313. marmistrz has left

  1314. zak has left

  1315. zak has left

  1316. rion has left

  1317. SamWhited has left

  1318. anjan has left

  1319. Valerian has left

  1320. Valerian has joined

  1321. Valerian has left

  1322. Valerian has joined

  1323. Andrew Nenakhov has left

  1324. Andrew Nenakhov has joined

  1325. Andrew Nenakhov has left

  1326. Andrew Nenakhov has joined

  1327. Valerian has left

  1328. Valerian has joined

  1329. la|r|ma has joined

  1330. la|r|ma has joined

  1331. la|r|ma has joined

  1332. lumi has joined

  1333. vanitasvitae has left

  1334. SamWhited has left

  1335. vanitasvitae has left

  1336. valo has left

  1337. daniel has left

  1338. anjan has joined

  1339. vanitasvitae has left

  1340. j.r has joined

  1341. Valerian has left

  1342. vanitasvitae has left

  1343. Nekit has joined

  1344. j.r has joined

  1345. Chobbes has left

  1346. Chobbes has joined

  1347. alexis has left

  1348. alexis has joined

  1349. lskdjf has joined

  1350. igor75 has joined

  1351. igor75 has joined

  1352. dos has left

  1353. jjrh has left

  1354. j.r has joined

  1355. SamWhited has left

  1356. matlag has joined

  1357. rtq3 has left

  1358. dos has joined

  1359. rainslide has joined

  1360. j.r has joined

  1361. anjan has left

  1362. rainslide has left

  1363. rtq3 has joined

  1364. UsL has left

  1365. jjrh has left

  1366. UsL has joined

  1367. rtq3 has left

  1368. rtq3 has joined

  1369. Lance has left

  1370. igor75 has left

  1371. muppeth has left

  1372. igor75 has joined

  1373. muppeth has joined

  1374. pep. has left

  1375. rtq3 has left

  1376. vanitasvitae has left

  1377. alexis has left

  1378. alexis has joined

  1379. vanitasvitae has joined

  1380. alexis has left

  1381. alexis has joined

  1382. rainslide has joined

  1383. j.r has joined

  1384. Lance has joined

  1385. alexis has left

  1386. alexis has joined

  1387. nyco has left

  1388. nyco has joined