XMPP Council - 2018-05-16

Should we not be having a meeting about now?

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

It is this time of the week indeed

oh wow, it's later than I thought

Right!

Sorry about that.

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

i'm here

still here

SamWhited: it always is.

Still here

Looks like I have some significant lag.

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

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

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

Yes

(Which it is, very nice).

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

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

It has.

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

Indeed, the requirements look updated to me, too.

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

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

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.

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

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

"Needs to look like HTTPS".

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

But it *is* HTTPS isn't it?

Just to a .well-known.

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

I didn't read that that ways

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

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

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

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

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

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

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

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

the author stated somewhere that the intent is to circumvent censorship

in some MUCs

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

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

yeah, that was my understanding, too, Kev

unless intended to replace it?

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

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.

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

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.

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

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

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.

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

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

OK, I think we should vote.

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

Kev, Ge0rG, daniel, SamWhited : Votes please.

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

moparisthebest: does anyone actually allow domain fronting anymore

+1

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.

amazon still allowed it at last check, technically

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

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

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.

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.

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

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

moparisthebest: I've read that.

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.

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?

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

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

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

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

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

nope

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

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

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.

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.

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

So I'll take that as assent from everyone.

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.

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

s/unnecessary//

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

5) AOB

Anyone got Any Other Bollocks?

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

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

Dave: sure we can?

Ge0rG, Not entirely.

Any *serious* Other Business?

(Assuming not)

6) Next Meeting

Not here.

(No AOB here)

23rd May 2018 1500Z?

SBTSBC should work for me.

works for me

WFM

Excellent.

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

But no reason to change the time for everybody.

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

7) Ite, Meeting Est.

Thanks all.

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

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

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

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

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

Dave: thanks, I'll keep that in mind

would have to remove those

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

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

Because SRV is unreliable in practice (Surprise!)

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

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

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

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

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

not *excellent*, not a deal breaker either

> 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

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

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)

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

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.

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

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

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

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

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

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

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

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

no the pins don't need ordered

are changes to draft business rules allowed at all though?

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

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.

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

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

moparisthebest: draft XEPs can be changed by Council vote.

ok thanks

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

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