XSF Discussion - 2019-10-28

  1. neshtaxmpp has left

  2. adiaholic has joined

  3. pdurbin has joined

  4. zach has left

  5. zach has joined

  6. mukt2 has left

  7. pdurbin has left

  8. mukt2 has joined

  9. david has left

  10. david has joined

  11. Chobbes has left

  12. Chobbes has joined

  13. Chobbes has left

  14. zach has left

  15. zach has joined

  16. adiaholic has left

  17. adiaholic has joined

  18. david has left

  19. zach has left

  20. zach has joined

  21. mukt2 has left

  22. mukt2 has joined

  23. lskdjf has left

  24. zach has left

  25. zach has joined

  26. derdaniel has left

  27. david has joined

  28. derdaniel has joined

  29. Shell has left

  30. Shell has joined

  31. pdurbin has joined

  32. debacle has left

  33. david has left

  34. adiaholic has left

  35. adiaholic has joined

  36. Shell has left

  37. Shell has joined

  38. arc has left

  39. arc has joined

  40. arc has left

  41. arc has joined

  42. neshtaxmpp has joined

  43. derdaniel has left

  44. derdaniel has joined

  45. adiaholic has left

  46. mukt2 has left

  47. mukt2 has joined

  48. mukt2 has left

  49. mukt2 has joined

  50. Douglas Terabyte has left

  51. Douglas Terabyte has joined

  52. david has joined

  53. Yagiza has joined

  54. mukt2 has left

  55. mukt2 has joined

  56. zach has left

  57. zach has joined

  58. adiaholic has joined

  59. mukt2 has left

  60. mukt2 has joined

  61. Douglas Terabyte has left

  62. Douglas Terabyte has joined

  63. andy has joined

  64. Nekit has joined

  65. david has left

  66. mukt2 has left

  67. mukt2 has joined

  68. mukt2 has left

  69. xalek has left

  70. aj has joined

  71. derdaniel has left

  72. lorddavidiii has joined

  73. derdaniel has joined

  74. Shell has left

  75. mukt2 has joined

  76. derdaniel has left

  77. Daniel has left

  78. Tobias has joined

  79. zach has left

  80. zach has joined

  81. aj has left

  82. derdaniel has joined

  83. Daniel has joined

  84. mukt2 has left

  85. j.r has left

  86. j.r has joined

  87. derdaniel has left

  88. mukt2 has joined

  89. mukt2 has left

  90. COM8 has joined

  91. COM8 has left

  92. mukt2 has joined

  93. wurstsalat has joined

  94. Mikaela has joined

  95. j.r has left

  96. j.r has joined

  97. derdaniel has joined

  98. LNJ has joined

  99. zach has left

  100. zach has joined

  101. karoshi has joined

  102. zach has left

  103. zach has joined

  104. aj has joined

  105. jonas’

    could be nice for a SFW-preview of NSFW-pictures though

  106. zach has left

  107. zach has joined

  108. pdurbin has left

  109. Nekit has left

  110. Nekit has joined

  111. lorddavidiii has left

  112. lorddavidiii has joined

  113. Ge0rG

    Again, how's that actually better than a low res jpeg?

  114. zach has left

  115. zach has joined

  116. j.r has left

  117. jabberjocke has left

  118. Daniel

    Ge0rG: just from doing some experiments jpegs thumbnails look much bigger

  119. Ge0rG

    Daniel: you mean the number of bytes?

  120. Daniel

    Yes file size

  121. Ge0rG

    Is that really significant, provided that we have XEP-0231 already in place?

  122. waqas has left

  123. chronosx88 has joined

  124. jonas’

    given the JPEG thing, one could use the same data of JPEG to render a blurhash

  125. mimi89999 has left

  126. mukt2 has left

  127. mimi89999 has joined

  128. Daniel

    I'm not able to generate jpeg images smaller than 3K

  129. zach has left

  130. zach has joined

  131. Daniel

    OK 2.8k if I don't store exif data

  132. mathijs has left

  133. mathijs has joined

  134. chronosx88 has left

  135. Ge0rG

    what's the "size" of a TLS handshake to HEAD an image URL?

  136. jonas’

    Ge0rG had 667 bytes the other day

  137. chronosx88 has joined

  138. Dele (Mobile) has joined

  139. lorddavidiii has left

  140. Ge0rG

    Normally, I'm all in for squeezing the most out of the bytes, and I love all the "42 bytes ELF file" style blog posts, but the question that we need to answer here is: are 2KB spared per image share worth adding a dependency on some third-party's personal pet project that doesn't even have a specification?

  141. jonas’

    Ge0rG, something about HSLuv?

  142. jonas’

    Ge0rG, BlurHash has the Algorithm.md which enables easy re-implementation.

  143. jonas’

    (for certain definitions of easy)

  144. jonas’

    (you need to know how to apply a DCT)

  145. lorddavidiii has joined

  146. Daniel

    The question is if the build in upscaler and compression methods in Android (for example) are good enough to provide similar output

  147. jonas’


  148. Daniel

    Or if I'm ending up including an external jpeg encoder then

  149. jonas’

    even that won’t help

  150. jonas’

    you’ll need a custom decoder to render it as nicely as blurhash

  151. jonas’

    you’ll have to decode the 8x8 block yourself and render it onto a larger canvas yourself, by evaluating the cosine functions

  152. jonas’

    that’s very different from taking the rendered 8x8 block and upscaling it with whatever filter

  153. Daniel

    well using convert --thumbnail 8 and then using the gimp upscaller produces images that look nice

  154. Ge0rG

    Let's bundle both of ImageMagick and GIMP!

  155. Daniel

    with a small enough file size. but then i need an upscaler that is as good as what ever gimp does; and an encoder that can strip all the crap such as imagemagick

  156. Dele (Mobile) has left

  157. Ge0rG

    Does the blurhash include the actual image resolution?

  158. Dele (Mobile) has joined

  159. Daniel

    that's by the way also a good question; because we need at least the aspect ratio

  160. Ge0rG

    Daniel: I wouldn't settle with just that, you also often need to know whether to down or up scale.

  161. Ge0rG

    Also rounding errors between the ratio and the final resolution

  162. mathijs has left

  163. mathijs has joined

  164. Ge0rG

    I think that SIMS is much more needed than blurhash, and that we could add blurhash as an optional field into SIMS

  165. Steve Kille has left

  166. Daniel

    I wish we had Sims without the references

  167. zach has left

  168. zach has joined

  169. mathijs has left

  170. mathijs has joined

  171. rion implemented it with references and it works quite well

  172. rion

    replacing the referenced text with media content

  173. Ge0rG

    yeah, the references part is a bit of overkill

  174. Steve Kille has joined

  175. goffi has joined

  176. derdaniel has left

  177. intosi has joined

  178. Zash has left

  179. Zash has joined

  180. mukt2 has joined

  181. Dele (Mobile) has left

  182. j.r has joined

  183. mukt2 has left

  184. aj has left

  185. zach has left

  186. zach has joined

  187. jubalh has joined

  188. adiaholic has left

  189. adiaholic has joined

  190. Dele (Mobile) has joined

  191. winfried has left

  192. winfried has joined

  193. winfried has left

  194. winfried has joined

  195. Dele (Mobile) has left

  196. Dele (Mobile) has joined

  197. j.r has left

  198. zach has left

  199. zach has joined

  200. mukt2 has joined

  201. debacle has joined

  202. zach has left

  203. zach has joined

  204. jabberjocke has joined

  205. MattJ

    I created https://modules.prosody.im/mod_muc_media_metadata.html

  206. MattJ

    and someone (jonas’ I think?) suggested it should use SIMS, so I'll probably make that switch

  207. adiaholic has left

  208. MattJ

    Essentially the MUC server does a HEAD on the URL, and embeds the data into the stanza

  209. Zash

    Does it make sense to reuse https://xmpp.org/extensions/xep-0131.html ?

  210. aj has joined

  211. larma has left

  212. MattJ

    > The Store header enables a sender to specify whether the stanza may be stored or archived by the recipient. The allowable values for this header are "true" and "false".

  213. MattJ

    We have such a treasure trove

  214. jonas’


  215. Ge0rG

    Somebody needs to start axing duplicate functionality, except that it's never a perfect overlap, but always different subsets. This is Venn Diagram Hell

  216. zach has left

  217. zach has joined

  218. larma has joined

  219. mukt2 has left

  220. MattJ

    Zash, it may be sensible - we can include etag for example

  221. MattJ

    I should have used that from the start

  222. Dele (Mobile) has left

  223. Dele (Mobile) has joined

  224. Dele (Mobile) has left

  225. Dele (Mobile) has joined

  226. Dele (Mobile) has left

  227. Dele (Mobile) has joined

  228. eevvoor has joined

  229. eevvoor has left

  230. j.r has joined

  231. zach has left

  232. zach has joined

  233. jmpman has joined

  234. eevvoor has joined

  235. debacle has left

  236. jabberjocke has left

  237. mukt2 has joined

  238. zach has left

  239. zach has joined

  240. eevvoor has left

  241. mukt2 has left

  242. neshtaxmpp has left

  243. j.r has left

  244. Steve Kille has left

  245. pdurbin has joined

  246. Steve Kille has joined

  247. Dele (Mobile) has left

  248. Dele (Mobile) has joined

  249. zach has left

  250. lskdjf has joined

  251. zach has joined

  252. pdurbin has left

  253. jabberjocke has joined

  254. mukt2 has joined

  255. debacle has joined

  256. Syndace has left

  257. Syndace has joined

  258. eevvoor has joined

  259. mukt2 has left

  260. adiaholic has joined

  261. debacle has left

  262. adiaholic has left

  263. eevvoor has left

  264. adiaholic has joined

  265. emus has joined

  266. mukt2 has joined

  267. zach has left

  268. zach has joined

  269. eevvoor has joined

  270. jubalh has left

  271. Mikaela has left

  272. jubalh has joined

  273. Mikaela has joined

  274. eevvoor has left

  275. eevvoor has joined

  276. jubalh has left

  277. zach has left

  278. zach has joined

  279. j.r has joined

  280. matlag has left

  281. matlag has joined

  282. krauq has left

  283. krauq has joined

  284. mukt2 has left

  285. zach has left

  286. zach has joined

  287. neshtaxmpp has joined

  288. mukt2 has joined

  289. zach has left

  290. zach has joined

  291. jabberjocke has left

  292. jmpman has left

  293. Chobbes has joined

  294. jabberjocke has joined

  295. adiaholic has left

  296. jabberjocke has left

  297. jabberjocke has joined

  298. adiaholic has joined

  299. Shell has joined

  300. zach has left

  301. zach has joined

  302. david has joined

  303. pdurbin has joined

  304. mukt2 has left

  305. mukt2 has joined

  306. Steve Kille has left

  307. zach has left

  308. pdurbin has left

  309. zach has joined

  310. Steve Kille has joined

  311. arc has left

  312. arc has joined

  313. Syndace has left

  314. Mikaela has left

  315. Mikaela has joined

  316. jubalh has joined

  317. zach has left

  318. zach has joined

  319. jubalh has left

  320. jubalh has joined

  321. jubalh has left

  322. jubalh has joined

  323. jubalh has left

  324. jubalh has joined

  325. mukt2 has left

  326. chronosx88 has left

  327. jubalh has left

  328. Syndace has joined

  329. chronosx88 has joined

  330. patrick has joined

  331. zach has left

  332. zach has joined

  333. mukt2 has joined

  334. aj has left

  335. Chobbes has left

  336. zach has left

  337. zach has joined

  338. Syndace has left

  339. mukt2 has left

  340. zach has left

  341. zach has joined

  342. mukt2 has joined

  343. debacle has joined

  344. Syndace has joined

  345. Chobbes has joined

  346. Chobbes has left

  347. david has left

  348. david has joined

  349. eevvoor has left

  350. mukt2 has left

  351. Nekit has left

  352. zach has left

  353. zach has joined

  354. pdurbin has joined

  355. mukt2 has joined

  356. neshtaxmpp has left

  357. neshtaxmpp has joined

  358. emus has left

  359. Chobbes has joined

  360. zach has left

  361. zach has joined

  362. waqas has joined

  363. pdurbin has left

  364. mukt2 has left

  365. Chobbes has left

  366. zach has left

  367. zach has joined

  368. mukt2 has joined

  369. david has left

  370. david has joined

  371. j.r has left

  372. jubalh has joined

  373. j.r has joined

  374. zach has left

  375. zach has joined

  376. emus has joined

  377. mukt2 has left

  378. zach has left

  379. zach has joined

  380. winfried has left

  381. winfried has joined

  382. jubalh has left

  383. jabberjocke has left

  384. mathijs has left

  385. mathijs has joined

  386. mukt2 has joined

  387. jonas’

    > Mastodon - The Mastodon decentralised social media network uses BlurHashes both as loading placeholders, as well as for hiding media marked as sensitive.

  388. matlag has left

  389. zach has left

  390. zach has joined

  391. matlag has joined

  392. mukt2 has left

  393. winfried has left

  394. winfried has joined

  395. lovetox has joined

  396. !XSF_Martin has left

  397. !XSF_Martin has joined

  398. adiaholic has left

  399. adiaholic has joined

  400. zach has left

  401. zach has joined

  402. mukt2 has joined

  403. pdurbin has joined

  404. david has left

  405. Steve Kille has left

  406. pdurbin has left

  407. david has joined

  408. Steve Kille has joined

  409. zach has left

  410. zach has joined

  411. adiaholic has left

  412. adiaholic has joined

  413. lorddavidiii has left

  414. lorddavidiii has joined

  415. mathijs has left

  416. mathijs has joined

  417. !XSF_Martin has left

  418. neshtaxmpp has left

  419. zach has left

  420. zach has joined

  421. jubalh has joined

  422. jubalh has left

  423. jubalh has joined

  424. jubalh has left

  425. jubalh has joined

  426. mukt2 has left

  427. mukt2 has joined

  428. jubalh has left

  429. jubalh has joined

  430. zach has left

  431. zach has joined

  432. jubalh has left

  433. Dele (Mobile) has left

  434. zach has left

  435. zach has joined

  436. Shell has left

  437. Shell has joined

  438. Yagiza has left

  439. jubalh has joined

  440. jubalh has left

  441. winfried has left

  442. winfried has joined

  443. winfried has left

  444. winfried has joined

  445. !XSF_Martin has joined

  446. winfried has left

  447. winfried has joined

  448. zach has left

  449. zach has joined

  450. mathijs has left

  451. mathijs has joined

  452. winfried has left

  453. winfried has joined

  454. mathijs has left

  455. mathijs has joined

  456. xalek has joined

  457. matlag has left

  458. matlag has joined

  459. Nekit has joined

  460. zach has left

  461. zach has joined

  462. Dele (Mobile) has joined

  463. pdurbin has joined

  464. jubalh has joined

  465. pdurbin has left

  466. andrey.g has left

  467. Wojtek has joined

  468. zach has left

  469. zach has joined

  470. rion

    MattJ: SIMS would ber perfect for the mod imho.

  471. rion

    and with xep-0131 I think it's not that clear how to handle multiple media links in one message

  472. lorddavidiii has left

  473. jubalh has left

  474. lorddavidiii has joined

  475. larma

    rion, does any client support oob-based http file transfer with multiple links in one message? I don't think it makes a lot of sense to send multiple files in one message

  476. Zash

    No sending foto albums?

  477. andrey.g has joined

  478. larma

    Zash, your photo album should be a pubsub node or something so that you can add further images to it

  479. moparisthebest

    what clients support *that* ?

  480. Link Mauve

    Salut à Toi should.

  481. rion

    larma: my client can send multiple SIMSs in one message regardless http or not.

  482. larma

    but multiple SIMS is not the same as multiple oob file transfers

  483. larma

    I don't think you can translate between the two server-side

  484. Zash

    OOB can be mapped to SIMS

  485. larma

    yes, but not the other way round

  486. Zash

    SIMS -> OOB would be lossy, yes

  487. LNJ has left

  488. larma

    and rion was bringing up multiple links in one message which I think is not supported by oob file transfer (but isn't properly written down anywhere)

  489. patrick has left

  490. moparisthebest

    I have ran across use cases for multiple images attached to some text, which as you said no clients really support, say a "refer to the differences in these 2 screenshots" message

  491. larma

    If we don't move to SIMS for file transfer soonish, we should probably write down the oob file transfer "standard"?

  492. larma

    "standard" = what most current clients do for sending a file that was uploaded with http file upload

  493. mukt2 has left

  494. pep.

    Standard !== what is specified? :p

  495. Zash

    Serverside OOB to SIMS translation would not be difficult. Ie mapping the URL into SIMS (and maybe description, if anyone ever uses that)

  496. lovetox

    what for?

  497. lovetox

    why another server translation xep

  498. lorddavidiii has left

  499. lovetox

    SIMS is not implemented because it is unfinished

  500. lovetox

    i saw countless emails to standards with discussions

  501. lovetox

    no update to the xep whatsoever

  502. lorddavidiii has joined

  503. larma

    pep., AFAIK there is no real specification for that. We have oob but nobody understands it as "display this file inline" or "display the link at all". We have http upload to upload files. And now apparently what is done is to put the URL of http uploaded file in both body and oob to indicate "display file inline or as file transfer".

  504. balu_der_baer has joined

  505. pep.

    larma, I agree nothing about body==oob url is standardized :)

  506. zach has left

  507. zach has joined

  508. larma

    So we should make a short informational XEP out of that?

  509. pep.

    That'd be a first step

  510. Link Mauve

    Should at least be a historical XEP.

  511. balu_der_baer has left

  512. lovetox

    what purpose does this serv

  513. lovetox

    documenting things for the sake of documenting or what?

  514. larma

    Well apparently there are things not clear about it

  515. moparisthebest

    some this get documented for the sake of documenting then the XEP gets rejected https://xmpp.org/extensions/inbox/omemo-media-sharing.html

  516. pep.

    lovetox, sure documenting.

  517. moparisthebest

    (even though basically all the clients implement it anyway?)

  518. pep.

    What about new clients appearing, how do they even know

  519. Link Mauve

    lovetox, when you write a new client, currently you have to read other clients to understand you have to do that for images to appear.

  520. chronosx88 has left

  521. Zash

    Documenting and discussing how to do things is our purpose here.

  522. Link Mauve

    moparisthebest, it should probably get resubmitted as historical.

  523. moparisthebest

    but it's not historical, all the clients do this

  524. Link Mauve

    It still didn’t get through any standardisation process, and is a historical artifact.

  525. lovetox

    this all is nonesense for me sorry

  526. Zash

    moparisthebest: lots of clients do lots of "historical" things still

  527. Link Mauve

    That’s enough for it to be historical.

  528. lovetox

    you cannot dictate what to display inline in other clients

  529. Link Mauve

    See OTR, see vCard-temp.

  530. larma

    > An Historical XEP documents a protocol that was developed before the XSF's standards process was instituted

  531. lovetox

    there can never be a standard that forces me as a client to display something inline

  532. lovetox

    i see no purpose for this at all

  533. moparisthebest

    all clients do this and there isn't even a proposed replacement yet? still historical?

  534. Zash

    larma: Maybe we should s/before/outside/ then?

  535. chronosx88 has joined

  536. lovetox

    you send me a SIMS message, guess what if i feel like it having a option to not display it inline, then thats it

  537. larma

    > An Informational XEP typically defines best practices for implementation or deployment of an existing protocol

  538. moparisthebest

    ah ok I guess maybe it fits that larma

  539. lovetox

    even if the XEP is called Inline media

  540. lovetox

    its the responsibility of the client to decide what to display inline and what not

  541. pep.

    larma, not that body==oob url is "best practices"

  542. pep.

    it's just what's out there :)

  543. chronosx88 has left

  544. lovetox

    i even display images inline that you send without oob, just paste a url into the chat, what now, are we going to document that also?

  545. larma

    yeah but it says "typically defines best practices" so "bad practices" are also fine 😉

  546. chronosx88 has joined

  547. larma

    Also XEP-0201 😉

  548. lovetox

    also body==url, never meant "display this inline"

  549. lovetox

    it meant, this is a filetransfer of a file uploaded with http upload

  550. lovetox

    knowing that a client can act on it

  551. larma

    lovetox, agree

  552. lovetox

    but nobody ever said, you have to display this now inline

  553. larma

    but again, this is not written down anywhere

  554. lovetox

    why invest the time into changing old XEPs, if we could work on finishing SIMS and migrate

  555. pep.

    lovetox, if you can do that, great

  556. pep.

    Please change all clients :)

  557. larma

    I don't think there is consensus on what the correct SIMS is.

  558. lovetox

    no the author should react to the countless standard mails

  559. lovetox

    yeah then discuss whats correct

  560. lovetox

    no future client should be forced to implement oob

  561. larma

    lovetox, "no future client should be forced to implement oob" unrealistic, also it is just about to be part of the CS2020

  562. lovetox

    ok if i hear compliance suite im out :D

  563. eevvoor has joined

  564. j.r has left

  565. j.r has joined

  566. lovetox

    no sorry go on, im grumpy had a long day, document away :)

  567. lovetox

    but please stay away from dictating UI behavior on the receiving side

  568. Nekit has left

  569. jabberjocke has joined

  570. larma

    I would never want a XEP to dictate UI. But we definitely need a way to indicate "this is a link to a third party resource" vs "this is a file transfer"

  571. Ge0rG

    Because users don't need consistency between different implementations, or between sender and recipient of a message.

  572. larma

    Ge0rG, we can still suggest UI outside XEPs

  573. larma

    but client consistency outside of protocol does not belong in XEPs IMO

  574. lovetox

    and client serv different communitys with different needs

  575. larma

    *thumbs up reaction*

  576. Ge0rG

    larma [21:16]: > "this is a link to a third party resource" vs "this is a file transfer" Unfortunately, there is no difference between those from a security point of view

  577. moparisthebest

    how are they different at all actually?

  578. lovetox

    a client may want to react differently

  579. waqas has left

  580. waqas has joined

  581. Ge0rG

    moparisthebest: the former could be anything, not just an image

  582. lovetox

    if a "file transfer" comes from a contact in my roster he could have a policy that this is trustable enough to just download and display inline

  583. lovetox

    while your contact just pasting links he found somewhere

  584. lovetox

    is maybe not something i want to immediatly download

  585. moparisthebest

    I'm still not seeing the difference

  586. lovetox

    not downloading vs downloading

  587. larma

    A file transfer *should* have a fixed hash and the sender sending that hash (ideally in a cryptographically signed message) thus sends a very specific file, if the downloaded resource does not match, the file transfer failed. A link to an external resource is usually handled by whatever local software is responsible for that uri protocol, thus could also extend beyond the http protocol (like a vnc uri to open your vnc viewer) and the resource behind the URI can change or be non global...

  588. moparisthebest

    If I'm sharing memes with my wife, why would I want it to display differently if I download and re-upload the meme vs paste the link?

  589. lovetox

    moparisthebest, its not about what you want

  590. lovetox

    you can not want anything for another client

  591. moparisthebest

    it is in the sense that not even *my* client can guess what I want

  592. waqas has left

  593. larma

    If your client displays external resources inline under certain criteria, that's something completely different

  594. waqas has joined

  595. moparisthebest

    so certainly the remote client cannot guess

  596. lovetox

    he does not need to guess, if you tell him

  597. lovetox

    hence the protocol we are discussing

  598. larma

    It's a known attack against clients that show "previews" to fake the preview to lure users into opening shady websites

  599. lovetox

    and the difference

  600. moparisthebest

    and sure you can write up a protocol for "hey the sender wants you to display it like X" but that's still useless because the sender won't do it

  601. lovetox

    im not sure what you are trying to say

  602. larma

    moparisthebest, it's not about what is possible, but about what makes sense

  603. lovetox

    clients react to that differently already

  604. lovetox

    and it works just fine

  605. chronosx88 has left

  606. chronosx88 has joined

  607. waqas has left

  608. waqas has joined

  609. Zash

    > it (body==oob.url) meant, this is a filetransfer of a file uploaded with http upload really? that doesn't seem like something that needed to be communicated.

  610. chronosx88 has left

  611. Zash

    the http upload part, that shouldn't matter

  612. lovetox

    but it does

  613. lovetox

    it means a user selected a file on his harddrive, and wants to transfer it to you

  614. lovetox

    only because thats done via http, does not mean every url i paste into a chat is now a filetransfer

  615. chronosx88 has joined

  616. moparisthebest

    that's a pretty dumb restriction anyway, I ran into this the other day actually

  617. Zash


  618. lovetox

    simple use case, i want to show a gallery of received media from a contact

  619. moparisthebest

    take a picture of the kid, want to send it to my Mom and my Wife, http upload to Mom, now do I waste space on the server by http upload'ing it to wife also, or just copy/paste the URL and paste to wife?

  620. waqas has left

  621. waqas has joined

  622. moparisthebest

    it sucks the second way changes how it's displayed on wife's end :)

  623. Link Mauve

    A simple solution for that would be for your client to have a cache of recently uploaded files.

  624. Link Mauve

    No need to change the UI, just it wouldn’t transfer it again and instead reuse the URL it already got.

  625. lovetox

    yeah clients could be just smart about that

  626. moparisthebest

    or you could stop relying on the sending client to decide which images to display inline or not, and have that be a preference of the recieving client as it should be :)

  627. waqas has left

  628. waqas has joined

  629. lovetox

    but it is, you got it backwards

  630. lovetox

    as we said, the sending client just tells this is a file from my harddrive

  631. lovetox

    the receiving client decides what it does with that information

  632. zach has left

  633. zach has joined

  634. moparisthebest

    "whether this came from my hardrive or not" is a really dumb distinction though

  635. waqas has left

  636. waqas has joined

  637. Zash


  638. moparisthebest

    I don't understand why it would matter in any concievable way

  639. Zash

    it makes no sense to me

  640. lovetox

    because its more trustable

  641. moparisthebest


  642. moparisthebest

    why is a http upload link on my server I uploaded 2 seconds ago less trustable than one I'm uploading now

  643. moparisthebest

    or, really anything else

  644. Zash

    It's an URL... twice. It means you sent a link to some out of band resource that you can click on if your client doesn't do something with it.

  645. moparisthebest

    you can make a client take any pasted http link, and pretend it's an http upload when sending it right?

  646. moparisthebest

    like presumably a gajim plugin could do that?

  647. waqas has left

  648. moparisthebest

    so how can the recieving client place any trust in that

  649. waqas has joined

  650. Zash

    `/embed arbitrary-url-here` in poezio for example, I've done that a bunch of times

  651. lovetox

    because you can share a link by accident or unkowing that it causes harm

  652. lovetox

    if you select a picture from your harddrive, it will most likely not

  653. lovetox

    and as i said above, media gallery of filetransfers

  654. waqas has left

  655. waqas has joined

  656. lovetox

    but yeah i know other messengers record every link as media that was sent

  657. larma

    I think it is easier to grasp if you put in the hash of the file. It gives certainty to the recipient that they receive the correct file and it requires the sender to actually have the file before "sending" it, but it doesn't need to upload it if it's already online

  658. lovetox

    thats why everybody with whatsapp ends up with X memes in his gallery shared by some people in groupchats

  659. moparisthebest

    uh sorry but I see people accidentally upload pictures in mucs all the time?

  660. moparisthebest

    probably more often than paste links even

  661. moparisthebest

    in fact it's pretty easy to open a picture in the android gallery, click share, then mis-click the conversation muc

  662. lovetox

    moparisthebest, i think you misunderstood

  663. lovetox

    its not about accidently sharing a file

  664. lovetox

    a file will never harm your contact

  665. moparisthebest

    that doesn't sound like a given

  666. lovetox

    a link could that you share further could

  667. moparisthebest

    they... are the same though...

  668. lovetox

    technially yes nobody argues anything else :)

  669. waqas has left

  670. waqas has joined

  671. moparisthebest

    if I paste a link, you have no idea if I uploaded it or if it was already there, if I send you http upload xml, you have no idea if I uploaded it or if it was already there, what's the difference?

  672. lovetox

    but one is a link someone wants you to see, and the other is a file he wanted you to have

  673. lovetox

    moparisthebest, its not about security, its about the intentions

  674. jonas’

    I tend to agree with lovetox to some extent

  675. moparisthebest

    it's about nothing because there is no difference at all

  676. lovetox

    if it was about security i could not rust anything that does not come from my server

  677. jonas’

    weird things happen for example with Conversations when you OOB-tag arbitrary links

  678. lovetox

    i agree its a very subtle difference

  679. jonas’

    I have code in JabberCat which simply OOB-tags all URL-only posts

  680. lovetox

    and i agree most clients will probably not make it

  681. jonas’

    which means that C will render them as file downloads

  682. lovetox

    but its still worth to have that hint

  683. jonas’

    instead of as links

  684. lovetox

    and if its just to sort, link meme shares into another category on harddrive

  685. moparisthebest

    which hint though? it seems like we are taking a mostly arbitrary "this is from my hard drive" hint, and interpreting it instead as a "this is ok to display inline" hint

  686. lovetox

    then actuall private files someone uploaded

  687. lovetox

    moparisthebest, no nobody says its ok to display inline

  688. lovetox

    thats a determination a client can make, but nobody suggest to do it

  689. waqas has left

  690. waqas has joined

  691. moparisthebest

    except all clients that have it implemented that way of course

  692. lovetox

    as i said simple usecase, i dont want your meme shares from 9gag in my file gallery

  693. larma

    write up on things I'd change in SIMS (including the name): https://gist.github.com/mar-v-in/f154b97ddc9869c1132b12bcd9a14f38

  694. moparisthebest

    I like how SIMS just assumes e2e doesn't exist lol

  695. moparisthebest

    makes it easy, don't have to answer any hard questions, also makes it un-useable in the real world but that's just a minor detail right?

  696. waqas has left

  697. waqas has joined

  698. larma

    moparisthebest, does it? I'd say it assumes we have full stanza encryption 😉

  699. moparisthebest

    that falls under "un-useable in the real world" I guess :)

  700. moparisthebest

    since there aren't any full stanza encryption methods implemented anywhere?

  701. lovetox

    yes they are

  702. lovetox


  703. Zash

    Can't you do E2E encrypted file transfers with Jingle? SIMS can use that.

  704. lovetox

    also dont know what that has to do with E2E at all

  705. waqas has left

  706. moparisthebest

    OX? there is a XEP, iirc it's not actually implemented anywhere

  707. waqas has joined

  708. larma

    moparisthebest, it is

  709. lovetox

    it is, Gajim has a plugin :D

  710. moparisthebest

    hashes/size/name/type all that private stuff that should probably be encrypted

  711. lovetox

    and also its not hard to implement

  712. lovetox

    developers just have other stuff to do right now

  713. larma

    also smack supports it

  714. lovetox

    moparisthebest, what is private about that? these are all things i can get from a oob url if i download the file

  715. lovetox

    so oob url is ok

  716. lovetox

    but SIMS is not?

  717. moparisthebest

    not one of these URLs: https://xmpp.org/extensions/inbox/omemo-media-sharing.html

  718. lovetox

    SIMS is just, i tell you the metadata before you have to download the file

  719. lovetox

    moparisthebest, we talk about media sharing XEPs, and if i want to share a picutre here in this MUC

  720. lovetox

    E2E is out of the question

  721. larma

    If you encrypt the file before uploading you should probably also encrypt SIMS

  722. waqas has left

  723. waqas has joined

  724. lovetox

    so why should i not be nice and sent metadata with so clients dont have to download to get them

  725. larma

    If you don't encrypt the http file upload, it makes little sense to encrypt SIMS data (like hash), but if you do encrypt the http file upload you also should encrypt such

  726. lovetox

    of course this xep is only to be used with full stanza encryption if your conversation is encrypted

  727. lovetox

    that goes without saying

  728. lovetox

    but a media sharing XEP must not care if currently full stanza encryption in use or not

  729. larma

    lovetox, people for some reason always assume that encryption is a body-only thing and thus complain about SIMS leaking things

  730. waqas has left

  731. waqas has joined

  732. moparisthebest

    yes, ie the only encryption that has ever been actually deployed :)

  733. pep.

    moparisthebest, in the meantime, if you don't think about it, it's probably never going to become viable

  734. waqas has left

  735. waqas has joined

  736. moparisthebest

    I'm also not sure the point of letting clients lie about stuff

  737. moparisthebest

    if you duplicate where info is, then you have to have rules about when it doesn't match

  738. waqas has left

  739. waqas has joined

  740. larma

    "duplicate where info is" what are you referring to?

  741. waqas has left

  742. waqas has joined

  743. pdurbin has joined

  744. moparisthebest

    if you send me a link to the file, I have it's size, content type, hash etc, after I get it

  745. moparisthebest

    what's the point of also sending all that? what if what you send me doesn't match with what I get?

  746. waqas has left

  747. waqas has joined

  748. Alex has left

  749. waqas has left

  750. waqas has joined

  751. Wojtek has left

  752. pdurbin has left

  753. larma

    if it doesn't match your download failed. You have a corrupt file and shouldn't tell the user "that's what the other person send you" because it's not true

  754. zach has left

  755. zach has joined

  756. Wojtek has joined

  757. waqas has left

  758. larma

    content type is not part of the file, so it's good you actually get it, size is useful to know before downloading it

  759. waqas has joined

  760. moparisthebest

    size would be useful to know before downloading, if you could trust it

  761. moparisthebest

    but you can't

  762. waqas has left

  763. waqas has joined

  764. flow

    I'd argue that it is still useful

  765. larma

    You can, just stop downloading after you reached this amount of bytes, if the link provides you with more data, then it's corrupt

  766. flow

    or malicious

  767. larma

    which is the same for the user (file transfer failed)

  768. waqas has left

  769. waqas has joined

  770. adiaholic has left

  771. chronosx88 has left

  772. adiaholic has joined

  773. !XSF_Martin has left

  774. !XSF_Martin has joined

  775. j.r has left

  776. j.r has joined

  777. Dele (Mobile) has left

  778. mukt2 has joined

  779. larma

    Anyone interested in DKIM for XMPP?

  780. zach has left

  781. zach has joined

  782. ralphm has left

  783. ralphm has joined

  784. Tobias has left

  785. Zash

    The what, why?

  786. Shell

    oh dear

  787. Wojtek has left

  788. pep.

    larma, what would you need that

  789. Zash

    MUC? .. because DKIM works so well for mailing lists

  790. Zash

    But, uh, please don't

  791. pep.

    To prove that a message is indeed coming from the server it's saying it's coming from?

  792. eevvoor has left

  793. pep.

    I'd rather do e2ee and verify that identity

  794. Zash

    s2s has pretty good security already, with mutual TLS certificate authentication.

  795. pep.

    Zash, the idea being that MUC can impersonate anybody, I guess..

  796. Zash

    I see no need for DKIM, except possibly in some relay case like MUC, but meh.

  797. mukt2 has left

  798. pep.

    And you need to trust MUC same as you trust your server. (Note that I'm not especially arguing in favor of DKIM)

  799. j.r has left

  800. Zash

    I'm quite happy leaving crypto stuff to the TLS library, thankyouverymuch.

  801. pep.


  802. j.r has joined

  803. jubalh has joined

  804. Zash

    And, mailing lists being equivalent to MUC, which is where I encountered enough problems with DKIM to just throw it all out and carry on with my life.

  805. jubalh has left

  806. Zash

    I imagine it'd be easier to apply to XMPP tho.

  807. larma

    Well, a proper client should ignore the origin information in messages in a private/non-anonymous MUC on an untrusted server right now.

  808. larma

    Zash, that's only because mailing lists modify the mail but claim it's from the original author, which is exactly what DKIM should prevent (for good reason)

  809. moparisthebest

    Dkim works on well configured mailing lists just fine, you are thinking of SPF that they break

  810. Zash

    Mailing lists don't break SPf

  811. pep.

    moparisthebest, mailing lists break dkim

  812. larma

    pep., they don't need to

  813. pep.

    They don't need to indeed

  814. pep.

    Most do

  815. moparisthebest

    Misconfigured ones that mangle the message only

  816. larma

    it's just because they a) want to display the original author in from and b) want to add a footer to the message (effectively the same as modifying it)

  817. Zash

    b) also breaks PGP signatures \o/

  818. Zash

    Nice things. Email. Pick one.

  819. zach has left

  820. zach has joined

  821. Zash

    Email and DANE seems to do okay tho.

  822. larma

    Zash, actually it doesn't (or doesn't need to) as you can concat with MIME

  823. waqas

    Picking nice things is a real option?

  824. Zash

    The nice thing is a lie.

  825. emus has left

  826. jubalh has joined

  827. jubalh has left

  828. jubalh has joined

  829. jubalh has left

  830. jubalh has joined

  831. jubalh has left

  832. jubalh has joined

  833. winfried has left

  834. winfried has joined

  835. Alex has joined

  836. goffi has left

  837. david has left

  838. david has joined

  839. zach has left

  840. zach has joined

  841. jubalh has left

  842. jubalh has joined

  843. jubalh has left

  844. jubalh has joined

  845. arc has left

  846. arc has joined

  847. jubalh has left

  848. jubalh has joined

  849. jubalh has left

  850. jubalh has joined

  851. david has left

  852. david has joined

  853. arc has left

  854. jubalh has left

  855. zach has left

  856. zach has joined

  857. lovetox has left

  858. jabberjocke has left

  859. stpeter has joined

  860. pdurbin has joined

  861. winfried has left

  862. winfried has joined

  863. pdurbin has left

  864. neshtaxmpp has joined

  865. stpeter has left

  866. zach has left

  867. zach has joined

  868. Mikaela has left

  869. mukt2 has joined

  870. david has left

  871. david has joined

  872. stpeter has joined

  873. mukt2 has left

  874. winfried has left

  875. winfried has joined

  876. adiaholic has left

  877. zach has left

  878. zach has joined

  879. adiaholic has joined

  880. stpeter has left