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’ no.
  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’ *twitch*
  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 wat
  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 this
  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 why???
  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 openpgp
  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