XMPP Council - 2018-05-16

  1. Kev

    Should we not be having a meeting about now?

  2. Dave

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

  3. Ge0rG

    It is this time of the week indeed

  4. SamWhited

    oh wow, it's later than I thought

  5. SamWhited quickly makes coffee but is here

  6. Dave


  7. Dave

    Sorry about that.

  8. Dave

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

  9. daniel

    i'm here

  10. SamWhited

    still here

  11. Ge0rG

    SamWhited: it always is.

  12. Kev

    Still here

  13. Ge0rG

    Looks like I have some significant lag.

  14. Dave

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

  15. SamWhited

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

  16. Dave

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

  17. Kev


  18. Dave

    (Which it is, very nice).

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

  20. Dave

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

  21. Kev

    It has.

  22. Kev

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

  23. Dave

    Indeed, the requirements look updated to me, too.

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

  25. Dave

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

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

  27. Dave

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

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

  29. Dave

    "Needs to look like HTTPS".

  30. Dave

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

  31. Kev

    But it *is* HTTPS isn't it?

  32. Kev

    Just to a .well-known.

  33. Dave

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

  34. SamWhited

    I didn't read that that ways

  35. Kev

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

  36. SamWhited

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

  37. Kev

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

  38. Dave

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

  39. Ge0rG

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

  40. Kev

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

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

  42. Dave

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

  43. jonasw

    the author stated somewhere that the intent is to circumvent censorship

  44. jonasw

    in some MUCs

  45. daniel

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

  46. Kev

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

  47. jonasw

    yeah, that was my understanding, too, Kev

  48. Zash

    unless intended to replace it?

  49. Kev

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

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

  51. moparisthebest

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

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

  53. Ge0rG

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

  54. moparisthebest

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

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

  56. moparisthebest

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

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

  58. Dave

    OK, I think we should vote.

  59. moparisthebest

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

  60. Dave

    Kev, Ge0rG, daniel, SamWhited : Votes please.

  61. Ge0rG

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

  62. SamWhited

    moparisthebest: does anyone actually allow domain fronting anymore

  63. daniel


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

  65. moparisthebest

    amazon still allowed it at last check, technically

  66. Ge0rG

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

  67. moparisthebest

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

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

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

  70. Ge0rG

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

  71. Dave

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

  72. Ge0rG

    moparisthebest: I've read that.

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

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

  75. Dave

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

  76. Ge0rG

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

  77. 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?"

  78. moparisthebest

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

  79. Dave

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

  80. SamWhited


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

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

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

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

  85. Ge0rG

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

  86. Dave

    So I'll take that as assent from everyone.

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

  88. daniel

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

  89. Ge0rG


  90. Dave

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

  91. Dave

    5) AOB

  92. Dave

    Anyone got Any Other Bollocks?

  93. Ge0rG

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

  94. Dave

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

  95. Ge0rG

    Dave: sure we can?

  96. Dave

    Ge0rG, Not entirely.

  97. Dave

    Any *serious* Other Business?

  98. Dave

    (Assuming not)

  99. Dave

    6) Next Meeting

  100. Kev

    Not here.

  101. Kev

    (No AOB here)

  102. Dave

    23rd May 2018 1500Z?

  103. Kev

    SBTSBC should work for me.

  104. daniel

    works for me

  105. SamWhited


  106. Dave


  107. Ge0rG

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

  108. Ge0rG

    But no reason to change the time for everybody.

  109. Dave

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

  110. Dave

    7) Ite, Meeting Est.

  111. Kev

    Thanks all.

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

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

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

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

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

  117. Ge0rG

    Dave: thanks, I'll keep that in mind

  118. moparisthebest

    would have to remove those

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

  120. Ge0rG

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

  121. Ge0rG

    Because SRV is unreliable in practice (Surprise!)

  122. moparisthebest

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

  123. moparisthebest

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

  124. moparisthebest

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

  125. moparisthebest

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

  126. moparisthebest

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

  127. moparisthebest

    not *excellent*, not a deal breaker either

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

  129. daniel

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

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

  131. daniel

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

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

  133. Ge0rG

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

  134. moparisthebest

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

  135. Ge0rG

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

  136. moparisthebest

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

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

  138. moparisthebest

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

  139. Ge0rG

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

  140. Ge0rG

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

  141. moparisthebest

    no the pins don't need ordered

  142. moparisthebest

    are changes to draft business rules allowed at all though?

  143. moparisthebest

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

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

  145. Kev

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

  146. moparisthebest

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

  147. Ge0rG

    moparisthebest: draft XEPs can be changed by Council vote.

  148. moparisthebest

    ok thanks

  149. Ge0rG

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

  150. moparisthebest

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