XSF Discussion - 2019-06-26

  1. karoshi has left

  2. UsL has left

  3. Wojciech Kapcia has joined

  4. Wojciech Kapcia has left

  5. lskdjf has left

  6. Lance has joined

  7. neshtaxmpp has left

  8. neshtaxmpp has joined

  9. lnj has left

  10. alacer has joined

  11. Douglas Terabyte has left

  12. pdurbin has joined

  13. alacer has left

  14. alacer has joined

  15. alacer has left

  16. alacer has joined

  17. alacer has left

  18. alacer has joined

  19. alacer has left

  20. alacer has joined

  21. pdurbin has left

  22. Yagiza has joined

  23. alacer has left

  24. alacer has joined

  25. lumi has left

  26. lumi has joined

  27. igoose has left

  28. alacer has left

  29. alacer has joined

  30. pdurbin has joined

  31. Douglas Terabyte has joined

  32. adityaborikar has left

  33. adityaborikar has joined

  34. Douglas Terabyte has left

  35. andy has joined

  36. kokonoe has left

  37. kokonoe has joined

  38. Douglas Terabyte has joined

  39. david has left

  40. david has joined

  41. moparisthebest has left

  42. moparisthebest has joined

  43. lumi has left

  44. Nekit has joined

  45. alacer has left

  46. alacer has joined

  47. igoose has joined

  48. pdurbin has left

  49. alacer has left

  50. sezuan has joined

  51. Daniel has left

  52. sezuan has left

  53. sezuan has joined

  54. adityaborikar has left

  55. j.r has joined

  56. andrey.g has left

  57. andy has left

  58. adityaborikar has joined

  59. sezuan has left

  60. wurstsalat has joined

  61. andy has joined

  62. andrey.g has joined

  63. Lance has left

  64. Daniel has joined

  65. Daniel has left

  66. goffi has joined

  67. Daniel has joined

  68. COM8 has joined

  69. COM8 has left

  70. rion has left

  71. rion has joined

  72. karoshi has joined

  73. mimi89999 has left

  74. waqas has left

  75. mimi89999 has joined

  76. pdurbin has joined

  77. pdurbin has left

  78. lnj has joined

  79. rtq3 has joined

  80. Steve Kille has left

  81. Alex has left

  82. Alex has joined

  83. Daniel has left

  84. Daniel has joined

  85. Steve Kille has joined

  86. Douglas Terabyte has left

  87. alacer has joined

  88. Zash has left

  89. adityaborikar has left

  90. Zash has joined

  91. debacle has joined

  92. alacer has left

  93. cc has joined

  94. cc


  95. david has left

  96. adityaborikar has joined

  97. igoose has left

  98. adityaborikar has left

  99. adityaborikar has joined

  100. david has joined

  101. igoose has joined

  102. adityaborikar has left

  103. pdurbin has joined

  104. rtq3 has left

  105. adityaborikar has joined

  106. kokonoe has left

  107. kokonoe has joined

  108. Holger has left

  109. rtq3 has joined

  110. Holger has joined

  111. pdurbin has left

  112. Nekit has left

  113. Nekit has joined

  114. matlag has left

  115. matlag has joined

  116. lskdjf has joined

  117. dele has joined

  118. cc has left

  119. alacer has joined

  120. dele has left

  121. COM8 has joined

  122. rion

    fippo: now I realize who you are. nice to meet you! :-D

  123. fippo

    not very active anymore but hey, small world :-)

  124. igoose has left

  125. igoose has joined

  126. COM8 has left

  127. Nekit has left

  128. Nekit has joined

  129. Yagiza has left

  130. jcbrand has joined

  131. Yagiza has joined

  132. COM8 has joined

  133. COM8 has left

  134. Nekit has left

  135. Nekit has joined

  136. rtq3 has left

  137. jcbrand has left

  138. Nekit has left

  139. flow

    fippo, you write that "Now transport-replace is difficult... XEP-0260 uses this in odd ways to fallback from s5b to ibb.", But when I look at the sequence diagram in xep260 § 3. I don't see any oddities, seems perfectly reasonable to use transport-replace(IBB) for the IBB fallback. I would expect that this can also be applied to fallback from ICE (xep371) to IBB, or am I wrong?

  140. pdurbin has joined

  141. Nekit has joined

  142. rtq3 has joined

  143. jcbrand has joined

  144. Ge0rG

    is xmpp.net melting down currently?

  145. Ge0rG

    jonas’: can you kick it gently?

  146. jonas’

    I don’t have any power there

  147. pdurbin has left

  148. Zash

    Ge0rG: Melting?

  149. Ge0rG

    Zash: I'm running into a 504 Gateway Time-out

  150. Ge0rG

    ...when submitting 404.city s2s

  151. Ge0rG

    which my prosody also fails to connect to, apparently due to "connection closed"

  152. fippo

    flow: 0260 does a "try, determine failure, fallback" approach. ICE does the equivalent (even though not falling back to ibb) in parallel, potentially using a inferior transport (i.e. a relay) for some time. results in a better ux

  153. Zash

    works for me

  154. Ge0rG

    Zash: ah, it closes after/during TLS handshake

  155. alacer has left

  156. Ge0rG

    hm. works from my desktop PC

  157. Zash

    Is that ejabberds way of telling you it doesn't like your cert?

  158. Ge0rG

    works with openssl s_client. doesn't work from prosody

  159. Zash


  160. Ge0rG

    this is taking very long to load

  161. Ge0rG

    and also runs into the 504

  162. rion

    fippo: as @zinid said s5b has to be forgotten in favor of TURN/ICE

  163. Zash

    rion, why?

  164. fippo

    rion: well, ICE doesn't offer any ibb-fallback. Even though I would still be scared of any attempt to run a videochat over ibb :)

  165. rion

    Zash: it's mainstream now

  166. Zash

    And isn't it already forgotten in favor of HTTP upload?

  167. Daniel

    S5b meaning si file transfer or the jingle mechanism?

  168. rion

    Jingle allows to fallback from ice to ibb theoretically or to http or vice verca

  169. Daniel

    I don't see anything wrong with the jingle mechanism

  170. fippo

    zash: never declare a protocol obsolete, dead or forgotten. because what happens then is that people start using it

  171. rion

    Daniel: jingle is more or less fine but its s5b is not

  172. Zash

    fippo so dead == ready for enterprise deployment? 🙂

  173. Daniel

    rion: what's wrong with s5b?

  174. rion

    Daniel: read my remarks on wiki

  175. Daniel


  176. j.r has left

  177. rion


  178. rion

    fippo: > ICE doesn't offer any ibb-fallback Do you mean ICE xep? I see transport-replace as more general purpose approach then transport specific. Currently in Psi I added kind of transport features. like if it's slow and/or reliable etc. And an application declares which features are compatible or preferable with it (still work in progress though). So jingle core mechanism can build kind of transports priority list from just compatible transports and do replace properly.

  179. mimi89999 has left

  180. mimi89999 has joined

  181. rion

    IBB will never be selected for the RTP application :)

  182. fippo

    rion: more correctly, ice doesn't specify a candidate format for xmpp ibb. only udp and tcp transports

  183. rion

    fippo: in theory ibb allows to open substreams. so it can have one for RTP and one for RTCP. candidates are not needed.

  184. flow

    Daniel, TURN sould be used instead of (peseudo) socks5 proxies, no matter if legacy XMPP stream initiation, or jingle

  185. flow

    fippo, but from an XMPP jingle point-of-view, the jingle ICE transport chould be replaced with an IBB transport, no?

  186. Nekit has left

  187. flow

    fippo, Maybe I understand your statement wrong, so there is nothing odd with how xep260 specifies the fallback from S5B to IBB?

  188. flow

    (context for those who wonder: https://github.com/xsf/xeps/pull/793#issuecomment-505792574)

  189. Nekit has joined

  190. fippo

    flow: i don't think this kind of scenario has seen much practical use otherwise the questions rion asked would have been asked earlier

  191. flow

    fippo, is that really so? If we consider a world with S5B replaced with TURN, and legacy SI replaced with Jingle, why not keep the door open for IBB fallback as last resort?

  192. j.r has joined

  193. flow

    I think the questions did not come up earlier because rion can be considered an early-adopter, at least of the FOSS community

  194. rtq3 has left

  195. fippo

    flow: it ends up being a question of maintenance cost. ibb fallback is cool but do you need to implement it to be compliant?

  196. ralphm

    I think IBB for any kind of media transfer, real-time or not, results in unwanted pressure on servers' routing and interference with 'regular' stanzas. This starts hurting quickly with increasing numbers of users.

  197. fippo

    also IBB wreaks havoc with rate limiting mechanisms (i.e. jabberds karma)

  198. ralphm

    So although it might work, I'd explicitly strongly recommend against it.

  199. flow

    fippo, Isn't a transport-replace(IBB) replacing a previous ICE tranpsort compliant?

  200. fippo

    flow: it is. but do we have a spec saying "try transports in this order"?

  201. flow

    fippo, do we need one?

  202. fippo

    flow: how do you know whether ice is better than raw-udp or ibb?

  203. ralphm

    From XEP-0176: * In Jingle, lists of "preferred" candidates are typically sent in the Jingle session-initiate and session-accept messages, in a way that is consistent with the SDP offer / answer model described in RFC 3264 [5] and the process described in ICE-CORE. * Candidates can also be sent in separate transport-info messages either before sending the session-accept message (to expedite negotiation) or after media begins to flow (to find modify existing candidates, find superior candidates, or adjust to changing network conditions).

  204. rion

    btw fallback from S5B to IBB works perfectly in Psi. but it would be nice to have some recommendation in XEP. like if your file is bigger than 100kb please avoid the fallback to IBB. Or maybe even checking props via server disco about current speed limits, stanzas burst mode etc.

  205. ralphm

    I also would like the ability for a server to (ahem) "discourage" this beyond a certain size.

  206. flow

    fippo, I may be mistaken, but ICE would potentially include TURN as far as I can tell. So it appears to be the natural higher priority transport mechanism with IBB as fallback

  207. flow

    ralphm, I am not sure if xep176 is really important here, given that it xep371 is expected to supersede xep176

  208. fippo

    flow: but ibb is not part of ice (which has its internal rules/priorities) but a different transport

  209. flow

    fippo, I know, that's why I talking abut transport-replace(IBB), replacing the XMPP Jingle ICE transport with the XMPP Jingle IBB transport

  210. ralphm

    Well, hah, so far nobody's cared enough for XEP-0371 to move forward, but yes. I also don't think it changes the idea behind the quoted text.

  211. fippo

    flow: and we certainly agree that ice is better than ibb. but i don't see a spec for that

  212. rtq3 has joined

  213. ralphm

    And indeed I'd put IBB at priority 0, but the problem I see is that a server doesn't have an easy way to not want to support it.

  214. fippo

    ralphm: it can provide a terrible experience to any user that uses it? :-)

  215. Zash

    How complicated is ICE to implement for an XMPP server?

  216. jonas’

    STUN would be a good start

  217. ralphm

    fippo: as well as all other users

  218. Zash

    TURN STUN ICE so many acronyms!!!

  219. rion

    Zash: do you mean integrate with any existing turn server?

  220. fippo

    ralphm: I assume servers do provide rate limiting :-)

  221. ralphm

    Zash: you can use an existing TURN/STUN server. Like coturn.

  222. rion

    it's matter of providing proper authentication to turn. that's it

  223. Zash

    And now you doubled the complexity of the installation procedure.

  224. ralphm

    And then look at implementing Jingle Nodes

  225. fippo

    zash: in general you don't want that. IM servers have completly different deployment patterns (200ms latency due to centralization for the whole world) is ok but for turn servers you want them in many datacenters around the world

  226. rion

    fippo can tell a lot about turn auth :)

  227. Zash

    Auth stuff already exists afaik

  228. ralphm

    So indeed, don't reimplement a TURN server, but provide an easy way to use them (Jingle Nodes).

  229. rion

    Zash: yes. xmpp servers should tell turn server about auth keys.

  230. fippo

    zash: prosody even has a module for xep-0215 :-)

  231. ralphm

    I'm literally writing a blog post on how we did this at VEON.

  232. mimi89999 has left

  233. rion

    ralphm: waiting for a link :)

  234. ralphm

    rion: noted

  235. Zash

    fippo: Me, with my single user self-hosting in my basement, now need to deploy things to multiple data centers?

  236. UsL has joined

  237. ralphm

    What, no.

  238. fippo

    zash: send 1$ to twilio each month instead

  239. ralphm

    At VEON we had one in Russia and one for the rest of the world. As you scale up, you geographically (network wise) add more.

  240. ralphm

    Just run coturn next to prosody, and you'll be fine.

  241. zach has left

  242. Zash

    Is that going to work if it runs behind a NAT?

  243. zach has joined

  244. fippo

    if you know your external ip that can be configured

  245. ralphm

    Also note that you don't provide TURN for others, it is for your (users) benefit. Your contacts should use their own.

  246. ralphm

    Zash: you need to be able to reach it, of course (single port), and for relaying you do need to open up additional ports so that your peer can connect to it.

  247. ralphm

    (typically a range of UDP ports)

  248. ralphm

    So, say you run this at home, you'd have your NAT pass on the traffic for that port range (udp, and 3478, udp and tcp).

  249. Nekit has left

  250. Nekit has joined

  251. mimi89999 has joined

  252. Nekit has left

  253. Nekit has joined

  254. rion

    Is there any XEP like Last Message Correction but to delete a message including mam?

  255. Zash

    There's a proto-xep in the inbox I think

  256. Zash

    Inbox isn't rendered?

  257. Zash

    rion https://github.com/xsf/xeps/blob/master/inbox/message-retraction.xml

  258. rion


  259. rion

    huh added almost 2 years ago. what's wrong with it?

  260. moparisthebest

    well Barbra Streisand tried it in 2003 and it didn't work out very well

  261. Zash

    Check standards archives and council logs from around that time?

  262. Zash

    Hm, was those logs lost in the crash?

  263. rion

    I see there is no notifications to other resources or muc participants about the retraction. So it's kind of incomplete

  264. Zash

    It should work the same as LMC?

  265. rion

    ah other resources will be notified with carbons.

  266. alacer has joined

  267. rion

    honestly I don't like the LMC idea. I'd prefer for changes to a message to be in place instead of a patch as it's for LMC.

  268. dwd

    moparisthebest, :-)

  269. pep.

    rion, what do you want to do exactly?

  270. Zash

    rion: It's not a patch, or do you mean that the old message is still in MAM for everyone? You know you can't really delete anything in an open system?

  271. Zash

    And that's probably why the retraction xep was not accepted.

  272. Zash

    You can't un-say something. Can't reverse time.

  273. pep.

    Does reversing time also reverse your actions?

  274. rion

    Just imagine I'm writing to my mistress something quite private and after sending a message I discover it's was a chat dialog with my wife! Fine, I can delete/correct the message. But fu** she can see the previous message from MAM. what??

  275. Zash

    Can't prevent clients from keeping the "deleted" message and sticking a blinking red border around it

  276. pep.

    rion, maybe she wouldn't be able to. Her client would

  277. Zash

    Same as if you say something to their face

  278. alacer has left

  279. Zash

    Can't un-say something.

  280. alacer has joined

  281. Zash

    Stop trying to break the laws of physics and causality

  282. rion

    would be better if I could :)

  283. Zash

    You can't

  284. Zash

    Deal with it

  285. rion


  286. Zash

    Not in an open system.

  287. mimi89999 has left

  288. pep.

    Even then.. people take pictures of pictures nowadays..

  289. rion

    Zash: and yes I have to be honest with my wife..

  290. pep.


  291. pep.

    Or you can claim plausible deniability

  292. Zash

    Claim temporary insanity

  293. dwd

    So it looks, to me, that message-deletion was almost accepted, but had its name changed as a result of council feedback - but I can't see it actually getting rejected.

  294. pep.

    Somebody not following up?

  295. dwd

    It was four years ago, though. But I think the general feel back then was that as long as we called it "retraction" and not "deletion", it'd be OK.

  296. dwd

    pep., Very hard to tell. I suspect it fell through the inter-council gap.

  297. pep.

    There was also a thread about something similar a few months ago iirc

  298. mimi89999 has joined

  299. dwd

    pep., If by a few months ago, you mean 2016...

  300. pep.

    I'm not sure, I think it was by one of the russian fellows

  301. pep.

    Trying to copy signal or telegram or something like that

  302. pep.

    There was no XEP proposed, just a discussion

  303. dwd

    Oh, yeah, Andrew Nenakhov mentioned it I think.

  304. alacer has left

  305. andy has left

  306. andy has joined

  307. COM8 has joined

  308. COM8 has left

  309. Nekit has left

  310. j.r has left

  311. Nekit has joined

  312. ralphm

    Even in Whatsapp, deleting a message at the remote party is a request, and if the remote app doesn't process it within (I think) 7 days, the request expires and the message stays.

  313. Andrew Nenakhov has left

  314. Andrew Nenakhov has joined

  315. j.r has joined

  316. oli has left

  317. rtq3 has left

  318. Nekit has left

  319. Nekit has joined

  320. oli has joined

  321. Yagiza has left

  322. Yagiza has joined

  323. rtq3 has joined

  324. COM8 has joined

  325. COM8 has left

  326. COM8 has joined

  327. pdurbin has joined

  328. adityaborikar has left

  329. adityaborikar has joined

  330. COM8 has left

  331. Douglas Terabyte has joined

  332. Lance has joined

  333. Daniel has left

  334. Daniel has joined

  335. Zash

    How do you test TURN/STUN/STUFF/ICE?

  336. pdurbin has left

  337. Lance

    Testing that connections work, or that candidates are generating?

  338. Lance

    There's https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ if you want to test candidate gathering is handing out the right things

  339. igoose has left

  340. igoose has joined

  341. Douglas Terabyte has left

  342. Douglas Terabyte has joined

  343. Zash

    Okay. It does something.

  344. j.r has left

  345. ralphm


  346. Zash

    What's the state of XEP-0215 (client) implementations?

  347. Zash

    I see there was a version bump to :2 at some point

  348. Lance has left

  349. Douglas Terabyte has left

  350. Nekit has left

  351. Nekit has joined

  352. fippo

    lance removed it from talky I think (boo lance!) and it seems jitsi uses :1

  353. Douglas Terabyte has joined

  354. murabito has left

  355. mimi89999 has left

  356. Douglas Terabyte has left

  357. ralphm

    Zash: were you trying to use it for discovering your TURN server?

  358. mimi89999 has joined

  359. Zash

    ralphm: I'm wondering why I did this, what I can use it with.

  360. ralphm

    Well, you might want to look at XEP-0278 (Jingle Nodes), which besides discovery also handles authentication and requesting a channel.

  361. ralphm

    This is what we used in VEON, likely also because the author (Thiago) was one of the team members :-D

  362. Daniel has left

  363. Daniel has joined

  364. adityaborikar has left

  365. adityaborikar has joined

  366. Douglas Terabyte has joined

  367. lovetox has joined

  368. Lance has joined

  369. Lance

    Talky will be getting 215 back soon. Have to finish writing patch for extdisco prosody mod first to generate service entries/credentials via an event instead of pulling from static config file

  370. Zash

    I went with https://modules.prosody.im/mod_turncredentials.html but it implements :1

  371. Zash

    Seems to magically Just Work tho

  372. Nekit has left

  373. Nekit has joined

  374. wojtek has joined

  375. wojtek has left

  376. david has left

  377. Yagiza

    Daniel, is registration ID a local device ID?

  378. lovetox

    its a device ID

  379. lovetox

    im not sure what you mean by local

  380. lovetox

    you generate it for the user on first use

  381. fippo

    zash: sadly i don't remember why we bumped the namespace even

  382. peter has joined

  383. Lance

    :2 added support for server pushing updated services/credentials to clients that had requested them

  384. lovetox

    where do you get the word registration ID from?

  385. lovetox

    lib signal?

  386. Kev has left

  387. Kev has joined

  388. goffi has left

  389. Yagiza

    lovetox, I mean that we have a local device ID, which we generated ourself and remote device IDs, generated by other devices, which we discover via PEP.

  390. lovetox

    yeah and libsignal has also something similar they call it registrationID

  391. lovetox

    in my lib i just set it to None and ignore it

  392. winfried has left

  393. Yagiza

    lovetox, that's what my question was. If "registration ID" is local "device ID" in terms of libsignal-protocol.

  394. lovetox

    but maybe you can use that, if i look through the code its actually just a value stored in libsignals objects

  395. lovetox

    i dont see it doing somewhere something specific

  396. Yagiza

    lovetox, I need to specify it when calling session_pre_key_bundle_create() to create a pre key bundle.

  397. winfried has joined

  398. lovetox

    yes pass the device id there

  399. Yagiza

    lovetox, ok, thanx.

  400. adityaborikar has left

  401. adityaborikar has joined

  402. Nekit has left

  403. Nekit has joined

  404. j.r has joined

  405. pdurbin has joined

  406. peter has left

  407. david has joined

  408. lumi has joined

  409. peter has joined

  410. pdurbin has left

  411. Andrew Nenakhov has left

  412. Andrew Nenakhov has joined

  413. peter has left

  414. rtq3 has left

  415. neshtaxmpp has left

  416. jcbrand has left

  417. frainz has left

  418. frainz has joined

  419. waqas has joined

  420. Nekit has left

  421. Steve Kille has left

  422. frainz has left

  423. frainz has joined

  424. alacer has joined

  425. neshtaxmpp has joined

  426. rtq3 has joined

  427. Lance has left

  428. alacer has left

  429. Alex has left

  430. Alex has joined

  431. goffi has joined

  432. Steve Kille has joined

  433. jcbrand has joined

  434. Lance has joined

  435. frainz has left

  436. frainz has joined

  437. frainz has left

  438. frainz has joined

  439. Nekit has joined

  440. peter has joined

  441. peter has left

  442. jcbrand has left

  443. alacer has joined

  444. alacer has left

  445. sezuan has joined

  446. pdurbin has joined

  447. Yagiza


  448. Yagiza

    What should be wrapped in <key/> elements? Serialized ciphertext_message?

  449. lovetox


  450. pdurbin has left

  451. debacle has left

  452. Yagiza

    And then I must deserialize it with signal_message_deserialize?

  453. lovetox

    maybe, in my python port of the lib this call loos like this PreKeyWhisperMessage(serialized=message)

  454. lovetox

    but yes you obviously have to deserialize it somehow

  455. Yagiza

    So, session_cipher is the only thing, which describes a session.

  456. Yagiza

    And I must use the only session_cipher for both encoding outgoing and decoding incoming messages?

  457. lovetox


  458. Douglas Terabyte has left

  459. lovetox

    and as you before asked key element wraps the ciphertext serialized

  460. lovetox

    but of course you should not forget about base64 encoding it first

  461. lovetox

    signallib does not do this for you

  462. Yagiza has left

  463. Douglas Terabyte has joined

  464. rtq3 has left

  465. eevvoor has joined

  466. sezuan has left

  467. APach has left

  468. COM8 has joined

  469. COM8 has left

  470. Wojtek has joined

  471. SaltyBones has left

  472. SaltyBones has joined

  473. j.r has left

  474. SaltyBones has left

  475. SaltyBones has joined

  476. SaltyBones has left

  477. eevvoor has left

  478. j.r has joined

  479. j.r has left

  480. j.r has joined

  481. ralphm

    Lance: oh, right. But clients should already know when to update, cause of expiry. Is this for premature expiry, like a turn server restart?

  482. mimi89999 has left

  483. mimi89999 has joined

  484. goffi has left

  485. Lance

    :2 added expiration attribute too. It was for server restarts and forcing move to new instance, yes

  486. andy has left

  487. waqas has left

  488. Zash


  489. Zash

    Gah, things detecting that stdout isn't a terminal and disabling color :(

  490. Zash

    https://cerdale.zash.se/upload/YxG91XYKo9S47ZSd/xep-0215-diff.html Now then?

  491. pdurbin has joined

  492. Nekit has left

  493. pdurbin has left

  494. debacle has joined

  495. Lance has left

  496. Lance has joined

  497. peter has joined

  498. Lance has left

  499. andrey.g has left

  500. alacer has joined

  501. alacer has left

  502. sezuan has joined

  503. sezuan has left

  504. sezuan has joined

  505. andrey.g has joined

  506. rtq3 has joined

  507. peter has left

  508. sezuan has left

  509. alacer has joined

  510. alacer has left

  511. alacer has joined

  512. alacer has left

  513. alacer has joined

  514. lovetox has left

  515. Lance has joined

  516. alacer has left

  517. lnj has left

  518. UsL has left

  519. UsL has joined

  520. Lance has left

  521. rtq3 has left