Gajim - 2016-09-11

  1. bot RSS: Feeds for Gajim • Ticket #8163 (Support XEP-0333: Chat Markers) updated Would like to see this too. • Ticket #8207 (Display a lock icon next to each encrypted message) updated I agree with this proposed change.
  2. stefano Hi, Know somebody how uptodate the XEP supportlist is?
  3. lovetox pretty much
  4. lovetox uptodate
  5. lovetox why, for what xep are you searching stefano?
  6. lovetox httpupload xep is missing
  7. lovetox and omemo xep
  8. stefano Thank you lovetox‎. Nothing sepecial. I just try to get an overview over XMPP and XEP. Just the list of official extensions [1] doesn't help much if they are nowhere implemented. [1]:
  9. bot RSS: Feeds for Gajim • GajimXEPSupport edited add httpupload and omemo (diff)
  10. lovetox yeah xmpp council just makes the standards, no one is forced to implement them
  11. lovetox but gajim is probably one of the clients that implement the most
  12. lovetox not xeps make sense to implement
  13. lovetox some xeps are 15 years old
  14. lovetox and just make no sense today anymore
  15. stefano I understand.
  16. q55 hello guys, couldn't stay online and read your answers. I'm going to ask again: is there a way to have Gajim accept file transfers automatically? People sending me pics or voice recordings from Conversations expect me to receive them while they see my client online
  17. lovetox why arent they using http upload?
  18. lovetox does their server not support it?
  19. lovetox i dont see a option for it to accept file transfers automatically
  20. lovetox but if the server of your contact supports http upload, you will not have that problem anymore
  21. lovetox q55
  22. own hm
  23. own i cant find tha serv owner
  24. own lovetox: can y send bot to may muc !
  25. lovetox no i cant
  26. own lovetox: who cant
  27. lovetox why do you need a bot in the channel?
  28. own lovetox: tha sime why that its need here
  29. lovetox to post commits from gajim trac?
  30. lovetox what are you talking about
  31. q55 lovetox, not all the servers out there provide http upload
  32. lovetox i know, thats why i asked :)
  33. lovetox but it would solve your problem
  34. lovetox maybe you can talk to the server admin
  35. own lovetox: what is id
  36. lovetox id?
  37. q55 lovetox: that is not a very "private" solution unless you run your own http server as well and host stuff at your place, I wil think about doing that in the future. Right now what would really help is an automatic acceptance of incoming file transfers
  38. lovetox thats why you encrypt the files
  39. lovetox i write it to the list, but i wouldnt count on seeing that feature soon
  40. q55 lovetox, you're right. I think OTR may have a problem and I don't use OMEMO in Gajim yet. I have to ask my friends to actually disable OTR everytime they send me anything from Conversations or I won't be able to read it
  41. lovetox otr doesnt support file transfer
  42. lovetox why you dont switch to OMEMO
  43. lovetox otr is bad in so many ways
  44. own lovetox: hi can y give me tha owner jid
  45. lovetox i dont have it
  46. lovetox he comes here from time to time
  47. own oky sory
  48. q55 I think OTR is good and most people still use it. I will enable OMEMO for MUC encryption and if that could help with file transfers too then awesome, but my problem would still exist. Would changing only my XMPP address to one that supports HTTP Upload do the trick? I can't ask people to switch to a different server
  49. q55 I think OTR is good and most people still use it. I will enable OMEMO for MUC encryption and if that could help with file transfers too then awesome, but my problem would still exist. Would changing only my XMPP address to one that supports HTTP Upload do the trick? I can't ask people to switch to a different server
  50. own q55: use a transpotr to talk to them
  51. q55 sorry if I sent a double message
  52. q55 own, I don't understand
  53. lovetox q55: you can talk to the server admin
  54. lovetox and tell him he should install httpupload
  55. q55 lovetox, on my side or on the senders' sides?
  56. lovetox no the one who sends the file needs http upload
  57. lovetox receiver needs nothing
  58. lovetox because the file is just a link to a httpserver
  59. lovetox and OTR is not good, it doesnt support multiple devices, has not way of transfering files, no MUC support
  60. lovetox all it can do is, send one message from one device to another
  61. q55 that's the point, all my contacts would have to do me the favour of changing their service. IM+ creates a HTML link even if your XMPP server doesn't offer HTTP Upload support by the way, so there are client-side solutions. I stick with my original request, an automatic acceptance would help me most
  62. lovetox but only if both are online at the same time
  63. lovetox q55 why would they have to change their service if you talk to the server admin?!
  64. q55 lovetox, from a security perspective I think it's safer than OMEMO but for everyday usage of course its "drawbacks" are huge. It wasn't meant to be used asynchronously and the key has to be ephimeral and disposable.. multiple devices of course threaten this security scenario but are handy. OMEMO is good for all that
  65. q55 lovetox, they are MANY people, I can't start a campaign for all the servers they use
  66. lovetox you should not start a campaign
  67. lovetox you should write one email
  68. tmolitor im+ is transfers all your conversations through their servers and stores your xmpp account's password on their servers, too...
  69. lovetox and how does im+ provide a http link if it doesnt upload the file to their server?!
  70. q55 lovetox, doesn't mean they will implement a HTTP Upload instance for me. That's why my original request still makes more sense in this situation. But I appreciate your effort to provide an alternative solution too
  71. q55 tmolitor, totally true. Not sure about the password
  72. bot RSS: Feeds for Gajim Plugins • Changeset [958:e65f662864ef]: Increased version number in manif[] • Changeset [959:ca88aaace650]: Small bugfix for windows users and fixed some demandimport errors. … Small bug[…] • Ticket #137 (Previews are not clickable since the latest version) closed […]
  73. tmolitor q55: but I'm sure ;)
  74. q55 lovetox, they do in fact. I believe it could be good to draw inspiration from them, like you can have your own client-configurated HTTP Upload hosting destination..
  75. q55 tmolitor, that's horrible news then
  76. tmolitor and yes, lovetox is right...they provide the http link because they sniff the conversation, automatically accept file transfers and offer the transfered files on their http server so that the im+ clients can download it from there (because the clients don't implement jingle file transfer etc.)...
  77. tmolitor q55: they have to, because they did a reconnect when the connection was dropped even though the mobile phone was without power...
  78. tmolitor (my girlfriend had to use im+ for some time when she had a windows phone :( )
  79. lovetox and why do you think OTR is more secure? OMEMO is based on the same encryption technics
  80. q55 tmolitor, I dislike their service and policy. I can't complain about how handy it is but it doesn't make it really more private than whatsapp so what's the point in using XMPP other than mobile-to-desktop IMing?
  81. q55 lovetox, it's an interesting topic I will discuss when I know more facts to support my theory
  82. lovetox for your feature request please write a small feature request on trac
  83. lovetox
  84. q55 sure, I will. Thanks
  85. q55 lovetox, by the way the real risk in OMEMO if you want to know what I'm talking about is that it allegedly makes it possible to derive all the conversations keys from one point in history like with PGP. So you crack one key and you can decrypt all the following conversations. That's what seems to be the main flaw as opposed to OTR which makes every session completely independent (and offline-incapable)
  86. lovetox but thats not true
  87. lovetox OMEMO has forward secrecy
  88. lovetox like OTR
  89. q55 that's what is being discussed, I'm not a security expert
  90. lovetox where is this beeing discussed?
  91. q55 many agree with you anyway
  92. linus lovetox: it's not forward secrecy if compromising a key allows decrypting *future* conversations
  93. lovetox it doesnt
  94. lovetox if you are talking about the root key
  95. lovetox if that is compromised then also OTR can be decrypted
  96. linus What you need to do, with OTR as with OMEMO and with any other encryption scheme, is untrust any keys that have been compromised
  97. q55 lovetox, it seems the "double-rachet" design is what needs to be understood before we can believe in the reality of OMEMO forward-secrecy
  98. lovetox OTR uses the same design
  99. lovetox axolotl, signal, omemo
  100. lovetox how ever you will call it
  101. lovetox its based on OTR
  102. q55
  103. lovetox what about that article?
  104. lovetox it only trys to decribe on a basic level how it works
  105. lovetox i doesnt in any way, talk about flaws with the design
  106. q55 lovetox, I know I know. I was just linking for reference. The discussions I mentioned are with people in real life so I can't link to them ;)
  107. lovetox the design has been audited
  108. lovetox
  109. lovetox the truth is, you can only believe, because i dont think you are going to study that article
  110. q55 I'm going to read it and compare it to the other reports for OTR, that is a good resource for me!
  111. q55 thanks for linking it
  112. de-facto lovetox about file transfers over jingle: is it planed to support :4 of JingleFT so files sent from Conversations can be received in Gajim? I think right now only :3 is supported in Gajim...
  113. linus Jingle FT isn't being maintained
  114. de-facto oh how come? i thought its the only way for transmitting files when no http upload is avail
  115. de-facto (which is the case with many servers nowerdays...)
  116. linus It is, but nobody who has the skills to maintain it finds it useful enough to do so, it seems
  117. de-facto hmm sad to hear that
  118. linus I'd do it but I have HTTP upload working and limited time available :/
  119. de-facto on my own server i have http upload too, but it seems the big servers arent supporting http upload for some reason (maybe too much traffic?)
  120. q55 de-facto, can't you receive Conversations files in Gajim? I can..
  121. linus Traffic and storage space
  122. de-facto q55 are you sure? without http uploads?
  123. q55 de-facto, sure!
  124. q55 without http uploads, I use it daily for pics and voice messages
  125. de-facto send a file from latest Conversations and receive it with Gajim? it wouldnt start transfering for me
  126. q55 I use Gajim nightly builds, and it works
  127. q55 I can also send to them
  128. q55 if lingers for a few seconds because, I think I read it somewhere, Conversations waits for a few seconds for a file proxy negotiation that doesn't happen on the Gajim side. Don't even know what that would entails but I know Pidgin still uses proxies for file transfers
  129. de-facto hmm interessting, just tried it with my own server (disabled http upload) and indeed it sits there for some seconds then starts transfering
  130. de-facto for some reason thats not the case for some big servers though
  131. de-facto have to look at a console when trying that next time
  132. de-facto could it be that it uses some extra port or something like that?
  133. de-facto it should use proxy of the xmpp server if both are behind a NAT, right?
  134. linus How are you running an XMPP server behind a NAT..?
  135. mathieui well, you do port forwarding and it just works
  136. linus But that doesn't involve a proxy
  137. de-facto not the server both the clients
  138. tmolitor linus: no, just port forwarding in your router :)
  139. linus And what's the proxy of the XMPP server?h
  140. linus You mean in-band transfer?
  141. tmolitor linus: no
  142. de-facto for my server its proxy56 on prosody
  143. de-facto for the big server it wouldnt work its something similar on ejabberd
  144. tmolitor the proxy is the socks proxy implemented in some xmpp servers...
  145. linus Ah right
  146. linus Didn't know that was a thibg
  147. tmolitor de-facto: yes, exactly :)
  148. de-facto just trying to find out why i cant receive files send from Conversations to my Gajim when im using
  149. de-facto it supports everything from compliance tester for conversations except XEP-357 (Push notifications) and XEP-363 (HTTP upload)
  150. de-facto though it seems it passes XEP-65 (SOCKS5 Bytestreams)
  151. q55 linus, I did for a long time with port-forwarding. Maybe not the best solution but very DIY and affordable ;)
  152. linus Yeah I get that, just didn't get how it was related to proxies, having misunderstood
  153. linus "it should use proxy of the xmpp server if both are behind a NAT, right?" I thought "both" referred to the client and the server here, not the two clients
  154. tmolitor linus:, it refers to the two clients...
  155. linus Yeah I figured that out eventually :)
  156. q55 if two clients are behind a NAT and don't have a public IP they can still use XMPP regularly. They will have a hard time with Jingle if neither has a public IP, like in the worst scenario. I'm having problems at the moment myself with Jitsi and other people behind a NAT from a provider which doesn't offer unhindered access to the Internet
  157. q55 I'm having problems myself* with Jitsi
  158. linus Yeah. Learnt about all this when I was trying to get SIP working to talk to people... :|
  159. q55 so this may affect file transfers too, de-facto
  160. q55 linus, I think that's when STUN servers and alike technologies come in handy but I still have to learn how to use them
  161. q55 technologies alike* / excuse my English
  162. linus STUN is just for finding a public address basically
  163. de-facto well that wont help if ports cant be forwarded
  164. de-facto many ppl dont know how to do that or simply cant (e.g. because of mobile providers)
  165. q55 linus, does that mean that if there is no *public* address it won't retrieve one for the user?
  166. linus q55, if it has internet access then it has some sort of public IP address
  167. linus Shared, in case of a NAT
  168. de-facto usually cell phone mobile providers implement the NAT themselves in their infrastructure
  169. de-facto e.g. your phone gets a private ip address assigned from the APN which differs from the one it is visible in the internet
  170. linus Of course it differs, but the one visible in the internet still exists
  171. de-facto hence its impossible to open ports in such a scenario
  172. linus And STUN is there so the device can find out what it is
  173. de-facto yes
  174. linus It's still possible in some sense, because otherwise you wouldn't be able to get any data from the internet
  175. q55 linus, wouldn't still be problematic though? How to get something sent to you without help from the ISP that knows how to route packets back to your actuall behind-NAT IP address?
  176. de-facto i guess only for connections initiated from the mobile device itself then
  177. linus Exactly
  178. linus But, well, UDP for instance is connectionlrss
  179. q55 de-facto, I'm confused. What's the difference?
  180. linus But a phone still needs to be able to receive replies if it sends UDP packets
  181. linus So the NAT router, when it sees the phone sending UDP packets from port x, forwards them out on port y (which may or may not be the same as port x) and sends incoming packets on port y to the phone's port x
  182. linus As I understand it that's how NAT usually works with UDP
  183. tmolitor linus: yes, that's how it works :)
  184. linus Similarly with TCP except that the router can make more assumptions thanks to the statefulness and 1-1 nature of TCP connections
  185. de-facto i thought xmpp uses bidirectional TCP streams initiated from the devices themselves
  186. linus Yes, XMPP
  187. linus But STUN has nothing to do with XMPP in and of itself
  188. linus Nor do peer-to-peer connections
  189. linus Anyway, STUN is there to allow a phone to discover what the address and port that its packets come from is
  190. de-facto well but if both are behind a NAT i thought there is no way to directly peer to peer with TCP
  191. linus So that peer to peer connections can be established
  192. linus That's correct, unless you have magic like uPnP
  193. de-facto well nothing like that exists for the mobile providers afaik
  194. linus That, I believe, is also correct
  195. linus Hence yay TURN relays or SOCKS proxied
  196. de-facto yes i think SOCKS is the only way on then
  197. de-facto worked from both clients behind NAT Conversations <-> Conversations (very slow) but not Conversations -> Gajim
  198. de-facto any idea how to investigate where it hangs then?
  199. linus Look at the XML console
  200. linus Beyond that, I don't really know. I haven't looked at gajim's jingle code so I don't know how thorough the logging is there, but it could be helpful maybe