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


  75. ralphm


  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


  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


  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


  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


  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


  210. Kev

    Also on xmpp.org?

  211. dwd


  212. Kev


  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


  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


  299. Tobias


  300. bear


  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


  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


  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