XSF Discussion - 2019-10-28

  1. jonas’

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

  2. Ge0rG

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

  3. Daniel

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

  4. Ge0rG

    Daniel: you mean the number of bytes?

  5. Daniel

    Yes file size

  6. Ge0rG

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

  7. jonas’

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

  8. Daniel

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

  9. Daniel

    OK 2.8k if I don't store exif data

  10. Ge0rG

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

  11. jonas’

    Ge0rG had 667 bytes the other day

  12. 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?

  13. jonas’

    Ge0rG, something about HSLuv?

  14. jonas’

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

  15. jonas’

    (for certain definitions of easy)

  16. jonas’

    (you need to know how to apply a DCT)

  17. Daniel

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

  18. jonas’


  19. Daniel

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

  20. jonas’

    even that won’t help

  21. jonas’

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

  22. jonas’

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

  23. jonas’

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

  24. Daniel

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

  25. Ge0rG

    Let's bundle both of ImageMagick and GIMP!

  26. 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

  27. Ge0rG

    Does the blurhash include the actual image resolution?

  28. Daniel

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

  29. Ge0rG

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

  30. Ge0rG

    Also rounding errors between the ratio and the final resolution

  31. Ge0rG

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

  32. Daniel

    I wish we had Sims without the references

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

  34. rion

    replacing the referenced text with media content

  35. Ge0rG

    yeah, the references part is a bit of overkill

  36. MattJ

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

  37. MattJ

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

  38. MattJ

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

  39. Zash

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

  40. 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".

  41. MattJ

    We have such a treasure trove

  42. jonas’


  43. 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

  44. MattJ

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

  45. MattJ

    I should have used that from the start

  46. jonas’

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

  47. rion

    MattJ: SIMS would ber perfect for the mod imho.

  48. rion

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

  49. 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

  50. Zash

    No sending foto albums?

  51. larma

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

  52. moparisthebest

    what clients support *that* ?

  53. Link Mauve

    Salut à Toi should.

  54. rion

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

  55. larma

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

  56. larma

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

  57. Zash

    OOB can be mapped to SIMS

  58. larma

    yes, but not the other way round

  59. Zash

    SIMS -> OOB would be lossy, yes

  60. 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)

  61. 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

  62. larma

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

  63. larma

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

  64. pep.

    Standard !== what is specified? :p

  65. Zash

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

  66. lovetox

    what for?

  67. lovetox

    why another server translation xep

  68. lovetox

    SIMS is not implemented because it is unfinished

  69. lovetox

    i saw countless emails to standards with discussions

  70. lovetox

    no update to the xep whatsoever

  71. 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".

  72. pep.

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

  73. larma

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

  74. pep.

    That'd be a first step

  75. Link Mauve

    Should at least be a historical XEP.

  76. lovetox

    what purpose does this serv

  77. lovetox

    documenting things for the sake of documenting or what?

  78. larma

    Well apparently there are things not clear about it

  79. moparisthebest

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

  80. pep.

    lovetox, sure documenting.

  81. moparisthebest

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

  82. pep.

    What about new clients appearing, how do they even know

  83. 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.

  84. Zash

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

  85. Link Mauve

    moparisthebest, it should probably get resubmitted as historical.

  86. moparisthebest

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

  87. Link Mauve

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

  88. lovetox

    this all is nonesense for me sorry

  89. Zash

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

  90. Link Mauve

    That’s enough for it to be historical.

  91. lovetox

    you cannot dictate what to display inline in other clients

  92. Link Mauve

    See OTR, see vCard-temp.

  93. larma

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

  94. lovetox

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

  95. lovetox

    i see no purpose for this at all

  96. moparisthebest

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

  97. Zash

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

  98. 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

  99. larma

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

  100. moparisthebest

    ah ok I guess maybe it fits that larma

  101. lovetox

    even if the XEP is called Inline media

  102. lovetox

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

  103. pep.

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

  104. pep.

    it's just what's out there :)

  105. 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?

  106. larma

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

  107. larma

    Also XEP-0201 😉

  108. lovetox

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

  109. lovetox

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

  110. lovetox

    knowing that a client can act on it

  111. larma

    lovetox, agree

  112. lovetox

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

  113. larma

    but again, this is not written down anywhere

  114. lovetox

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

  115. pep.

    lovetox, if you can do that, great

  116. pep.

    Please change all clients :)

  117. larma

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

  118. lovetox

    no the author should react to the countless standard mails

  119. lovetox

    yeah then discuss whats correct

  120. lovetox

    no future client should be forced to implement oob

  121. larma

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

  122. lovetox

    ok if i hear compliance suite im out :D

  123. lovetox

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

  124. lovetox

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

  125. 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"

  126. Ge0rG

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

  127. larma

    Ge0rG, we can still suggest UI outside XEPs

  128. larma

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

  129. lovetox

    and client serv different communitys with different needs

  130. larma

    *thumbs up reaction*

  131. 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

  132. moparisthebest

    how are they different at all actually?

  133. lovetox

    a client may want to react differently

  134. Ge0rG

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

  135. 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

  136. lovetox

    while your contact just pasting links he found somewhere

  137. lovetox

    is maybe not something i want to immediatly download

  138. moparisthebest

    I'm still not seeing the difference

  139. lovetox

    not downloading vs downloading

  140. 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...

  141. 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?

  142. lovetox

    moparisthebest, its not about what you want

  143. lovetox

    you can not want anything for another client

  144. moparisthebest

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

  145. larma

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

  146. moparisthebest

    so certainly the remote client cannot guess

  147. lovetox

    he does not need to guess, if you tell him

  148. lovetox

    hence the protocol we are discussing

  149. larma

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

  150. lovetox

    and the difference

  151. 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

  152. lovetox

    im not sure what you are trying to say

  153. larma

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

  154. lovetox

    clients react to that differently already

  155. lovetox

    and it works just fine

  156. 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.

  157. Zash

    the http upload part, that shouldn't matter

  158. lovetox

    but it does

  159. lovetox

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

  160. lovetox

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

  161. moparisthebest

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

  162. Zash


  163. lovetox

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

  164. 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?

  165. moparisthebest

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

  166. Link Mauve

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

  167. Link Mauve

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

  168. lovetox

    yeah clients could be just smart about that

  169. 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 :)

  170. lovetox

    but it is, you got it backwards

  171. lovetox

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

  172. lovetox

    the receiving client decides what it does with that information

  173. moparisthebest

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

  174. Zash


  175. moparisthebest

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

  176. Zash

    it makes no sense to me

  177. lovetox

    because its more trustable

  178. moparisthebest


  179. moparisthebest

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

  180. moparisthebest

    or, really anything else

  181. 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.

  182. moparisthebest

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

  183. moparisthebest

    like presumably a gajim plugin could do that?

  184. moparisthebest

    so how can the recieving client place any trust in that

  185. Zash

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

  186. lovetox

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

  187. lovetox

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

  188. lovetox

    and as i said above, media gallery of filetransfers

  189. lovetox

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

  190. 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

  191. lovetox

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

  192. moparisthebest

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

  193. moparisthebest

    probably more often than paste links even

  194. moparisthebest

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

  195. lovetox

    moparisthebest, i think you misunderstood

  196. lovetox

    its not about accidently sharing a file

  197. lovetox

    a file will never harm your contact

  198. moparisthebest

    that doesn't sound like a given

  199. lovetox

    a link could that you share further could

  200. moparisthebest

    they... are the same though...

  201. lovetox

    technially yes nobody argues anything else :)

  202. 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?

  203. lovetox

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

  204. lovetox

    moparisthebest, its not about security, its about the intentions

  205. jonas’

    I tend to agree with lovetox to some extent

  206. moparisthebest

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

  207. lovetox

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

  208. jonas’

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

  209. lovetox

    i agree its a very subtle difference

  210. jonas’

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

  211. lovetox

    and i agree most clients will probably not make it

  212. jonas’

    which means that C will render them as file downloads

  213. lovetox

    but its still worth to have that hint

  214. jonas’

    instead of as links

  215. lovetox

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

  216. 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

  217. lovetox

    then actuall private files someone uploaded

  218. lovetox

    moparisthebest, no nobody says its ok to display inline

  219. lovetox

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

  220. moparisthebest

    except all clients that have it implemented that way of course

  221. lovetox

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

  222. larma

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

  223. moparisthebest

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

  224. 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?

  225. larma

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

  226. moparisthebest

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

  227. moparisthebest

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

  228. lovetox

    yes they are

  229. lovetox


  230. Zash

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

  231. lovetox

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

  232. moparisthebest

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

  233. larma

    moparisthebest, it is

  234. lovetox

    it is, Gajim has a plugin :D

  235. moparisthebest

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

  236. lovetox

    and also its not hard to implement

  237. lovetox

    developers just have other stuff to do right now

  238. larma

    also smack supports it

  239. lovetox

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

  240. lovetox

    so oob url is ok

  241. lovetox

    but SIMS is not?

  242. moparisthebest

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

  243. lovetox

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

  244. lovetox

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

  245. lovetox

    E2E is out of the question

  246. larma

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

  247. lovetox

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

  248. 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

  249. lovetox

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

  250. lovetox

    that goes without saying

  251. lovetox

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

  252. larma

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

  253. moparisthebest

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

  254. pep.

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

  255. moparisthebest

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

  256. moparisthebest

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

  257. larma

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

  258. moparisthebest

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

  259. moparisthebest

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

  260. 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

  261. 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

  262. moparisthebest

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

  263. moparisthebest

    but you can't

  264. flow

    I'd argue that it is still useful

  265. 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

  266. flow

    or malicious

  267. larma

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

  268. larma

    Anyone interested in DKIM for XMPP?

  269. Zash

    The what, why?

  270. Shell

    oh dear

  271. pep.

    larma, what would you need that

  272. Zash

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

  273. Zash

    But, uh, please don't

  274. pep.

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

  275. pep.

    I'd rather do e2ee and verify that identity

  276. Zash

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

  277. pep.

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

  278. Zash

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

  279. pep.

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

  280. Zash

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

  281. pep.


  282. 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.

  283. Zash

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

  284. larma

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

  285. 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)

  286. moparisthebest

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

  287. Zash

    Mailing lists don't break SPf

  288. pep.

    moparisthebest, mailing lists break dkim

  289. larma

    pep., they don't need to

  290. pep.

    They don't need to indeed

  291. pep.

    Most do

  292. moparisthebest

    Misconfigured ones that mangle the message only

  293. 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)

  294. Zash

    b) also breaks PGP signatures \o/

  295. Zash

    Nice things. Email. Pick one.

  296. Zash

    Email and DANE seems to do okay tho.

  297. larma

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

  298. waqas

    Picking nice things is a real option?

  299. Zash

    The nice thing is a lie.