Gajim - 2014-03-01


  1. Link Mauve I remember Gajim supporting some kind of ad-hoc commands to control it from another resource.
  2. coyo huh
  3. coyo "resource"?
  4. Link Mauve The technical name of another client connected to the same bare JID.
  5. coyo oh
  6. coyo fascinating.
  7. Link Mauve Actually, the identifier after the / in a JID.
  8. coyo oh, okay.
  9. coyo so, in coyo@darkdna.net/pidgin, the pidgin part is the resource identifier?
  10. Link Mauve Yep.
  11. coyo alright, cool
  12. Link Mauve It’s the mechanism that allows you to have multiple clients.
  13. coyo i see. do all clients support resource-to-resource communications?
  14. coyo i noticed on some clients i could initiate private chats with other clients, and those clients would show it, but i wasnt able to test that on enough clients to know if that was a core protocol feature, or just a quirk of some clients
  15. coyo ah, nice. jitsi supports mucs.
  16. Link Mauve It’s a protocol feature, yeah.
  17. Link Mauve Actually there is nothing different from sending stanzas to another contact.
  18. coyo i see! that makes a lot of ideas i have been brewing not just possible but feasible..
  19. coyo gets evil, EVIL, ideas.
  20. coyo you know what this needs? more client-on-client action O:
  21. coyo i wonder why autojoin/subscribe is called "bookmark" on most clients?
  22. Link Mauve Because that’s where you store MUC bookmarks, with an optional autojoin tag.
  23. mathieui coyo, because « bookmark » is actually the proper terminology
  24. coyo uh huh. who decides what terminology is proper or not?
  25. mathieui http://xmpp.org/extensions/xep-0048.html
  26. coyo stpeter?
  27. mathieui « XEP-0048: Bookmarks »
  28. mathieui people who write the XEPs, not necessarily stpeter, and this is really more fitting than a subscription
  29. coyo yeah, i'm familiar with the xep, but why "Bookmarks" and not "auto-join" or "subscribe" or something else?
  30. mathieui and autojoin isn’t that, because a bookmark does not always have auto-join
  31. mathieui coyo, browser use « bookmarks », and it is a familiar term
  32. mathieui browsers*
  33. coyo this is a little different.
  34. mathieui well, you bookmark a room to keep it in a list you may want to join or not
  35. coyo because although in theory, a bookmark does not always mean auto-join, i've wanted to "bookmark" hard-to-find chatrooms and NOT join them automatically, usually because they are NOT prosody, and dislike multiple logins
  36. Link Mauve And this XEP does non-MUC bookmarks too.
  37. coyo i never got that option
  38. mathieui coyo, gajim has it, I believe :x
  39. coyo "Remember this, but dont join without the explicit instruction" does not exist.
  40. coyo orly?
  41. Link Mauve Yes.
  42. coyo but arent bookmarks stored on the server?
  43. mathieui I think there is a checkbox
  44. Link Mauve They are.
  45. mathieui coyo, often, yes, and there is an autojoin attribute in the XML schema
  46. coyo is it possible to put arbitary information in a bookmark?
  47. mathieui <conference name='The Play&apos;s the Thing' autojoin='true' jid='theplay@conference.shakespeare.lit'> <nick>JC</nick> </conference>
  48. coyo in other words, will the server honor it if you DONT want to auto-join?
  49. Link Mauve coyo, yes, but AFAIK Gajim wipes them. :/
  50. Link Mauve The server has no role in autojoin, this is purely an informative hint for the client.
  51. mathieui Link Mauve, arbitrary data is not allowed
  52. mathieui yes, the server is “dumb”, the client sends data, retrieves it, and acts accordingly
  53. Link Mauve Ah true, no ##other namespace. :/
  54. coyo fail.
  55. coyo that does definitively answer my question.
  56. mathieui the only allowed things are what I pasted
  57. mathieui which include a custom name for the room, the nick you want, autojoin or not, and the jid of the room
  58. mathieui which is what most people seek in such bookmarks, imo
  59. coyo i suppose i could always publish xeps, and in theory, there IS an established way to have xeps implemented, but since the xmpp community is already established, and not everyone likes me, i may have to ignore the standardization process and simply publish xeps internally. if someone asks for it, i wont HIDE the standards, but i wont volunteer them either.
  60. coyo i've joined the various client and server mucs before, people generally dont like me much.
  61. coyo my ideas are more or less unwelcome, and i'm fine with that.
  62. mathieui coyo, but what would you want to add?
  63. coyo well, since skype has imploded, it's no longer a threat
  64. mathieui http://pix.toile-libre.org/upload/original/1393629846.png this is the gajim UI for managing bookmarks
  65. coyo and editing one's messages IS supported in SOME clients to a degree, but not all clients do, and it looks ODD when they dont, and you cant edit arbitrary messages, only the immediately previous one, and only within a short period of time after its sent
  66. coyo the editing a message feature is experimental at best, and it's one of the best things i liked about skype.
  67. coyo pre-microsoft skype, anyway
  68. mathieui coyo, while this is out of scope of the XEP, a client editing an older message than the last one would mostly work, I guess
  69. mathieui (for clients supporting editing)
  70. coyo most of my ideas center around cryptography, direct client-to-client messaging and other Jingle hackery, advanced MuJi featuresets, mostly around video conferencing, as well as standardized alternatives to skype, sip and google hangouts.
  71. Link Mauve I wanted to write a plugin for poezio to correct another message than the last one, but I never wrote it.
  72. coyo but i kinda lost any hope that anyone would bother. i like xmpp, i want it to succeed and become THE standard for instant messaging and telephony
  73. mathieui (I have been using last message correction for more than a year now, I believe the feature set in the XEP is mostly fine ^^)
  74. coyo but it turns out i'm a bad programmer, so even if i bothered to write patches, i am pretty confident they would be rejected out of hand
  75. Link Mauve coyo, about e2e encryption, I’ve started implementing Jingle XMP Streams and XTLS in SleekXMPP.
  76. coyo wasted effort.
  77. coyo orly?
  78. coyo i'd love to hear your progress on that.
  79. Link Mauve Currently I can transfer unencrypted files. :D
  80. coyo my jid is coyo@darkdna.net. i'll put you under "coworkers" if you dont mind.
  81. coyo yay file transfer
  82. Link Mauve But I (mostly) have the fundations for e2e XMPP and then encrypted e2e.
  83. Link Mauve I won’t have time to implement it further, I’m going to Germany on tuesday and I have a lot of things to do this weekend. :/
  84. mathieui Link Mauve, don’t forget patches to the XEP
  85. Link Mauve mathieui, yeah, I’ve started that too.
  86. coyo i'm told that xmpp file transfers are slow because the default socks bytestream proxy is overburdened, but my xmpp service provider provides a socks bytestream proxy which is NOT overburdened, but file transfer is slow regardless. i'm confident it is not my proxy, since the server it's running on can support my full bandwidth, 9.8 MB's (not megabits, megaBYTES) as tested with winSCP
  87. coyo is incredibly curious about the status message killer.095 joined with o.o
  88. coyo that's arabic, isnt it?
  89. Link Mauve Looks like it, yeah.
  90. killer.095 hi
  91. Link Mauve I have currently only implemented in-band bytestream, which is the slowest but most reliable method of reliable transport for Jingle.
  92. Link Mauve 261
  93. coyo how does file transfer work in xmpp? assuming the client doesnt bother with NAT traversal or UDP hole punching, it quickly falls back to socks bytestream proxies, doesnt it? do you need proxies at both ends?
  94. coyo in other words, the file transfer, is it as slow as the slowest bytestream proxy?
  95. mathieui coyo, the worst case is always IBB, which is often limited to 10kB/s
  96. coyo which defaults to proxy.eu.jabber.org
  97. coyo IBB?
  98. mathieui in-band bytestreams, what Link Mauve was talking about
  99. coyo oh, in-band bytestreams
  100. coyo ew.. in theory, in-band can be very fast, but most xmpp servers are incredibly slow
  101. Link Mauve No, it can’t be fast.
  102. Link Mauve it shouldn’t be allowed to be fast*
  103. coyo does IBB forcibly limit to 10kB?
  104. Link Mauve No, it’s a server policy.
  105. coyo oh, just default server policy
  106. mathieui coyo, sane servers should enforce rate-limiting policies
  107. coyo in which case, why do xmpp file transfers almost guarantee worse-case scenarios?
  108. coyo is jingle just that bad?
  109. mathieui They don’t :D
  110. coyo i have a very fast bytestream proxy set. why dont it use that?
  111. Link Mauve coyo, Jingle File Transfer only guarantees the transfer can actually happen if every other option has been tried, using ibb.
  112. Link Mauve And I guess your client is just misconfigured?
  113. coyo i doubt that's it. isnt disco supposed to discover things like bytestream proxies automagically?
  114. coyo why dont clients choose sane defaults?
  115. Link Mauve Which client are you speaking about?
  116. coyo i mean, in theory, things like NATs should not exist at all.
  117. mathieui coyo, because there are only few implementations of Jingle FT already, I guess it’s hard to test against, and there might be bugs
  118. coyo i've tested gajim, pidgin, psi, trillian, and swift
  119. coyo others i cant say either way
  120. coyo i tested three servers, darkdna.net, is-a-furry.org, furid.net when it was still up, and jabber.org
  121. mathieui coyo, you would have to produce an xml dump of the session to be able to understand what is going on
  122. coyo i can retest, maybe it changed
  123. coyo oh, okay. give me a few hours, and i'll perform a battery of tests. most xmpp clients can log full xml streams, i think
  124. mathieui well, I’m going to sleep
  125. coyo sleep well
  126. mathieui but if you have them tomorrow, with your credentials and personal info removed, I would be happy to check what’s going on
  127. mathieui thanks
  128. Link Mauve I’m also going to sleep, tomorrow will be a long day…
  129. coyo /topic
  130. coyo huh.
  131. utapyngo Can't launch dev version Windows
  132. utapyngo D:\Pro\gajim>launch.bat D:\Pro\gajim>cd src D:\Pro\gajim\src>gajim.py D:\Pro\gajim\src>cd .. D:\Pro\gajim>
  133. utapyngo And nothing...
  134. utapyngo D:\Pro\gajim\src>python -V Python 2.7.6
  135. utapyngo I have installed the dependencies from https://trac.gajim.org/wiki/Win32Env
  136. utapyngo Sorry, did not set PYTHONPATH to point to python-nbxmpp directory.
  137. utapyngo But I had to run gajim.py with IPython to understand this.
  138. bot RSS: Feeds for Gajim • Win32Env edited (diff) https://trac.gajim.org/wiki/Win32Env?version=25
  139. bot RSS: Feeds for Gajim • JingleFileTransfer edited updat[…] https://trac.gajim.org/wiki/JingleFileTransfer?version=7 • [] • [] • [] • []
  140. bot RSS: Feeds for Gajim • BOSH edited update links (diff) https://trac.gajim.org/wiki/BOSH?version=15 • PluginSystem edited update links (diff) https://trac.gajim.org/wiki/PluginSystem?version=33
  141. bot RSS: Feeds for Gajim • Ticket #7671 (Options to set authentication mechanisms) created To enable the fix ​https://python-nbxmpp.gajim.org/ticket/20 an options to set authentication mechanisms muss be created. https://trac.gajim.org/ticket/7671
  142. bot RSS: Feeds for Gajim • Changeset [15367:ed16c3055b3a]: New option 'authentication_mechanisms' Fixes #76[…] https://trac.gajim.org/changeset/ed16c3055b3aa193ddb00a1f437a93d8d51d4a33 • Ticket #7671 (Options to set authentication mechanisms) closed fixed: In ed16c3055b3aa193ddb00a1f437a93d8d5[…] https://trac.gajim.org/ticket/7671#comment:1 • Cha[…] https://trac.gajim.org/changeset/dede4d2cb5546fd7ee90dc29fa76c402add090e2
  143. xmt Is the prosody room broken for any one else?
  144. mathieui yes
  145. Asterix they pobably run a poor jabber server ;)
  146. xmt ;o
  147. Asterix yeah I have a windows build with audio!
  148. Asterix (it still crashes on exit though ...)
  149. Asterix and now an installer! it is 41.4M with gstreamer / farstream, it was 25M before ...
  150. Asterix outgoing video seems to work (win -> linux) both when we initiate and when we receive the call, but incoming video does not start
  151. bot RSS: Feeds for Gajim • Ticket #7668 (Registration of a new account on Server with self-signed SSL-certificate …) updated Status changed could you try 0.16 beta2 release? Things have changed about that. https://trac.gajim.org/ticket/7668#comment:1
  152. xmt Asterix: You can probably strip a bunch of those binaries I sent you.
  153. xmt Hopefully bring the size down.