Gajim - 2015-08-27


  1. tmolitor arune: mime_type is set in the enclosing function...
  2. tmolitor arune: yes, the gpg thing is fixed as well...
  3. tmolitor asterix: I sent you my key as private message :)
  4. tmolitor Link Mauve, I set the maximum image size to 2048 bytes in the httpupload plugin...smaller sizes produced unusable thumbnails in most circumstances...but I think 2048 bytes should be ok...
  5. tmolitor arune: I uploaded a new plugin with all changes (demandimport, gpg in mucs and image thumbnail via xhml-im and data: uri scheme)...
  6. Link Mauve tmolitor, you really shouldn’t use data: URIs for big file transfer. :/
  7. Link Mauve Especially not in MUC.
  8. Zash I think my high-res avatar is 2kb
  9. Link Mauve In one to one it might be acceptable, even though it’s still very bad practice, but you do know the recipient.
  10. Link Mauve I would never inflict that upon anyone though.
  11. tmolitor I know, but I'm waiting for arune to shed some light on the usage of this binary bits thing...
  12. tmolitor but why are 2kb too much? even loading the last messages of a muc provides for more data than that...
  13. Link Mauve tmolitor, have you read XEP-0231 already?
  14. Zash message*s*
  15. tmolitor Zash, some girls write 2048 bytes in one message also ;)
  16. Link Mauve tmolitor, the size isn’t the issue, really.
  17. Zash followed by 2048 messages that are just smileys, so it averages out
  18. Link Mauve It’s broadcasting that to everyone, including all those who don’t want it, whether because they are on mobile, or don’t want any image, or any other reason really.
  19. tmolitor well, the thing is...bits of binary (XEP-0231) is way more complicated to implement then just sending data: uris...you have to wait for some iq stanza to request the data and you have to cache that data till this request comes in...how long would you cache that (and this is only one questions of many more)...
  20. tmolitor sending a data: uri stores the data in the message and all this trouble is gone...
  21. Link Mauve Why would you cache anything?
  22. Link Mauve Are you expecting the other party to send you the same bits of binary again?
  23. tmolitor because I would have to wait till the receiver asks for the thumbnail data...
  24. Link Mauve That’s just one more roundtrip, not the End of the World.
  25. Link Mauve You already have that with your HTTP requests, don’t you?
  26. Link Mauve They don’t come in the message either, you have to do another query.
  27. Link Mauve It’s just a slightly different transport, and Bits of Binary is way simpler than HTTP.
  28. tmolitor its not about the roundtrip...its about complicating the httpupload plugin just because "data: uris are bad"...
  29. tmolitor and its about my time (I don't have much time left to implement all sorts of fancy stuff in the httpupload plugin)....
  30. Link Mauve Then, leave it out?
  31. Link Mauve Let another plugin handle that?
  32. Link Mauve You are not expected to fix absolutely everything, consolidating what you currently have would already be very useful.
  33. tmolitor that's why I think 2048 bytes should be ok and everything else (better thumbnails with filesizes up to 8kb and more) can be done later or by another plugin...
  34. tmolitor bits of binary would imply that the sender is the http server --> stores the data for every client to receive...that would be much traffic in a muc...and you don't know how long to store that bits of binary...
  35. Link Mauve Wut?
  36. Link Mauve First of all, why do you insist on storing it?
  37. tmolitor because I as a sender have to wait for the receiver(s) to ask for it...
  38. tmolitor using an iq stanze...
  39. tmolitor [...]the recipient would then retrieve the data by sending an IQ-get to the sender (or potentially some other entity) containing an empty <data/> element whose 'cid' attribute specifies the data to be retrieved, to which the sender would reply with an IQ-result containing a <data/> element whose XML character data provides the binary data. [...]
  40. Link Mauve Second, MUCs are kind of expected to route messages, having a few clients request some data is much more efficient than sending it indiscriminately to every client.
  41. Link Mauve Ah, that kind of cache.
  42. Link Mauve You can probably keep it as long as you are in the room.
  43. tmolitor why do you think only a few clients would request the data? every client supporting xhtml-im would probably request the data...and according to you that's almost every client...
  44. Link Mauve Or clear it after your message is out of your history.
  45. Link Mauve Or add a timeout of a few hours, as a client is unlikely to request it after that time.
  46. Link Mauve tmolitor, 231 isn’t 71, those are two different specs.
  47. Link Mauve XHTML-IM is much more widespread than bits of binary.
  48. tmolitor well, if bits of binary aren't that widespread, why use it?
  49. Link Mauve The latter one came out when people needed to exchange small files, like emoticons or CAPTCHA, efficiently.
  50. tmolitor I think data: uris are displayed by more clients then bits of binary...
  51. Link Mauve Because it’s the correct solution for this problem?
  52. Link Mauve This might be true.
  53. Link Mauve But it doesn’t make it the right solution.
  54. tmolitor but it doesnt help to deliver the correct solution if nobody can use it...
  55. Link Mauve I already started an implementation in my client, anyway. ^^
  56. tmolitor yes...it doesn't make it the right solution...but it does make it the better solution...at leas for some time until bits of binary is better supported in other clients...
  57. Link Mauve This isn’t how it works.
  58. Link Mauve Clients will support what is in use, and promoting the wrong solution is a very bad way to get the right one to be used.
  59. tmolitor and still bits of binary suffers from the large upload I have to do in mucs...if I have 20 clients in a muc I have to send 20*8kb of data just for one single thumbnail...and I have to cache the data...at least for some hours...and when I delete it and some client joins the muc and retrieves the old message it still wouldn't see it...
  60. tmolitor why is using data: uris so wrong? why is it the wrong solution?
  61. Link Mauve If this somehow becomes an issue, I’m sure server-side caching will come.
  62. Link Mauve Because it doesn’t take in account what the other recipients want.
  63. Link Mauve Imagine you pay for the amount of data you download, on a mobile plan for example.
  64. tmolitor okay...but I want to use my client and my software today...I don't want to wait for some years until other clients support bits of binary properly and I don't want to wait some more years till server side caching comes...
  65. tmolitor yeah, if the image was 20kb or more in size your argument would be valid...but for 2kb?
  66. tmolitor reconnecting 2 times makes more amount of data than 2kb...
  67. tmolitor plus: maybe I am the one who has to pay for the data volume I use...and I certainly don't want to send the same thumbnail over and over again only because every client has to request it from me on its own...
  68. Link Mauve mFUPhy769Z7QjiHIDCghKzqQwFLhfkTWlUIz115AlNcykqhh5mcMejkC7vKsT6AJ2WPlfKq9RCzQ sNEZ6eIFLoOe6F/SRi02uTVhlUHejQwAJ0QjYvUc774BcCl+wLHi/9zW/Z+PhXrsDanOrUSJbB/o VYbj2cq8OSJ5XmvYTXN9SFGEef4/yOkwXtxz6qBCDtqqEtPv4f/+iy2lKGiJDlODNi6bdPPU8oTX xPuEBz9R8TY8fEEBNcK++gt/M8Yi9jJSzLtVwE1KjD8y+XCf08VvGcg4YqQbw1c9PrLYt7vZSdYt BoSV3PHtIUrEajcUJNS3VdtFPPNXOUrsuytOBqRO74sb9+Zzky5HgclbAHedpMc8aZirFHu5qHvh TuGZqLgOoYCEdqyZkm7mNTN/e3qHfipVuW+qiaJNHsYFTVhCcEJsUx0TNTLzcVeo61dvG0sF9MpL lIItNeJZv/VY6TizLd4io+AfuKkbGRe9OlyoxjgVwE10OPP4J4kf+9w6XHNzTdtLHg6B5sDt2E6u L74oxZehYfE4ng47n7p/tx5QKELi8q9wW50HJ9cKe2f67JTRgrV56O35lN07Lb0zf+D1OQc9AZ/D xXfrstVQPDPknzF5/BZDH/kUlfWN3SAtH/rsxMkkoVn3wPd2Lx9xi5FGtclU9bTbpJLyUp6Hl05u Q7dXqLWaLZsU/IPob/jnw7GBHdqhSACfnOo3K6DefQH0AFjwJ8U0BmW4BqyVudtEEU6nWbzAsYNg MZeXy6zf0hFfGd1Bl/tXrGzBnr7wIhoSxUoaJWTQZd7vfZq9JnVEe25X0K/AtUXZ9EPXVTlKHcXj 48kk4hT3JYgbT8OiLgK2B3QWoXabFFCnVRxO5+O2/zBGfUyDuyTe18nmgxdp1GdSpe6XG66Obthq X7wbzdc7WkG6RQEgizmgONGTkRs8wFLXgL7uiSOT3y++EbjYyDAAnQWr/K0Quzxg537Fc6vPum94 Bir+udGN490hWJWilJh8V+hb7WUvtZr830pjSUaaWllbG3kNyhWNZOaQHW7hK+2SnpD4FZmwgXcS 73Sx5HgkOIl8fsAjLB1hamCH4Avb2sSqcupz2mVv4CU5aK4kAoWbxCBwlfBTjjsQv9nx2m1d19dS u0g78zPdkwPkc3hbmqRJwk2xNA8pwbs2s0lQX9FOlwuZThpXwHxga/aTrljeSKgRtibVzrym9KuH FS3PRsGr/UpWE4c6uimEIK3C5EYlnO+qlwU/2TZC43DW/iV3FOIF4uAVpfH5tsN2H56ugkW8auf0 hkGtCoqdaypIxY3p3KVR9qDnHt7293GibXaVaHOQ5oV7/1qMMw4jQXhwuf3zzR3n3hBKwuLCHhc1 9Yz1uXj7Eopf7/EWSaNlMvB/KRIBfco7/mL3siDvlmt69BI9S4CVK/D1wSABvC3qSpQES6y7BziY UIIRSeJPvICPnQObCd0y2lqTqItn9gKfJi2IR4xoAOoPMpiiic/3K6DCzT2RCi6ABU/VWIY3cwdn GqebbD4pyZdyl47JgLivvXa2RGskBhgT7XSYdklEpP8x/LcsX0GFElWU4+JD9FMwOIBE1PE0ZTXJ U2riWBLKiXkL4nBL0rFeZUVjUp5UR1eEBikWXWp7fBNhTRUHLUyG3qiQOqJFnvG8EXiSYnS9PAy2 y2N033RkPNykX9Gtd6Y0tAuf6zJMRLR4/KCPnfBc2oKo9qjN9xc4WkOz/HUkFneE+WOmH0hRMVUI RIKAruxJz5dKsaeszp1NIjmZ8ixTNHhTig+6iPGS8AM7Dd6UVldbYAjdpQFDu1b02akIidiKd6Hp 2pxnzlqXVXh+Azp8k9uT4g2PFF+ZU+ooKqsRlbsO+lV/tyTbV92TdBCt8ZIMNrosXsE3Ul3GU/F0 ybky7t6SgItpFElrkMQ4aBjglMaAoTtzmLCsfXgYPgzrxsbn5zcqjBtnzQWcTM7NilTVM9ZRj/oD 2ec2rTDMPrWo/alJ+TgY/l/bjKRxFWkBXUPZsAxiXkyhXa8Pf9isDaDe1iqLJ6ohLDXw26oyTy7P bvvaldApyO+UQBcEwf//64vUJJ+seiUy64yvmq208sY8CeVgtreLMA97aJ/GVqB4jxXm9ezCAZhy ToAjfYiS1CzjE8Qo0mAsduVmuRhuKVtdIHs205m87q00pMqs2cnvju0mgGeVtZXCtafbwxaK2MEi +BznrW/IEJ/fj+RQGqTnbchyPRRbh7RiT+k7oCMs6lzwcdEWDnM37gB1v35d8qK8SHxHjwmkHksl o2RqBa5YSJ+mGwxM6+Kdm8JnJrYG2bqjd9pavdRhdgHEuxG8Qtz8NzW548NwleziljvzeFCt0KF0 MF23kjzO9i7TGg9lGwso4K5bqN9gJvGKbQl11I3Oc7EHJSQPfCWJ3zRW6/q68RaqmB/EoZDM6jmo JjgXGKaLuZlWN0YFjTaAsFT3NjsDrll2iva2rSnCDpGcVqHoML3SjI/grF/97lZL7yLCStyLHj+u p8QbxmMXlKG+7MZcf7aedJDyBUHTZg1sbQUdHfri2LPbHoIzzLMcpTTGyr7iI7vNAPCpvXIotY0a BS/fMrS45FdEJMgteCGBYk5f3fs1iVA63uTLCYKsGFLWADmBHefr4jxGKiyTVZDT9wGlQG3hsjRM /u2SwM/6TEU97Tg66XpKzuICG8ePq2M9YO/Tz3ffqTNyNWXInEYtLEVnVmTrfwSvP9CdeKM=
  69. Link Mauve Oh. ^^
  70. tmolitor that's exactly 2kb of garbage...oh okay...more than 2kb...as you encoded it as base64 (when I say 2kb i mean 2kb of base64 data)...
  71. tmolitor but this doesn't prove anything ;)
  72. Link Mauve This is what I would see whenever somebody posted some base64 data instead of an URI.
  73. tmolitor yes, but I won't post some base64 data...my plugin will post xhtml-im containing base64 data in the src attribute of an image tag...and you won't see this...
  74. tmolitor your client doesn't support xhtml-im and it would show you the plaintext body (which contains only the link to the original image)...
  75. tmolitor wait...I'll show you...
  76. tmolitor https://xmpp-upload.datenknoten.me/f9baf755ecbb5aee0d05f8815f7eeacd0dd6c690/FIHHMWW0PRFCURTXF2BDCRH7QLOXVT1KMV4GZ195/webapptest.png
  77. Link Mauve tmolitor, I will.
  78. tmolitor why that?
  79. Link Mauve Because that’s how XHTML-IM is implemented in my client, by displaying the URL at which I can retrieve the image.
  80. tmolitor I think your client doesn't support xhtml-im....well okay...than your client has to be fixed...
  81. tmolitor every user can send you xhtml-im containing some big data: uri....and this would be some kind of dos...
  82. tmolitor displaying data: uris is very bad...
  83. Link Mauve Well, nobody should do that, the spec says not to.
  84. tmolitor it says: This is NOT RECOMMENDED for use in XHTML-IM, because it can significantly increase the size of the message stanza and XMPP is not optimized for large stanzas
  85. tmolitor and 2kb data uri is not a large stanza...besides that...it doesn't say it is not allowed...
  86. Link Mauve NOT RECOMMENDED is pretty strong, by 2119 language.
  87. Link Mauve You just shouldn’t do that.
  88. tmolitor and: just because it is not allowed your client shouldn't rely on that...that's not the way someone should deal with security issues...
  89. Link Mauve I don’t consider it a security issue on my server.
  90. tmolitor but it is...do you want someone to send you big data uris to fill all your screen?
  91. Link Mauve I’m more than willing to display things that would warn me something is wrong on the network, instead of just putting my head in the sand to never see anything.
  92. tmolitor the image plugin can send images as big as 40kb using a data uri...
  93. Link Mauve I would do the necessary against someone like that, yes.
  94. tmolitor well, let's agree to disagree here ;) I'm going to sleep...
  95. Link Mauve They should fix their shit instead.
  96. tmolitor well....let's wait for some more opinions on that...maybe asterix or arune have to say something, too...
  97. Link Mauve You see, just earlier you were kicked by the bot for having sent too much base64 data. :p
  98. Link Mauve You should speak about it on standards@ instead, if you want some actual useful opinion about how XHTML-IM is meant to be used.
  99. Link Mauve Or maybe jdev@, I’m not sure.
  100. tmolitor well...in my opinion there are only 2 options...don't send a thumbnail at all or do it this way...bits of binary is just not useful today....
  101. tmolitor maybe...
  102. Link Mauve It is.
  103. Link Mauve And has been since 2008. ^^
  104. tmolitor and what clients support bits of binary? can you list some?
  105. tmolitor sorry...I really have to go to bed....
  106. tmolitor let's continue tomorrow...
  107. Link Mauve I’d say Gajim, Pidgin, already.
  108. Link Mauve I have never looked at that.
  109. tmolitor could you send some image using xhtml-im and bits of binary then?
  110. Link Mauve I haven’t finished the implementation in poezio, sorry.
  111. bot RSS: Feeds for Gajim • Ticket #8135 ([RFE] Show file transfer requests in chat window) updated Yes, but there is more to this request: at the moment, interaction with the download is done through a separate dialog box. In addition, there is no thumbnailing of the file once received (see the Url image preview for an example of what I have in mind). https://trac.gajim.org/ticket/8135#comment:2
  112. arune Gajim only supports fetching bits of bin, so that's partial support
  113. arune And bob does not support my use case, the sender might not be online when the recipients wants the thumb
  114. arune That's why I want httpupload in the first place; asynchronous file transfers
  115. arune tmolitor: I'm perfectly fine with sending the data directly so that this works asynchronously and multi-resource
  116. arune 2kb might be to little for me but I will distribute a gajim package to my users and tweak that a bit
  117. johnny arune, what version are you using?
  118. arune johnny: version of what? Why?
  119. johnny of gajim
  120. arune johnny: nightly on Linux and 0.16 on windows
  121. arune tmolitor, nice hack reducing jpeg quality in steps :) I really like it
  122. arune it works great now, both for muc and with single-person chats
  123. arune the small-small changes I want are: 1. move the thumbnail size next to where you define max_thumbnail_size 2. send url instead of XHTML-IM if PIL/Pillow is not available (set a variable on except ImportError)
  124. arune then upload to the repos! :)
  125. bot RSS: Feeds for Gajim • Ticket #8139 (Gajim fails to minimize on startup) created Bug description When gajim is setup in "One window for everything" mode and you have a tab opened when you close it, it won't minimize on next startup, even with the option "show roster" sets to "never". Steps to reproduce In preferences, tell gajim to use "one window for everything". In preferences, tell gajim to "never" sho[…] https://trac.gajim.org/ticket/8139
  126. bot RSS: Feeds for Gajim • Changeset [15805:4a5f5f99d5db]: delete cache db when logs db doesn't exist. Anyway data will be wrong … […] https://trac.gajim.org/changeset/4a5f5f99d5dbd7de26e364b6c2410e95fde6bb0b • Ticket #8133 (Gajim fails to start on fresh configuration) closed fixed: In 4a5f5f99d5dbd7de26e364b6c2410e95fde6bb0b: delete cache […] https://trac.gajim.org/ticket/8133#comment:5
  127. tmolitor arune: 1. what do you mean by this? 2. that's exactly why there is a try-except around the thumbnail creation and the import...if the thumbnail creation fails for whatever reason a plain message containing only the link is sent...
  128. bot RSS: Feeds for Gajim • Ticket #8138 (Gajim asks for password for anonymous accounts) updated Upon pressing OK, I am getting the following programming error message. Traceback (most recent call last): File "/usr/share/gajim/src/dialogs.py", line 269, in on_okbutton_clicked self.ok_handler(passph, checked) File "/usr/share/gajim/src/gui_interface.py", line 730, in on_ok obj.conn.set_password(passphrase) File "/usr/share/gajim/sr[…] https://trac.gajim.org/ticket/8138#comment:1
  129. bot RSS: Feeds for Gajim • Ticket #8092 (Overrides ~/.config/gajim/config symlink) updated Yes, symlinks should always be treated as transparent imo, except for very special reasons. I as the user should have authority where I place the files and if I want a redirection. https://trac.gajim.org/ticket/8092#comment:4
  130. arune tmolitor, YAY an official XEP: http://xmpp.org/extensions/xep-0363.html
  131. arune tmolitor, 2. OK! good solution
  132. arune 1. at line 35 you have max_thumbnail_size = 2048, have another variable on the next line thumbnail_dimension = 160
  133. arune and use that :)
  134. bot RSS: Feeds for Gajim • Ticket #8112 (Conversations MUC image support) updated There is now an official XEP: ​XEP-0363: HTTP File Upload https://trac.gajim.org/ticket/8112#comment:10
  135. arune tmolitor, any news on repo access btw?
  136. tmolitor arune: 2. ah okay...that's easy :)
  137. tmolitor arune: no, I missed asterix yesterday...and he didn't show up here today I think...
  138. arune Yeah, didn't want to send a patch for that one 😉
  139. tmolitor arune: that would have been overkill :D
  140. arune Great timing to have the released XEP!
  141. tmolitor arune: yes, I updated the namespace and the manifest file to point at the new xep...
  142. arune Great ☺
  143. tmolitor I'll upload this version (0.2.7) as soon as I get upload rights :)
  144. arune Great! Available as zip? ☺
  145. tmolitor no, not yet...do you need it today? I thought I just wait till I get upload rights...
  146. arune I won't test tonight, it can wait ☺
  147. tmolitor arune: okay...good :)
  148. tmolitor do you want to test my image preview plugin?
  149. tmolitor not the merged one but the one I modified...
  150. arune Yes, sure!
  151. arune I won't test tonight though
  152. tmolitor okay...I'll send it to you via httpupload :)
  153. arune I guess doing the lookup on messages with just the URL in them is ok
  154. arune I would like some kind of message/progressbar/link until the image is displayed
  155. arune tmolitor: thx
  156. tmolitor arune: you have to overwrite url_image_preview.py with this file...
  157. tmolitor it uses a cache directory to cache the images...
  158. arune Cool, does it use gajims cache dir? Likely to also work on windows?
  159. tmolitor yes...sort of...I didn't know the different gajim paths when I wrote it, so I created a cache dir in the gajim data dir (beneath the plugin dir)...but that can easily be changed...
  160. tmolitor it shows a download indication (just some text indicating the file is downloaded)...
  161. tmolitor but it does not do head requests like your plugin and the image is not clickable....
  162. tmolitor asterix: did you receive my key yesterday? :)
  163. arune A text for indicating ongoing download is good!
  164. tmolitor arune: a progressbar would be even better ;)
  165. arune I supposed that if you're writing a message and there's an incoming image URL you don't want a progressbar popping up over everything
  166. tmolitor no...I'm thinking of an embedded progressbar...no extra window :)
  167. arune Then it's cool
  168. tmolitor arune: yeah ;)
  169. arune Night!
  170. tmolitor arune: gn8 :)