XSF Discussion - 2014-02-04

  1. abmar has left
  2. stpeter has joined
  3. Jef has left
  4. Lance has joined
  5. Tobias has left
  6. Lance has left
  7. kevin has joined
  8. kevin has left
  9. waqas has left
  10. waqas has joined
  11. waqas has left
  12. Lance has joined
  13. Lance has left
  14. Steffen Larsen has joined
  15. Neustradamus has joined
  16. Neustradamus has joined
  17. Alex has joined
  18. winfried has joined
  19. Ge0rG mhm. looks like it all started here: http://mozilla.6506.n7.nabble.com/SCTP-and-WebRTC-FYI-td228999.html
  20. fippo ge0rg: i think it was earlier... i'll check the notes from the kickoff
  21. Simon has joined
  22. Ge0rG fippo: I'd be glad to get to the root of it. I'm looking for material supporting the not-quite-obvious decision of SCTP-over-DTLS
  23. Zash has joined
  24. fippo http://rtc-web.alvestrand.com/ might have some hints... but I can't find anything obvious right now
  25. Zash has left
  26. emcho has joined
  27. emcho has left
  28. emcho has joined
  29. ralphm Ge0rG: I might have missed earlier discussion on this, but what is the issue?
  30. Ge0rG is on a flaky 2G connection right now. can't do extensive surfing :(
  31. ralphm Ge0rG: I mean, why is SCTP-over-DTLS a thing that needs to be gotten to the root of? Why is it an unexpected choice?
  32. abmar has joined
  33. Ge0rG ralphm: what I am looking for is extensive documentation of the possible alternatives, and why stacking a transport-layer protocol implemented at the app layer on top of another transport layer protocol has been chosen.
  34. Ge0rG also, my 2G connection lags. icmp_req=454 ttl=40 time=34930 ms
  35. Steffen Larsen has left
  36. Steffen Larsen has joined
  37. Ge0rG ralphm: I can understand the choice was made because of NAT, but I fail to believe it was the only possible choice.
  38. Ge0rG you know, if all you ave is a srtp/dtls hammer, file transfer might look like a nail as well.
  39. fippo ge0rg: RTMFP was/is way more cool imo :-)
  40. SouL has joined
  41. Tobias has joined
  42. Ge0rG sometimes people make brave decisions and stack protocols like it is Babel all over again. And sometimes it even works out reasonably well.
  43. SouL has left
  44. Zash has joined
  45. Ge0rG so far, the guardianproject managed twice already to impress and to disgust me at the same time with their protocol stacking: one was serverless XMPP over avahii over OLSR on mobile, and the other was HTTP over OTR text messages over XMPP
  46. Ge0rG and I'd like to form a strong opinion on that SCTP-over-DTLS thing before opening my mouth and ranting it to the moon ;)
  47. fippo ge0rg: shout at rtcweb for using DTLS-SRTP instead of ZRTP :-)
  48. Ge0rG fippo: I have no strong opinion on RTP encryption mechanisms, and do not intend to form one soon
  49. fippo the bad thing about all RTP encryption mechs is that they don't encrypt the header. which really makes me wonder about the https://www.schneier.com/blog/archives/2011/03/detecting_words.html kind of stuff :-/
  50. winfried has left
  51. SouL has left
  52. SouL has joined
  53. ralphm fippo: what about http://tools.ietf.org/html/rfc6904?
  54. SouL has left
  55. ralphm (which of course doesn't cover all headers)
  56. fippo ralphm: the basic problem is that there is alot of infrastructure that wants to have access to the rtp headers for QoS.
  57. ralphm yeah, of course
  58. ralphm I suppose the same holds for http v.s. https
  59. fippo well, voip is timecritical. http isn't
  60. ralphm with Internet "service" providers mucking around with your javascript, styling and images if you use http
  61. ralphm Ge0rG: but just so you know, server-less XMPP over SCTP/DTLS/SRTP will be a thing.
  62. Zash But you still need servers to find them.
  63. Zash ralphm, like what XTLS was supposed to be?
  64. fippo ralphm: i think the guys from the RWTH aachen have a prototype for exactly that ,-)
  65. ralphm Zash: Yeah, there have been proposals to negotiate peer-to-peer XML Streams over Jingle to do end-to-end encryption.
  66. ralphm that was using XTLS
  67. ralphm They never left the XEP inbox
  68. ralphm and then were IETF drafts
  69. fippo but we bumped the jingle namespace for XTLS at least!
  70. winfried has joined
  71. Kev That was why they never left the inbox, wasn't it?
  72. Kev I forget, this was a while ago.
  73. ralphm Kev: indeed
  74. ralphm tools.ietf.org/html/draft-meyer-xmpp-e2e-encryption-02
  75. ralphm http://tools.ietf.org/html/draft-meyer-xmpp-e2e-encryption-02
  76. Ashley Ward has joined
  77. ralphm in fact, that spec mentions dtls
  78. fippo i tried implementing XTLS, but found the openssl BIO api to be ... hard to use.
  79. ralphm I think it might be picked up again to match the new webrtc reality
  80. ralphm OpenSSL is the bane of everyones existance
  81. ralphm existence even
  82. ralphm unfortunately, there aren't many alternatives
  83. Zash fippo: Why would you use that directly?
  84. fippo i do think the approach in xep-0320 (mapping rfc 5763 without much more thought) is better than the one shown in draft-meyer
  85. SouL has joined
  86. fippo zash: for doing xtls over ibb
  87. ralphm fippo: can we forget about that use case?
  88. Zash fippo: Oh. Yeah. :/
  89. SouL has left
  90. ralphm I think we should maybe move beyond thinking that we want to fall back on ibb
  91. Kev ralphm: Why's that?
  92. Kev And are you saying that as a general policy, or just for some use cases?
  93. fippo https://code.google.com/p/webrtc/issues/detail?id=2796 -- ah, they're going to fix the wrong m-line then!
  94. ralphm Kev: for streaming, file transfer, IBB is an unholy approach. Most servers will not handle it well and large stanzas block streams, I believe.
  95. Kev I'm not sure why server shouldn't handle it well, it's just message switching, same as everything else.
  96. Zash You /could/ run multiple client connections ...
  97. fippo ralphm/zash: +1000!
  98. Kev And in reasonably small chunks.
  99. fippo kev: bad traffic properties. bad karma
  100. Kev There is clearly an upper limit on what is sensible.
  101. ralphm Kev: and I think the upper limit is probably around GSM encoded audio.
  102. Kev fippo: That's choosing not to handle it, rather than being unable to handle it.
  103. Kev I have no idea if fallback for media streams is viable. It feels like it's probably not.
  104. ralphm I'd rather have a single model here, having byte streams out of band.
  105. ralphm If you need alternative transports there, Jingle should be able to handle that.
  106. ralphm If only with co-located proxies
  107. Kev I see your point. But equally, I'm not sure we should dismiss IBB out of hand.
  108. ralphm I'd love to see a counter argument besides "it might still be useful".
  109. ralphm We've been dragging on this forever and it always felt icky
  110. Kev Well, it's guaranteed interop.
  111. Kev Which seems slightly more than 'it might be useful'.
  112. ralphm I mean, base64 encoded RTP wrapped in XML on stanza-switched (neologism?) connection. Meh.
  113. SouL has joined
  114. fippo i like it as last-resort for file transfer. but I'd actually prefer to see how well webrtc with all its nat traversal requires it. no decisions without data :-)
  115. Tobias has joined
  116. SouL has left
  117. ralphm I /could/ kind of see how we might do inband if there's going to be a HTTP/2.0 binding for XMPP eventually.
  118. ralphm fippo: agreed
  119. ralphm fippo: but I do like the idea of separation of concerns, while being sympathetic to Kev's argument.
  120. ralphm Kev: don't break jabber.org, please!
  121. ralphm :-P
  122. Kev The DoS did that already :(
  123. Kev Although it's back now.
  124. intosi That's not Kev breaking things.
  125. ralphm intosi: don't break things
  126. intosi I'm trying to unbreak it.
  127. ralphm hehe
  128. ralphm Meanwhile, I updated the topic for jdev to point here, as many discussions seem to happen here instead of over there
  129. Kev I don't have strong opinions on this.
  130. Kev Well, actually, I do.
  131. ralphm set the topic to XSF discussion room | Logs: http://logs.xmpp.org/xsf/
  132. Kev Which is that this room gets used for official purposes from time to time, so we shouldn't encourage entry from the types of people who will be a nuisance.
  133. Tobias you welcome anything that takes load of jabber.org?
  134. Tobias :)
  135. Kev But it's not clear to me that this fails that test.
  136. Kev Tobias: The jdev load really isn't a problem.
  137. Tobias i know..was just joking
  138. Kev Although if it encourages the DoSsers to start attacking muc.xmpp.org instead, we will possibly have issues. Athena is...not as powerful.
  139. ralphm Kev: I'm trying to reflect reality, still forming my opinion. Arguably, since standards@xmpp.org is hosted by the XSF, maybe the discussions on MUC should too.
  140. MattJ I can handle it ;)
  141. Tobias yeah...it's Lua, not some C/C++ stuff
  142. ralphm Kev: are the DoSsers targetting jdev specifically?
  143. Kev No.
  144. Tobias all DoS packets are JIT compiled to a single NOP
  145. Kev Which is why I'm not jumping up and down and calling you a lunatic for pointing them here :)
  146. ralphm Do you think pointing to it in the topic gives them ideas?
  147. Kev Probably not. I think this is probably not going to lead to problems.
  148. ralphm awesome
  149. Zash Create a new room for general discussions?
  150. ralphm Zash: I don't see the point, to be honest
  151. ralphm But, one could argue we should reflect the mailinglists in rooms. I've seen a trend to reduce the number of lists, though.
  152. Alex has joined
  153. Kev I don't see much value in moving jdev here. I don't see much harm in it.
  154. ralphm oh, heh, there is a board room. Single occupant is a non-board member.
  155. Kev And some old spam in the history.
  156. ralphm techreview@ points here
  157. Tobias also been wondering why board meeting happen here and not at board@
  158. Zash Destroy all rooms!
  159. ralphm Tobias: they are public
  160. Kev Tobias: There's no reason for them not to happen here :)
  161. ralphm Tobias: like we discuss mostly everything on the members list
  162. Tobias Kev, let's move council meetings here?
  163. Kev Council and Board sometimes overlap slightly, so that seems like a not great idea.
  164. ralphm Tobias: that crossed my mind, but what Kev says
  165. Tobias i just seem to remember they've been hold in the board@muc...but if that's wrong nvm
  166. ralphm Tobias: we won't any time soon, I think
  167. ralphm board@ should probably be a restricted room
  168. ralphm like the mailing list
  169. intosi A board-only back channel doesn't sound like a bad idea to me.
  170. ralphm except we would almost never use it
  171. intosi You wouldn't for board meetings, at least.
  172. Kev intosi: A /second/ Board-only back channel.
  173. intosi Kev: right
  174. ralphm Kev: I'd merge them, of course
  175. Kev I think Board can decide if they want such a thing. I don't see the value, but I'm not Board.
  176. ralphm Kev: indeed
  177. Ashley Ward has left
  178. ralphm has left
  179. Ge0rG 's got one good reason for IBB. With 0198, you can have stream resumption for file transfers.
  180. ralphm While that might be an argument, I am not sure if it is a particularly strong one.
  181. fippo if your server doesn't like IBB and kills you for bad karma, you might trick the karma mechanism :-)
  182. Ge0rG how does SCTP-DTLS handle live network changes?
  183. ralphm I.e. for file transfers, if the transfer is broken at some point, you know which pieces you have, and can simply start a new transfer for the missing pieces
  184. fippo (i don't want to look further down the road... karma was always simplified too much)
  185. fippo ge0rg: using ice / mice
  186. fippo ge0rg: http://tools.ietf.org/html/draft-wing-mmusic-ice-mobility-02
  187. Jef has joined
  188. Steffen Larsen has joined
  189. Ge0rG puts mice on his read-list
  190. SouL has joined
  191. ralphm has left
  192. SouL has left
  193. Ge0rG ralphm: resuming a file transfer somewhere in the middle is a security problem, as well
  194. ralphm Ge0rG: I don't see how the transport method affects that statement
  195. Ge0rG ralphm: maybe I'm just hanging at the slight semantic difference between "resume" and "continue"
  196. ralphm Ge0rG: hang in there!
  197. Ge0rG whistles Jeopardy tune...
  198. abmar has joined
  199. Ash has joined
  200. winfried has left
  201. dwd has joined
  202. Steffen Larsen has left
  203. Jef has left
  204. dwd We (the Board) do actually have a seperate MUC for private discussion, but we've rarely used it.
  205. dwd I think we used it to discuss an incoming sponsor once, and that's it.
  206. Kev dwd: Other than board@?
  207. dwd Yes; seemed easier to setup a new one than repurpose an existing one at the time.
  208. zooldk has joined
  209. Kev OK.
  210. Kev Also on xmpp.org?
  211. dwd Yes
  212. Kev OK.
  213. Simon has left
  214. simon has joined
  215. Lance has joined
  216. Jef has joined
  217. zooldk has left
  218. Lance has left
  219. winfried has joined
  220. Neustradamus has joined
  221. Lance has joined
  222. jabberjocke has joined
  223. winfried has left
  224. Lance has left
  225. jabberjocke has left
  226. jabberjocke has joined
  227. ralphm simon: I want to add pictures from the Lounge to the Summit event in Plus. Can you extend the dates?
  228. ralphm or any other suggestion for collecting pictures from both in one album
  229. ralphm emcho: you guys have a bunch of pictures of the lounge, yes?
  230. emcho has left
  231. emcho has joined
  232. stpeter has left
  233. emcho ralphm: I'll ask around and I'll come back to you
  234. waqas has joined
  235. emcho https://docs.google.com/a/sip-communicator.org/file/d/0BwiF7kZbHitaT3ZxUlNYbWdSWE0/edit https://docs.google.com/a/sip-communicator.org/file/d/0BwiF7kZbHitaYWxCWXdLbW9LeUE/edit https://docs.google.com/a/sip-communicator.org/file/d/0BwiF7kZbHitaU1d0TTBjZUVXNFU/edit https://docs.google.com/a/sip-communicator.org/file/d/0BwiF7kZbHitadUF4bUFNc3lrZE0/edit https://docs.google.com/a/sip-communicator.org/file/d/0BwiF7kZbHitaVXdvY2VlSzNrRkk/edit
  236. emcho are those readable to you?
  237. Tobias emcho, seems so
  238. emcho cool
  239. ralphm emcho: cool. Since they are in the Googleplex already, can you add them to the photos on the XMPP Summit event on G+ by Simon?
  240. waqas has left
  241. emcho ralphm: where's that. can't find anything on simon's page other than the BC photos from the mountains
  242. Tobias https://plus.google.com/events/cducp61naq050ce9cufjlfh37d8?authkey=CIjS4KHjiq2zpAE this is it i think
  243. Zash has left
  244. ralphm emcho: what Tobias says. It is in the XMPP community page
  245. Lance has joined
  246. ralphm hi Lance
  247. Tobias has left
  248. winfried has joined
  249. emcho ralphm: ok done. will add more as people check them in
  250. Lance has left
  251. SouL has joined
  252. SouL has left
  253. Jef has left
  254. Zash has joined
  255. stpeter has joined
  256. Zash has left
  257. stpeter has left
  258. Zash has joined
  259. stpeter has joined
  260. winfried has left
  261. simon ralphm: dates extended. Photos should be addable.
  262. bear has joined
  263. Zash has joined
  264. intosi has joined
  265. ralphm has joined
  266. ralphm has joined
  267. Zash has joined
  268. bear dwd - can you send that link to my andyet email address?
  269. dwd BTW, I personally have no issues with the spreadsheet currently being played with by Board being made public; but I wasn't happy doing that unilaterally or when the figures were still rough.
  270. bear once we get all the final data, no reason to not publish a read-only version IMO
  271. Steffen Larsen has joined
  272. SouL has joined
  273. intosi has joined
  274. ralphm has joined
  275. Steffen Larsen has left
  276. bear has left
  277. Lance has joined
  278. Tobias has joined
  279. Jef has joined
  280. Jef has left
  281. waqas has joined
  282. ralphm emcho: thanks!
  283. ralphm simon: thanks! It seems Plus doesn't actually mind
  284. emcho has left
  285. emcho has joined
  286. Steffen Larsen has joined
  287. Tobias has left
  288. bear has joined
  289. Tobias has joined
  290. Steffen Larsen has left
  291. emcho has left
  292. Steffen Larsen has joined
  293. emcho has joined
  294. Steffen Larsen has left
  295. simon has left
  296. dwd [17:27:17] Dave Cridland: http://ubber.com seems to give me German error messages. Might want to check that out. [17:35:20] Florian Jensen: hmm [17:35:21] Florian Jensen: our geo db is off then
  297. dwd I'm *so* cruel.
  298. fippo rotfl
  299. Tobias hehe
  300. bear LOL
  301. Simon has joined
  302. Tobias has left
  303. Tobias has joined
  304. ralphm dwd: good thing you have a thinking cap now
  305. bear ralphm - remember to send me an email for the cost of the realtime logo'd bean bags
  306. ralphm bear: ack
  307. ralphm bear: sent
  308. bear ta
  309. ralphm has left
  310. Simon has left
  311. SouL has left
  312. intosi has joined
  313. ralphm has joined
  314. Lance has left
  315. Lance has left
  316. Lance has joined
  317. emcho has left
  318. emcho has joined
  319. Lance has left
  320. Ash has left
  321. dwd bear, You messed up my spreadsheet. :-)
  322. Simon has joined
  323. Zash BEAR, WHYYYYY
  324. Tobias yeah...didn't you get that memo?
  325. waqas Tobias: Which one?
  326. Tobias waqas, about the spreadsheets....right next to the one about the TPS reports
  327. Lance has joined
  328. Zash has left
  329. dwd unmesses the sheet.
  330. dwd bear had made the loss look bigger, whereas now it's much better. Benefits of some ad-hoc training in accountancy.
  331. waqas They train you to make losses look smaller?
  332. dwd No, they train you to get the signs correct.
  333. stpeter has left
  334. bear has left
  335. Tobias has left
  336. Tobias has joined
  337. Zash has joined
  338. Lance has left
  339. intosi has joined
  340. Neustradamus one guy will post an article about FOSDEM on the website?
  341. ralphm has joined
  342. Neustradamus has left
  343. dwd Yes, we'll get to that. The Summit, too.
  344. ralphm dwd: what if is isn't one. Or not even a guy?
  345. dwd ralphm, I'm somewhat hoping it won't be a guy. :-)
  346. Zash Maybe it'll be a person.
  347. Zash Or two
  348. Zash or more
  349. ralphm Zash: what!
  350. Zash Just maybe
  351. Alex has left
  352. stpeter has joined
  353. Ash has joined
  354. Steffen Larsen has joined
  355. Neustradamus has joined
  356. stpeter has left
  357. Ash has left
  358. Neustradamus has left
  359. Lance has joined
  360. Neustradamus has joined
  361. SouL has left
  362. Lance has left
  363. Neustradamus has left
  364. Neustradamus has joined
  365. emcho has left
  366. stpeter has joined
  367. emcho has joined
  368. Tobias has left
  369. Tobias has joined
  370. emcho has left