Gajim - 2016-10-09

  1. bot RSS: Feeds for Gajim Plugins • Ticket #145 (OTR leaks cleartext when using XHTML) created <message from='xxxxxxxxxx' to='xxxxxxxxxxxx' xml:lang='de' type='chat' id='386'> asd <html xmlns=''> asd <body xmlns=''>?OTR:AAIDAAAAAAEAAAABAAAAwKBYzRnXBpmvA2WtMapToeCp1aCqWp8Q+vyblAA7R/+meZP0i6if3pLIByBYzo67+B/5WxfCqfL+LsHvgQ4E[…]
  2. bot RSS: Feeds for Gajim Plugins • Changeset [971:c7c2e519ed63]: Fix leaking cleartext when using XHTML - Fixes #145 Fix leaking cleartext when using XHTML - Fixes #145 • Ticket #145 (OTR leaks cleartext when using XHTML) closed fixed: In 971:c7c2e519ed63: Fix leaking cleartext when using XHTML - Fixes #145
  3. pvoigt I have created a persistent room and would like to add members domain based. This turn out not to work and I have to add members by jabberID. My server is prosody. I am not sure, if this is a gajim or a prosody issue. Could anybody please give me a hint were to find information to narrow this down.
  4. lovetox_ what do you mean with domain based
  5. pvoigt I mean add a domain to the members list allowing all members of this domain to be member of the room.
  6. lovetox you should be able to do this
  7. lovetox do you mean you cant find the UI for it?
  8. lovetox or you did the setting and it doesnt work
  9. pvoigt lovetox, yeah, I did the setting and it didn't work.
  10. pvoigt Do you know, if prosood
  11. pvoigt prosody stores persistent room information including memberships anywhere in the file system?
  12. lovetox sorry i dont know, but i guess it would be better you ask this in the prosody room
  13. lovetox so what was the outcome?
  14. lovetox nobody could join
  15. lovetox or everyone could join?
  16. pvoigt Nobody could join, but as soon as I add those complaing members by JabberID via Gajim they could just join.
  17. pvoigt Do you know, if Prosody has a public MUC?
  18. lovetox
  19. pvoigt lovetox, did you get my last message?
  20. lovetox yes
  21. lovetox if it was that
  22. pvoigt lovetox, thanks anyway, will join the prosody room.
  23. lovetox ‎[01:43:09] ‎pvoigt‎: Do you know, if Prosody has a public MUC?
  24. pvoigt Yeah, thats what I mean and I got your answer - thanks.
  25. lovetox if you discover that gajim does something wrong here please report :)
  26. pvoigt I asked because I had meanwhile read your disconnect.
  27. lovetox different resource :D
  28. pvoigt lovetox, yes, I will do so.
  29. bot RSS: Feeds for Gajim • Ticket #8414 (Problems with receipt icons and emojis) updated what font do you have selected in gajim?
  30. bot RSS: Feeds for Gajim Plugins • Ticket #146 (Upload in OMEMO works, but image is not displayed) crea[…] • Ticket #144 (OMEMO plugin or its integration bug - no fingerprint exchange happens) updated Logger gajim.plugin_system.omemo level set to 10 04.10.2016 14:17:56 (D) gajim.plugin_system.omemo: Using fast cryptography 04.10.2016 14:18:01 (D) gajim.plugin_system.omemo: jabber.ru1 => Announce Support after Sign In[…][…]
  31. bot RSS: Feeds for Gajim Plugins • Ticket #146 (Upload in OMEMO works, but image is not displayed) updated you need the plugin url_image_preview. and set the configuration of the plugin to accept all under 10 MB
  32. Asterix tmolitor: tarball should be correctly built this night. Debian package too
  33. tmolitor asterix: great!!! thanks a lot!!
  34. Asterix let's wait tomorrow to see
  35. tmolitor :D
  36. lovetox Asterix do you have an idea, how to better implement MAM
  37. lovetox right now Gajim requests ALL Histroy ever on the frist connect
  38. lovetox this seems problematic in many ways
  39. Asterix mam as itself works well, doesn't it? maybe the only problematic thing is displying what we get via MAM in opened windows?
  40. lovetox yeah it works
  41. lovetox but if you start gajim after one month chatting on another client
  42. lovetox gajim is blocked for minutes
  43. Asterix we reqiest a lot of history on the first connection, yes. We could limit to a year or so. But afterthat, we request since last time
  44. lovetox yes, but im not having an idea how a UI for this should look like or work
  45. lovetox how can the user request more
  46. lovetox if he wants more than the limit
  47. lovetox a button in the history window?
  48. lovetox also smartphones display history in the chatwindow
  49. lovetox now people say do it also
  50. lovetox but im not so sure, if this is the best way for a desktop client
  51. lovetox also it seems not to be easy
  52. Asterix it is not for sure.
  53. Holger I can imagine it being hard to implement, but I think it would certainly be a desirable UI on the desktop as well.
  54. Asterix the only way to implement it would be showing a message in chat window (as we show when we get a FT request) saying "there is new messages downloaded from server, do you want to reload this window" and then we clean the chat window and show last X messages
  55. tmolitor well, we could display mam messages in opened windows if the timestamp of those messages is greater than the timestamp of the oldest message already displayed in the chat window...
  56. tmolitor and for the general fetching...isn't there a way to request only history since the last online time/last mam request?
  57. lovetox and if there is no last online?
  58. Asterix we already request since the last mam request
  59. tmolitor then request all...yes...that's not ideal...
  60. tmolitor asterix: okay...that's good :)
  61. tmolitor displaying incoming mam messages in open chat windows is on my todo list anyways ;)
  62. lovetox the problem is, when the user opens the chat window and the mam request is still running, we have no possibility to insert messages inbetween other messages, only at the end or at the start of a window
  63. lovetox we would have to tag each line with a message id
  64. Asterix displaying those after last displayed message is quite easy indeed (but we need to keep in a variable what is the time of the last displayed message)
  65. Asterix for the others ... good luck!
  66. lovetox make each line in a chatwindow like an object
  67. Asterix lovetox: tagging is the other option, yes, but quite a big memory overhead for a small addition IMHO
  68. lovetox but do we do something like that not already, because we have to set the received marker on the lines
  69. Asterix yes we have tags, but they are deleted when we get the ack IIRC
  70. Asterix we also have tags for LMC, but once again, only one or 2 per chat window (our last and contact's last)
  71. tmolitor asterix, lovetox: my idea was to store an associative array (or how this is called in python) mapping the timestamp of every printed conversation line to a textview marker...thus allowing to insert a new line at any timestamp....
  72. lovetox textview marker can have a name
  73. lovetox so just name it after the timestamp :)
  74. tmolitor okay...then do that...easy :)
  75. tmolitor but with some prefix for namespacing...
  76. tmolitor like "msgts_1234567"
  77. lovetox what do you mean by namespacing
  78. tmolitor well, if someone wants to add another feature giving the markers numeric names we could get a name clash...
  79. tmolitor if you prefix the timestamps used by mam with some unique string and the other implementation uses another unique string such clashes can never happen :)
  80. lovetox ok yes seems right
  81. lovetox after what is the message db sorted
  82. lovetox how does gajim know what message comes first
  83. lovetox only timestamp?
  84. lovetox hm yes seems enough
  85. tmolitor yes...there is no other way as the resolution of timestamps is only in seconds...
  86. tmolitor you could only try to compare the text of already displayed messages with the messages coming from mam and that are BEFORE our message in question and derive the message position from that...
  87. tmolitor rather complicated and seldom of use I requires a connection drop between two messages send in the same second to be used...
  88. lovetox but what timestamp do we use
  89. lovetox the one we received the message?
  90. lovetox or the one provided in the message
  91. tmolitor the one in the message (delay tag) or the time we receive the message if that is not available...
  92. lovetox so if someone would send us a messag with a delay tag, he could insert history?
  93. tmolitor well...that's already the case...if you close the chat window and reopen it I would guess such a insertion takes place, too...
  94. lovetox but there has to be a mechanism to not allow that
  95. lovetox or can only the server add an delay tag
  96. lovetox ?
  97. lovetox i think i have to read :)
  98. Holger No, clients can and should add delay tags as well.
  99. tmolitor no...clients cann add those delay tags as well...
  100. tmolitor yes...
  101. tmolitor well...why would you want such a mechanism?
  102. lovetox Therefore, a recipient SHOULD NOT rely on delayed delivery notations to provide a completely accurate representation of the delivery path or timing of a stanza it has received.
  103. lovetox so on what should we rely to put messages in correct order
  104. tmolitor is that from the XEP?
  105. lovetox yes
  106. tmolitor well...I don't know...I would use the delay tag...maybe add a tooltip stating when the message was received actually...
  107. tmolitor that would provide both informations for users and adding a second field to db containing the received timestamp would be trivial...
  108. lovetox why shoud i allow a client to add an delay tag? my server is always online and reachable, for me the server gets a message is the correct time
  109. lovetox only my server should communicate that time to me
  110. tmolitor well...conversations adds a delay tag if you write a message while you are not connected for example...
  111. lovetox the server is always connected
  112. lovetox why not let him add a delay tag?
  113. tmolitor and on my server I have a prosody plugin running which adds a delay tag to every message not having one...
  114. Holger lovetox: Because the server doesn't know the time the message was written?
  115. tmolitor holge, lovetox: yes..see my conversations example above...
  116. lovetox are you refering to the seconds it needs to transfer?
  117. lovetox writen was the message when the server received it minus 2 seconds
  118. lovetox when is that not true?
  119. tmolitor no, you can write a message while not connected...
  120. Holger lovetox: The message might have been written a long time before it reaches the server.
  121. tmolitor for example because your phone is offline at time of writing...and only goes online again several minutes later...
  122. lovetox this information is rather useless, when someone written something, when i didnt receive it at that time
  123. lovetox but ok
  124. lovetox so let the user add this information
  125. lovetox but this should not overwrite the time my server got the message
  126. Holger lovetox: Imagine you ask me a number of questions and later receive a response with this content: "Yes."
  127. lovetox ok i get the use case
  128. Holger lovetox: The timestamp added by my client might help matching this response with the question I was referring to.
  129. lovetox it might, but only if you have another timestamp to choose from
  130. lovetox if its the ONLY timestamp
  131. lovetox thats bad
  132. lovetox so how do we decide order?
  133. Holger Yes you cannot blindly trust other client's timestamps so these issues aren't trivial.
  134. lovetox my contact decideds the order?
  135. tmolitor you always have a second timestamp available: the one corresponding to the time when your client received the message...
  136. lovetox no tmolitor
  137. lovetox that timestamp is also useless
  138. lovetox because with one client im online
  139. tmolitor why that?
  140. lovetox with another 2 weeks later
  141. lovetox same message two received timestamps
  142. tmolitor well...the other has to use the timestamp from mam...which is the server timestamp...
  143. lovetox so mam adds a timestamp?
  144. Holger Yes.
  145. lovetox thats thats something
  146. tmolitor's the time the server received the message...
  147. lovetox i would like the server add such a timestamp to every message :)
  148. lovetox but ok i guess its not so bad hten
  149. tmolitor lovetox: I've written a prosody module to do exactly that...
  150. Holger "The <result/> element contains a <forwarded/> element which SHOULD contain the original message as it was received, and SHOULD also contain a <delay/> element". --
  151. Holger tmolitor: So that *adds* a delay tag to existing tags?
  152. tmolitor holger: yes, if there is not already a delay tag present...
  153. Holger Ah, I see.
  154. lovetox thats not how i read it
  155. Holger I'm not sure whether all clients cope with multiple delay tags (though I think they should).
  156. Holger lovetox: I think the XEP is unclear on that.
  157. lovetox would a client added delay tag not be inside the message tag?
  158. lovetox and the xep states it has to be child of forwarded
  159. Holger lovetox: Yes, we're talking about different cases. There's no conflict when the server just adds a tag to the wrapped MAM message.
  160. Holger But there is in other cases.
  161. Holger
  162. lovetox ah you mean the not MAM case
  163. Holger Yup.
  164. tmolitor holger: my module only adds a delay tag to the message if there is not already one present...
  165. Holger Right, I see.
  166. tmolitor you could use the received timestamp or the timestamp of the forwarded element in the mam case for the received timestamp and the delay tag of the message or the received timestamp for the written timestamp...
  167. lovetox still a message written offline, should not be inserted into history, it should be inserted on the server received time, and client could make it visible that the message was written in response to some timestamp
  168. lovetox though we dont have a server received time on normal messages, which sucks
  169. lovetox for a chat protocol so old, i thought this elemental issue was more clear
  170. lovetox though we could treat all normal messages that add a delay tag, with the client received time
  171. lovetox and hint in some way that it was written before
  172. lovetox i wonder how that would look, and how often this happens in a way that the history would look weird
  173. tmolitor lovetox: you could use the timestamp classification I wrote earlier and use the received timestamp of this classification as insertion time and the written timestamp of this classification for the timestamp displayed in the chat window...
  174. tmolitor that's what I would do...
  175. tmolitor holger: here is the module for prosody :)
  176. tmolitor
  177. tmolitor lovetox, holger: what do you think?
  178. lovetox about the timestamp issue?
  179. tmolitor yes
  180. lovetox hm, yes in my opinion we should do what the xep says and SHOULD NOT rely on the delay tag a client added
  181. lovetox so we could place such messages somewhere in the chat
  182. lovetox but i would make it to the user visible
  183. tmolitor ‎[23:22:32] ‎[23:27:29] this two messages I wrote...
  184. lovetox that its possibly not the correct position
  185. tmolitor that's exactly that I think...
  186. lovetox i just cant judge if this would be a breaking expierience, how often does this regulary happen that clients have to add delay tags?
  187. lovetox would that hint be once every 100 messages
  188. lovetox or once every 10
  189. tmolitor I don't know...
  190. Holger tmolitor, lovetox: Conversations doesn't just display the <delay/> timestamp but also trusts it for ordering.
  191. tmolitor but when you use one timestamp for insertion an another as displayed timestamp it is relatively clear what happened fot the user...
  192. Holger Personally I'd definitely display the (oldest) <delay/> timestamp but am unsure about ordering.
  193. lovetox yeah i think the ordering is not soo important here
  194. Holger tmolitor: And yes, nice module. I thought about having the server add a timestamp to every message myself.
  195. lovetox as long as the user is aware
  196. lovetox of course the ordering should make sense in most of the cases
  197. Holger lovetox: Regarding your question, I don't have numbers of course but I think it's quite common for mobile users.
  198. Holger As it's quite common for them to be offline for a few minutes.
  199. lovetox tmolitor
  200. lovetox regarding mam
  201. lovetox we should just save the unique stanza id , the server adds to every MAM message
  202. lovetox so we can never get doubles