jdev - 2019-09-01

  1. aj has left

  2. Daniel has left

  3. Daniel has joined

  4. Daniel has left

  5. lksjdflksjdf has left

  6. Daniel has joined

  7. gav has left

  8. aj has joined

  9. aj has left

  10. lovetox has left

  11. larma has left

  12. larma has joined

  13. lovetox has joined

  14. aj has joined

  15. lksjdflksjdf has joined

  16. gav has joined

  17. lovetox has left

  18. lovetox has joined

  19. gav has left

  20. aj has left

  21. Zash has left

  22. Zash has joined

  23. rion has left

  24. rion has joined

  25. actupper has joined

  26. Alex has left

  27. larma has left

  28. larma has joined

  29. lovetox has left

  30. gav has joined

  31. tom has joined

  32. tom


  33. tom

    I am a bit confused on how OMEMO pubsub nodes should be setup

  34. tom

    should the subscriber model be presence or open?

  35. tom


  36. pep.

    generally clients set the access_model to open for OMEMO stuff

  37. tom

    pep., would that be the subscriber or publisher model?

  38. pep.


  39. tom

    I see

  40. Zash

    Generally this gets handled by the client without the user needing to do anything tho

  41. pep.

    publisher is probably whitelist with your own jid

  42. tom

    the default it was subscriber model set to presence

  43. pep.

    Which client?

  44. tom

    but that was causing people to be unable to communicate with my over OMEMO unless we accepted roster requests both ways

  45. tom

    Gajim 0.6.X

  46. pep.


  47. tom

    yes I mean 0.16.X

  48. pep.

    I guess that's been fixed in 1.x

  49. tom

    I can't use gtk3 so I'm going to have to fork 0.16.9

  50. pep.


  51. pep.

    Maybe you can backport the fixes, dunno

  52. tom

    I'm just trying to figure out how it should work so I can fix bugs in my fork

  53. wurstsalat has left

  54. tom

    so just to be clear, there are multiple axolotl pubsub nodes

  55. tom


  56. pep.

    I'd recommend trying to backport stuff from the stable/master branch, so you don't have to rewrite everything yourself, but just the graphics toolkit bits

  57. Zash

    Presumably the same settings would need to be applied to all different nodes to avoid weird interop problems

  58. tom

    so I've modified axolotl.device list to be open subscriber model, but what are the bundles:somelongnumber?

  59. pep.

    tom, same permissions

  60. tom

    are those private conversations? should those be presence only or open as well?

  61. Zash

    Each device picks a random integer and creates a node for it

  62. Zash

    IIRC it publishes pre-keys or something there

  63. Zash

    (I'm not a fan of this design)

  64. tom

    I'm sorry I'm confused, I thought the devicelist node stored the keys

  65. Zash


  66. tom

    what exactly is the difference between devicelist and bundles?

  67. Zash

    The device list stores those numbers

  68. tom

    ok so when sending OMEMO messages the backlog (offline encrypted messaging) is still stored in MAM serverside not a special pubsub node

  69. Zash

    IIRC this is because you can't count on being able to store more than one item per node

  70. tom

    the device list contains a list of the bundles and the bundles contain the key right?

  71. Zash

    But OMEMO got publish options and subscriber models implemented and deployed, so it could just as well have used a single node with an item per device

  72. tom

    it SHOULD as in says the in the spec or are you saying the spec should have did that instead but it doesnt?

  73. Zash

    You SHOULD assume that I have no idea what I'm talking about.

  74. tom


  75. Zash

    Not a client developer.

  76. tom

    ok So I've modified all the axolotl device list and bundle nodes to be open. I'll experiment with this and go over the spec extra fine. If this ends up being correct I'll modify the source

  77. tom

    to be open by default

  78. Zash

    DO NOT do that for every PEP node

  79. pep.

    yeah, just OMEMO

  80. pep.

    devicelist and bundles

  81. pep.

    Also as I said above, maybe you should try backporting stuff from master rather than rewriting everything

  82. pep.

    I might every ask lovetox (current maintainer) and see if it's not worth starting from 1.x and porting it to gtk2 if that's really what you want

  83. tom

    only did that for the eu.siacs.conversations.axolotl.devicelist and eu.siacs.conversations.axolotl.bundles:$rand nodes

  84. pep.

    I might even ask lovetox (current maintainer) and see if it's not worth starting from 1.x and porting it to gtk2 if that's really what you want

  85. Zash


  86. pep.

    Also maybe the gajim discussions could go in gajim :)

  87. pep.

    Ah wait this is jdev@, I though we were in operators@, I have this mental picture of "tom" the ghost of operators@

  88. Zash

    How supported is GTK2 these days?

  89. tom

    >pep.‎: Also as I said above, maybe you should try backporting stuff from master rather than rewriting everything I'll take that into consideration but as I understand it the 1.X changes do more than just switch the toolkit but change around the user interface very extensively and include functions lke hamburger menus. These things don't exist in gtk2. Also, the really only things that I need to fix in the 0.16.X client I'm aware of is this OMEMO pubsub thing and changing the Jingle implementation to use a more modern version of libfarstream (or other protocol implementing Jingle) and work with either a modern version of gstreamer or better just use ffmpeg instead

  90. pep.

    I think there's a lot more things you don't see that have been fixed

  91. pep.

    Lots of code refactor as well

  92. tom

    I don't think the main gajim developers are very open to making the 1.X branch support gtk2 or any other toolkit like qt5 either

  93. tom

    they seem pretty set on gtk3

  94. Zash

    Switching toolkits is no small task

  95. tom

    >Lots of code refactor as well Yeah i can see. there's lots of single-character variables in the source code like somebody just copy-pasted from stack overflow

  96. Zash

    I would be happy if lower level libraries are reusable

  97. Zash

    Like, protocol stuff

  98. tom

    my experience with gstreamer has always been painful. Where it's always been better to use ffmpeg if possible and if not install gstreamer-libav plugin that just wraps ffmpeg anyways

  99. tom

    I've met some camera developers who say they like using gstreamer internally rather than learning ffmpeg because it's more abstracted but I already know ffmpeg and I've had nothing but problems with gstreamer dating back to KDE3 on slackware

  100. tom

    >How supported is GTK2 these days? It receives bugfixes on it's own branch and is generally considered 'mature' or 'finished'

  101. tom

    It's also first class on Devuan even all the way to sid

  102. pep.

    Devuan, heh

  103. pep. runs away now

  104. tom

    still use exclusivly by Gimp and claws-mail

  105. pep.

    iirc Gimp was going to jump to gtk4

  106. tom

    yeah, the problem with that is that gtk3-+ is considered the GNOME toolkit. The development direction is only geared to serve GNOME's needs. The GNOME3 development team have explicitly stated this. While at the same time the gtk2 toolkit is the Gimp toolkit. Was originally designed as a generic graphical toolkit to make gimp with. However it was not explicity for gimp

  107. tom

    so a lot of other *nix programs use gtk2.

  108. pep.

    Yeah I've read that whole discussion before and I'm not replaying it

  109. tom


  110. tom

    but yeah, I'm not running GNOME so it gtk3 really does not meet my needs so I'm needing to fork

  111. tom

    I appreciate your pointers pep. and Zash . thank yo

  112. tom


  113. Zash


  114. pep.

    While Gajim devs might not be interested in supporting gtk2 anymore, being a friendly fork would be nice I think. If it's in your cords, talk to lovetox a bit, even if it's just asking advice on where to look at, what has been changed etc.

  115. pep.

    You might want to stick to gtk2 but getting bug fixes can be a good thing :)

  116. pep.

    (Also not annoying other users with bugs we've already seen here and there and that are fixed in master :))

  117. tom

    ok. I'm not sure what you mean by 'friendly fork'

  118. Zash

    MVC-ish separation of UI code and other application logic is good, so you might be able to ensure/push for that 🙂

  119. pep.

    Yeah, either try to make the new code easy to adapt to new toolkits, to make it easier for you to have your gtk2 patches on top

  120. pep.

    It's a bit more maintenance for the gajim devs, but if you're willing to help maybe they would be ok? And you benefit from new features/bugs (fixes) etc.

  121. tom

    maybe. I don't see me needing to change toolkits in the near future, if I was going to do that I'd probably be going from gtk2 to qt but going from gtk to qt is a much bigger change than going to one gtk version to another. I don't expect to have to save development model as Gajim. I'm more interested in conservative LTS releases and stabilizing those as much as possible than implementing many features very fast. However everything is still very much up in the air right now so I'll definitely think about it. And as I see it currently the Gajim devs have a very different grand vision in mind than I do right now.

  122. tom

    I also see myself using the XFCE 4.12 theme engine for at least another 6 years and gtk2 is very well supported there

  123. Zash

    I thought XFCE were going GTK3 too

  124. tom

    yes, but Debian isn't

  125. tom

    nor am i

  126. pep.

    Debian isn't?

  127. pep.

    So they'll maintain their fork downstream?

  128. tom

    Debian will maintain the 4.12 release for 6+ years

  129. tom

    with security patches and bugfixes only

  130. pep.

    What kind of Debian releases are you talking about?

  131. pep.

    LTS ?

  132. tom


  133. pep.

    stable only go 4 years no? + maybe another year for LTS?

  134. Zash

    Not 3 years? (new release about every 2,

  135. tom

    I don't know how well versed you are with Devuan/Debian release models but ounce a STABLE RELEASE becomes OLDSTABLE RELEASE it then goes into LTS support by a private company that employs a team of fulltime developers

  136. Zash

    +1 y support) (gah why is enter there?)

  137. pep.

    stable (2) -> oldstable (2) -> lts (1)

  138. tom

    as long as the funding goals are met it's 6 years

  139. pep.


  140. pep.

    I'm not well versed into LTS tbh

  141. pep.

    Also I'm surprised I haven't yet shouted HERESY all over this room

  142. Zash

    pep., I've been very tempted to ask whether this fork is Python2 😛

  143. pep.

    That makes me really sad

  144. tom


  145. pep.

    tom, yeah I know about them, just never bothered to read

  146. pep.

    I shall return to my omemo stuff now.. (another fun thing to play with)

  147. tom

    Well, I would be tempted to convert Gajim 0.16.X to python3

  148. Zash

    Oh, so the py3 switch was in 1.x then?

  149. Zash

    (I've not been following Gajim that closely)

  150. tom

    let me check

  151. tom

    yes, It looks like Gajim.py specifies the python interpreter, and the default version in Devuan ASCII is Python 2.7.13 (default, Sep 26 2018, 18:42:22) [GCC 6.3.0 20170516] on linux2