XSF Discussion - 2017-09-27

  1. Tobias has left

  2. tim@boese-ban.de has left

  3. tim@boese-ban.de has joined

  4. tim@boese-ban.de has left

  5. tim@boese-ban.de has joined

  6. tim@boese-ban.de has left

  7. tim@boese-ban.de has joined

  8. ralphm has left

  9. Tobias has joined

  10. la|r|ma has joined

  11. waqas has joined

  12. jere has left

  13. jere has joined

  14. mimi89999 has left

  15. la|r|ma has left

  16. Valerian has joined

  17. Valerian has left

  18. Valerian has joined

  19. lskdjf has joined

  20. Guus has left

  21. Guus has joined

  22. tux has joined

  23. nyco has left

  24. nyco has joined

  25. uc has joined

  26. jere has left

  27. jere has joined

  28. Yagiza has joined

  29. Valerian has left

  30. Guus has left

  31. Guus has joined

  32. Guus has left

  33. Valerian has joined

  34. daniel has left

  35. daniel has joined

  36. Valerian has left

  37. tux has left

  38. tux has joined

  39. Guus has joined

  40. Valerian has joined

  41. Guus has left

  42. Valerian has left

  43. Guus has joined

  44. jere has joined

  45. Guus has left

  46. Guus has joined

  47. Guus has left

  48. Zash has left

  49. Guus has joined

  50. Guus has left

  51. Guus has joined

  52. Guus has left

  53. SamWhited has left

  54. daniel has left

  55. daniel has joined

  56. Flow has joined

  57. Flow has joined

  58. daniel has left

  59. daniel has joined

  60. SouL has left

  61. Guus has joined

  62. Guus has left

  63. Guus has joined

  64. ralphm has left

  65. Guus has left

  66. Guus has joined

  67. ralphm has left

  68. ralphm has left

  69. daniel has left

  70. daniel has joined

  71. waqas has left

  72. tim@boese-ban.de has left

  73. Martin has joined

  74. daniel has left

  75. daniel has left

  76. daniel has left

  77. emxp has joined

  78. stefandxm has left

  79. daniel has left

  80. stefandxm has joined

  81. Ge0rG has left

  82. daniel has left

  83. daniel has left

  84. tim@boese-ban.de has joined

  85. stefandxm has left

  86. jcbrand has joined

  87. ralphm has joined

  88. daniel has left

  89. daniel has left

  90. zinid has left

  91. stefandxm has joined

  92. tim@boese-ban.de has joined

  93. daniel has left

  94. goffi has joined

  95. goffi has joined

  96. ralphm has left

  97. daniel has left

  98. daniel has left

  99. daniel has left

  100. ralphm has left

  101. daniel has left

  102. daniel has left

  103. goffi has joined

  104. goffi has joined

  105. la|r|ma has joined

  106. Kev has left

  107. Kev has left

  108. emxp

    Guus, Ge0rG: Coming back to the 'new' Foundations discussion. My intention is a) focus on important issues in the xmpp comunity in general b) maybe put paid devs on these task or specific clients which are likey to improve the UX of xmpp in general (yes, money is an issue i know) c) build a platform/website to show what xmpp can do for standard users who never heard of xmpp before d) may provide general information about the network (number of users, how does xmpp work etc) - you get what my intention is? I dont talk about if that's likely to happen. I ask whether is the right way?

  109. lumi has joined

  110. Guus

    emxp: I don't know. There likely is not one right way. If you see value in it, by all means.

  111. Ge0rG

    emxp: (a) yes, 100%. I'm trying that for a while now. (b) not only money is an issue, fair distribution of the money is as well. (c) I'm not sure people are reading such websites, but it might attract some nerds / multipliers, so yeah! I wish we could host it on jabber.org... (d) that's actually hard. The XSF is trying to, but you can hardly get reliable data from a federated system like XMPP

  112. daniel has left

  113. daniel has left

  114. daniel has left

  115. Tobias has left

  116. daniel has left

  117. Tobias has left

  118. daniel

    If you are good at fund raising by all means go ahead. I don't think developers will say no to money

  119. daniel

    Ironically fund raising is a full time job. So as soon as you start you'll have to raise enough money to at least pay your own salary

  120. Tobias has left

  121. Flow has joined

  122. lskdjf has joined

  123. daniel has left

  124. tim@boese-ban.de has joined

  125. Ge0rG

    daniel: actually, to pay for two people.

  126. tim@boese-ban.de has joined

  127. Ge0rG

    ...so that you have one effective developer

  128. daniel

    My personal approach is to create a sustainable business model. I know that's quite revolutionary idea in today's world. But you it might be more... sustainable...

  129. zinid

    sustainable model is to get hired :D

  130. mathieui

    daniel, did you think about pitching your idea to a VC to get funding? :p

  131. daniel

    zinid, only if that company itself has a sustainable business model. i'm sure the matrix developer can agree

  132. Martin has left

  133. Martin has joined

  134. daniel has left

  135. Ge0rG

    I've heard that Erlang an C++ developers are in high demand...

  136. emxp

    daniel, Ge0rG: For me there is no direct discussion of fairness. the foundation can act transparent, only invest in open source code and only spend money to task/work they all agree to. based on some principles - opensource, leading for xmpp, of intrest for xmpp community etc.. If people dont agree to those projects, they wont spend. so the foundation is forced to define task which are in the interest of most xmpp users somehow... or they can define task, the necessary effort, and let people donate and offer like 10-20% of the necessary amount. It's better to have a central plattform to collect task, than wait for third party aproaches maybe

  137. daniel has left

  138. emxp

    I think most people, dont like to donate, if they have no idea, about where the money goes

  139. Kev

    Pushing only OSS projects sounds like a Really Bad Idea, given where so much of the XSF's expertise and effort has come from over the years.

  140. mathieui

    Kev, yeah, although I can see the point if people are donating the funding

  141. jubalh has joined

  142. emxp

    mathieui: what do you mean exactly

  143. emxp

    Kev: Just an example. What software would you suggest to support?

  144. Zash

    Some may find it weird to donate to commercial projects.

  145. Kev

    Ah, this is a separate 'pay for software' foundation? I thought you meant the XSF.

  146. Kev

    If it's some 'pay for opensource XMPP foundation', it's fine to focus on open source.

  147. Kev

    Zash: Sure, so it has to be both non-commercial and open source? :)

  148. Ge0rG

    Kev: I think that OSS is the only way to ensure that the software won't just fold up and die at any moment in time after or before the funding stops.

  149. Kev

    Ge0rG: I don't think OSS ensures that at all. But I understand what you mean.

  150. Ge0rG

    Kev: with closed source, there is no way at all to achieve that.

  151. Ge0rG

    Kev: and there are many viable business models around OSS, so I don't think this is about offending commercial closed-source providers.

  152. Kev

    Also not true, but it's harder to get anyone to agree to it.

  153. Ge0rG

    Kev: it's always hard to agree on how to spend money. Your first remark is a good example of that.

  154. fp-tester has left

  155. fp-tester has joined

  156. Kev

    Ge0rG: If the business model is viable, we don't need a new foundation to be fundraising to inject money, I suppose? :)

  157. Ge0rG

    Kev: so we need to focus our money on non-viable business models. Wow, that sounds like a very awful framing of paying for non-commercial OSS development.

  158. Kev

    I don't have any problem with someone running a "raise money and we'll give it to projects" org, BTW. I misunderstood and thought it was suggested to do it through the XSF, which I disagree with.

  159. Kev

    I think the prospect is filled with difficulties, but as long as it's not the XSF that's shouldering them, more people working in XMPP is good :)

  160. Ge0rG

    The more I think about it, the more I like the idea of resurrecting the Jabber Software Foundation.

  161. zinid has left

  162. zinid has left

  163. mathieui start writign JEPs

  164. Ge0rG

    Which is my second "it used to be more appropriate in the past" epiphany after "message routing was better before Carbons, and we should try to get back to it"

  165. zinid has joined

  166. mathieui starts writing JEPs

  167. Kev

    Routing was better before carbons?

  168. Zash

    Ge0rG: I suddenly have this urge to tell you something along the lines of "I told you so"

  169. Ge0rG

    Kev: I've been pondering about how to improve the message routing mess we are currently in, and my proposal for a future XMPP would be this: - messages to the bare JID are persistent, routed to all online resoures and archived - messages to a full JID are ephemeral, only routed to the target full JID (or bounced) and not stored.

  170. Ge0rG

    - resource locking must be burned with fire.

  171. Ge0rG

    and this is very close to XMPP message routing rules pre-Carbons

  172. Kev

    I'm fine with that in principle, although we're not ready for "resource locking must be burned with fire." because of not having a sensible caps story yet, but we could get there. We need to anyway, because of carbons.

  173. Ge0rG

    Except there is no sane way to get from here to there.

  174. Ge0rG

    Kev: because of carbons and archives.

  175. MattJ

    There are ways though

  176. Ge0rG

    and race conditions.

  177. Kev

    The idea of not doing full-JID fallback is sensible enough, in a MAM world.

  178. Kev

    But only if you archive. Hmm.

  179. Ge0rG

    Kev: if we make full-JID synonymous with ephemeral, there is no need for fallback.

  180. fp-tester has left

  181. Ge0rG

    But reassigning the semantics of full-JID is a tough call.

  182. Kev

    Except for requiring a forklift upgrade.

  183. fp-tester has joined

  184. Ge0rG

    Kev: I'm open to less radical suggestions.

  185. Kev

    I was trying to think through whether it was possible for a 'modern' client on a 'modern' server to accept messages in 'old' style, but still do sensible things.

  186. Ge0rG

    Kev: but I think it's important that we analyze the situation we are in, determine that it's a huge mess, and have a vision of where we want to be in X years.

  187. Kev

    I guess there is.

  188. Kev

    If we in some way mark sessions as being xmpp 1 or xmpp 2.

  189. Zash

    Design from the top instead of the bottom?

  190. Ge0rG

    Kev: https://wiki.xmpp.org/web/XMPP_2.0 ;)

  191. Kev

    Ge0rG: I don't disagree with that. I've been trying to do this for some time.

  192. Kev

    (that being working a way out of the mess)

  193. Ge0rG

    and I'd love that vision to be "XMPP(-IM) is a transport protocol to synchronize a message history between a user's devices on login and live.

  194. Ge0rG

    plus what we have with presence, that's working well more or less.

  195. Kev

    I think a long session at the next summit would be justified.

  196. Ge0rG

    Zash: yeah.

  197. Ge0rG

    Kev: +1 to that, though I don't know yet if I can attend.

  198. Kev

    Or a fully-virtual summit.

  199. Zash

    Ge0rG: Yeah, I too have this feeling that we've built a bunch of things that we don't know how they are supposed to fit togeather.

  200. Kev

    Or just a video chat between interested parties. Whatever.

  201. Kev

    I don't think IM/mail is the most productive way to work through such a core issue.

  202. Kev

    (But I could be wrong)

  203. Ge0rG

    Kev: I think that whoever is going to attend a live meeting needs to understand the problem first.

  204. Zash

    FOSDEM isn't too far away?

  205. Ge0rG

    Zash: it's not just a feeling, it's our current situation. Have a look at the interop between MAM and MUC, MUC and Carbons, etc.

  206. Ge0rG

    Even presence in MUC is a challenge.

  207. Ge0rG

    And the current situation is sufficiently f***ed up that we can't fix it by piling more protocols on top.

  208. Kev

    I think needing to understand the problem is why high-bandwidth is useful.

  209. Kev

    I'm not at all convinced that it can't be fixed by building on top, though.

  210. Ge0rG

    I'm pondering about writing something long-ish to explain the problem as I see it and possible solution directions

  211. Zash

    Ge0rG: MAM, MUC, Carbons, SM, Push, CSI etc

  212. daniel has left

  213. Ge0rG

    Zash: yeah.

  214. tim@boese-ban.de has joined

  215. Kev

    All your examples there included MUC.

  216. Zash

    And the number of things involved has grown to be more numerous than what fits in my head

  217. Kev

    Binning MUC and replacing it might be an idea...

  218. Ge0rG

    Kev: what Zash said.

  219. Ge0rG

    Kev: how should Carbons and MAM interact with 0184 ACKs for example?

  220. Kev

    I think they're all necessary. Whether they're called individual things, or xmpp2core just gets really long.

  221. Kev

    You need archiving, you need groupchat, you need routing rules, you need app-level acks, you need push, you need bandwidth management...

  222. Ge0rG

    Kev: all those things are needed, yes.

  223. Ge0rG

    Kev: that's not the question. The question is how to make them work together.

  224. Ge0rG

    They are all individual patches for individual problems, and they interop badly.

  225. stefandxm has left

  226. Kev

    I'm far from saying everything's perfect. I challenge the notion that things can't be fixed without binning the core, though.

  227. Kev

    And we certainly need The Big Picture sorted.

  228. Ge0rG

    Kev: this is not about binning the core.

  229. Ge0rG

    Kev: but about some of the assumptions it made that are not appropriate any more.

  230. Kev

    You'll remember (you won't, actually, because it was before your time :)) that I started a protoXEP for this many many years ago, but we didn't have the building blocks to solve it. It was in the days before MAM et al.

  231. Ge0rG

    Kev: I'm not intending to replace XMPP with JSON-REST. But I want to start from The Big Picture and see what needs to be changed to make XMPP2 work well.

  232. Martin has left

  233. Martin has joined

  234. Kev

    I'm very much in favour of big-picture here.

  235. emxp has joined

  236. la|r|ma has left

  237. emxp

    Kev: Yes, i was talking about a different organsisation and if my thoughts are senseful

  238. Zash

    And big-picture needs a big whiteboard! :)

  239. Kev

    Maybe Ge0rG should publish a Thought-A-Day on each of the problems he sees with the current state, so it's not TL;DR, and at the end of the series we've got the full picture :D

  240. jonasw

    Kev, I thnik he started a blog series :)

  241. Kev

    Odd, I thought I had planet jabber in my feed.

  242. jonasw

    does the xmpp.org blog federate to that?

  243. zinid

    I'm lost, xmpp2.0 is coming?

  244. zinid

    just don't use XML anymore :)

  245. Zash


  246. valo has left

  247. valo has joined

  248. emxp has joined

  249. zinid

    or JSON if that matters

  250. zinid

    JSON is XML of nowadays

  251. zinid

    kids from 2030s will laught at us again

  252. Kev has left

  253. Zash

    Wake me up when ASN.1 is cool again

  254. zinid


  255. zinid

    it's not modern, ya know

  256. zinid

    protocol buffers is THE THING

  257. Yagiza has left

  258. Ge0rG

    actually, protocol buffers is one of the saner protocol designs.

  259. jonasw

    Zash, ASN.1 over XML over JSON over HTTP over XMPP over VTEP

  260. jonasw

    Ge0rG, I’m not convinced by their implicit defaults.

  261. Ge0rG

    Kev: I've started a blog post series on "Easy XMPP", which is different. I think for this one, I'd rather go with my personal blog and the "xmpp" tag there.

  262. Ge0rG

    jonasw: admittedly, I haven't had a deep dive into it. But any protocol that doesn't implicitly encode data lengths and uses escapable special markers is sane for me.

  263. Zash

    jonasw: Considering ASN.1 being something of a schema thing, and the existence of an XML encoding of it ... I wonder if there's a JSON one yet.

  264. Ge0rG

    https://blog.plan99.net/its-time-to-kill-the-web-974a9fe80c89 was an awesome post showing that all the modern web protocols actually fail the same way the US telephone network did in the 70ies. Mixing of meta-data and data.

  265. Zash

    Make Gohper Great Again

  266. Ge0rG

    The author is calling it "buffer overflows" and meaning "lack of explicit buffer lengths", but it's all the same story.

  267. Zash

    Don't LangSec people say that that's a giant security hole too?

  268. Ge0rG

    Zash: that what?

  269. Ge0rG

    Kev: I'm just not sure if I can start with individual problems and somehow arrive at the big picture.

  270. Zash

    Whop's, bit got flipped in the length field and everything turned into a giant buffer overflow!

  271. Zash

    Something something length fields don't fit into some simpler language category?

  272. zinid

    Ge0rG: why not prefix length? you can parse it in parallel, unlike scanning

  273. Zash

    Because Heartbleed?

  274. Zash

    Length prefixed fields helped so much there

  275. Ge0rG

    Zash: the issue with heartbleed was conflicting length fields.

  276. zinid

    Zash: using same logic I would say don't use C then

  277. jonasw

    zinid, that’s a reasonable statement :-)

  278. Guus has left

  279. zinid

    well, yes :)

  280. Ge0rG

    Zash: besides, my point wasn't that old protocols are sane, just that the current ones are mad.

  281. stefandxm has joined

  282. Martin has left

  283. Martin has joined

  284. zinid

    yeah, like http2

  285. zinid

    tcp over http, wtf...

  286. Zash

    Gotta let Google have their optimizations

  287. zinid

    right, today everyone is accepting what Google suggests, to be exact, what's good for their bussiness

  288. zinid

    IETF is degrading

  289. SouL has left

  290. Ge0rG

    W3C has fallen.

  291. Ge0rG

    zinid: https://jacquesmattheij.com/the-web-in-2050 is for you :P

  292. daniel has left

  293. zinid

    Ge0rG: wait, I didn't finish reading your first article (about kill web)

  294. nyco has left

  295. nyco has joined

  296. stefandxm has left

  297. tim@boese-ban.de has joined

  298. zinid

    Ge0rG: for the record, from your article: > The fix: All buffers should be length prefixed from database, to frontend server, to user interface. There should never be a need to scan something for magic characters to determine where it ends. Note that this requires binary protocols, formats and UI logic throughout the entire stack.

  299. tim@boese-ban.de has joined

  300. Zash

    I forget where I read it, but you shouldn't underestimate human-readable protocols and formats. At least not for early versions. Later versions being binary might be sensible.

  301. Zash

    It was kinda cool way back in the day to open the XML console and see something that made sense.

  302. Zash

    Or View Source and reading the HTML and stuff.

  303. Zash

    can't do that anymore tho, not with all the minifications and whatnot.

  304. zinid

    Zash: yes, it was cool because there were no encryption, I used tcpflow for this ;)

  305. Holger

    Not sure why $length:$readable_data would be impossible though.

  306. zinid

    actually, there can be well-defined mechanism to dump structures in human-readable form

  307. zinid

    like they do for WebAssembly

  308. daniel has joined

  309. Guus has left

  310. Zash

    Do binary protocols usually have that tho?

  311. Zash

    Like, included by default and accessible?

  312. jonasw

    Zash, protobuf does

  313. zinid

    Zash: I don't think so, but it's not that hard to write rules how to dump protobuffs structures for example

  314. jonasw

    Zash, $homebrewbinary probably doesn’t

  315. zinid

    and dumping structures is trivial and not error prone (almost)

  316. zinid

    unlike parsing them

  317. Zash

    Sure sure, but text formats make it really easy to get into fiddling with things, which helps with early adoption.

  318. Zash

    Of course it comes back to bite you later, but still.

  319. jonasw


  320. jonasw

    XML worksforme

  321. Guus has left

  322. zinid

    this is the same argument as Python vs Haskell

  323. zinid

    Python will bite you later for sure

  324. zinid

    duck typing accepts no excuses

  325. Zash

    Duckt tapeing ftw

  326. jonasw

    duct taping?

  327. jonasw


  328. Zash


  329. Ge0rG

    Holger: it's not impossible with human-readable formats, but then you end up with whitespace or newline in the wrong place and the parser freaks out :(

  330. jonasw

    Ge0rG, #poezio? ;-)

  331. zinid

    anyway, I'm relaxed, because I implemented XML codec for ejabberd, it does the same as asn.1/protobufs/etc and it works (despite everyone cries you should not validate)

  332. Ge0rG

    jonasw: no way :P

  333. jonasw

    Ge0rG, a good example of a working system is the chunked HTTP encoding

  334. daniel has left

  335. daniel has joined

  336. Ge0rG

    jonasw: how many HTTP entities will accept unix LF instead of CRLF, what do you think?

  337. lskdjf has left

  338. lskdjf has joined

  339. jonasw

    Ge0rG, right, it’s CRLF

  340. Zash

    The finer points HTTP header syntax will make you mad

  341. jonasw

    Zash, I’ve seen a fun talk about that

  342. jonasw

    forgot how it was called

  343. Ge0rG

    jonasw: also is there a CRLF at the end? https://stackoverflow.com/questions/33878377/why-are-some-servers-not-using-crlf-after-the-last-chunk-length-of-zero ;)

  344. jonasw

    but they made ascii-art out of well-formed HTTP headers, soo....

  345. jonasw

    TIL there are trailers

  346. Ge0rG

    movie trailes? or the ones you live in?

  347. stefandxm has joined

  348. jonasw

    Ge0rG, the ones behind the last chunk in chunked transfer encoding

  349. jonasw

    read the answer you linked :)

  350. Ge0rG

    Oh. My. God.

  351. jere has joined

  352. SouL has left

  353. jcbrand has left

  354. ralphm has left

  355. lovetox has joined

  356. vanitasvitae has left

  357. valo has joined

  358. daniel has left

  359. daniel has joined

  360. tim@boese-ban.de has joined

  361. tim@boese-ban.de has joined

  362. jcbrand has joined

  363. jere has joined

  364. emxp has left

  365. jere has joined

  366. Ge0rG has left

  367. waqas has joined

  368. ralphm has left

  369. dwd has left

  370. dwd has joined

  371. emxp has joined

  372. valo has joined

  373. SamWhited has joined

  374. vanitasvitae has joined

  375. Martin has left

  376. daniel has left

  377. daniel has joined

  378. stefandxm has left

  379. stefandxm has joined

  380. mimi89999 has joined

  381. Martin has joined

  382. Valerian has joined

  383. daniel has left

  384. Alex has joined

  385. SamWhited has joined

  386. edhelas has left

  387. edhelas has joined

  388. xnyhps has left

  389. Tobias has left

  390. SamWhited

    > tcp over http I start twitching every time I hear that because it makes me think of BOSH…

  391. Holger has left

  392. daniel has left

  393. Holger has joined

  394. stefandxm has left

  395. stefandxm has joined

  396. Martin has left

  397. Martin has joined

  398. daniel has left

  399. zinid

    bosh... plz god no

  400. Holger has left

  401. Zash

    speaking of which, anyone feel like going around the interwebz and purging old pre-standard xmpp-over-websockets implementations?

  402. MattJ

    Sorry, I have a soft spot for BOSH

  403. zinid

    I have a bunch of issues related to mod_bosh, it's brutally hard to debug with all that overcomplicated sid/rid/cid crap

  404. zinid

    just terrible protocol

  405. Holger has joined

  406. SamWhited

    Indeed… impossible to debug, hard to implement in any reasonable way, can't really be decoupled from the underlying thing it's transporting (although the XMPP over websocket protocol is that way too)

  407. Zash

    Thanks Web & JavaScript!

  408. SamWhited

    it's a right pain.

  409. Ge0rG

    There is a followup to kill-the-web: https://blog.plan99.net/what-should-follow-the-web-8dcbbeaccd93

  410. Martin has left

  411. Zash


  412. fippo

    have you heard of dns over http aka DOH?

  413. Zash

    fippo: It needs moar JSON

  414. Martin has joined

  415. zinid

    Can't we deprecate bosh btw? Do we still need it when we have websockets?

  416. pep.

    https://caniuse.com/websockets I suppose we could

  417. Ge0rG

    zinid: are you going to pay the developers of all BOSH clients to migrate?

  418. Ge0rG

    Also I wonder how that will work with TCP interruptions, bad firewalls / web firewalls, etc.

  419. Ge0rG

    Also how good is WebSocket library support for non-webbrowser applications?

  420. Zash

    Maybe we should have standardized two xmpp-over-websocket versions. One with WebJS fiddlery and one that's just the same as TCP but over WS

  421. Zash

    Does Websockets work with all those restrictive corporate firewalls that are forcing everything into becoming https on 443?

  422. Ge0rG

    Zash: I think WS is masquerading as HTTPS, but of course with irregular traffic patterns.

  423. Ge0rG

    Zash: so it will work with the subset of firewalls that don't look too deeply into the traffic and don't have low timeouts

  424. daniel has left

  425. daniel has left

  426. la|r|ma has joined

  427. la|r|ma has joined

  428. daniel has left

  429. lumi has joined

  430. ralphm has joined

  431. Yagiza has joined

  432. Holger has left

  433. Holger has joined

  434. efrit has joined

  435. moparisthebest

    zinid, excellent work on TLS SRV patch :)

  436. zinid

    > are you going to pay the developers of all BOSH clients to migrate? Wow, we now care about backward compatibility? What about private storage, vcard avatars, privacy lists? Who payed the developers?

  437. zinid

    moparisthebest: thanks

  438. mathieui

    zinid, nobody, and most clients are still using private storage

  439. zinid

    regarding firewalls: it's just https traffice, timeouts will be handled by stream management

  440. zinid

    mathieui: I know ;)

  441. dwd

    zinid, I think we still need BOSH. We have to use it on occasion.

  442. moparisthebest

    I'm biased, but I think web clients use websockets, and non-web clients use direct TLS, both are equivalent when over 443 as far as evil firewalls go

  443. zinid

    moparisthebest: I think this webby stuff is mostly for browsers now, no?

  444. zinid

    not sure why would a non-web client use bosh/ws

  445. moparisthebest

    iirc gajim has a bosh implementation

  446. moparisthebest

    but I agree it *should* be

  447. zinid

    dwd: can't we use ws occasionally? :)

  448. dwd

    We experience browsers with websockets explicitly disabled. This is far from ideal, but still, they exist.

  449. moparisthebest

    dwd, I didn't know that was a possibility

  450. mathieui

    zinid, when you have no other choice for direct connection, ws/bosh in desktop clients seem like a nice fit

  451. Kev

    We experience browsers too old to websocket, too.

  452. Kev

    (Yes, yes, I know, I know, but they do)

  453. mathieui

    hopefully they will be 0dayed into history before long

  454. zinid

    damn, so I need to fix those mod_bosh bugs :(

  455. zinid

    thank you!

  456. dwd

    zinid, Also, I don't think your IPv6 is working.

  457. zinid

    dwd: it doesn't, yeah

  458. zinid

    something wrong with firewall probably

  459. dwd

    Kev, No, we're seeing new browsers, but with it disabled. And no, I didn't know either.

  460. moparisthebest

    mathieui, but for a desktop client direct TLS is also a (far easier) option whenever ws/bosh is

  461. Kev

    dwd: Yes, you said that, I didn't doubt it.

  462. mathieui

    moparisthebest, sometimes you cannot

  463. zinid

    dwd: the problem with ipv6 is I have nowhere to test it from

  464. zinid

    dwd: I don't have ipv6 at home, so...

  465. moparisthebest

    mathieui, aren't you connecting to ws/bosh over direct TLS ?

  466. moparisthebest

    unless you mean, fully in-the-clear-no-tls-xmpp :/

  467. pep.

    moparisthebest, sometimes non-standards ports are blocked

  468. mathieui

    no, I mean, you can proxy those from 443 with nginx

  469. moparisthebest

    and you can alpn (or protocol-inspect, ew) xmpp and http to xmpp server or nginx on 443

  470. moparisthebest

    it all depends on the server to have it set up properly, but bosh/ws does too

  471. jonasw

    moparisthebest, alpn will be blocked by firewalls if they really want to

  472. la|r|ma has joined

  473. la|r|ma has joined

  474. la|r|ma has joined

  475. moparisthebest

    yes it can be, and probably will one day, but not by wifi hotspots in coffee shops most likely

  476. moparisthebest

    also why it's not required, daniel and I talked about it back in the day, conversations will probably try with alpn and if it fails then without it, or vice versa

  477. Holger has joined

  478. Zash

    not *yet*

  479. moparisthebest

    so today, using alpn, you can have client -> sslh (based on alpn) -> (prosody,nginx)

  480. zinid

    yeah, ALPN is a really bad idea if you want to bypass the DPI: you're literally saying: "hey, I'm jabber"

  481. moparisthebest

    today you could also, without alpn, have client -> stunnel (or something decrypting TLS) -> sslh (based on xmpp/http) -> (prosody,nginx)

  482. moparisthebest

    the original spec sent the SRV name in SNI and used that to multi-plex :P

  483. moparisthebest

    no one liked my wanton abuse of SNI though :'(

  484. dwd

    moparisthebest, Wouldn't work in Java, I think.

  485. daniel has left

  486. zinid

    for the record, I heard it TLS v1.3 sni and other extensions will not be that easy to inspect

  487. zinid

    can somebody confirm?

  488. zinid

    I tried to read the I-D, but it's brutal

  489. moparisthebest

    yea TLS lib support for "serve the certificate for xmpp.org when server1.xmpp.org is in SNI" is probably spotty/non-existant

  490. moparisthebest

    I used sslh to multiplex on SNI and prosody just served the 1 cert regardless meh

  491. moparisthebest

    zinid, I know people were pushing to encrypt SNI/ALPN but last I heard it was abandoned to the future, they might have done something to obfuscate it or something, not sure

  492. Martin has left

  493. zinid

    moparisthebest: too bad, because the government firewall is annoying (it detects SNI)

  494. daniel has left

  495. Martin has joined

  496. moparisthebest

    which government?

  497. zinid


  498. moparisthebest

    ah that sucks

  499. dwd

    zinid, We could work around that.

  500. dwd

    zinid, Use starttls to establish the session and then resume it on directtls.

  501. moparisthebest

    you are just announcing it another way, also they could inspect the certificate coming back couldn't they?

  502. daniel has left

  503. zinid

    dwd: but starttls can be detected easily

  504. daniel has left

  505. moparisthebest

    so my work on 443 just holds your connection up temporarily, connects on it's own to see if the TLS handshake succeeds (and only supports TLS 1.0), and only if successful lets your connection through

  506. moparisthebest

    so if you only support TLS 1.1+ it won't allow that either, without also supporting 1.0...

  507. tux has left

  508. zinid

    yes, they could inspect the certificate

  509. Valerian has left

  510. zinid

    so I would prefere all parameters to be encrypted

  511. zinid


  512. moparisthebest

    it's a shame to have to consider that at a country level

  513. moparisthebest

    but nowadays even 'free-er' countries like UK look like they are moving in that direction...

  514. zinid

    right, you never know who's next

  515. zinid

    so this should be developed now

  516. zinid

    thus I'm wondered the TLS folks abandoned the idea

  517. moparisthebest

    it's been a year or two since I looked, hopefully it was picked back up idk

  518. moparisthebest

    the reason was because it breaks all the multi-plexing TLS business like I do with sslh

  519. moparisthebest

    so akamai and such were super against it

  520. moparisthebest


  521. moparisthebest

    August 29, 2017

  522. moparisthebest

    safe to say it's actively being worked on

  523. ralphm has left

  524. zinid

    but 20 pages...

  525. Arc has joined

  526. Zash

    Weren't all the CDNs strongly opposed to that?

  527. moparisthebest

    ha yea it's not short

  528. Zash

    oh you said that

  529. Zash

    20 pages is not what?

  530. moparisthebest

    but whatever they come up with there in theory should apply equally to ALPN

  531. moparisthebest

    Zash, he is saying https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-00 is 20 pages long

  532. zinid

    moparisthebest: there is a lot non-normative text, it's fine after all

  533. moparisthebest

    I can't find anything about ALPN encryption

  534. SamWhited

    I hadn't seen that; might be interesting to try and do an early implementation in our TLS 1.3 stack. I might give that a shot one of these days if I can convince my boss to loan me to the crypto team for a bit.

  535. SamWhited

    Does it look relatively implementable in its current form?

  536. edhelas


  537. mimi89999

    edhelas: We saw it.

  538. zinid

    mimi89999: in another chatroom ;)

  539. Ge0rG

    If we all are in all the same rooms, can't we just merge them into one?

  540. Zash

    Ge0rG: You are the one who started another? :)

  541. jonasw

    ... after people complained about off-topic discussions here

  542. jjrh has left

  543. Zash

    The off-topic discussions there are too on-topic!!

  544. tim@boese-ban.de has joined

  545. Ge0rG

    Zash: that's not my fault.

  546. mimi89999

    Ge0rG: 😁

  547. zinid

    last time I checked there was dead silence in this room

  548. zinid

    now it's active, that's cool

  549. Ge0rG

    zinid: board meeting approaching

  550. zinid

    Ge0rG: nah, I mean several years ago

  551. waqas has left

  552. MattJ


  553. Arc


  554. Martin

    Ding ding, board o'clock

  555. MattJ

    Looking promising :)

  556. jjrh has left

  557. nyco


  558. Arc

    4/5 this looks very promising

  559. MattJ

    ralphm, ?

  560. nyco

    I have to leave at :30 max

  561. MattJ


  562. jjrh has left

  563. Arc

    i cant stay much beyond :30 either

  564. Martin

    Ok, let's get cracking then

  565. Martin

    1. Roll call

  566. MattJ


  567. Arc


  568. nyco


  569. Martin

    2. Minutes, any volunteers? dwd?

  570. jonasw

    I can do it

  571. Valerian has joined

  572. jonasw

    but I’ll also have to leave at :30

  573. Martin

    Thanks jonasw, much appreciated.

  574. Martin

    3. Topics for decisions

  575. Martin

    Drawing from here: https://trello.com/b/Dn6IQOu0/board-meetings

  576. Martin

    3.1: Logo amendments. Struggled to get this tied off last week, thoughts?

  577. Arc


  578. nyco


  579. MattJ

    I think it was left last week that ralphm wanted other board members to express their opinion as well

  580. nyco

    voted on the GH issue

  581. nyco


  582. MattJ

    I was in favour, but it seems some folks are fairly against the change

  583. MattJ

    I continue to be +1, for the record

  584. Martin

    OK, me too

  585. Arc

    We are the only ones who even notice the glitch. It doesnt substantially alter our logo in any way a non-xsf member would ever notice.

  586. jcbrand has left

  587. Arc

    we notice it because we end up with it in front of us in inkscape, like guus did

  588. Guus

    board is now 4 times +1, one time 0.

  589. Arc

    (and btw, I printed the "fixed" logo on the trifolds for fosdem and nobody even noticed)

  590. Guus

    Arc: someone did.

  591. Guus


  592. SouL

    Yes, I did :(

  593. SouL

    That was supposed to be a happy smiley face, issues for using more than one keyboard layout.

  594. Ge0rG

    That logo has been triggering my OCD for years.

  595. jonasw pokes the participants

  596. Martin

    OK, so we're decided, it's approved

  597. Arc cheers

  598. Martin

    Moving on

  599. Martin

    4. Commitment list

  600. Martin

    4.1 D&0 quote?

  601. jonasw

    in one sentence for the minutes, what’s that?

  602. nyco

    no news? let's move on?

  603. Martin

    jonasw: I don't know. There's nothing more in Trello and this card precedes me being on Board

  604. jonasw

    I am amused.

  605. nyco

    stpeter is assignee

  606. jonasw

    I won’t put that in the minutes ;-).

  607. nyco


  608. nyco

    Council/board bios?

  609. nyco

    Arc and Martin, type here a short sentence! ;-)

  610. Martin

    4.2 Board bios

  611. mimi89999

    You chose the version where the 2 parts of the logo don't cross?

  612. Martin

    Will do my best

  613. ralphm

    Hi. I'm commuting, but following along

  614. Guus has left

  615. nyco

    next item?

  616. Martin

    5. Items for discussion

  617. Martin

    5.1 XSF Editor team. There's a comment from Guus that this might be solved?

  618. ralphm


  619. Martin

    …ok… anyone else got anything on this?

  620. jonasw

    I suspect no.

  621. nyco

    nope, next? ;-)

  622. Arc

    I have no basis to say anything on the topic

  623. Martin

    5.2 Legal notice on old public domain XEPs

  624. Martin


  625. Martin

    Looks like it's been merged, so I think the card's out of date

  626. daniel has left

  627. Martin

    5.3 Ongoing marketing activities & budget. It seems I added this card, but back in February, which is definitely too long ago for me to remember what it's about

  628. Arc

    you know we can, for once, close the meeting early :-)

  629. ralphm

    So if we don't know what to discuss, can we remove it?

  630. Martin

    ralphm: That's what I'm doing. If there's nothing, it's gone.

  631. ralphm

    I have one minute thing: elections

  632. nyco

    yes please

  633. stefandxm has left

  634. ralphm

    Shouldn't we have started this year's round?

  635. Martin

    5.4 Blog post on hold: nyco?

  636. Guus has left

  637. Guus has joined

  638. jonasw

    is that anything board needs to discuss?

  639. daniel has left

  640. Martin

    Nothing. OK. Next. AOBs.

  641. Martin

    ralphm: Elections?

  642. ralphm

    Yeah, sorry for jumping the agenda

  643. nyco

    blog post is published, so unblocked, but needs some fixes, in discussion with Guus, card can be archived

  644. ralphm

    But we need to have them

  645. jonasw

    Alex, you around?

  646. MattJ

    ralphm, Alex said he was working on it

  647. nyco

    what elections?

  648. ralphm

    I missed that

  649. jonasw


  650. jonasw

    what elections? board?

  651. MattJ

    a couple of weeks ago

  652. ralphm

    Council and board

  653. MattJ

    jonasw, yes

  654. efrit has left

  655. jonasw

    yeah, alex mentioned he’d work on it after the Q3 application meeting

  656. Guus

    Indeed, Alex mentioned he was going to address that soonish.

  657. jonasw

    "ASAP" were his words back then :)

  658. ralphm

    Ok. Martin can you put that in our Trello?

  659. Arc

    our last job as a board

  660. ralphm

    What, no

  661. ralphm

    Preparation takes weeks

  662. ralphm

    Finding candidates, then the online voting, etc

  663. Arc

    i mean, seeing a new board into their new role

  664. Guus

    (is board involved in the prep or execution?)

  665. ralphm

    Well ultimately we are responsible, yes

  666. ralphm

    Details are in the bylaws

  667. ralphm


  668. Arc

    Guus: tricking, er, fooling, er, convincing 5+ people to take the role is the board's responsibility. we can't leave until its done

  669. jonasw

    itym "welcoming"

  670. ralphm

    We should all consider if we would like to run again, as will council, and try and find good candidates for board

  671. Arc

    jonasw: yes, "welcoming"

  672. SamWhited

    I always get those confused :)

  673. goffi has joined

  674. nyco

    I'm gone, sorry, bye all!

  675. MattJ

    Thanks nyco

  676. Arc

    yea i need to head out soon. is there AOB?

  677. valo has joined

  678. MattJ

    I think we're done

  679. Guus

    The XEP status thing?

  680. Martin

    Think we're done, if people are going to start breaking off

  681. Guus

    Didn't Sam add a card?

  682. jonasw

    meh, someone forgot to put that on the trello I’m afraid, Guus

  683. ralphm


  684. jonasw

    ah, no it was there

  685. ralphm

    Guess we're done?

  686. Martin

    Ah, yes, "Rename Draft to Stable"

  687. jonasw

    but ralphm interrupted the agenda before it could be reached

  688. Alex

    yes I am here, cacthing up o the messages :-)

  689. Arc

    is it pressing such that we can't do it next week?

  690. jonasw

    personally, I don’t think so

  691. Guus

    Not pressing I think

  692. SamWhited

    It's not pressing

  693. ralphm


  694. Martin

    Right, then we're done.

  695. Martin

    +1W for next?

  696. Arc


  697. ralphm

    Yay. Thanks for chairing Martin

  698. ralphm


  699. Arc

    yes thanks for chairing

  700. MattJ


  701. jonasw

    Alex, can you give me a quick statement for the minutes on the status of the preparation of the elections for board & council?

  702. ralphm takes back hammer and bangs gavel

  703. Arc

    thanks ralphm :-)

  704. Alex

    jonasw: I was trying to find out when we had the election last year, need to look this up on teh memberlist, becasue the meeting minutes form last year are not on the new Wiki

  705. jonasw


  706. jonasw

    I’ll note that down as "preparation in progress"

  707. ralphm

    Last year was too late

  708. jonasw

    with some "data recovery needed due to data loss"

  709. Alex

    wanted to do this this week, but had to travel unexpted again then for the whole week to a customer

  710. ralphm

    We've been slipping over the years. Used to be in August

  711. emxp has joined

  712. Alex

    hopefully I can get some work done in the hotel in the evenings

  713. ralphm


  714. ralphm

    I know how life can conflict with foundation duties

  715. Guus

    Alex: need a hand?

  716. daniel has left

  717. Alex


  718. Alex


  719. Alex

    ralphm: yes, but we also said we should stick the 12 month term

  720. ralphm

    Yeah, I know

  721. ralphm

    So this is a good time to start then, right?

  722. Alex

    we had discussion a while ago to either make a term longer or shorter once, and agree on a fix schedule

  723. Alex

    I think Peter proposed a calendar year, Jan 1st to Dec 31,

  724. Alex

    ralphm: yes, this is why I have it on my TODO list for this week

  725. Alex

    I can setup the Wiki page this evening, and send out an Email

  726. ralphm


  727. Alex is on EST time this week

  728. moparisthebest

    calendar year makes sense for serving times, you'd still want the vote (much?) earlier though to avoid voting over holidays/new year

  729. SamWhited

    It seems like if you did calendar year that the first meeting would never happen because people would be on vacation.

  730. jubalh has joined

  731. jere has joined

  732. Alex has left

  733. Alex has joined

  734. jubalh has left

  735. jubalh has joined

  736. jubalh has left

  737. Martin has left

  738. moparisthebest

    that TLS SNI encryption RFC is making my brain hurt

  739. Zash

    RFC? Wasn't it an I-D?

  740. stefandxm has joined

  741. zinid

    moparisthebest: it's http fronting, not sure how it's better than tor for example

  742. zinid

    I read it too

  743. SamWhited

    I should figure out how the printer in this building works so that I can read it…

  744. jubalh has joined

  745. zinid

    easy in fact

  746. zinid

    The current draft proposes two designs for SNI Encryption in TLS. Both designs hide a "Hidden Service" behind a "Fronting Service". To an external observer, the TLS connections will appear to be directed towards the Fronting Service. The cleartext SNI parameter will document the Fronting Service. A second SNI parameter will be transmitted in an encrypted form to the Fronting Service, and will allow that service to redirect the connection towards the Hidden Service.

  747. zinid

    that's all

  748. Zash

    SamWhited: PC LOAD LETTER

  749. Zash

    I should figure out how to turn arbitrary RFCs and I-Ds into epubs or something I can read on the eink thing

  750. Yagiza has left

  751. Zash

    It's a pain, but at least I don't have to deal with printers.

  752. zinid

    what is a problem to ban this "fronting" sni?

  753. zinid

    I really don't get it

  754. Zash

    Wait so it's TLS over TLS???

  755. Arc has left

  756. jonasw

    Zash, https://tools.ietf.org/ebook/

  757. zinid

    Zash: yes :)

  758. zinid


  759. Tobias has joined

  760. Tobias has joined

  761. daniel has left

  762. jubalh has left

  763. jonasw

    rfc-std.epub appears to contain all the RFCs. It doesn’t take at all long to load on my machine....

  764. Zash

    I believe I have one of those already

  765. Zash

    Not the most optimal to navigate unfortunately

  766. xnyhps has joined

  767. tux has joined

  768. zinid

    ah, I got it, you can use any junk in the Fronting SNI

  769. zinid

    probably :)

  770. moparisthebest

    Zash, it's got txt/xml/pdf/html/bibtex

  771. Alex has left

  772. Zash


  773. moparisthebest


  774. pep.

    anybody using this https://xmpp.org/extensions/xep-0146.html

  775. goffi has left

  776. Zash

    moparisthebest: those are not what I want

  777. moparisthebest

    pep., I thought council voted to deprecate that?

  778. daniel has left

  779. pep.

    Doesn't seem deprecated to me, yet. "Last Updated: 2006-03-23"

  780. Zash has left

  781. pep.

    But I could see why

  782. Zash


  783. daniel has left

  784. moparisthebest

    pep., Council meeting minutes 2017-08-30: Vote on obsoleting XEP-0146 (Remote controlling clients) Period has expired with missing votes from Tobias and Dave. Dave and Tobias say they are happy with their implicit +1s.

  785. moparisthebest

    so, officially, it's deprecated, I think? editors? :)

  786. pep.


  787. moparisthebest

    or obsoleted

  788. daniel has left

  789. dwd has left

  790. Ge0rG has joined

  791. daniel has left

  792. jonasw

    moparisthebest, oha

  793. jonasw

    I remotely recalled there was something like that, thanks for pointing this out

  794. jonasw

    moparisthebest, I can’t find it in the council minutes you mentioned, are you sure it’s the correct date?

  795. jonasw

    ah, nevermind

  796. jonasw

    found it

  797. jonasw

    yeah, that indeed needs Deprecation

  798. moparisthebest

    jonasw, btw if you want to add alpn support to your client I can give you a test account on my server

  799. Zash

    jonasw: btw a big reason why I wanted xep->markdown was to produce epubs using pandoc, and it works pretty well for that

  800. ralphm has left

  801. fp-tester has left

  802. pep.

    https://xmpp.org/extensions/xep-0267.html what about "Server Buddies"? Anybody using it?

  803. jere has left

  804. jere has joined

  805. Zash

    I wanna use it for all sorts of things, but haven't gotten around to it :(

  806. arc has joined

  807. moparisthebest

    pep., this references it https://blog.process-one.net/wp-content/uploads/2016/07/Fighting-XMPP-messaging-spam-thanks-to-ejabberd-API.pdf

  808. moparisthebest

    more in a 'for the future' way

  809. pep.

    cool, thanks

  810. vanitasvitae has left

  811. Guus has left

  812. Guus has joined

  813. zinid has left

  814. fp-tester has left

  815. daniel has left

  816. Wiktor has joined

  817. Wiktor has joined

  818. waqas has joined

  819. mimi89999 has left

  820. mimi89999 has left

  821. Guus has left

  822. Guus has joined

  823. goffi has left

  824. goffi has joined

  825. Valerian has left

  826. Valerian has joined

  827. daniel has left

  828. dwd has joined

  829. Guus has left

  830. Guus has joined

  831. Valerian has left

  832. goffi has left

  833. ralphm has left

  834. Flow has joined

  835. uc has joined

  836. ralphm has left

  837. Valerian has joined

  838. ralphm has left

  839. jere has left

  840. jere has joined

  841. ralphm has left

  842. lskdjf has left

  843. lskdjf has joined

  844. Guus

    I've applied the logo change in most of the obvious places

  845. Guus

    if someone finds an old logo somewhere, please let me know

  846. jubalh has joined

  847. edhelas has left

  848. jubalh has left

  849. jubalh has joined

  850. winfried has left

  851. jubalh has left

  852. lskdjf has left

  853. lskdjf has left

  854. la|r|ma has joined

  855. Guus has left

  856. Guus has left

  857. jubalh has left

  858. daniel has left

  859. lovetox has left

  860. Guus has left

  861. daniel has left

  862. Guus has joined

  863. Guus has left

  864. Guus has joined

  865. lovetox has joined

  866. Guus has left

  867. uc has joined

  868. ralphm has left

  869. Guus has left

  870. daniel has left

  871. lovetox has left

  872. daniel has left

  873. lovetox has joined

  874. jubalh has joined

  875. jubalh has left

  876. lovetox has left

  877. Zash has left

  878. lovetox has joined

  879. Ge0rG

    Google Image search is full of it...

  880. moparisthebest has joined

  881. MattJ


  882. tim@boese-ban.de has joined

  883. jubalh has joined

  884. tux has left

  885. lovetox has left

  886. lovetox has joined

  887. Valerian has left

  888. SouL has joined

  889. nyco has left

  890. dwd has left

  891. Valerian has joined

  892. lovetox has left

  893. lovetox has joined

  894. moparisthebest has joined

  895. daniel has left

  896. moparisthebest has joined

  897. valo has left

  898. valo has joined

  899. fp-tester has joined

  900. jubalh has left

  901. Valerian has left

  902. fp-tester has left

  903. fp-tester has joined

  904. daniel has left

  905. SamWhited has left

  906. daniel has left

  907. daniel has left

  908. daniel has joined

  909. efrit has joined

  910. waqas has left

  911. SamWhited has joined

  912. Guus has left

  913. sonny has joined

  914. moparisthebest has joined

  915. moparisthebest has joined

  916. zinid has left

  917. SamWhited has joined

  918. lovetox has left

  919. lumi has joined

  920. arc has left

  921. Guus has left

  922. SamWhited has left

  923. SamWhited has joined