Gajim - 2018-05-29

  1. bot Link Mauve created an issue in _gajim_ < >: #9152: < Gajim aborts on load if gnome-keyring isn’t launched >
  2. bot xekon modified an issue in _gajim_ < >: #9146: < zeroconf bonjour local not displaying linux user name correctly on windows roster. link-local messaging >
  3. lovetox thanks Daniel
  4. lovetox pep. rational is, we support this for years and no other client did implement it, it needs a session management per resource which is complicated and error prone, the encryption itself does not fit current needs anymore (MAM, Offline Messages, Carbons)
  5. lovetox we have soon 3 other encryption methods which do not have these drawbacks (omemo, pgp, openpgp)
  6. lovetox and because this was implemented deep in gajim core, the whole thing stops gajim from evolving because you always have to check if esession still works
  7. lovetox there are also other reasons like, never audited crypto code, because no other client uses this we dont have any indication if we do this correctly
  8. Neustradamus lovetox: have you seen for the XMPP icon?
  9. lovetox no
  10. bot André updated a merge request for _gajim/master_ < >: Add support for flatpak extensions
  11. bot André updated a merge request for _gajim/master_ < >: Add release notes and content rating information to appdata
  12. bot André updated a merge request for _gajim/master_ < >: Add release and content rating information to appdata
  13. bot Philipp Hörist pushed 1 commit to branch _refs/heads/master_ of _gajim_ < >: *3f2d4e50* < > Add release notes and content rating information to appdata
  14. bot Philipp Hörist merged a merge request for _gajim/master_ < >: Add release and content rating information to appdata
  15. bot Philipp Hörist updated a merge request for _gajim/master_ < >: Add support for flatpak extensions
  16. bot Philipp Hörist pushed 1 commit to branch _refs/heads/master_ of _gajim_ < >: *5e712768* < > Add support for flatpak extensions
  17. bot Philipp Hörist merged a merge request for _gajim/master_ < >: Add support for flatpak extensions
  18. bot Директор Завода created an issue in _gajim_ < >: #9153: < delete contakt >
  19. bot Daniel closed an issue in _gajim_ < >: #9153: < delete contakt >
  20. debacle Backtrace nach "/invite (irgendein JID)" im MUC:
  21. debacle
  22. concerto I just got a message in Gajim that I'm "banned from joining X room".
  23. lovetox ja wäre interessant was die xml console sagt
  24. lovetox anscheinend kein from attr am invite
  25. concerto It'd be nice if it said which account (perhaps only when one has multiple active accounts - which I, in this case, did), and displayed the title of the room in addition to the address (Conversations is fond of making human-unreadable MUC addresses...)
  26. lovetox
  27. lovetox still would need ideas how to display this
  28. lovetox title big, jid small, or the otherway around
  29. Daniel I'd prefer title big, jid small. It's like a nickname, the one you'd like to be displayed (more prominent) instead of contact's jid
  30. concerto lovetox: should I create a ticket for the rest?
  31. lovetox what rest?
  32. lovetox the account?
  33. lovetox yeah why not
  34. concerto Oh, I forgot to add that I wasn't banned from the room, the room had merely been destroyed (I was the admin from another account). So it'd be nice if the message was more accurate about that.
  35. lovetox to add where?
  36. lovetox i dont see anything about beeing banned from somewhere
  37. concerto > I just got a message in Gajim that I'm "banned from joining X room".
  38. concerto > I just got a message in Gajim that I'm "banned from joining X room". > It'd be nice if it said which account (perhaps only when one has multiple active accounts - which I, in this case, did), and displayed the title of the room in addition to the address (Conversations is fond of making human-unreadable MUC addresses...) (was the first line not received?)
  39. lovetox no
  40. lovetox uf a room doesnt exist you get a different message normally
  41. lovetox the server most likely issued a <forbidden/> error
  42. lovetox which by the XEP: Inform user that he or she is banned from the room
  43. concerto lovetox: hm...since I don't know which account received the banned error, can I figure it out from Gajim's logs? I searched for "forbidden", but didn't find anything (other than your messages here)...what should I search for?
  44. lovetox no we dont log that
  45. lovetox you dont know anymore which room you wanted to join?
  46. lovetox its probably in your bookmarks?
  47. concerto I do
  48. concerto Oh, yeah, it's the MUC server that is to blame.
  49. concerto Oh, yeah, it would be the MUC server that is to blame.
  50. concerto Thanks, lovetox
  51. lovetox then just try to join it again
  52. lovetox and post me what the xml console says
  53. concerto Now it says I'm not in the members list o_o'
  54. concerto
  55. lovetox someone has to add you to the memberlist
  56. concerto lovetox: this account _was_ in the memberlist, but as I said, another of my accounts was the admin, and I deleted the room.
  57. concerto So it should say the room was deleted, instead of giving member list or banned errors, right? o.o
  58. lovetox seems its not really destroyed
  59. lovetox try to join with your other account
  60. concerto lovetox: now I just can't join, the "Join Group Chat" dialog says "invalid character in nickname" ._.'
  61. concerto lovetox: now I just can't join with the admin account, the "Join Group Chat" dialog says "invalid character in nickname" ._.'
  62. debacle Which version targets master at the moment? `1.1`?
  63. Link Mauve debacle, yes.
  64. pep. lovetox, did you get my comment on the ESessions commit?
  65. debacle Back to the exception some hours ago. In the public MUC ``, the `/invite` command leads to a backtrace in 1.0.3. Can others confirm that?
  66. debacle I have this backtrace in some MUCs, in most not.
  67. debacle thanks, Link Mauve. I will use 1.1 as Debian package version for "experimental", while following 1.0.x in unstable etc.
  68. Daniel pep. He already replied ;)
  69. pep. hmm, I didn't get notified
  70. pep. Daniel, sorry I must be blind can you point to his comment?
  71. pep. Ah, here on the channel..
  72. Daniel
  73. pep. There are also advantages to ESessions, and we're having issues with OMEMO ESessions doesn't have, not just body is encrypted for example, that is only just being addressed in OX (still a few things to figure out). It's not just *a* container in a message, the whole session is encrypted which has its own use-case.
  74. pep. I agree no other client is implementing it and we should have pushed that way maybe
  75. pep. It's really sad to see this going for the benefit of lesser protocols
  76. lovetox pep., its resource based, this is a no-go today
  77. lovetox like OTR
  78. lovetox and stanza encryption you can have with any encryption, its not dependend on anything the encryption protocol specifies
  79. pep. I don't think the comparison stands with OTR, that's really not the main reason we're pushing it away
  80. pep. lovetox, not saying it's perfect
  81. pep. In fact I don't know much about it, just the baseline, but I know it fixes issues we have with OMEMO
  82. pep. So maybe it was worth trying to improve
  83. lovetox no, because it had no offline message capabilities
  84. lovetox to fix that you would have to touch the encryption itself
  85. lovetox and then you would arrive at signal protocol
  86. pep. OMEMO != signal
  87. pep. I'm not saying the signal encryption is bad
  88. lovetox its all the same pep, esessions, otr, signal
  89. lovetox one more advanced than the other
  90. pep. omemo is not signal as I said above, please be careful with that
  91. pep. omemo uses signal
  92. lovetox i didnt mention omemo once since we talk
  93. lovetox Oo
  94. pep. well then signal doesn't stand on the same level as otr nor esessions
  95. pep. Not sure why you mention it
  96. lovetox im talking about the encryption not the transport protocol
  97. pep. Right, not me
  98. pep. I care about the transport here
  99. lovetox and the encryption that esessions uses sucks
  100. pep. That can be changed
  101. lovetox because it is neither available in a lib, nor ever audited, nor does it have feautres that are necessary today
  102. lovetox no it can not be changed
  103. pep. why?
  104. lovetox it makes no sense, every further development of the esessions encryption would lead either to a copy of OTR or signal
  105. lovetox you will not invent a new encryption scheme, nobody has thought of yet
  106. lovetox this is all already here
  107. pep. Why do you want to invent one, you could make esessions use signal, where's the issue
  108. pep. And no it's not already there
  109. lovetox what about esessions do you like so much?
  110. lovetox negotiation?
  111. lovetox nobody wants to do that
  112. lovetox stanza encryption?
  113. lovetox everyone can do that
  114. pep. OMEMO doesn't. OX doesn't.
  115. pep. OTR doesn't.
  116. lovetox yes because nobody writes the sentence into the XEP
  117. lovetox so why do you think anyone would write it into esessions?
  118. lovetox also OX does full stanza encryption, at least i do it with my plugin
  119. lovetox sorry esessions has it already ^^
  120. lovetox but big changes need to be done to the xep, much bigger ones than have to be done to omemo
  121. pep. esessions is much more than just an encrypted container inside a <message>
  122. pep. iiuc
  123. lovetox yes i know, nice idea
  124. lovetox how many xeps do you know where we negotiate something between clients that are wide adopted?
  125. lovetox jingle?
  126. pep. yeah
  127. lovetox everything with negotiation is complicated doesnt work offline
  128. lovetox in a federated env like xmpp, i think something like that will not catch on
  129. pep. I don't think it wouldn't be impossible to handle that
  130. pep. The fact that sessions are currently negociated between resources is annoying but I'm sure that can also be changed
  131. lovetox really why would you invest so much time in that, and not in a xep thats already adopted
  132. lovetox you have to change the entire xep
  133. pep. I'm sure there is something to be done with this, maybe evolve it into something better, or take the ideas for OX, instead of just encrypting _some_ of the stanza
  134. lovetox im all for that, learn, take the good parts
  135. pep. This one is not on my priority list, but yes I'd invest time to get rid of OMEMO and the way it's polluting other XEPs atm, "because only body is encrypted we must put everything in it", and esessions' ideas seem better for privacy in general
  136. lovetox really daniel said multiple times for me he is all for encrypting stanzas
  137. pep. I know we talked about it
  138. pep. Still that's the current state of affairs
  139. pep. I hope to implement OX after I'm done with OMEMO in poezio (really lumi is doing all the work :p)
  140. lumi pep.: well it's a bit on hold now as i'm doing other things, but yes i am helping :D
  141. Link Mauve pep., I already have half of it done, the part which is not shared with OMEMO.
  142. lovetox pep. why do you think stanza encryption xep-200 is better than what OX does?
  143. lovetox it looks much the same to me
  144. lovetox bascially everything inside <message> is encrypted with a few exceptions
  145. debacle Now that Gajim (master) supports MUC avatars - why doesn't this MUC have an avatar? Missing server support?
  146. lovetox yes
  147. lovetox and about the invite error
  148. lovetox i need the xml stanza that triggers the error
  149. Daniel Hm didn't Link Mauve say something about a prosody module supporting MUC avatars? :)
  150. Link Mauve Yes.
  151. debacle lovetox, I just tried again with the same MUC, but it did not lead to an error, but I'm on Gajim master now instead of 1.0.x. Same nbxmpp though.
  152. lovetox this has nothing to do with it
  153. lovetox it seems under some circumstances we get a invitation without a from attr
  154. lovetox thats why gajim complains
  155. debacle OK. I'll try to catch the stanza, but don't hold your breath :~)
  156. Link Mauve Daniel, today I’ve been adding some to our MUCs at JabberFR, the introduction page looks way nicer:
  157. pep. lovetox, hmm, ok it seems I was picturing stanza encryption (200) differently. There only seems to be profiles for <signcrypt/> for <message/> though atm and not other stanzas like 200
  158. debacle Link Mauve, mod_vcard_muc ?
  159. Link Mauve debacle, mod_vcard for now.
  160. Link Mauve I’m thinking about an alternative (supplementary) way to advertise MUC avatars, through the muc#roominfo FORM_TYPE.
  161. debacle I see mod_vcard_muc in the prosody modules, but not mod_vcard.
  162. Link Mauve The one you get when you disco#info a MUC, to let you know the avatar before you even join the room.
  163. pep. debacle, it's in the prosody repo
  164. pep. not modules
  165. debacle I see!
  166. Daniel Link Mauve that's nice! Hope this room is catching up soon :)