XSF Discussion - 2017-09-27


  1. 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?

  2. Guus

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

  3. 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

  4. daniel

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

  5. 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

  6. Ge0rG

    daniel: actually, to pay for two people.

  7. Ge0rG

    ...so that you have one effective developer

  8. 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...

  9. zinid

    sustainable model is to get hired :D

  10. mathieui

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

  11. daniel

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

  12. Ge0rG

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

  13. 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

  14. emxp

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

  15. 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.

  16. mathieui

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

  17. emxp

    mathieui: what do you mean exactly

  18. emxp

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

  19. Zash

    Some may find it weird to donate to commercial projects.

  20. Kev

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

  21. Kev

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

  22. Kev

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

  23. 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.

  24. Kev

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

  25. Ge0rG

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

  26. Ge0rG

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

  27. Kev

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

  28. Ge0rG

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

  29. Kev

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

  30. 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.

  31. 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.

  32. 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 :)

  33. Ge0rG

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

  34. mathieui start writign JEPs

  35. 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"

  36. mathieui starts writing JEPs

  37. Kev

    Routing was better before carbons?

  38. Zash

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

  39. 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.

  40. Ge0rG

    - resource locking must be burned with fire.

  41. Ge0rG

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

  42. 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.

  43. Ge0rG

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

  44. Ge0rG

    Kev: because of carbons and archives.

  45. MattJ

    There are ways though

  46. Ge0rG

    and race conditions.

  47. Kev

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

  48. Kev

    But only if you archive. Hmm.

  49. Ge0rG

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

  50. Ge0rG

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

  51. Kev

    Except for requiring a forklift upgrade.

  52. Ge0rG

    Kev: I'm open to less radical suggestions.

  53. 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.

  54. 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.

  55. Kev

    I guess there is.

  56. Kev

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

  57. Zash

    Design from the top instead of the bottom?

  58. Ge0rG

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

  59. Kev

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

  60. Kev

    (that being working a way out of the mess)

  61. 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.

  62. Ge0rG

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

  63. Kev

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

  64. Ge0rG

    Zash: yeah.

  65. Ge0rG

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

  66. Kev

    Or a fully-virtual summit.

  67. 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.

  68. Kev

    Or just a video chat between interested parties. Whatever.

  69. Kev

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

  70. Kev

    (But I could be wrong)

  71. Ge0rG

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

  72. Zash

    FOSDEM isn't too far away?

  73. 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.

  74. Ge0rG

    Even presence in MUC is a challenge.

  75. Ge0rG

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

  76. Kev

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

  77. Kev

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

  78. Ge0rG

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

  79. Zash

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

  80. Ge0rG

    Zash: yeah.

  81. Kev

    All your examples there included MUC.

  82. Zash

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

  83. Kev

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

  84. Ge0rG

    Kev: what Zash said.

  85. Ge0rG

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

  86. Kev

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

  87. Kev

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

  88. Ge0rG

    Kev: all those things are needed, yes.

  89. Ge0rG

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

  90. Ge0rG

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

  91. Kev

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

  92. Kev

    And we certainly need The Big Picture sorted.

  93. Ge0rG

    Kev: this is not about binning the core.

  94. Ge0rG

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

  95. 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.

  96. 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.

  97. Kev

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

  98. emxp

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

  99. Zash

    And big-picture needs a big whiteboard! :)

  100. 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

  101. jonasw

    Kev, I thnik he started a blog series :)

  102. Kev

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

  103. jonasw

    does the xmpp.org blog federate to that?

  104. zinid

    I'm lost, xmpp2.0 is coming?

  105. zinid

    just don't use XML anymore :)

  106. Zash

    funny

  107. zinid

    or JSON if that matters

  108. zinid

    JSON is XML of nowadays

  109. zinid

    kids from 2030s will laught at us again

  110. Zash

    Wake me up when ASN.1 is cool again

  111. zinid

    never?

  112. zinid

    it's not modern, ya know

  113. zinid

    protocol buffers is THE THING

  114. Ge0rG

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

  115. jonasw

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

  116. jonasw

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

  117. 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.

  118. 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.

  119. 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.

  120. 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.

  121. Zash

    Make Gohper Great Again

  122. Ge0rG

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

  123. Zash

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

  124. Ge0rG

    Zash: that what?

  125. Ge0rG

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

  126. Zash

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

  127. Zash

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

  128. zinid

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

  129. Zash

    Because Heartbleed?

  130. Zash

    Length prefixed fields helped so much there

  131. Ge0rG

    Zash: the issue with heartbleed was conflicting length fields.

  132. zinid

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

  133. jonasw

    zinid, that’s a reasonable statement :-)

  134. zinid

    well, yes :)

  135. Ge0rG

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

  136. zinid

    yeah, like http2

  137. zinid

    tcp over http, wtf...

  138. Zash

    Gotta let Google have their optimizations

  139. zinid

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

  140. zinid

    IETF is degrading

  141. Ge0rG

    W3C has fallen.

  142. Ge0rG

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

  143. zinid

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

  144. 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.

  145. 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.

  146. Zash

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

  147. Zash

    Or View Source and reading the HTML and stuff.

  148. Zash

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

  149. zinid

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

  150. Holger

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

  151. zinid

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

  152. zinid

    like they do for WebAssembly

  153. Zash

    Do binary protocols usually have that tho?

  154. Zash

    Like, included by default and accessible?

  155. jonasw

    Zash, protobuf does

  156. zinid

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

  157. jonasw

    Zash, $homebrewbinary probably doesn’t

  158. zinid

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

  159. zinid

    unlike parsing them

  160. Zash

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

  161. Zash

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

  162. jonasw

    *shrug*

  163. jonasw

    XML worksforme

  164. zinid

    this is the same argument as Python vs Haskell

  165. zinid

    Python will bite you later for sure

  166. zinid

    duck typing accepts no excuses

  167. Zash

    Duckt tapeing ftw

  168. jonasw

    duct taping?

  169. jonasw

    kinky

  170. Zash

    DuckDuckTape?

  171. 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 :(

  172. jonasw

    Ge0rG, #poezio? ;-)

  173. 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)

  174. Ge0rG

    jonasw: no way :P

  175. jonasw

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

  176. Ge0rG

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

  177. jonasw

    Ge0rG, right, it’s CRLF

  178. Zash

    The finer points HTTP header syntax will make you mad

  179. jonasw

    Zash, I’ve seen a fun talk about that

  180. jonasw

    forgot how it was called

  181. 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 ;)

  182. jonasw

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

  183. jonasw

    TIL there are trailers

  184. Ge0rG

    movie trailes? or the ones you live in?

  185. jonasw

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

  186. jonasw

    read the answer you linked :)

  187. Ge0rG

    Oh. My. God.

  188. SamWhited

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

  189. zinid

    bosh... plz god no

  190. Zash

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

  191. MattJ

    Sorry, I have a soft spot for BOSH

  192. 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

  193. zinid

    just terrible protocol

  194. 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)

  195. Zash

    Thanks Web & JavaScript!

  196. SamWhited

    it's a right pain.

  197. Ge0rG

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

  198. Zash

    CORBA YEAAAAAh

  199. fippo

    have you heard of dns over http aka DOH?

  200. Zash

    fippo: It needs moar JSON

  201. zinid

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

  202. pep.

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

  203. Ge0rG

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

  204. Ge0rG

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

  205. Ge0rG

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

  206. 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

  207. Zash

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

  208. Ge0rG

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

  209. 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

  210. moparisthebest

    zinid, excellent work on TLS SRV patch :)

  211. 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?

  212. zinid

    moparisthebest: thanks

  213. mathieui

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

  214. zinid

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

  215. zinid

    mathieui: I know ;)

  216. dwd

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

  217. 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

  218. zinid

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

  219. zinid

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

  220. moparisthebest

    iirc gajim has a bosh implementation

  221. moparisthebest

    but I agree it *should* be

  222. zinid

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

  223. dwd

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

  224. moparisthebest

    dwd, I didn't know that was a possibility

  225. mathieui

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

  226. Kev

    We experience browsers too old to websocket, too.

  227. Kev

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

  228. mathieui

    hopefully they will be 0dayed into history before long

  229. zinid

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

  230. zinid

    thank you!

  231. dwd

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

  232. zinid

    dwd: it doesn't, yeah

  233. zinid

    something wrong with firewall probably

  234. dwd

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

  235. moparisthebest

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

  236. Kev

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

  237. mathieui

    moparisthebest, sometimes you cannot

  238. zinid

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

  239. zinid

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

  240. moparisthebest

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

  241. moparisthebest

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

  242. pep.

    moparisthebest, sometimes non-standards ports are blocked

  243. mathieui

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

  244. moparisthebest

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

  245. moparisthebest

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

  246. jonasw

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

  247. moparisthebest

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

  248. 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

  249. Zash

    not *yet*

  250. moparisthebest

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

  251. zinid

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

  252. moparisthebest

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

  253. moparisthebest

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

  254. moparisthebest

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

  255. dwd

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

  256. zinid

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

  257. zinid

    can somebody confirm?

  258. zinid

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

  259. moparisthebest

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

  260. moparisthebest

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

  261. 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

  262. zinid

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

  263. moparisthebest

    which government?

  264. zinid

    russian

  265. moparisthebest

    ah that sucks

  266. dwd

    zinid, We could work around that.

  267. dwd

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

  268. moparisthebest

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

  269. zinid

    dwd: but starttls can be detected easily

  270. 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

  271. moparisthebest

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

  272. zinid

    yes, they could inspect the certificate

  273. zinid

    so I would prefere all parameters to be encrypted

  274. zinid

    *prefer

  275. moparisthebest

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

  276. moparisthebest

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

  277. zinid

    right, you never know who's next

  278. zinid

    so this should be developed now

  279. zinid

    thus I'm wondered the TLS folks abandoned the idea

  280. moparisthebest

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

  281. moparisthebest

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

  282. moparisthebest

    so akamai and such were super against it

  283. moparisthebest

    https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/

  284. moparisthebest

    August 29, 2017

  285. moparisthebest

    safe to say it's actively being worked on

  286. zinid

    but 20 pages...

  287. Zash

    Weren't all the CDNs strongly opposed to that?

  288. moparisthebest

    ha yea it's not short

  289. Zash

    oh you said that

  290. Zash

    20 pages is not what?

  291. moparisthebest

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

  292. moparisthebest

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

  293. zinid

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

  294. moparisthebest

    I can't find anything about ALPN encryption

  295. 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.

  296. SamWhited

    Does it look relatively implementable in its current form?

  297. edhelas

    https://signal.org/blog/private-contact-discovery/

  298. mimi89999

    edhelas: We saw it.

  299. zinid

    mimi89999: in another chatroom ;)

  300. Ge0rG

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

  301. Zash

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

  302. jonasw

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

  303. Zash

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

  304. Ge0rG

    Zash: that's not my fault.

  305. mimi89999

    Ge0rG: 😁

  306. zinid

    last time I checked there was dead silence in this room

  307. zinid

    now it's active, that's cool

  308. Ge0rG

    zinid: board meeting approaching

  309. zinid

    Ge0rG: nah, I mean several years ago

  310. MattJ

    ding

  311. Arc

    dong

  312. Martin

    Ding ding, board o'clock

  313. MattJ

    Looking promising :)

  314. nyco

    hey

  315. Arc

    4/5 this looks very promising

  316. MattJ

    ralphm, ?

  317. nyco

    I have to leave at :30 max

  318. MattJ

    Ok

  319. Arc

    i cant stay much beyond :30 either

  320. Martin

    Ok, let's get cracking then

  321. Martin

    1. Roll call

  322. MattJ

    Here

  323. Arc

    Here

  324. nyco

    Présent

  325. Martin

    2. Minutes, any volunteers? dwd?

  326. jonasw

    I can do it

  327. jonasw

    but I’ll also have to leave at :30

  328. Martin

    Thanks jonasw, much appreciated.

  329. Martin

    3. Topics for decisions

  330. Martin

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

  331. Martin

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

  332. Arc

    +1

  333. nyco

    +1

  334. MattJ

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

  335. nyco

    voted on the GH issue

  336. nyco

    done

  337. MattJ

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

  338. MattJ

    I continue to be +1, for the record

  339. Martin

    OK, me too

  340. 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.

  341. Arc

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

  342. Guus

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

  343. Arc

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

  344. Guus

    Arc: someone did.

  345. Guus

    *twitch*

  346. SouL

    Yes, I did :(

  347. SouL

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

  348. Ge0rG

    That logo has been triggering my OCD for years.

  349. jonasw pokes the participants

  350. Martin

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

  351. Arc cheers

  352. Martin

    Moving on

  353. Martin

    4. Commitment list

  354. Martin

    4.1 D&0 quote?

  355. jonasw

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

  356. nyco

    no news? let's move on?

  357. Martin

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

  358. jonasw

    I am amused.

  359. nyco

    stpeter is assignee

  360. jonasw

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

  361. nyco

    thx

  362. nyco

    Council/board bios?

  363. nyco

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

  364. Martin

    4.2 Board bios

  365. mimi89999

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

  366. Martin

    Will do my best

  367. ralphm

    Hi. I'm commuting, but following along

  368. nyco

    next item?

  369. Martin

    5. Items for discussion

  370. Martin

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

  371. ralphm

    .

  372. Martin

    …ok… anyone else got anything on this?

  373. jonasw

    I suspect no.

  374. nyco

    nope, next? ;-)

  375. Arc

    I have no basis to say anything on the topic

  376. Martin

    5.2 Legal notice on old public domain XEPs

  377. Martin

    https://github.com/xsf/xeps/pull/345

  378. Martin

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

  379. 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

  380. Arc

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

  381. ralphm

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

  382. Martin

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

  383. ralphm

    I have one minute thing: elections

  384. nyco

    yes please

  385. ralphm

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

  386. Martin

    5.4 Blog post on hold: nyco?

  387. jonasw

    is that anything board needs to discuss?

  388. Martin

    Nothing. OK. Next. AOBs.

  389. Martin

    ralphm: Elections?

  390. ralphm

    Yeah, sorry for jumping the agenda

  391. nyco

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

  392. ralphm

    But we need to have them

  393. jonasw

    Alex, you around?

  394. MattJ

    ralphm, Alex said he was working on it

  395. nyco

    what elections?

  396. ralphm

    I missed that

  397. jonasw

    ^

  398. jonasw

    what elections? board?

  399. MattJ

    a couple of weeks ago

  400. ralphm

    Council and board

  401. MattJ

    jonasw, yes

  402. jonasw

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

  403. Guus

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

  404. jonasw

    "ASAP" were his words back then :)

  405. ralphm

    Ok. Martin can you put that in our Trello?

  406. Arc

    our last job as a board

  407. ralphm

    What, no

  408. ralphm

    Preparation takes weeks

  409. ralphm

    Finding candidates, then the online voting, etc

  410. Arc

    i mean, seeing a new board into their new role

  411. Guus

    (is board involved in the prep or execution?)

  412. ralphm

    Well ultimately we are responsible, yes

  413. ralphm

    Details are in the bylaws

  414. ralphm

    Also

  415. 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

  416. jonasw

    itym "welcoming"

  417. ralphm

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

  418. Arc

    jonasw: yes, "welcoming"

  419. SamWhited

    I always get those confused :)

  420. nyco

    I'm gone, sorry, bye all!

  421. MattJ

    Thanks nyco

  422. Arc

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

  423. MattJ

    I think we're done

  424. Guus

    The XEP status thing?

  425. Martin

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

  426. Guus

    Didn't Sam add a card?

  427. jonasw

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

  428. ralphm

    Thanks!

  429. jonasw

    ah, no it was there

  430. ralphm

    Guess we're done?

  431. Martin

    Ah, yes, "Rename Draft to Stable"

  432. jonasw

    but ralphm interrupted the agenda before it could be reached

  433. Alex

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

  434. Arc

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

  435. jonasw

    personally, I don’t think so

  436. Guus

    Not pressing I think

  437. SamWhited

    It's not pressing

  438. ralphm

    Agreed

  439. Martin

    Right, then we're done.

  440. Martin

    +1W for next?

  441. Arc

    +1W

  442. ralphm

    Yay. Thanks for chairing Martin

  443. ralphm

    Wfm

  444. Arc

    yes thanks for chairing

  445. MattJ

    Thanks

  446. jonasw

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

  447. ralphm takes back hammer and bangs gavel

  448. Arc

    thanks ralphm :-)

  449. 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

  450. jonasw

    okay

  451. jonasw

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

  452. ralphm

    Last year was too late

  453. jonasw

    with some "data recovery needed due to data loss"

  454. Alex

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

  455. ralphm

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

  456. Alex

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

  457. ralphm

    Cheers

  458. ralphm

    I know how life can conflict with foundation duties

  459. Guus

    Alex: need a hand?

  460. Alex

    https://mail.jabber.org/pipermail/members/2016-September/008346.html

  461. Alex

    https://mail.jabber.org/pipermail/members/2016-November/008397.html

  462. Alex

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

  463. ralphm

    Yeah, I know

  464. ralphm

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

  465. Alex

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

  466. Alex

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

  467. Alex

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

  468. Alex

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

  469. ralphm

    Yay

  470. Alex is on EST time this week

  471. moparisthebest

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

  472. SamWhited

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

  473. moparisthebest

    that TLS SNI encryption RFC is making my brain hurt

  474. Zash

    RFC? Wasn't it an I-D?

  475. zinid

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

  476. zinid

    I read it too

  477. SamWhited

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

  478. zinid

    easy in fact

  479. 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.

  480. zinid

    that's all

  481. Zash

    SamWhited: PC LOAD LETTER

  482. Zash

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

  483. Zash

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

  484. zinid

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

  485. zinid

    I really don't get it

  486. Zash

    Wait so it's TLS over TLS???

  487. jonasw

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

  488. zinid

    Zash: yes :)

  489. zinid

    kinda

  490. jonasw

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

  491. Zash

    I believe I have one of those already

  492. Zash

    Not the most optimal to navigate unfortunately

  493. zinid

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

  494. zinid

    probably :)

  495. moparisthebest

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

  496. Zash

    what?

  497. moparisthebest

    https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/

  498. pep.

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

  499. Zash

    moparisthebest: those are not what I want

  500. moparisthebest

    pep., I thought council voted to deprecate that?

  501. pep.

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

  502. pep.

    But I could see why

  503. Zash

    https://www.zash.se/upload/-kIpyeZzS4C6LOXuehhxhQ.jpg

  504. 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.

  505. moparisthebest

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

  506. pep.

    k

  507. moparisthebest

    or obsoleted

  508. jonasw

    moparisthebest, oha

  509. jonasw

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

  510. jonasw

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

  511. jonasw

    ah, nevermind

  512. jonasw

    found it

  513. jonasw

    yeah, that indeed needs Deprecation

  514. moparisthebest

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

  515. Zash

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

  516. pep.

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

  517. Zash

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

  518. moparisthebest

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

  519. moparisthebest

    more in a 'for the future' way

  520. pep.

    cool, thanks

  521. Guus

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

  522. Guus

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

  523. Ge0rG

    Google Image search is full of it...

  524. MattJ

    DMCA