Gajim - 2019-02-28


  1. stp Hey guys, I now have two accounts running in Gajim and I have one of my contacts on both account's rosters. When I send a message to that contact from my account (A) that message also appears in the chat via account (B) with the same contact. Is that hows you guys wanted it to behave or a bug? If it's the former I think this is a very bad design decision.
  2. mrDoctorWho could anyone please check the gajim.org server logs regarding s2s connections between helldev.net and conference.gajim.org?
  3. asterix I can, but not right now. This evening
  4. lovetox stp yes account is not stored in the database
  5. ta https://uploads.trashserver.net/upload/0fe4966a-f75a-49d6-8e2a-a85c769947ab/inline_codebocks.png
  6. ta does this concern gajim directly or syntax highlighting plugin?
  7. lovetox syntax highlighting
  8. ta fm, are you there? ;-)
  9. stp lovetox‎, hm, but *what* is stored in the database instead and why?
  10. fm ta: which gajim/plugin versions are you using?
  11. ta fm, gajim 1.1.2 nightly from some days ago, syntax highlight 1.1.3
  12. fm Hm... I will have a look later.
  13. fm I changed the way I search for inline code spans and made it more strict (and compliant to the format xep)
  14. fm Having multiple inline code spans is something I explicitly tested
  15. fm Maybe I've missed something
  16. ta it probably is the comma directly after ` i think the xep says only start and end signs in front of a word and after a word should be treatet as beginning and end of a span. So the comma sourrounds one end-sign... and so on...
  17. fm Oh, yeah, you're right. I did not see the comma there....
  18. fm Guess I will have to whitelist some characters there
  19. ta at least it needs to be discussed. Obviously the xep says nothing about "sentence ending" characters.
  20. fm Yet another point to as to the list of things that should go into a xep refinement ...
  21. fm Can you think about any non-alphanumeric character that should *not* be excepted?
  22. fm OT: for some reason I can't correct messages I've sent in here using conversations.... Works with all other nucs. Conversions issue or a room setting? (iirc it has been working not long ago)
  23. ta fm, just the usuals ,.;?! in line blocks can be problematic because ` can be in the span as well. whatever you decide it will only work until something breaks again.
  24. Link Mauve Can we just move away from encoding semantics into plain text, and go back to structured formatting?
  25. Link Mauve XEP-0071 does support all of that already.
  26. ta Link Mauve, how do clients react, that dont know about html tags? What i like about xep 393 ist that it highlights somewhat even on clients not supporting it, just because _of_ *the* ~signs~ `used`
  27. ta what i like about xep 394 is that it does not format body at all, and looks normal everywhere and formatted on supporting clients. Scizophrenic, i know.
  28. Link Mauve ta, the signs used are super ugly. :x
  29. Link Mauve ta, 0071 isn’t HTML fyi, it’s XHTML-IM, that is a very small subset of tags you can implement, split into different profiles.
  30. ta yeah, opinions. Thats why we fight a lot here ;-)
  31. Link Mauve And it involves having two different representations of the same message, one which is really plain text, and one with formatting.
  32. Link Mauve If your client doesn’t support the latter, it will display the former.
  33. ta ok, i have not read it completely. All i know is, i disable it in Gajim, and happen to like this markup xep for some subjective reasons.
  34. ta probably because it is not used too much. On the other hand, one can fuck up my chat logs with CAPITAL LETTERS as well, even i disable xhtml-im
  35. Link Mauve I see it used a lot, but maybe we have different circles.
  36. Link Mauve Also some clients don’t support it, most notably Conversations.
  37. ta looking at xhtml-im it is to powerfull in my opinion. This hand ful markup commands are enough for me in a messenger. bullets maybe. And you can type them very fast on a hardware keyboard. Of course you could translate markup in xhtml and do it like pandoc...
  38. Link Mauve ta, yes exactly, 0393 is fine as an input method, but on the wire it really should be XHTML-IM.
  39. Link Mauve No user should have to type XHTML. :D
  40. ta but like i said, i like 393 on the wire, because it ads visuals on the plaintext even without bolding or underlining. And it looks nerdy. Sorry, for not being neutral.
  41. lovetox fm, its a anonym muc here
  42. lovetox conversations does not allow corrections in anonym mucs
  43. Link Mauve ta, it’s fine to continue to leak 0393 tags for compatibility with clients which don’t support 0071, but it shouldn’t be relied on imo.
  44. Link Mauve Its parsing rules are way too brittle.
  45. Link Mauve And then you get people asking for extensions, I’ve seen links being asked for on standards@ for instance.
  46. Link Mauve At this point, using a proper wire protocol just makes sense.
  47. ta lovetox, i think since recent updates LMC should work in public mucs
  48. ta lovetox, i think since recent updates LMC should work in public mucs with conversations
  49. lovetox ah ok didnt know
  50. ta Link Mauve, i would not want links as underlined words without visual feedback where that link points me to.
  51. ta but as always its debatable.
  52. Link Mauve ta, you can represent it however you want visually, once you have the information.
  53. Link Mauve You can’t however do that if it’s just some random markup put in an otherwise plain text field.
  54. ta yeah i know. Lets see where clients develop. At the moment xep 393 seems widely adopted and syntax highlighting works like a charm in gajim.
  55. Link Mauve I don’t plan to implement it in my client, it’s just way too brittle.
  56. ta poezio that is, no?
  57. ta since poezio has avatars, what about syntax highlighting??? ;-)
  58. lep i would like if gajim wouldnt hl me when my nick is in `backticks`
  59. pep. ta, there is syntax highlighting in poezio via xhtml-im already
  60. Link Mauve ta, it also has that. :p
  61. Link Mauve Gajim has been displaying it fine for quite a long while.
  62. Link Mauve Of course, only if you don’t disable it.
  63. ta but then you rely on the formatting of the sender or does it only tell the programming language used in the "verbatim" block?
  64. ta Just curious how poezio does it, since i obviously never used xhtml-im
  65. lovetox it just puts the code into <block> or <code> tags and not in the body
  66. Link Mauve ta, both.
  67. lovetox just check out 0071 xep
  68. ta i put it on my pillow for tonight ;-)
  69. bot rcpa0 created an issue in _gajim_ < https://dev.gajim.org/gajim/gajim/issues/9606 >: #9606: < idle/closed laptop lid/reopened/login to ubuntu/crash popup >
  70. fm ta: sorry, have been at a business meeting and couldn't join the discussion here
  71. fm ta: > fm, just the usuals ,.;?! > in line blocks can be problematic because ` can be in the span as well. whatever you decide it will only work until something breaks again. So true.... I've got escaping of backticks on my todo list, too. However, that does not have priority until someone really requests it...
  72. fm Even though I do not fully agree with 393, I still like it. Neither the recipient *nor* the sender do need to know and l about additional formatting besides the plain text as opposed to 0071. There you require the sender to supply additional formatting besides the plain text with the message. Even if the recipient's client will use the supplied plain text, there is no way for it to work vice versa
  73. fm Or am I missing something?
  74. fm If only one wold design a common standard..... ;-)
  75. ta *a wild xkcd 927 appears*
  76. lovetox both have their place
  77. lovetox if we only talk about simple things like bold, underlining the approach is fine
  78. lovetox but people often want more
  79. lovetox and if you start with lists and nested stuff etc
  80. ta like Link Mauve explained it today they all three can coexist, but it is probably a pain in the ass for a client developer to support all and present them in gui to his user.
  81. lovetox then a clear syntax like html is definitly better
  82. lovetox or if you bring in fontsizes, or colors etc
  83. ta for transfering html is better, but typing markup is great. easy to remember, fast to type.
  84. lovetox obviously you should have a editor for that
  85. lovetox not type it
  86. ta fontsize and color is something i hate in messengers, like links/hrefs for security reasons
  87. lovetox And in gajim you can make stuff bold etc without knowing markdown
  88. lovetox this is essentially a discussion on how the info is transfered
  89. lovetox the user should not care about it
  90. fm Exactly. But it shouldn't be a burdon neither. And selecting text on a mobile device is. But I guess that would be the only thing an ui could offer for generating xhtml
  91. fm Typing markdown is simple even with mobile touch keyboards
  92. fm Still, the user needs to have that knowledge
  93. ta well... ` is hard to type. mobile needs other approaches than normal keaboards offer. or some symbols need better placement on the softkeaboard.
  94. fm Lol, I really thought ` would be on the first page of special characters.... Guess my motor memory has automated that away already... But who types in code on mobile device anyway ;)
  95. lovetox you are limted on a phone
  96. lovetox this does not depend on if you use html or markdown
  97. lovetox a client can also convert * bold * to <b>bold</b> and send it over the wire
  98. fm lovetox: is there a way to easily get the xhtml blocks Link Mauve mentioned (block and code, iirc) in a plugin?
  99. lovetox the way how a user marks something as bold does not depend on how it is transfered
  100. fm That's right wire format should be independent. But as I said, there are issues with that too. At least with the current situation in which clients don't do the conversion on sender's side
  101. lovetox fm i think you plugin is fine i would limit it to displaying stuff
  102. lovetox one could implement that gajim converts backticks to <block> when sending the message
  103. fm lovetox: do you think Link Mauve's proposal would be viable for gajim?
  104. fm > it’s fine to continue to leak 0393 tags for compatibility with clients which don’t support 0071, but it shouldn’t be relied on imo.
  105. fm That one
  106. fm Oh. You were faster ;)
  107. lovetox I think what link mauve is saying, be generous at what we accept (markdown and html)
  108. lovetox but if we offer our users a chance to send out a codeblock
  109. lovetox we should do it with html
  110. lovetox but there is yet another problem
  111. lovetox html does not work with omemo encryption
  112. lovetox because omemo only encrypts the body
  113. fm With or without insertions of markdown in plain text?
  114. fm Omemo is problematic, right
  115. lovetox one could do indeed both
  116. lovetox we could leave the backticks in the body
  117. lovetox and add a html for clients who support it
  118. fm I think that would be a great compromise
  119. fm For other formatting too...
  120. fm ...As long as it is part of 393
  121. lovetox yes of course
  122. lovetox or what would be even greater
  123. lovetox is if we could add this to the message input editor
  124. lovetox like we have for bold etc
  125. lovetox a button that says code
  126. lovetox and we click it we use tags and format the selected part for the user
  127. fm I guess I should put my to-do list in gitlab tickets...
  128. lovetox yeah why not
  129. lovetox the xhtml formatting menu would need a rework anyway
  130. lovetox its not really good
  131. fm The widget I have been working on is already designed to be used as an input, too
  132. fm For exact this purpose
  133. fm Sorry, I am slow at typing on virtual keyboards ;)
  134. fm Project stress at work should go down for a while now, so I'll be back at it.... Maybe (...) I'll even find time to help with that formatting options rework
  135. lovetox yeah, a general overhaul of the message input and what it is capable would be nice, the message input is also nicely separated in the message_textview.py
  136. lovetox so you dont really need knowledge about the rest of Gajim codebase to work on it
  137. fm Sounds good :)
  138. fm Since we are at it, what is your opinion on
  139. fm Providing an input widget base class with some serialization methods and an on-send callback?
  140. fm `on_send` ;)
  141. lovetox What for?
  142. lovetox whats your end goal
  143. fm That would allow (plugins) to provide any kind of widget inside the input text view in a common way. Allowing the image upload, for instance, to place the image in the input first.
  144. fm Same for the code blocks....
  145. lovetox yes not a bad idea, though i think for the code example it should be done differently
  146. lovetox im not sure its so nice to put a textview into a textview that has then the capabilities to format text
  147. lovetox when you can just give the normal gajim textview this capability
  148. lovetox writing a plugin to get to know gajim is nice, but i would recommend not writing an application in a application, plugin should be for smaller things that can be separated easily and not everybody needs
  149. lovetox having an editor textview for formatting text is something most people would want in a messaging client
  150. lovetox so i would not want you to spend too much work writing all this functionality into a plugin
  151. lovetox instead contribute it directly to the gajim codebase :)
  152. fm > im not sure its so nice to put a textview into a textview that has then the capabilities to format text My idea was to open a simple code input window and only put a placeholder in the actual input text view
  153. fm That placeholder would need serialization capabilities then to do it's magic on message send
  154. fm I guess you don't want all the code stuff in the gajim core, right?
  155. fm But the general concept could be beneficial for others too. That would be great to put into gajim itself
  156. lovetox yeah but why do it in a different textview when we already have one
  157. lovetox i dont see why a block formatting option should not be in Gajim
  158. lovetox im not against your idea, just not for message formatting, this is a feature that counts for me as one of the basic jobs a messenger should be capable off
  159. fm I didn't mean it for general message formatting. But IMHO, code blocks might be hard to write in the few (4 at max?) Lines that the input view is showing at a time
  160. lovetox so lets make a button that makes it much bigger for the purpose of writing longer texts with much formatting
  161. fm By 'it' you mean the text view?
  162. lovetox yes, my idea would be some kind of up arrow icon beside the formatting button, and if you click it the textview expands to 40 lines hight, overlaying the chattextview
  163. fm That would be great, as it would work for any long text
  164. ta my i switch back to omemo/e2ee. I think that point is pretty important. If omemo is enabled nothing should be send outside the body tag. I know, there are other places where xmpp is leaking, but it should not add to that if it is possible to prevent.
  165. ta the other stuff you brainstormed sounds very promising.
  166. fm i also think the leaking with the xhtml formatting is a huge issue. especially since most users are not aware of this
  167. lovetox nothing leaks
  168. lovetox this is of course prevented by the omemo plugin
  169. fm oh?
  170. fm how is this handledS
  171. ta ok, that is smart of the plugin.
  172. ta probably everything outside body is stripped away
  173. lovetox encryption is the last step before sending a message out
  174. lovetox the omemo plugin has a whitelist of xml nodes
  175. lovetox everything else gets deleted from the stanza
  176. ta yeah, sounds obvious. So the omemo enthusiasts are back to markup inside message body ;-)
  177. fm hm. is there a notification for the sending user that additional elements in the xml are deleted?
  178. fm has to test that....
  179. ta as i use this plugin and see no notification, i would say no.
  180. lovetox it is basically only xhtml
  181. fm i do not use formatting except markup, so i dont know ;)
  182. lovetox there is no other stuff that puts plaintext outside of the body
  183. lovetox but no gajim does not deactivate formatting if omemo is activated
  184. lovetox that would be also a nice edition
  185. lovetox that would be also a nice addition
  186. ta its a pity that omemo has so many little flaws, since it is pretty wide spread nowadays. To deploy some improved e2ee would take years probably
  187. fm > there is no other stuff that puts plaintext outside of the body but metadata migth still be unencrypted, iirc?
  188. ta pulling from http upload, pulling vcards... there are a lot of leaks.
  189. fm yes, but that is an additional leak outside "normal" messages
  190. ta well, i assume there are more leaks. that are some points i think need improvement.
  191. lovetox yes metadata is unencrypted
  192. fm so, I infer from the discussion, formatting should do both -- create xhtml and markup in the plain text if unencrypted. If OMEMO is used, formatting should only be done only with markup as far as supported.
  193. ta and for interpreting incomming text? i have xhtml disabled. Even if enabled it should be matched against the xhtml, i suppose.
  194. ta and according to xep 393 the symbols should not be stripped away but be displayed. conversations greys them out a little bit.
  195. fm for incoming text xhtml should have priority, if it is in the received message *and* enabled on receiver's side. if either does not apply, the plain text + markup should be used
  196. fm stripping symbols is independant of that, isn't it?
  197. fm oh, do you mean that they are implicitly stripped in xhtml
  198. fm ?
  199. ta sorry, you are right. body becomes meaningless, as soon as xhtml-im is supported.
  200. ta now that i think about it. of course they can be stripped in xhtml. since you as receiver want formated text that way. the SHOULD of keeping them applies only to markup in body. you also need them for markup in citation.
  201. Link Mauve ta, the generally recommended way for code is <pre><code class="language-python">print('Hello world!')</code></pre>, and that’s what poezio sends (with coloured spans inside, but that you can ignore if you do your own rendering).
  202. pep. "fm> so, I infer from the discussion, formatting should do both -- create xhtml and markup in the plain text if unencrypted. If OMEMO is used, formatting should only be done only with markup as far as supported.", indeed, that's a limitation of OMEMO
  203. pep. :(
  204. lovetox right now, its not a general limitation
  205. pep. how is that general?
  206. pep. Can you not send xhtml-im in OX?
  207. lovetox its something that can be changed, is what i mean
  208. pep. Sure.
  209. pep. I'd like to see how that's going to be done though. OMEMO v1 and v2 are likely not compatible at all
  210. pep. It's basically rolling yet another encryption mechanism
  211. lovetox hm no we did this once already
  212. lovetox you start with implementing read support everywhere
  213. lovetox then give it some months for users to update
  214. lovetox then implement the sending part
  215. pep. You mean examples like dino still implementing the old sending protocol? And new libraries coming and not knowing about it
  216. lovetox its not painless
  217. lovetox but i think its doable
  218. pep. Also think about "stable" distributions
  219. pep. That adds 2 to N years of delay
  220. lovetox you could also think up some discovery stuff
  221. lovetox announce that you support omemo:2 and then the client starts to use full stanza encryption with you
  222. lovetox otherwise use normal
  223. pep. Yeah you need disco
  224. ta so an evolving messenger standard should be updated like browsers and other critical stuff, that is useless with only security patches but too old feature levels.
  225. pep. And you need to market it differently, otherwise users are going to come to you "I do OMEMO and my contact too and it doesn't work"
  226. ta but i use rolling release distros for a reason. my empathy for too old stable distributions is limited.
  227. fm how advanced is omemo v2 so far?
  228. pep. ta, I also use a rolling-release distribution :)
  229. pep. At work I have to deal with stable stuff, it's painful
  230. ta well depends on the software needed. since debian/ubuntu-server is quite widespread a lot of server daemons work on that stable stuff.
  231. fm never thought
  232. fm I would say that one day, but nowadays i prefere centos on servers
  233. pep. ta, yeah, being Idontknowhowmany versions behind the actual one you're looking for :)
  234. pep. Which is another issue
  235. fm on the server side: does omemo v2 require any support ? besides pep and maybe disco additionally?
  236. lovetox no
  237. lovetox there is no v2
  238. fm :(
  239. pep. There is OX! :P
  240. lovetox just ideas what could be done :)
  241. ta well my employer maintains virtual machines of ubuntu 12.04. no that did not receive updates until it was deprecated 2017. yes it is still in production and online. no i am not in power to change that for better.
  242. pep. ta, sad
  243. fm lovetox, I of course ment the "hopefully upcoming" version v2 ;)
  244. lovetox there are some parts that the server could do
  245. lovetox but they are not strictly necessary for it to work
  246. fm is self-signing own keys part of the discussed ideas? that would be so great.... the entire trust management/handling is cumbersome which led to some of my contacts drop omemo after all :(
  247. fm and: are there any resources to check so far? so I don't have to spam you with questions ;)
  248. lovetox hm you can simply trust all keys blind
  249. lovetox then its not cumbersome
  250. fm yeah. that's what I told them, too.... -.-
  251. lovetox but yeah there is some trust sharing stuff in the works
  252. fm even though I would not want to trust blindly myself
  253. fm gread
  254. fm great
  255. lovetox but its mainly for the purpose that if you trust a key on one device, that you dont have to trust it on your other device also
  256. ta yeah trusting devices is annoying. but i understand there are usecasese, where this is wanted. But then again, xmpp should leak less to be effective. i think having an e2ee with device verification and one with only verifying once have their niches.
  257. fm sure, thats what I was thinking about
  258. fm @ lovetox
  259. ta lovetox, gajim sends messages first and then offers the omemo-trust-new-keys-dialog. after trusting new keys, these users dont get the afformentions message send again so they can read it, no?
  260. ta conversations does it the other way arround,asks first for trust of new keys and then sends to all. the ones trusted before and the newly trusted ones. That is more intuitive, i think.
  261. lovetox yes i plan to fix that
  262. lovetox but this shouldnt happen often
  263. lovetox i mena how often do people get new devices
  264. ta (we have a group of >10 nerds, each one with 2-4 devices. some devices off for several days. sometimes a user is on vacation for weeks. and then there are nerds trying different applications or flashing roms... new omemo keys happen often once a weak.
  265. ta the devices beeing offline for longer periods probably have other sideeffects, than "new" omemo keys. But anyway, we have a lot of fun with it.
  266. lovetox fm do you want to look at making the message input bigger with some button?
  267. lovetox we just need a nice editor kind of thing :)
  268. fm lovetox, yeah, would do that. But let me tell you right away that I can't promise a time frame for that....
  269. fm probably I would continue the plugin-widget thing first, just to get it of my table
  270. lovetox yeah no hurry, just want to prevent 2 people working on the same thing