XMPP Council - 2018-05-16


  1. guus.der.kinderen has left

  2. guus.der.kinderen has left

  3. guus.der.kinderen has joined

  4. moparisthebest has joined

  5. SamWhited has left

  6. Zash has left

  7. Dave has left

  8. Dave has left

  9. guus.der.kinderen has left

  10. dwd has joined

  11. guus.der.kinderen has left

  12. Dave has left

  13. dwd has left

  14. dwd has joined

  15. Dave has left

  16. dwd has left

  17. Dave has left

  18. dwd has joined

  19. dwd has left

  20. Dave has left

  21. Dave has left

  22. dwd has joined

  23. Dave has left

  24. dwd has left

  25. guus.der.kinderen has joined

  26. dwd has joined

  27. Dave has left

  28. dwd has left

  29. dwd has joined

  30. guus.der.kinderen has left

  31. dwd has left

  32. guus.der.kinderen has left

  33. Dave has left

  34. guus.der.kinderen has left

  35. guus.der.kinderen has left

  36. guus.der.kinderen has left

  37. guus.der.kinderen has left

  38. guus.der.kinderen has left

  39. guus.der.kinderen has joined

  40. guus.der.kinderen has left

  41. guus.der.kinderen has left

  42. Dave has left

  43. Dave has left

  44. dwd has joined

  45. guus.der.kinderen has left

  46. guus.der.kinderen has left

  47. guus.der.kinderen has joined

  48. dwd has left

  49. Zash has left

  50. SamWhited has left

  51. daniel has left

  52. daniel has joined

  53. daniel has left

  54. daniel has joined

  55. guus.der.kinderen has left

  56. guus.der.kinderen has left

  57. guus.der.kinderen has joined

  58. Dave has left

  59. dwd has joined

  60. dwd has left

  61. guus.der.kinderen has left

  62. guus.der.kinderen has left

  63. guus.der.kinderen has joined

  64. Dave has left

  65. Dave has left

  66. dwd has joined

  67. dwd has left

  68. Dave has left

  69. Dave has left

  70. dwd has joined

  71. Dave has left

  72. dwd has left

  73. dwd has joined

  74. Dave has left

  75. dwd has left

  76. dwd has joined

  77. Dave has left

  78. dwd has left

  79. dwd has joined

  80. Dave has left

  81. dwd has left

  82. dwd has joined

  83. Dave has left

  84. dwd has left

  85. dwd has joined

  86. guus.der.kinderen has left

  87. Dave has left

  88. dwd has left

  89. Dave has left

  90. dwd has joined

  91. dwd has left

  92. guus.der.kinderen has left

  93. jere has left

  94. guus.der.kinderen has left

  95. guus.der.kinderen has left

  96. guus.der.kinderen has joined

  97. guus.der.kinderen has left

  98. guus.der.kinderen has left

  99. guus.der.kinderen has joined

  100. guus.der.kinderen has left

  101. guus.der.kinderen has left

  102. guus.der.kinderen has left

  103. guus.der.kinderen has left

  104. guus.der.kinderen has joined

  105. moparisthebest has joined

  106. Dave has left

  107. Dave has left

  108. Tobias has left

  109. Dave has left

  110. Tobias has joined

  111. dwd has joined

  112. dwd has left

  113. ralphm has joined

  114. pep. has left

  115. ralphm has left

  116. Remko has joined

  117. ralphm has joined

  118. moparisthebest has joined

  119. moparisthebest has joined

  120. Dave has left

  121. dwd has joined

  122. Dave has left

  123. Dave has left

  124. dwd has left

  125. dwd has joined

  126. dwd has left

  127. Dave has left

  128. dwd has joined

  129. dwd has left

  130. Dave has left

  131. dwd has joined

  132. Dave has left

  133. dwd has left

  134. Dave has left

  135. Dave has left

  136. dwd has joined

  137. dwd has left

  138. Dave has left

  139. daniel has left

  140. daniel has joined

  141. moparisthebest has joined

  142. moparisthebest has joined

  143. moparisthebest has left

  144. jere has joined

  145. moparisthebest has joined

  146. guus.der.kinderen has left

  147. jere has left

  148. jere has joined

  149. ralphm has joined

  150. vanitasvitae has left

  151. vanitasvitae has left

  152. guus.der.kinderen has left

  153. guus.der.kinderen has left

  154. moparisthebest has left

  155. guus.der.kinderen has left

  156. guus.der.kinderen has left

  157. guus.der.kinderen has left

  158. guus.der.kinderen has left

  159. guus.der.kinderen has left

  160. guus.der.kinderen has left

  161. guus.der.kinderen has joined

  162. guus.der.kinderen has left

  163. guus.der.kinderen has left

  164. guus.der.kinderen has joined

  165. Ge0rG has joined

  166. ralphm has left

  167. ralphm has joined

  168. Ge0rG has left

  169. Kev

    Should we not be having a meeting about now?

  170. Dave

    Yes, sorry, just on a call. There in one minute.

  171. Ge0rG

    It is this time of the week indeed

  172. SamWhited

    oh wow, it's later than I thought

  173. SamWhited quickly makes coffee but is here

  174. Dave

    Right!

  175. Dave

    Sorry about that.

  176. Dave

    1) Roll Call [https://en.wikipedia.org/wiki/Roll_Call_(IQ_album)]

  177. daniel

    i'm here

  178. SamWhited

    still here

  179. Ge0rG

    SamWhited: it always is.

  180. Kev

    Still here

  181. Ge0rG

    Looks like I have some significant lag.

  182. Dave

    Looks like we have everyone. My apologies for being late, there - a call at precisely the wrong moment.

  183. SamWhited

    Ge0rG: It's too early in the morning to be making big existential statements…

  184. Dave

    2) Isn't it nice that Tedd Sterr does the minutes?

  185. Kev

    Yes

  186. Dave

    (Which it is, very nice).

  187. Dave

    3) Adopt Proposed new XEP: XMPP Connections across HTTPS (HACX) Title: XMPP Connections across HTTPS (HACX) Abstract: This specification defines a procedure to look up various connection methods for an XMPP server over HTTPS, with a focus on censorship resistance. URL: https://xmpp.org/extensions/inbox/hacx.html

  188. Dave

    I believe this has been updated now, but I don't know if the new version has been published.

  189. Kev

    It has.

  190. Kev

    Version 0.0.2 (2018-05-16) Fix requirements, editing, add alternatives. (tjb)

  191. Dave

    Indeed, the requirements look updated to me, too.

  192. Ge0rG

    It references 0156 as something inappropriate because inflexible, but I'm not convinced we can't use http://docs.oasis-open.org/xri/xrd/v1.0/xrd-1.0.html#element.property for the desired use case

  193. Dave

    My own feeling is that if you want to circumvent firewalls, censorship, etc, then you should probably be using Tor, etc.

  194. Kev

    I'm perplexed how you're supposed to find the right server to make the HTTPS request to, given that it claims that, unlike DoH, you don't need to trust any third-party DNS.

  195. Dave

    And if Tor doesn't masquerade or steganographise itself, than fix that instead.

  196. Kev

    Oh, is that what it's for? I don't think that's actually listed in the Requirements (or I'm being dense, which is always possible).

  197. Dave

    "Needs to look like HTTPS".

  198. Dave

    Which it won't of course, beyond a matter of "It's TLS to the same port".

  199. Kev

    But it *is* HTTPS isn't it?

  200. Kev

    Just to a .well-known.

  201. Dave

    HACX is, but I think the intent is that the XMPP session can also look like HTTPS.

  202. SamWhited

    I didn't read that that ways

  203. Kev

    I'm not getting that from reading the XEP at all.

  204. SamWhited

    The title was the part that read that way to me and felt misleading.

  205. Kev

    As far as I can get from reading it, it's just trying to be 156 with some extra payloads.

  206. Dave

    If it's intended to be '156 with a bit more, then it can be done as extensions to '156, right?

  207. Ge0rG

    I had the same feeling as Kev, see above re Link/Property.

  208. Kev

    It seems that way to me, but we seem to have people with vastly different readings of what it's trying to do.

  209. daniel

    i’m not really sure how that XEP is supposed to circumvent censorship (it think it is meant to be used in conjunction with domain fronting). in any case as long as the XEP is formally correct and not 'complete garbage' i don't think we need to make the call about 'usefullnes' or 'duplicates other xep' right now

  210. Dave

    Kev, See, for example, the PR title: https://github.com/xsf/xeps/pull/627

  211. jonasw

    the author stated somewhere that the intent is to circumvent censorship

  212. jonasw

    in some MUCs

  213. daniel

    thats - if i'm not mistaken - only a requirment when going from experimental to draft

  214. Kev

    I think 'duplicates existing XEP' is one of the sensible reasons for rejecting a protoXEP, actually.

  215. jonasw

    yeah, that was my understanding, too, Kev

  216. Zash

    unless intended to replace it?

  217. Kev

    Dave: Interesting. I completely didn't get that from the XEP contents.

  218. Kev

    Zash: It says that 156 doesn't contain the information needed, but I'm not sure at this point that the information can't be added to 156.

  219. moparisthebest

    I listed why I didn't think it duplicated other XEPs in requirements

  220. SamWhited

    Yah, I agree with Kev. One of the frustrating things about developing for XMPP is searching the big xeps list and finding 3 things that all seem like they do the same thing and not knowing which one to use.

  221. Ge0rG

    If it wants to replace 0156, it better have a damn good rationale for reinventing the wheel.

  222. moparisthebest

    and why I thought we couldn't use/extend other XEPs

  223. SamWhited

    Whether this does or not is up for debate; but we should figure that out and if we want to eat that cost before going to experimental.

  224. moparisthebest

    if I was wrong about those, happy to just do that

  225. jonasw

    yeah, from http://docs.oasis-open.org/xri/xrd/v1.0/xrd-1.0.html#element.property (linked by Ge0rG earlier) it seems that XRD can easily extended

  226. Dave

    OK, I think we should vote.

  227. moparisthebest

    and yes it's to circumvent censorship in the same way that signal/telegram are pulling off in russia for example now

  228. Dave

    Kev, Ge0rG, daniel, SamWhited : Votes please.

  229. Ge0rG

    BTW, domain fronting has been disabled by Google and Amazon now.

  230. SamWhited

    moparisthebest: does anyone actually allow domain fronting anymore

  231. daniel

    +1

  232. Kev

    I'm -1 for now because I'd like to investigate not reinventing 156, but leave the door open to using this instead of it transpires 156 isn't suitable.

  233. moparisthebest

    amazon still allowed it at last check, technically

  234. Ge0rG

    -1, because I don't see a reason this can't be made an extension to 0156.

  235. moparisthebest

    they told signal 'don't do this please' but it still works

  236. SamWhited

    I am -1 for now. I think the title is misleading (makes me think it's a transport over HTTP) and we need to decide if we want a new thing or to merge it into the old thing, which seems like a longer discussion than we want to have here.

  237. moparisthebest

    Ge0rG, I specifically addressed that: Discovering Alternative XMPP Connection Methods (XEP-0156) [5] has a similar HTTP .well-known URL document, but since the XSF doesn't control the namespace we can't extend it with the extra required attributes to support weight/priority/alpn/sni and pinned keys, along with future methods. The business rules also state that it must only be used as a fallback which is in direct opposition of what HACX requires.

  238. Ge0rG

    they told signal "don't do this or else"

  239. Dave

    I'm -1; I think avoiding censorship is best done by Tor etc.

  240. Ge0rG

    moparisthebest: I've read that.

  241. Ge0rG

    moparisthebest: please explain to me that you can't add a different-namespace element to <Link> or have an encoding for <Property> values to express what you need expressed.

  242. moparisthebest

    I didn't think you could, if that's possible it's worth considering for sure, but then what about all the incompatible business rules?

  243. Dave

    OK, discussion over, we'll move on now.

  244. Ge0rG

    moparisthebest: you can change the business rules of 156 if desired.

  245. Zash has left

  246. Dave

    4) MIX Split Sayeth Kev: "Steve and I are looking at splitting up MIX at some point in the future. In the past it’s happened that when an already-accepted spec has been split into multiple that the Editor’s just published the ‘new’ XEPs without Council voting, as Council’s already accepted the content. Does anyone have any objections if we follow that principle here, or would Council like to go through voting processes for each split?"

  247. moparisthebest

    I'll wait until meeting end and bring this back up Ge0rG thanks

  248. Dave

    I think most of us have responded to this - anyone feel strongly either way?

  249. SamWhited

    nope

  250. Ge0rG

    I'd like to see MIX split up into many baby-MIXes, and I don't see a need to vote each of those.

  251. jonasw

    as I was CC’d to the request, I’m happy to do whatever council decides on this matter. A split would be great.

  252. Kev

    I feel fairly strongly that, given the split is a thing that I think Council either want or don't care about, and it's going into multiple documents, it's going to be fiddly and annoying to vote on everything in the right order, and we should just Do The Right Thing.

  253. Ge0rG has left

  254. Dave

    I would prefer MIX to be split, and would prefer not to make technical changes at the same time just out of good practise. Otherwise, split away.

  255. Ge0rG

    Agree with Dave. Separate editorial changes from technical ones and I'm fine.

  256. Dave

    So I'll take that as assent from everyone.

  257. SamWhited

    I would prefer that all the unnecessary stuff from MIX be split, but then just thrown away and not put into new documents which will just be even more confusing and hard to find.

  258. daniel

    i already gave my ok at the list; but i'm happy to vote +1 if it comes to a vote

  259. Ge0rG

    s/unnecessary//

  260. Dave

    daniel, Tempting as it is to vote on whether or not to vote, I'm not going there. :-)

  261. Dave

    5) AOB

  262. Dave

    Anyone got Any Other Bollocks?

  263. Ge0rG

    I propose to have a vote on whether we should perform meta-votes or not.

  264. Dave

    Ge0rG, We can vote on whether to do that or not.

  265. Ge0rG

    Dave: sure we can?

  266. Dave

    Ge0rG, Not entirely.

  267. Dave

    Any *serious* Other Business?

  268. Dave

    (Assuming not)

  269. Dave

    6) Next Meeting

  270. Kev

    Not here.

  271. Kev

    (No AOB here)

  272. Dave

    23rd May 2018 1500Z?

  273. Kev

    SBTSBC should work for me.

  274. daniel

    works for me

  275. SamWhited

    WFM

  276. Dave

    Excellent.

  277. Ge0rG

    I'm not 100% settled in my new project yet, so 1500Z might prove problematic in the next month or so.

  278. flow has left

  279. Ge0rG

    But no reason to change the time for everybody.

  280. Dave

    Ge0rG, If it's a problem, shout and we can move the time to one convenient for everyone.

  281. Dave

    7) Ite, Meeting Est.

  282. Kev

    Thanks all.

  283. moparisthebest

    so as far as extending 156, it looks like using http://docs.oasis-open.org/xri/xrd/v1.0/xrd-1.0.html#element.property it could represent all needed extra info, that's not a problem

  284. guus.der.kinderen has left

  285. moparisthebest

    not quite sure how you'd represent the same in the host-meta.json format, but maybe we just add extra tags in there

  286. moparisthebest

    the real problem is the business rules, can we change them in a Draft standard? https://xmpp.org/extensions/xep-0156.html#httpbizrules of the 3, 1 and 2 would just need removed entirely

  287. moparisthebest

    1. HTTP queries for host-meta information MUST be used only as a fallback after the methods specified in RFC 6120 have been exhausted.

  288. moparisthebest

    2. A domain SHOULD NOT present information in host-meta link records that is available via the DNS SRV records defined in RFC 6120.

  289. Ge0rG

    Dave: thanks, I'll keep that in mind

  290. moparisthebest

    would have to remove those

  291. moparisthebest

    well, *technically* not #2 because I'd be representing XEP-0368 SRV records and not RFC 6120 SRV records, but still might be best to remove it

  292. Ge0rG

    moparisthebest: I think that #2 is harmful independent of your ideas.

  293. Ge0rG

    Because SRV is unreliable in practice (Surprise!)

  294. moparisthebest

    yea, and can't actually be done over Tor fyi

  295. moparisthebest

    I mean, not without doing dns over https over tor or something

  296. moparisthebest

    actually hang on, representing the current hacx attributes as <Property/> would be straightforward, but what about the public-key-pin elements ?

  297. moparisthebest

    you'd either need to do something insane like <Property type="public-key-pin-1"> <Property type="public-key-pin-2">

  298. moparisthebest

    or something like seperating them with semi-colons inside the value?

  299. moparisthebest

    not *excellent*, not a deal breaker either

  300. guus.der.kinderen has left

  301. guus.der.kinderen has left

  302. daniel

    > One of the frustrating things about developing for XMPP is searching the big xeps list and finding 3 things that all seem like they do the same thing and not knowing which one to use. people should be looking for draft or stable xeps only. in general i don't see a problem with competing experimental xeps. it's just that our process is broken in a way that for a lot of vital functionality people are forced to use (and trained to use) experimental xeps. which is the real problem

  303. guus.der.kinderen has left

  304. daniel

    also the unfiltered list of xeps is probably not the best starting ground for new comers

  305. SamWhited

    If it worked that way I'd agree, except that MAM still isn't draft and Message Archiving would still have looked like something worth using until very recently. I've been trying to trim that down, but I still think we don't have a good process for making sure the draft XEPs keep up with what the community is actually doing (or are what we think the community should be doing, either way)

  306. daniel

    and doesn't have to be. that's what the compliance suite (or other more suitable means) are for

  307. Ge0rG has left

  308. SamWhited

    Same with the compliance suites; I agree they're a bette rway to get started, but we're not quite there yet. They're still hard to discover.

  309. Ge0rG

    the problem here is that once it's Draft, you can't touch it any more

  310. moparisthebest

    so any thoughts about 1. Whether most business rules for 156 can be nuked and others added?

  311. peter has joined

  312. Ge0rG

    moparisthebest: I don't know XRD well enough, but what about having multiple Properties with the same name?

  313. moparisthebest

    and then 2. if <Property> is suitable for public-key-pins

  314. daniel

    i mean i totally get where you are coming from; but fixing our broken process of xeps not moving fast enough through the pipeline by essentially not accepting experimental xeps anymore or putting them to unreasonable high expectations doesn't seem like the right fix

  315. moparisthebest

    hmm not sure if that's allowed Ge0rG , I'll see if I can figure it out

  316. Ge0rG

    moparisthebest: that might still be problematic if you need the pins ordered.

  317. Ge0rG

    moparisthebest: the process for the bizrules would be to make a PR and let council vote.

  318. moparisthebest

    no the pins don't need ordered

  319. moparisthebest

    are changes to draft business rules allowed at all though?

  320. moparisthebest

    I don't want to waste mine or anyone else's time if not

  321. SamWhited

    daniel: maybe. But if this can be merged into the existing thing I think it should be; and if not we should have this discussion first.

  322. Kev

    There's also 'can it be an extension to the existing, rather than a replacement?'.

  323. Ge0rG has left

  324. moparisthebest

    so again are changes to draft business rules allowed at all?

  325. Ge0rG

    moparisthebest: draft XEPs can be changed by Council vote.

  326. moparisthebest

    ok thanks

  327. Ge0rG

    There might be conditions on that change though, like "version bump". But I don't think that's useful for business rules

  328. moparisthebest

    what about editorial changes? like 156 references draft-ietf-xmpp-websocket instead of RFC 7395 ? can an editor merge those themselves?

  329. Ge0rG has left

  330. ralphm has left

  331. Ge0rG has left

  332. flow has left

  333. guus.der.kinderen has left

  334. guus.der.kinderen has left

  335. guus.der.kinderen has left

  336. guus.der.kinderen has left

  337. guus.der.kinderen has left

  338. Ge0rG has left

  339. SamWhited has left

  340. guus.der.kinderen has left

  341. guus.der.kinderen has left

  342. guus.der.kinderen has left

  343. guus.der.kinderen has left

  344. guus.der.kinderen has left

  345. guus.der.kinderen has left

  346. guus.der.kinderen has left

  347. vanitasvitae has left

  348. Ge0rG has left

  349. Lance has joined

  350. Lance has left

  351. daniel has left

  352. Ge0rG has left

  353. Syndace has joined

  354. Syndace has joined

  355. Ge0rG has left

  356. SamWhited has left

  357. Ge0rG has left

  358. guus.der.kinderen has left

  359. guus.der.kinderen has left

  360. guus.der.kinderen has joined

  361. guus.der.kinderen has left

  362. guus.der.kinderen has left

  363. guus.der.kinderen has left

  364. Ge0rG has left

  365. guus.der.kinderen has left

  366. Lance has joined

  367. guus.der.kinderen has left

  368. guus.der.kinderen has left

  369. guus.der.kinderen has left

  370. guus.der.kinderen has left

  371. vanitasvitae has left

  372. Ge0rG has left

  373. SamWhited has left

  374. flow has joined

  375. Lance has left

  376. Ge0rG has left

  377. vanitasvitae has left

  378. Dave has left

  379. dwd has joined

  380. Ge0rG has left

  381. dwd has left

  382. dwd has joined

  383. dwd has left

  384. Tobias has left

  385. Tobias has joined

  386. ralphm has joined

  387. vanitasvitae has joined

  388. Dave has left

  389. Dave has left

  390. dwd has joined

  391. SamWhited has left

  392. Dave has left

  393. Ge0rG has left

  394. dwd has left

  395. dwd has joined

  396. Dave has left

  397. dwd has left

  398. Ge0rG has left

  399. Ge0rG has left

  400. Dave has left

  401. Dave has left

  402. dwd has joined

  403. dwd has left

  404. dwd has joined

  405. dwd has left

  406. Ge0rG has left

  407. guus.der.kinderen has left

  408. Dave has left

  409. Dave has left

  410. Dave has left

  411. Dave has left

  412. Dave has left

  413. dwd has joined

  414. Ge0rG has left

  415. dwd has left

  416. pep. has left

  417. pep. has left

  418. pep. has joined

  419. Dave has left

  420. Dave has left

  421. Dave has left

  422. Ge0rG has left

  423. pep. has left

  424. dwd has joined

  425. Tobias has left

  426. Tobias has joined

  427. dwd has left

  428. Remko has left

  429. Ge0rG has left

  430. Ge0rG has left

  431. Dave has left

  432. Dave has left

  433. dwd has joined

  434. moparisthebest has joined

  435. jere has joined

  436. dwd has left

  437. dwd has joined

  438. dwd has left

  439. dwd has joined

  440. jere has joined

  441. dwd has left

  442. dwd has joined

  443. daniel has left

  444. dwd has left

  445. Ge0rG has left

  446. SamWhited has left

  447. vanitasvitae has left

  448. Ge0rG has left

  449. dwd has joined

  450. Ge0rG has left

  451. vanitasvitae has left

  452. dwd has left

  453. Syndace has left

  454. Syndace has joined

  455. Dave has joined

  456. Ge0rG has left

  457. Ge0rG has left