Gajim - 2019-03-17


  1. RonUL_ lovetox, thanks
  2. bot Daniel Brötzmann created an issue in _gajim_ < https://dev.gajim.org/gajim/gajim/issues/9623 >: #9623: < 'NoneType' object has no attribute 'get_index' in Start New Chat dialog >
  3. ivucica Hello hello! A modest request: maybe "Unable to join groupchat - service-unavailable" dialog (and other error messages) could, maybe, not be modal and block user interactions when they show up?
  4. ivucica I just had an error loop on Windows where I couldn't 1) open XML console 2) even QUIT gajim when this happened
  5. ivucica Also, the error doesn't even tell you which group chat Gajim failed to join.
  6. ivucica So, uh, having to go to task manager because Gajim is not even in the systray and is in an error loop trying to join a chat repeatedly just to be told it can't... yeah, that seems bad?
  7. lovetox most bugs are, did you cam out of standby?
  8. lovetox i experienced this one but never again
  9. mikaela I have similar on Debian coming out of hibernation, but for invalid jid or something. The groupchat not being named is open enchanchement.
  10. ivucica >‎[1:17:29 PM] ‎<lovetox‎> most bugs are, did you cam out of standby? >‎[1:17:38 PM] ‎<lovetox‎> i experienced this one but never again yes
  11. maltel In the fingerprint window of the omemo plugin the "red option" for trust is called "not trusted". However, internally, "untrusted" is used in most places (see in particular backend/util.py:32). I think that "not trusted" is confusing, because I would think that that referred to all trust levels except "trusted". So I would be in favor of changing this and I could put together a merge request if that is ok.
  12. maltel The reason I think about this is that I am working on a separate change where I want to make the lock icon be in another color if the key the message was received from is not "trusted" and the tooltip should then probably also include this information, perhaps as "(not trusted)" after the fingerprint. But this would be confusing with the current terminology.
  13. lovetox > think that "not trusted" is confusing, because I would think that that referred to all trust levels except "trusted" im not quite getting that sentence
  14. lovetox you see a fingerprint and it says "Not Trusted"
  15. lovetox pretty clear to me what it means
  16. lovetox what term do other applications use?
  17. maltel I parse that as "it is not 'trusted'", so if there are three levels, 0,1 and 2 and 1 is called "trusted", then by "not trusted" I would assume it could also be meant to refer to both 0 or 2, because they are not the level called "trusted"
  18. lovetox haha ok .. i think you do to much programming :D
  19. lovetox but yeah im open to changing the term, but i would find it good if we could look what other applications use so we dont invent something totally new again
  20. maltel I'll have a look at what other applications use, but in your interpretation what would you use to refer to "any trustlevel other than 'trusted'"?
  21. lovetox this is simply not a possibility, this is user faceing UI, we dont do logic games here
  22. lovetox the thing has one state and one only
  23. lovetox the red icon makes that even more clear
  24. maltel I agree that with the red icon etc. in the fingerprint window it is easy to understand what is meant - the issue arose for me because I now want to distinguish "trusted" vs. "all other states" elsewhere in the UI
  25. lovetox why?
  26. lovetox ah i get it
  27. lovetox i dont think this is a good idea
  28. lovetox encryption schemes exist for a long time, and i dont see that we get unexpected states someday
  29. lovetox Gajim should display 3-4 states
  30. lovetox and it should not interpret states of plugins
  31. lovetox the plugins have to pass the Gajim state
  32. lovetox So maybe looking into the future, Gajim could support, Verified, Blind trusted (auto trust) and Untrusted
  33. lovetox i dont see much use for any other states
  34. lovetox Maybe we can add that Undecided state also
  35. lovetox to make it more clear if you receive a message from a new contact, and if you receive one from a key that you definitly set to untrusted
  36. lovetox and yes we could rename the Trusted state in omemo to verified
  37. maltel yes, that seems like a good idea. and then the different crypto plugins need to map their internal trust levels to those four options. the openpgp plugins seems to have more or less exactly these four levels at the moment, so that should work well with the current plugins
  38. lovetox yes and omemo will get the same
  39. lovetox it is missing the blind trust option at the moment
  40. lovetox and maybe we could use the exact enum from openpgp
  41. lovetox just move it to gajim and import it into the plugin
  42. lovetox then you only have to map for now with omemo
  43. maltel yes, that sounds good. I will look into what naming scheme other projects use and then see if I can move the enum to gajim etc.
  44. lovetox also look into if we can use the same shield icon in Gajim
  45. lovetox instead of the lock
  46. lovetox as it not only depends on color, its also visually different
  47. maltel what shield icon?
  48. lovetox then one in the fingerprint window
  49. maltel ah, ok. so that would then replace the lock completely? or should it be a second icon for the trust alongside the lock for encryption?
  50. lovetox no replacing would be my idea
  51. lovetox or maybe not, do as you think is good
  52. lovetox i just think about the blind trust option
  53. lovetox and i struggle how that would look
  54. lovetox a other tone of green on the lock?
  55. lovetox with shield you could use the half full shield
  56. maltel hm. A problem I can see if we use shields for trust is what to do with unencrpyted messages
  57. lovetox empty red
  58. lovetox untrusted, is full red
  59. lovetox but yes the open lock is nicer for that
  60. bot BoySka created an issue in _gajim_ < https://dev.gajim.org/gajim/gajim/issues/9624 >: #9624: < gajim-remote output format >
  61. maltel So the only programs I could easily check with regards to "untrusted" vs "not trusted" naming scheme for now were converse.js and gpg. The former uses a slider with "untrusted " and "trusted". The latter does have "I do NOT trust", with other options "Don't know", "I trust marginally" and "I trust fully". So a bit inconclusive.
  62. lovetox So what would you propose ? Untrust
  63. lovetox also we should probably use on the action "Untrust" but on the tooltip "Untrusted"
  64. maltel I prefer untrusted. I will need to decide for the Trust enum as well. the openpgp module uses NOT_TRUSTED, while the omemo plugin currently uses UNTRUSTED.
  65. lovetox one beeing a action that we can exectue, the other is display the current state
  66. maltel true
  67. maltel do you prefer VERIFIED over TRUSTED?
  68. lovetox Verified, other application use it also
  69. lovetox like conversations
  70. maltel yes, signal was well. what I don't like about that terminology is the strange mix if you can "untrust" something that is "verified" etc. but "unverify" would be even weirder
  71. lovetox hm no that makes sense to me, verifying is the act of comparing fingerprints with another device
  72. lovetox if that device gets stolen i set it to "untrusted"
  73. lovetox this makes it not less verified
  74. lovetox so actually we want to say, verfied and trusted
  75. lovetox but i think we can imply that with the colors
  76. lovetox no need to write that out
  77. maltel So should we go with UNTRUSTED / UNKNOWN / BLIND / VERIFIED then? I still kind of prefer TRUSTED a little bit, but I also understand that several apps that are used by a lot of people use the "verified" terminology now, so being consistent with those is also useful for the average user.
  78. lovetox they use it because in these applications there is a workflow that lets the user verify a fingerprint, with a qr code and a scanner
  79. lovetox they want to show that the user has completed this
  80. lovetox yeah i think we should stay consistent here
  81. lovetox is UNKNOWN not confusing?
  82. lovetox we actually know the user has not made a decision
  83. maltel ah, that was from openpgp. the omemo UNDECIDED is better
  84. lovetox yeah i find that better
  85. maltel yeah, me too. I just copied that from the openpgp plugin and didn't notice that this level has a different level too
  86. maltel *different name
  87. lovetox changing the enum names is easy, just dont change the INTs they are mapping too
  88. lovetox this is a bit unfortunate that omemo and openpgp dont use the same
  89. lovetox but changing that results in much more pain and backwards incompatibility
  90. maltel what do you mean? should we not make both plugins import the gajim data structure for Trust and change these things to make them consistent? Or not, because that means that the plugins only work with the newer (future) gajim version that has this data structure?
  91. lovetox yes but its not possible for both
  92. lovetox the names map to different INTs
  93. lovetox 2 is UNDECIDED in omemo
  94. lovetox in openpgp its BLIND
  95. lovetox you can rename UNKNOWN to UNDECIDED in openpgp
  96. lovetox and use that enum for Gajim
  97. lovetox but in omemo you have to add a translation method that translates the omemo enum to the gajim one
  98. lovetox otherwise you would ahve to make a database migration changing the trust values in the database
  99. lovetox which would mean no user could go back to a older version of gajim without invalid data
  100. maltel ah I see, I did not think about the database issue
  101. maltel that is unfortunate...
  102. lovetox renaming the names of the enum is though no problem
  103. lovetox the number gets written into the database
  104. lovetox not the name
  105. bot Daniel Brötzmann modified an issue in _gajim_ < https://dev.gajim.org/gajim/gajim/issues/9624 >: #9624: < gajim-remote output format >
  106. bot Cimpian Alin Constantin created an issue in _gajim_ < https://dev.gajim.org/gajim/gajim/issues/9625 >: #9625: < New bug report >
  107. bot mahlzahn created an issue in _gajim_ < https://dev.gajim.org/gajim/gajim/issues/9626 >: #9626: < Sudden Crash when trying to remove contact from roster >
  108. bot Malte L proposed a new merge request for _gajim/master_ < https://dev.gajim.org/gajim/gajim/merge_requests/383 >: Show trust level for incoming encrypted messages
  109. bot Malte L proposed a new merge request for _gajim-plugins/master_ < https://dev.gajim.org/gajim/gajim-plugins/merge_requests/120 >: [omemo] Pass trust level to gajim
  110. bot Malte L updated a merge request for _gajim-plugins/master_ < https://dev.gajim.org/gajim/gajim-plugins/merge_requests/120 >: [omemo] Pass trust level to gajim
  111. bot Daniel Brötzmann closed an issue in _gajim_ < https://dev.gajim.org/gajim/gajim/issues/9625 >: #9625: < New bug report >
  112. bot Daniel Brötzmann closed an issue in _gajim_ < https://dev.gajim.org/gajim/gajim/issues/9626 >: #9626: < Sudden Crash when trying to remove contact from roster >
  113. hannibal wurstsalat: you can use `/duplicate #issue` to mark issues as duplicate
  114. wurstsalat That I didn't know! Thanks :)
  115. lovetox but to send that use the comment button, not the close button
  116. lovetox because the comment will close the issue by itself
  117. wurstsalat Good to know :)
  118. bot Daniel Brötzmann closed an issue in _gajim_ < https://dev.gajim.org/gajim/gajim/issues/9587 >: #9587: < sound and login >