1) Roll Call [https://en.wikipedia.org/wiki/Roll_Call_(IQ_album)]
daniel
i'm here
SamWhited
still here
Ge0rG
SamWhited: it always is.
Kev
Still here
Ge0rG
Looks like I have some significant lag.
Dave
Looks like we have everyone. My apologies for being late, there - a call at precisely the wrong moment.
SamWhited
Ge0rG: It's too early in the morning to be making big existential statements…
Dave
2) Isn't it nice that Tedd Sterr does the minutes?
Kev
Yes
Dave
(Which it is, very nice).
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
Dave
I believe this has been updated now, but I don't know if the new version has been published.
Kev
It has.
Kev
Version 0.0.2 (2018-05-16)
Fix requirements, editing, add alternatives.
(tjb)
Dave
Indeed, the requirements look updated to me, too.
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
Dave
My own feeling is that if you want to circumvent firewalls, censorship, etc, then you should probably be using Tor, etc.
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.
Dave
And if Tor doesn't masquerade or steganographise itself, than fix that instead.
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).
Dave
"Needs to look like HTTPS".
Dave
Which it won't of course, beyond a matter of "It's TLS to the same port".
Kev
But it *is* HTTPS isn't it?
Kev
Just to a .well-known.
Dave
HACX is, but I think the intent is that the XMPP session can also look like HTTPS.
SamWhited
I didn't read that that ways
Kev
I'm not getting that from reading the XEP at all.
SamWhited
The title was the part that read that way to me and felt misleading.
Kev
As far as I can get from reading it, it's just trying to be 156 with some extra payloads.
Dave
If it's intended to be '156 with a bit more, then it can be done as extensions to '156, right?
Ge0rG
I had the same feeling as Kev, see above re Link/Property.
Kev
It seems that way to me, but we seem to have people with vastly different readings of what it's trying to do.
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
Dave
Kev, See, for example, the PR title: https://github.com/xsf/xeps/pull/627
jonasw
the author stated somewhere that the intent is to circumvent censorship
jonasw
in some MUCs
daniel
thats - if i'm not mistaken - only a requirment when going from experimental to draft
Kev
I think 'duplicates existing XEP' is one of the sensible reasons for rejecting a protoXEP, actually.
jonasw
yeah, that was my understanding, too, Kev
Zash
unless intended to replace it?
Kev
Dave: Interesting. I completely didn't get that from the XEP contents.
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.
moparisthebest
I listed why I didn't think it duplicated other XEPs in requirements
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.
Ge0rG
If it wants to replace 0156, it better have a damn good rationale for reinventing the wheel.
moparisthebest
and why I thought we couldn't use/extend other XEPs
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.
moparisthebest
if I was wrong about those, happy to just do that
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
Dave
OK, I think we should vote.
moparisthebest
and yes it's to circumvent censorship in the same way that signal/telegram are pulling off in russia for example now
Dave
Kev, Ge0rG, daniel, SamWhited : Votes please.
Ge0rG
BTW, domain fronting has been disabled by Google and Amazon now.
SamWhited
moparisthebest: does anyone actually allow domain fronting anymore
daniel
+1
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.
moparisthebest
amazon still allowed it at last check, technically
Ge0rG
-1, because I don't see a reason this can't be made an extension to 0156.
moparisthebest
they told signal 'don't do this please' but it still works
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.
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.
Ge0rG
they told signal "don't do this or else"
Dave
I'm -1; I think avoiding censorship is best done by Tor etc.
Ge0rG
moparisthebest: I've read that.
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.
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?
Dave
OK, discussion over, we'll move on now.
Ge0rG
moparisthebest: you can change the business rules of 156 if desired.
Zashhas left
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?"
moparisthebest
I'll wait until meeting end and bring this back up Ge0rG thanks
Dave
I think most of us have responded to this - anyone feel strongly either way?
SamWhited
nope
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.
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.
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.
Ge0rGhas left
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.
Ge0rG
Agree with Dave. Separate editorial changes from technical ones and I'm fine.
Dave
So I'll take that as assent from everyone.
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.
daniel
i already gave my ok at the list; but i'm happy to vote +1 if it comes to a vote
Ge0rG
s/unnecessary//
Dave
daniel, Tempting as it is to vote on whether or not to vote, I'm not going there. :-)
Dave
5) AOB
Dave
Anyone got Any Other Bollocks?
Ge0rG
I propose to have a vote on whether we should perform meta-votes or not.
Dave
Ge0rG, We can vote on whether to do that or not.
Ge0rG
Dave: sure we can?
Dave
Ge0rG, Not entirely.
Dave
Any *serious* Other Business?
Dave
(Assuming not)
Dave
6) Next Meeting
Kev
Not here.
Kev
(No AOB here)
Dave
23rd May 2018 1500Z?
Kev
SBTSBC should work for me.
daniel
works for me
SamWhited
WFM
Dave
Excellent.
Ge0rG
I'm not 100% settled in my new project yet, so 1500Z might prove problematic in the next month or so.
flowhas left
Ge0rG
But no reason to change the time for everybody.
Dave
Ge0rG, If it's a problem, shout and we can move the time to one convenient for everyone.
Dave
7) Ite, Meeting Est.
Kev
Thanks all.
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
guus.der.kinderenhas left
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
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
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.
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.
Ge0rG
Dave: thanks, I'll keep that in mind
moparisthebest
would have to remove those
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
Ge0rG
moparisthebest: I think that #2 is harmful independent of your ideas.
Ge0rG
Because SRV is unreliable in practice (Surprise!)
moparisthebest
yea, and can't actually be done over Tor fyi
moparisthebest
I mean, not without doing dns over https over tor or something
moparisthebest
actually hang on, representing the current hacx attributes as <Property/> would be straightforward, but what about the public-key-pin elements ?
moparisthebest
you'd either need to do something insane like <Property type="public-key-pin-1"> <Property type="public-key-pin-2">
moparisthebest
or something like seperating them with semi-colons inside the value?
moparisthebest
not *excellent*, not a deal breaker either
guus.der.kinderenhas left
guus.der.kinderenhas left
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
guus.der.kinderenhas left
daniel
also the unfiltered list of xeps is probably not the best starting ground for new comers
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)
daniel
and doesn't have to be. that's what the compliance suite (or other more suitable means) are for
Ge0rGhas left
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.
Ge0rG
the problem here is that once it's Draft, you can't touch it any more
moparisthebest
so any thoughts about 1. Whether most business rules for 156 can be nuked and others added?
peterhas joined
Ge0rG
moparisthebest: I don't know XRD well enough, but what about having multiple Properties with the same name?
moparisthebest
and then 2. if <Property> is suitable for public-key-pins
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
moparisthebest
hmm not sure if that's allowed Ge0rG , I'll see if I can figure it out
Ge0rG
moparisthebest: that might still be problematic if you need the pins ordered.
Ge0rG
moparisthebest: the process for the bizrules would be to make a PR and let council vote.
moparisthebest
no the pins don't need ordered
moparisthebest
are changes to draft business rules allowed at all though?
moparisthebest
I don't want to waste mine or anyone else's time if not
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.
Kev
There's also 'can it be an extension to the existing, rather than a replacement?'.
Ge0rGhas left
moparisthebest
so again are changes to draft business rules allowed at all?
Ge0rG
moparisthebest: draft XEPs can be changed by Council vote.
moparisthebest
ok thanks
Ge0rG
There might be conditions on that change though, like "version bump". But I don't think that's useful for business rules
moparisthebest
what about editorial changes? like 156 references draft-ietf-xmpp-websocket instead of RFC 7395 ? can an editor merge those themselves?