jdev - 2020-10-05

  1. chr

    hi guys, can any one help me on best xmpp client to use in react native application?

  2. Ge0rG

    chr: there is no ready-made client with UI, but you can use xmpp.js

  3. bala

    hi can we add xmpp to laravel 5+?

  4. bala

    or we want to use any nodejs and react js only?

  5. marmistrz

    I might've asked, is there anything on par with xmpp.js for typescript?

  6. Ge0rG

    marmistrz: I'm not aware.

  7. Zash

    https://github.com/legastero/stanza mayhaps

  8. edhelas

    bala to Laravel ?

  9. sonny

    (author of xmpp.js here) xmpp.js has the best RN support AFAIK but is very low level compared to stanza https://github.com/legastero/stanza/blob/master/docs/React_Native.md

  10. sonny

    if you're not that familiar with xmpp or need builtin TypeScript I'd recommend stanza

  11. sonny

    some people have shared their TypeScript definition for xmpp.js https://github.com/xmppjs/xmpp.js/issues/542

  12. lovetox

    hm is just a localpart a valid JID?

  13. lovetox

    hm my parsing logic says JID("asd")

  14. lovetox

    is a valid jid

  15. lovetox

    what JID parsing rule should prevent that?

  16. Zash

    lovetox: not

  17. lovetox

    ah i think its recognized as domainpart

  18. lovetox

    and IDN2008 allows that?

  19. sonny

    a domain is a valid jid

  20. lovetox

    hm yes seems its a valid domain

  21. lovetox

    yes is know

  22. lovetox

    but i didnt think "asd" is a valid domain

  23. lovetox

    seems i was wrong

  24. jonas’

    why wouldn’t it be?

  25. lovetox

    because a rule exists that says otherwise

  26. Ge0rG

    with the ICANN going wild with gTLDs, you can't sensibly restrict what a domain name is.

  27. Ge0rG

    Also you can have local hostnames without a TLD

  28. Ge0rG

    and things like xmpp.server.local

  29. Zash

    or localhost

  30. Ge0rG

    and IP addresses.

  31. Ge0rG

    IP addresses are legitimate XMPP domains.

  32. flow

    lovetox> but i didnt think "asd" is a valid domain it is a valid DNS name

  33. flow

    it's mapped to "asd." fwiw

  34. bala

    yes edhelas

  35. bala


  36. edhelas

    bala laravel is mostly an async framework, good for rest and stuff like that

  37. edhelas

    if you want to do XMPP stuff in PHP there's not a lot of choices afaik

  38. bala

    okay edhelas thank you very much.

  39. edhelas

    where do you want your XMPP connection to sit ? server side or browser side ?

  40. bala

    edhelas need both

  41. edhelas


  42. bala

    We need to integrate chat feature on our mobile app.

  43. bala

    How can we get started with XMPP?

  44. edhelas

    what is your mobile app architecture ?

  45. bala

    We are going to have iOS and android apps. What do you mean by architecture in specific?

  46. edhelas

    well, so two native apps, with a REST backend ?

  47. bala

    Yes,Its a Rest backend

  48. bala

    the app is an enterprise one, with different types of users.

  49. bala

    We need to enable chat among users.

  50. edhelas

    and the android app and ios app are writen in Java/Kotlin/Swift/ObjectiveC ?

  51. bala

    Yes, exactly. Java for Android and Swift for iOS

  52. edhelas

    well, then I advise you to use native Java and Swift XMPP libraries then :)

  53. edhelas

    you'll have to figure out how to create accounts/authenticate them in sync with your REST accounts ones

  54. bala

    Well.We need to integrate XMPP on our backend, right?

  55. edhelas

    why ?

  56. bala

    Well.We need to integrate XMPP on our backend, right?

  57. edhelas

    is you backend connecting with other XMPP servers ?

  58. edhelas

    what is the goal of XMPP here for you ?

  59. bala

    nope. We need an XMPP server which can be used for iOS and Android apps, right

  60. bala

    For user creation, maintaining chat history and all

  61. bala

    how can we configure our XMPP server?

  62. edhelas

    so this xmpp server will be standalone, and it's only for those app users to communicate together

  63. edhelas

    then you setup the XMPP server next to your REST app, with ejabberd you can create/configure accounts using their internal REST API directly https://docs.ejabberd.im/developer/ejabberd-api/

  64. edhelas

    and you add a native XMPP lib in your mobile apps to connect to those accounts

  65. edhelas

    the only big thing I see is to figure out how to authenticate properly using server generated accounts

  66. bala

    okay thank you very much edhelas

  67. sonny

    on the backend, you can use ejabberd with https://github.com/processone/ejabberd-contrib/tree/master/ejabberd_auth_http or an other xmpp server supporting some kind of similar integration

  68. edhelas

    sonny 👍

  69. sonny

    edhelas 👍

  70. lovetox

    so domain.org is a bare jid?

  71. jonas’

    lovetox, yes

  72. jonas’

    domain.org/foo is a full-jid

  73. lovetox

    ok do we have a name for localpart@domainpart ?

  74. jonas’

    that’s also a bare jid

  75. lovetox

    yeah, but library wise, if i want to test for localpart@domainpart, what would i call that method

  76. lovetox

    is_bare_with_domain sounds a bit long

  77. jonas’


  78. jonas’

    (what do you need that test for, anyway?)

  79. Zash

    And http://www.example.com/ is a horror (host="xmpp:",resource="/www.example.com/")

  80. lovetox

    that does not exclude that it has a resource part..

  81. Zash

    And http://www.example.com/ is a horror (host="http:",resource="/www.example.com/")

  82. lovetox

    sometimes for example for bookmarks

  83. jonas’

    what do bookmarks have to do with that?

  84. lovetox

    it makes no sense if a jid as a resource, or is only domainpart

  85. lovetox

    a bookmark should be localpart@domainpart

  86. jonas’


  87. lovetox

    because thats how it is, only domain can not be a room

  88. lovetox

    and resource describes a certain resource

  89. jonas’

    that’s wrong

  90. jonas’

    a domain can be a room

  91. Zash

    XEP-0045 forbids it IIRC?

  92. lovetox

    Each room is identified as a "room JID" <room@service>

  93. jonas’

    either way, I don’t think it’s the job of clients to enforce that, unless it makes things more complicated to *not* enforce it

  94. jonas’

    and I think in this case, it might be more complicated to enforce it that not enforcing it

  95. lovetox

    as i said i was talking from a library standpoint

  96. lovetox

    i just wanted a name for a property that reflects that this

  97. jonas’

    I was curious and asking because I haven’t had use for such a property yet

  98. jonas’

    I think I’d just use jid.is_bare and not jid.has_localpart or something like that

  99. jonas’

    it seems like a rare use case

  100. Zash

    is_bare := not has_resource ?

  101. lovetox

    yeah, thats what i was using, just was curious if there is a technical name for that

  102. Zash

    or .. :-?

  103. lovetox

    but it seem it is not

  104. jonas’

    Zash, yes

  105. flow

    lovetox, here are the terms that jxmpp uses: https://github.com/igniterealtime/jxmpp#jxmpp-jid beware, you may not like them

  106. flow

    http://jxmpp.org/releases/1.0.1/javadoc/org/jxmpp/jid/Jid.html has some examples

  107. lovetox

    thanks flow

  108. pep.

    jid-rs uses only FullJid and BareJid (and Jid { Full(FullJid), Bare(BareJid) })

  109. flow

    pep., then your API methods can't express that they require a full jid with localpart as argument, right?

  110. pep.

    Not for the moment no, because we haven't found a place where it's necessary yet

  111. pep.

    But also the xmpp library on top isn't really much used..

  112. flow

    > because we haven't found a place where it's necessary yet MUC room addresses?

  113. pep.

    I don't think it's necessary there

  114. pep.

    I don't really want to enforce this weird restriction

  115. flow

    (that was bascially one the motivation behind jxmpp's jid types)

  116. flow

    (that was bascially one major motivation behind jxmpp's jid types)

  117. flow

    which weird restriction?

  118. flow


  119. pep.

    flow, I'm not sure why there should be a MUC component on top of a room, for example. You can disco the room itself and be just fine

  120. pep.

    (that is, not sure why you'd require a localpart to a room)

  121. jonas’

    I also think that semantically, there is little difference between foo@bar and bar

  122. jonas’

    not enough to enforce it on the type system level anyways

  123. pep.


  124. pep.

    When I got xmpp.rs I wanted to have both chat@xmpp.rs (MUC room) and bot@xmpp.rs (user account, and other accounts), because it's cool and I don't see why I shouldn't be allowed to. And while it's technically possible I've seen pain around chat@dino.im and.. :x

  125. pep.

    Technically it's only really an issue for me operator. there's no issue as long as I control what gets into this namespace (xmpp.rs)

  126. pep.

    Note that this is not exactly the issue described above, but it's the kind of things that people are afraid to do because it doesn't fit exactly what the protocol mandates for weird reasons

  127. jonas’

    well, there is a reason why that doesn’t work

  128. jonas’

    or why it’s painful

  129. jonas’

    it boils down to "how should clients discover rooms"

  130. jonas’

    the written-down protocol is that it queries via disco#items and disco#info until it finds a MUC service associated with a domain, and then it uses disco#items to find rooms

  131. jonas’

    subdomains are cheap, hence there’s no problem with that

  132. pep.

    "it boils down to "how should clients discover rooms" < that feels like UX straight from the 90s

  133. pep.

    with /list

  134. jonas’

    all of MUC is UX from the 90ies

  135. pep.

    Yeah, so by nowadays' standards some things are weird :)

  136. jonas’

    fair enough

  137. pep.

    It's not like xmpp.rs was going to host real users anyway, mostly utilities or contributors. You don't end up on chat@xmpp.rs because you found it with /list :p

  138. pep.

    Same for dino.im really

  139. jonas’

    "not real users […], mostly […] contributors"

  140. pep.

    Welll, only a few select, not like, users you want to give proper care to because they don't understand anything to the protocol :)

  141. Zash

    Will clients refuse to talk to user@host if host advertises the muc feature?

  142. pep.

    Welll, only a few select, not like, users you want to give proper care to because they don't understand anything about the protocol :)

  143. pep.

    jonas’, we all know developers are not real users

  144. jonas’

    Zash, I hear that poezio does strange things w.r.t. muc feature

  145. pep.

    Look at their clients

  146. jonas’

    pep., hah

  147. pep.

    hmm I think the thing has been fixed in poezio(?)

  148. pep.

    Ah wait, no I don't remember anything about this

  149. pep.

    There was stuff related to carbons and muc lately but that's about it

  150. pep.

    (because detecting PMs is meh)

  151. jonas’

    yeah, that was based on disco#info on the domain (incorrectly)

  152. pep.


  153. pep.

    Exactly this :)

  154. pep.

    The one place I'd see requiring a MUC service is when a client wants to create new rooms

  155. Wojtek

    quick question - should we be concerned with lenght of the stanza id? from what I gather schema doesn't limit it...

  156. pep.

    I think it's profanity that has immensely long IDs. Some kind of HMAC iirc

  157. jonas’

    Wojtek, there is no specified limit beyond the limit of th eoverall stanza

  158. jonas’

    I suggest to limit it to 1023 utf-8 bytes (or codepoints, if that’s easier for you) if you have to place a limit

  159. jonas’

    it’s the same limit as resource and localpart have

  160. Wojtek

    yeah, but that's not specified, and someone may decide well I wannna have longer IDs. would have been nice to have this in the specs IMHO

  161. Wojtek

    > it’s the same limit as resource and localpart have yeah, that seems reasonable

  162. pep.

    Which spec?

  163. pep.


  164. jonas’

    Wojtek, yeah, it would be nice to have a limit written down in '6120

  165. Wojtek


  166. marmistrz

    > https://github.com/legastero/stanza mayhaps thanks!

  167. flow

    > When I got xmpp.rs I wanted to have both chat@xmpp.rs (MUC room) and bot@xmpp.rs (user account, and other accounts) I also like that, but I don't see how this is related to a MUC address being a bare jid with a localpart

  168. flow

    Wojtek> yeah, but that's not specified, and someone may decide well I wannna have longer IDs. Then you should be worried about pub sub item IDs and (pubsub/xep30/…) node name length too

  169. Zash

    Just say 1023 octets

  170. Zash

    like JID parts

  171. flow

    Zash, note sure that simply saying it helps if we don't specify it

  172. Zash

    Someone once mentioned this issue wrt 'node' in disco and/or pubsub

  173. flow

    we could start with recommending size limits for xep359 IDs, pubsub item IDs, and node names

  174. flow

    we could, at least, start with recommending size limits for xep359 IDs, pubsub item IDs, and node names

  175. Zash

    and lack of normalization specs

  176. flow

    a lack of unicode normalization specs?

  177. Zash


  178. flow

    aren't there like, a dozen of them

  179. Zash

    I mean, for stanza ids, nodes etc

  180. flow

    apply NFC and ensure that length in codepoints is less than X?

  181. Zash

    for example

  182. flow

    leaves the question what X sould be

  183. Zash

    1023 octets!

  184. flow

    is there an argument for less?

  185. flow

    where do 1023 come from anyway?

  186. Zash

    The parts of a JID

  187. flow

    (i know it's in the jid rfc, but where does that come from?)

  188. Zash


  189. Zash

    historical raisins?

  190. flow

    so cargo cult at its finest

  191. Zash

    I prefer to call it Consistency

  192. Zash

    You could also argue that the limit should be 37

  193. flow

    sure, and if nobody comes up with an argument that the limit should be different, i'd also go with conistency

  194. Zash

    which iirc is the size of the textual form of an UUID

  195. flow

    but I could imagine that database people may have a strong feeling about the length of the primary key type

  196. Zash

    In the case of MySQL it's 20

  197. Zash

    Or 700 something.

  198. flow

    37 seems to low, at least for node names and item IDs, as these are sometimes used to carry a little bit of text with them

  199. Zash

    are node names meant to be human-readable?

  200. Zash

    If so then fun concerns apply

  201. flow

    duno, but there where at least two people who worked on a filesystem in pubsub

  202. flow

    so it does not appear to be far fetched that node names are user entered strings

  203. flow

    in some use-cases

  204. flow

    and we don't want to be the DOS of instant messaging

  205. flow

    cmon, no one?

  206. Zash

    Filenames on Linux are limited to 256 octets

  207. Zash

    ... and can contain arbitrary binary except NUL and '/'

  208. Zash

    Or just ignore the whole thing and if you need to store arbitrary-sized IDs in your database you jam them trough a hash function

  209. flow

    sure, but meh

  210. jonas’

    effectively what jabbercat does

  211. jonas’

    because of the aforementioned limit