XSF Discussion - 2020-03-24

  1. jonas’

    07:10:43 pollo> TIL jitsi meet is mainly an XMPP frontend 07:11:01 pollo> I find it very amusing, since I felt XMPP was kinda dead

  2. jonas’

    am I seeing this correctly that we don’t actually have a spec for multi-user A/V calls?

  3. jonas’

    if so: does anyone have contacts to the Jitsi Meet folks so that we can get them to spec their stuff?

  4. Link Mauve

    jonas’, Jitsi people wrote CoLiBri, which is what Jitsi Meet is using, AFAIK.

  5. jonas’

    Link Mauve, where is that?

  6. Link Mauve

    In some XEP I don’t remember the number.

  7. jonas’


  8. jonas’


  9. Link Mauve

    It describes jicofo.

  10. Link Mauve

    As well as COIN.

  11. jonas’

    that’s it, yes

  12. jonas’


  13. Link Mauve

    Another XEP.

  14. jonas’


  15. jonas’


  16. Link Mauve


  17. jonas’


  18. Link Mauve

    I don’t know how different the implementation is nowadays, though.

  19. Link Mauve

    It may have significantly diverged, or not.

  20. MattJ

    I believe it has diverged a lot and there was not much interest in fixing that

  21. flow

    that is my understanding too

  22. flow

    Is muc 333 supposed to be alone in an unsubscribe message?

  23. flow


  24. flow

    I have somehow the feeling that this was the intention, to keep backwards compatiblity

  25. flow

    but then I saw this: https://github.com/igniterealtime/Smack/pull/374

  26. flow

    xep45 is not really clear on that (beside the examples showing 333 never alone)

  27. flow

    jonas’, ^

  28. Zash

    s/unsubscribe/unavailable/ ?

  29. jonas’

    flow, hmmmm?

  30. jonas’

    flow, 333 is an additional code which specifies which type of kick it was, using it alone doesn’t make much sense IMO.

  31. MattJ


  32. flow

    Zash, correct

  33. flow

    jonas’, but is it required to never appear allone?

  34. flow

    IMHO, if so, xep45 should spell it out explicitly

  35. jonas’

    I wouldn’t say it’s required

  36. jonas’

    I would say currently there is no specified case where that happens

  37. flow

    well allowing 333 standalone has backwards compatiblity issues

  38. flow

    Zash, MattJ, since the bug report come from the jitsi folks, I'd assumed that it was potentially prosody producing those unavailable presence stanzas. Is this the case?

  39. MattJ

    Ah, now I remember

  40. MattJ

    this whole discussion

  41. MattJ

    I'm confused, what's the bug on the Smack side?

  42. MattJ

    Not treating unavailable presence as "client left the room"?

  43. MattJ

    status codes are colour on top of that

  44. jonas’

    yup, 333 without anything should be treated as "client left normally" by any entity not knowing 333

  45. MattJ

    There was some discussion about whether 333-type leaves should be parts or kicks

  46. MattJ

    The argument is that they are kicks because the user didn't request to leave

  47. flow

    I totally aggree that status codes are additional metainformatino and that unvaialble presence means that a participant has left the room

  48. Zash

    I distinctly remember some client having a bug with multiple status codes

  49. MattJ

    While the inverse argument is that it's not a moderation thing, and kicks are noisy

  50. flow

    The question is about allowing 333 standalone in an unavailble presence

  51. flow

    I think allowing 333 standalone causes backwards compatiblity issues and hence should not be allowed

  52. MattJ

    What problems does it cause?

  53. flow

    MattJ, basically smack assumes that if the unavailable presence contains any status codes, one of those codes it at least one that has been there from the very beginning of xep45

  54. jonas’

    flow, I think that assumption is flawed

  55. MattJ

    I think that's definitely a flawed assumption

  56. jonas’

    status codes are a registry

  57. flow

    jonas’, potentially, but I could imagine that other libs do the same

  58. jonas’

    then other libs are also flawed

  59. MattJ

    Well so far we haven't found any

  60. MattJ

    Also this is why the status codes likely aim to follow the HTTP style of buckets

  61. flow

    I am also not convinced that this assumption is really flawed

  62. MattJ

    all the 3xx status codes are about an occupant leaving, afaik

  63. flow

    I mean I see your point

  64. MattJ

    This would have been done initially to make status codes extensible

  65. MattJ

    Not that I see much point in this case

  66. flow

    but adding additional causes that do not refine existing causes seems like a bad approach

  67. jonas’

    flow, unless you can find a piece of text in XEP 0045 which says that on an unavailable presence, there must be no status code or one of these X status codes, your assumption is flawed

  68. flow

    and in this case 333 seems to simply refine an existing cause ('kicked')

  69. MattJ

    Actually no, in this stanza before Prosody added 333 there would have been no status codes

  70. jonas’

    flow, a future status code could be refining the voluntary client leave, for example "leaving forever not going to come back"

  71. MattJ

    So we went from nothing -> 333

  72. jonas’

    the library still needs to be able to deal with that

  73. MattJ

    333 was just additional colour for the leave

  74. MattJ

    (iirc trunk nightly builds may have used a kick status code for a while, before 333 was introduced - but I don't think that was ever in a released version)

  75. flow

    Either way, it should be explicitly spelled out in xep45 what clients to can expect

  76. jonas’

    flow, I think it’s already pretty clear

  77. jonas’

    there are some requirements about status codes which MUST be present

  78. jonas’

    but there’s no wording on which are not going to be present

  79. jonas’

    so you’ve got to deal with that

  80. jonas’

    (just like there’s no wording on the order of status codes, you need to deal with any ordre)

  81. flow

    I would at least suggest to add an example where 333 appears standalone

  82. jonas’


  83. jonas’

    there’s currently no defined use-case for that

  84. flow

    then why does prosody do it?

  85. MattJ


  86. flow

    MattJ, thanks for the link :)

  87. MattJ

    (and discussion before/after)

  88. jonas’


  89. jonas’

    MattJ, make a PR against '45 then, because 45 clearly states that there MUST be 307 at this time

  90. MattJ

    So I see, that's news to me

  91. jonas’

    only in the GC1.0 case though wtf

  92. jonas’


  93. MattJ

    Basically the fallback behaviour we want (for UX reasons) is a normal leave, not a kick

  94. jonas’


  95. MattJ

    because kicks were making users "wtf"

  96. jonas’

    here it’s not clearly spelt out: https://xmpp.org/extensions/xep-0045.html#service-error-kick

  97. flow

    yep, users don't like to get kicked

  98. jonas’

    so it can go either way

  99. jonas’

    MattJ, I suggest someone makes a PR which states that and fixes the wording then.

  100. flow

    jonas’, for clarification: states what?

  101. jonas’

    https://xmpp.org/extensions/xep-0045.html#service-error-kick shouldn’t use 307

  102. jonas’

    flow, that https://xmpp.org/extensions/xep-0045.html#service-error-kick shouldn’t use 307

  103. Ge0rG

    something something somebody suggested a specific error condition just for that

  104. flow

    Ge0rG, what is it, that you want to tell us?

  105. Ge0rG

    flow: IIRC jonas’ had interesting ideas for a new error condition that's neither kicked nor access denied, in the context of 0410

  106. jonas’

    Ge0rG, irrelevant, because MUC leaves don’t have stanza errors

  107. Ge0rG

    Also we abandoned that idea because nobody had time to pursuit it

  108. moparisthebest

    so much for the military using XMPP https://www.theregister.co.uk/2020/03/18/army_adopts_whatsapp_orders_coronavirus

  109. Zash

    There's more than one army

  110. Zash

    and more than one branch of military

  111. mbt

    hi all, im trying to develop an messaging app with React-Native. I have Prosody server installed and i can send/recieve messages but cant complete in-band registration. i couldnt find a package for that. Does anyone know how to do it in RN environment? Thanks

  112. Ge0rG

    mbt: are you using xmpp.js?

  113. Ge0rG

    looks like it's a lonstanding wish... https://github.com/xmppjs/xmpp.js/issues/783

  114. mbt

    yes i use xmpp.js for connection and messaging, in those topics 'https://xmpp.org/extensions/xep-0389.html' is offered but i cant understand how can do these instructions

  115. Zash

    XEP-0389 is not really ready yet

  116. Zash

    https://xmpp.org/extensions/xep-0077.html is what you would use

  117. mbt

    okay thanks, i can send iq stanzas with xmpp.js. Then should i use 0077s iq examples?

  118. Zash

    If you can do that before you're fully connected, then I guess that'll work

  119. mbt

    okay then i will try this thank you very much Zash, Ge0rG

  120. Jeybe

    Just disovered Kontalk. Somebody knows if they federate?

  121. moparisthebest

    last I looked they do yes

  122. Daniel

    But you have to manually hash the phone number to talk to someone on kontalk. With Quicksy.im you can just write +12345...@quicksy.im #shamelessPlug

  123. moparisthebest

    quicksy is ever so slightly easier to un-hash into a plain phone number though :)

  124. Zash

    JIDs like sha1(phone number)@beta.kontalk.net from what I could find on some wiki

  125. MattJ

    But SHA1 is broken! ;)

  126. moparisthebest

    yep, where phone number is +12223334455

  127. moparisthebest

    https://www.moparisthebest.com/phonehash/ this doesn't work anymore because I no longer have 500gb to spare but it "unhashed" kontalk numbers instantly

  128. MattJ

    500GB? I feel like you could get away with far less than that

  129. Zash

    Rainbow tables aren't known for being small

  130. MattJ

    I guess

  131. Zash

    I guess you could cheat and only store the shortest prefix or something

  132. Daniel

    Iirc it wasn't a rainbow table but just all hashes

  133. Zash

    Have I misunderstood what a rainbow table is?

  134. Daniel

    I always wanted to make it a nice weekend project to learn how to build rainbow tables and actual have all possible numbers

  135. Daniel

    Rainbow tables only store a subset of hashes

  136. moparisthebest

    rainbow tables could maybe be smaller, but still are computationally expensive

  137. moparisthebest

    500gb was all numbers, stored as 5 byte integers, sorted by hash, so I could binary search them and do at most like 5 sha1 operations to find any number instantly

  138. jonas’

    ah, I knew it was something clever

  139. moparisthebest

    all the technical details here https://github.com/moparisthebest/phonehash it's actually not clear to me if rainbow tables would actually be smaller or not

  140. Ge0rG

    moparisthebest: why didn't you upload the 500GB to github? :D

  141. moparisthebest

    I don't think it supports that haha, but the code to generate it is there

  142. Ge0rG

    In Germany, phone numbers are 12 or sometimes even 13 digits.

  143. moparisthebest

    yep, doesn't support any of that nonsense either :)

  144. moparisthebest

    I guess it'd still fit in a 5 byte number but you'd need significantly more than 500gb to store them all, unless you just went for a subset

  145. moparisthebest

    don't really feel like doing the math to figure out how much data that is right now :)

  146. Ge0rG

    the fixed prefix is +49, leaving 10 or 11 useful digits

  147. Ge0rG

    you'd have to cut the prefix off or go for six-byte indexes

  148. moparisthebest

    ah ok that changes things, I'm storing 11 digits there, so you'd just do the same except prefix +49 instead of +

  149. rion

    looks like there is something wrong with s2s with this new xmpp.org. I checked two Russian servers with quite old ejabberds. none of them allowed me to connect here.

  150. Zash

    How old is old?

  151. rion


  152. rion

    and 2.1.13

  153. rion

    oh. it's not s2s. I see myself in the web logs joining here

  154. rion

    hm or s2s.. well muc sent me nothing back

  155. rion

    but obviously received and handled my presence

  156. Zash

    So the connectivity problem is in the other direction

  157. moparisthebest

    won't connect to TLS 1.0 or something?

  158. rion

    ok jabber.ru admin say s2s is connected. there is something upper-level

  159. Zash

    I vaguely recall there being all sorts of s2s issues between prosody and ejabberd back in those dark ages

  160. Zash

    MattJ: poke? ↑

  161. Zash

    I don't have access to the new box

  162. MattJ

    Uh, can get you access in a bit

  163. MattJ

    No idea what would cause this

  164. Zash

    rion: Did this that work before the crash?

  165. rion


  166. Zash

    All I can think of is some kind of network or DNS issue on the new box

  167. flow

    hmm Dele also reported that his openfire (?) instances could no longer connect to xmpp.org

  168. flow

    I was speculating TLS

  169. Zash

    No TLS 1.2?

  170. Zash

    I'd say 'try xmpp.net' but that's not up yet

  171. MattJ

    Ah, it's Debian buster so it could indeed be TLS

  172. Ge0rG

    Old software still attempting SSL 3?

  173. pep.

    Who doesn't do TLS1.3 yet? /s

  174. Zash

    If I'm guessing their domain correctly then that's not the problem. I get a Dialback error instead.

  175. rion

    does s2s uses 2 connections between 2 particular servers?

  176. jonas’


  177. Kev

    Usually at least 2, yes.

  178. jonas’

    (most of the time actually)

  179. Ge0rG

    Yes, for hysterical raisins

  180. jonas’

    there’s s2s bidirectional mode, but it’s not too widely deployed

  181. rion

    so usually 2 uno-directional

  182. rion

    jabber.ru guys looking into the problem too.

  183. rion

    [23:15:45] *** rion2 заходит как участник [23:15:46] *** rion2 удален из комнаты по техническим причинам that was me from jabber.ru

  184. Zash

    what looks like this here? 18:14:44 ---> rion joined the room 18:14:45 <--- rion has left the room due to an error (Kicked: remote server not found) 18:15:25 ---> rion joined the room 18:15:26 <--- rion has left the room due to an error (Kicked: remote server not found)

  185. Zash

    Oh, rion_2_?

  186. rion


  187. Zash

    s2s with jabber.ru seems to work everywhere else I try

  188. rion

    Psi writes: removed by technical reasons. I don't remember what's this in xml log

  189. Zash

    Pretty sure it's the 333 code discussed earlier

  190. Zash

    It's what Prosody uses if you send an error to the room, which is what it sees if the s2s connection in the other direction fails

  191. MattJ

    rion, Zash: from the log: Mar 24 20:47:28 server_epoll debug TLS handshake error on FD 231 (, 5269,, 33976): dh key too small

  192. jonas’

    ah, yeah, jabber.ru

  193. pep.

    What was the result of the discussion around Inbox again at Summit. The "ordered list" of tabs doesn't seem mentioned in the minutes, I assume that's supposed to be something separate

  194. oxpa

    took me awhile how to figure this out. I'm curious why p256 is 'short' though

  195. Zash

    If you get that message then it's not using ECDHE

  196. Zash

    That's plain old DHE

  197. Zash

    probably with 1024bit parameters

  198. oxpa

    :~$ openssl s_client -connect jabber.ru:5269 -starttls xmpp-server 2>/dev/null | grep Temp Server Temp Key: ECDH, P-256, 256 bits

  199. oxpa

    Or may be it's because it's not ephemeral though

  200. oxpa

    not sure how to force that through s_client to check

  201. Zash

    ~$ wrapsrv _xmpp-server._tcp.jabber.ru openssl s_client -connect %h:%p -starttls xmpp-server -cipher 'HIGH+kEDH:HIGH+kEECDH:HIGH:!PSK:!SRP:!3DES:!aNULL' this would be closer to what prosody 0.11 does

  202. Zash

    Server Temp Key: DH, 4096 bits

  203. Zash

    Odd. Recently changed?

  204. oxpa

    i tend to answer 'no' in a most sarcastic way, usually. But I guess sarcasm is difficult to transfer through xmpp. So, yes, minutes ago

  205. oxpa

    but what's curious is that DHE is used only when I try a longer EC curve

  206. oxpa

    that's why I was asking about P256

  207. oxpa

    openssl s_client -connect jabber.ru:5269 -starttls xmpp-server -curves secp384r1 this is a curve my openssl doesn't yet support so this results in using DH instead of ECDH

  208. Zash

    Oh no, I didn't want to be reminded of how OpenSSl handles curve

  209. oxpa


  210. oxpa

    but I have to change dh param default length due to this handling >_<

  211. Neustradamus

    pep.: Jabber.org has this problem since several years ;)