jdev - 2020-01-25


  1. Guus

    I've never touched the functionality. It was put in by Jive, at the time. I think we used it with Nimbuzz, at the time. Must've been 2006 or something. I never get questions around it though.

  2. Jannie

    https://bit.ly/DateMeDaddy

  3. flow

    IIRC ejabberd also supports extended stanza addressing and MAXS makes use of it

  4. defanor-tmp

    Hello. Slightly off-topic, but I'm failing to join this room using my regular client (currently using the web interface on xmpp.org), apparently my server fails to connect to muc.xmpp.org (208.68.163.210:5269); is it just me, or a common issue? And I've only tried that after failing to subscribe to the jdev mailing list (HTTP 403 there), is it also a common issue?

  5. MattJ

    defanor-tmp: hi

  6. MattJ

    Not a common issue, pretty much everyone here is joined from their own server

  7. defanor-tmp

    Is 208.68.163.210:5269 the correct address? I failed to connect there directly from my computer (different network/ISP/country) too.

  8. MattJ

    I can check jdev subscription is working later

  9. MattJ

    Not sure of the IP (I'm currently on my phone so can't easily check DNS)

  10. defanor-tmp

    And netcat from the server also says that connection times out.

  11. MattJ

    Oh, 5269? Pretty sure that's the wrong port at least

  12. defanor-tmp

    Thanks, I'll try to investigate why that happens then. It's Prosody that picks it.

  13. defanor-tmp

    "dig srv _xmpp-server._tcp.muc.xmpp.org" says "_xmpp-server._tcp.muc.xmpp.org. 900 IN SRV 1 1 9269 xmpp.xmpp.org."

  14. MattJ

    Prosody would always look up the SRV first, and would only use 5269 by default if that fails to resolve

  15. MattJ

    Debug logs from Prosody would help

  16. defanor-tmp

    Hrm, though not from the server. Apparently an issue with DNS there, Prosody is what I'm using.

  17. defanor

    It was a DNS issue indeed, the server tried to use ISP's DNS instead of a local one. Which for some reason didn't serve SRV records, and somehow Prosody didn't pick it up from alternative DNS servers (which do serve those).

  18. defanor

    And the on-topic question I had is about reusable XMPP client implementations. I keep looking for relatively complete (in the "advanced client" compliance suite sense) libraries providing C API, implementing XMPP correctly, and embeddable into a program's main loop (instead of using their own or, say, glib's), but not finding much. I also keep wondering whether it's viable to implement it in a way that would allow to define the core and

  19. defanor

    each XEP separately (in the hope to achieve a relatively clean/maintainable implementation): apparently it can be (and sometimes is) mostly achieved using some kinds of hooks on stanza (and other depth-1 element) sending and retrieval, but it still wouldn't suffice for the "direct TLS" XEP (and possibly some others). Are there known attempts to do that, and/or is it known to be futile?

  20. lovetox

    i would not do that

  21. lovetox

    there are XEPs that make sense as its own module pluginable etc

  22. lovetox

    but others absolutely not

  23. lovetox

    like 0368

  24. lovetox

    nobody will want to disable that

  25. defanor

    Indeed, that's the "direct TLS" one I've mentioned. It made me to think of hooks on all the I/O actions instead of just XML element sending/retrieval, but then it'd probably be a mess of its own.

  26. lovetox

    i just rewritten a library

  27. lovetox

    and most clients would want the library to pass the domain, and the library should connect and do everything on its own

  28. lovetox

    there are still many things to consider

  29. MattJ

    I also agree with that (having worked on a number of libraries)

  30. MattJ

    The way XEPs are split does not necessarily match the ideal split in a library

  31. jonas’

    as a library author: don’t make the low level stuff plugins

  32. jonas’

    it’s a terrible choice which only leads to heartache. instead, make your core modular so that people who want to experiment with low-level stuff (like '386 or compression or something) can easily do so in their own fork

  33. jonas’

    99% of users won’t want to do this

  34. jonas’

    they just need additional payloads for standard elements -> make *that* easy

  35. lovetox

    - DNS resolution and connection priority (suprisingly complicated) - Happy eyeballs - Proxy Support - Other connection method support (e.g. Websocket) - DIRECT TLS, START TLS, Unencrypted - Support for Client certificates - Support for functioning with non- valid server certificates and thats just out of my head, and thats all *before* you send a single stanza

  36. defanor

    I see, thanks. I'm not writing a library though, since it seems rather wrong to add yet another one, given that there's quite a few already. Yet finding it puzzling that there's nothing in sight that could be reusable from arbitrary languages via C FFI, complete, and hookable to an external main loop (say, glib's/GTK's, libev's, or whatever the program using that library would want to use). Am I missing something, and/or does such

  37. defanor

    flexibility seem like a bad idea?

  38. jonas’

    defanor, I guess the C libraries could be made to be usable that way

  39. jonas’

    I forgot the name of the library used by profanity, but it’s in C

  40. jonas’

    howevre, working with XML and text in C is a PITA, so nobody wants to do that

  41. jonas’

    and people prefer to write an idiomatic library in whatever more high-level language

  42. defanor

    libstrophe, but IIRC profanity struggles to introduce even XEP-0198 for years with it

  43. jonas’

    which makes sense to me -- a native library is more likely to be idiomatic and useful for the language ecosystem either way

  44. jonas’

    oh and yeah, libraries created before the widespread use of '198 are likely to be in pain (looking at you, libpurple)

  45. jonas’

    '198 is one of the things you absolutely don’t want in a plugin

  46. MattJ

    Yeah, I used to use (and contribute to) libstrophe

  47. defanor

    i've added 0198 into libpurple more than an year ago, but it's still not released

  48. jonas’

    it’s hard enough to get right even when having full access to the stack’s internals

  49. MattJ

    jonas’: FWIW I've implemented it in a plugin on the client and server side, I don't think it's that bad

  50. lovetox

    defanor, 0198 its not "hard" or "complicated"

  51. jonas’

    MattJ, mod_smacks isn’t that bad? ;)

  52. lovetox

    but a library should have that in mind when written

  53. lovetox

    otherwise it gets almost impossible if you have bad luck

  54. flow

    > lovetox> defanor, 0198 its not "hard" or "complicated" I am not sure i'd put it that way given that most implementations of xep198 ran into the same set of issues at first

  55. defanor

    Yes, that's what also seems awkward about relying on core modifications to implement XEPs.

  56. MattJ

    jonas’: mod_smacks has issues (but it works), I don't think they necessarily stem from it being a plugin

  57. Holger

    The hard thing about 0198 is counting!

  58. jonas’

    counting the right things

  59. MattJ

    I disagree, we haven't had a counting bug for a very long time

  60. Holger

    "1 stanza", "2 stanzas", "3 stanzas", "oh wait let's do something else" ... "2-and-a-half stanzas" ... "damn how many stanzas have I seen again I'm lost!"

  61. MattJ

    The XEP says what to count and (now) when counters get reset

  62. flow

    yep, the xep198 clarifications that where added likely helped to improve the situation

  63. MattJ

    How do you get distracted during stanzas_received++? :)

  64. Holger

    Threads and stuff.

  65. Holger

    No idea actually :-)

  66. Holger

    I'm just not sure I've ever seen an implementation that got it right from start. And I think at least ChatSecure is still borked.

  67. MattJ

    We did have bugs in the early days, but again I don't see that they were caused by it being a plugin

  68. flow

    I am not sure if what holger described actually borks the implementations, but it sure was/is identifying the point where to reset the counter and start counting

  69. flow

    MattJ, same

  70. MattJ

    I think the main reason it shouldn't be a plugin is for the library maintainer's sanity

  71. Holger

    flow: That was one multiple problems I've seem implementations running into, and it's good this one has been clarified in the XEP, yes.

  72. Holger

    *one of

  73. MattJ

    It's hard to ensure you have the right plugin API and all the plugins interact correctly

  74. Holger

    But e.g. both ejabberd and Conversations were running into threading foo that was unrelated to "when to start counting", initially.

  75. MattJ

    Threads are the root of all evil

  76. jonas’

    MattJ, one thing which went "wrong" in aioxmpp was that a stanza which caused an exception during processing would not be counted

  77. jonas’

    MattJ, one thing which went "wrong" in aioxmpp was that a stanza which caused an exception which terminated the stream (really bad) during processing would not be counted

  78. jonas’

    this would cause the stream to reconnect and resume

  79. jonas’

    causing a fun tight reconnect loop

  80. Holger

    MattJ: Yeah.

  81. jonas’

    admittedly, many problems at play here, but still.

  82. Holger

    jonas': Exactly, stuff like that.

  83. jonas’

    (reconnect loop because the stanza would be re-received during resumption)

  84. MattJ

    jonas’: I'd argue that not counting a stanza you haven't processed is sensible from a data loss perspective

  85. jonas’

    MattJ, define "have not processed" please

  86. MattJ

    In Prosody we are moving 198 to core, it's my ideal that we wouldn't back until the stanza is committed to storage or delivered, for example

  87. MattJ

    Not sure we'll achieve that, it's Hard

  88. jonas’

    if I auto reply with <service-unavailable/>, is that "processed"?

  89. MattJ

    Sure

  90. jonas’

    if I reply with (I don’t recall what we do) because of a deserialiser error, is that "processed"?

  91. jonas’

    because that’s exactly what (should’ve) happened in the above example (that the deserialiser error broke the XMLStream instead of properly being handled was a different issue)

  92. MattJ

    If you reply of course it's processed

  93. jonas’

    (scrolling through `git log aioxmpp/stream.py`)

  94. jonas’

    MattJ, I mean, what you say makes sense, but it’s hard to get that into code right from the beginning

  95. jonas’

    there are dragons and nasal demons very close due to fun race conditions (even without threads)

  96. jonas’

    maybe race condition isn’t the right term, but edge case is.

  97. jonas’

    https://github.com/horazont/aioxmpp/commit/f9af3cb485e9b6d7bc0d76d10e919aa76e822872 that’s the one

  98. jonas’

    oh, no, that’s a different one

  99. jonas’

    that was when parsing errors didn’t even propagate to the SM implementation

  100. jonas’

    finding the right place to count "stanzas" wasn’t easy, and it took more than one iteration

  101. lovetox

    what impl get wrong mostly is not how to count

  102. lovetox

    is when to start

  103. lovetox

    and its not when you receive the first stanza

  104. lovetox

    its also not after the server sent you <enabled>

  105. lovetox

    which probably is the most common pitfall

  106. jonas’

    what?

  107. jonas’

    I’m pretty sure it is

  108. jonas’

    I’m pretty sure you start to count inbound after you received <enabled/>, and outbound after you sent <enable/>

  109. jonas’

    which is the only way to make this reliable

  110. flow

    jonas’, probably lovetax was talking about counting outbound stanzas

  111. flow

    jonas’, probably lovetox was talking about counting outbound stanzas

  112. jonas’

    flow, I got confused by "its not when you receive the first stanza", sounds like inbound to me

  113. hrithik

    Guys i need your help

  114. hrithik

    .setXmppDomain("admin@192.168.1.9") .setPort(5280) .setHost("192.168.1.9") .setResource("Rooster")

  115. hrithik

    when connecting with client it showing error as (client not connected to server message not sent ) how to resolve it?

  116. jonas’

    what library is that even?

  117. hrithik

    smack library

  118. jonas’

    java?

  119. hrithik

    yes

  120. jonas’

    flow, ^

  121. jonas’

    though one thing which stands out right away is that using bare IP addresses is asking for trouble.

  122. Zash

    and a nodepart passed to something called set domain

  123. Zash

    and the standard bosh port

  124. jonas’

    that’s probably not good either

  125. Zash

    and also everything

  126. hrithik

    DomainBareJid domainname = JidCreate.domainBareFrom("192.168.1.9"); XMPPTCPConnectionConfiguration conf = XMPPTCPConnectionConfiguration.builder() .setXmppDomain("admin@192.168.1.9") .setPort(5280) .setHost("192.168.1.9") .setResource("Rooster")

  127. hrithik

    i have my server in another system

  128. hrithik

    how to set connection with server and client(mobile)

  129. lovetox

    yeah jonas’ but thats counter to most of other XMPP flows

  130. lovetox

    normally you send a IQ get, receive a set, then something happens

  131. lovetox

    or you negotiate something with, <xxx> and get back <succeeded>

  132. lovetox

    etc

  133. lovetox

    and thats probably the first intention when implementing smacks

  134. lovetox

    we enable, wait for response <enabled> then we start doing our thing

  135. xmppnoob

    hi everyone. not sure if this is the right place for the questions i have, but maybe you can give me some pointers. i'm trying to build an xmpp client for my organization (web and mobile), on mobile i'm using smack for android which is great (haven't started ios yet...). on web, my search has led me to strophe library, which sadly i coudn't even compile (dirs and files unexistent) and xmpp.js, (node-xmpp rewrite) which i'm currently testing, the basic demo covers connection, send and receive messages, pretty useful, but i'm struggling on finding documentation on some other topics (roster management, file transfer, etc.), do you know and recommend some other library?

  136. MattJ

    Hi xmppnoob

  137. MattJ

    Take a look at converse.js <https://conversejs.org>

  138. MattJ

    strophe.js is generally a low-level library, so there is a lot of DIY involved, though it does have a bunch of plugins that handle some tasks for you

  139. MattJ

    converse.js is a more featured client on top of it, which handles lots more stuff, and is easily customizable/embeddable

  140. MattJ

    Also if you're working on clients, take a look at https://docs.modernxmpp.org/client/protocol/ which has a bunch of relevant notes

  141. xmppnoob

    thanks MattJ, i'm a little confused about conversejs, it is a client or a library?

  142. MattJ

    It's primarily a client, but it has an API that you can use to control/customize it with your own code

  143. xmppnoob

    great! i'll give it a try