XSF logo 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 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 https://xmpp.net/result.php?domain=404.city&type=server
  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 Link?
  176. j.r has left
  177. rion https://wiki.xmpp.org/web/XEP-Remarks/XEP-0260:_Jingle_SOCKS5_Bytestreams_Transport_Method
  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 thx.
  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 nooo!
  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. good
  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 Yay?
  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 Well
  448. Yagiza What should be wrapped in <key/> elements? Serialized ciphertext_message?
  449. lovetox yes
  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 yes
  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 https://cerdale.zash.se/upload/ylN-_jalmw_Dvpuh/xep-0215-diff.html
  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