XMPP Council - 2019-09-25

oh, it is the day again

And there are PRs waiting for the Inbox.

Oh right, I’ll try to be available but nothing guaranteed, my bus is at 6pm 25 minutes away from my current restaurant.

I’ll try to be at some café at 5pm.

'tis time

Hi.

are we again without dwd and Kev?

and without an agenda.

Kev's here.

that’s at least something

Dave was just replying to Council stuff on-list, so I assume is about somewhere.

Do we have things that need to be agendarised this week?

probably

edhelas just pointed at https://github.com/xsf/xeps/pull/824

There's a protoXEP too isn't there?

Also JC split up the Retractions XEP into two inboxes

I think we missed voting on the ProtoXEP

The ProtoXEP from last week?

Here, sorry.

Ge0rG, I haven’t taken care of those yet because I was without internet over the weekend

we also have got https://github.com/xsf/xeps/pull/834

Note: I will have to leave exactly at 17:30 CEST or before, to not be left behind in Hamburg.

Wife's birthday today, so I was makinge mother-in-law a cuppa.

So:

Link Mauve: Hamburg is a very nice place. Just use the Council Meeting as an excuse to stay.

1) Roll Call

Full House!

Yay.

Ge0rG, that’s why I’m here. :D

2) Agenda Bashing

Sorry for no agenda - work is extremely busy for me right now.

dwd, to summarize what was writetn above: - https://github.com/xsf/xeps/pull/824 - https://github.com/xsf/xeps/pull/834 - https://xmpp.org/extensions/inbox/auth-tokens.html ✏

Ace, thanks.

(thanks)

3) Items for a vote:

* Message retractions: https://github.com/xsf/xeps/pull/832 * Message moderation: https://github.com/xsf/xeps/pull/833

a) https://github.com/xsf/xeps/pull/824

Ge0rG, tohse cannot be voted on yet

XEP-0060: Add pubsub#public in Publish-Subscribe features #824

they are not merged and have not been announced

and at least one of them has a build failure

This feels like it'd also be blocked on similar grounds to the MUC one Dave just -1d.

I'm going to vote on-list on this, pending the outcome of a quick chat I'd like to have in AOB about how we do this kind of thing.

Although somewhat less so.

dwd: "this kind of thing" - what kind of thing?

dwd, I have a few words on that AOB

Ge0rG, adding new informative features to a main XEP.

Ge0rG, See note to list (or wait until AOB), but summary is that if we constantly add small things to big specs they get bigger and never progress to Final.

Ge0rG, Particular things in extensible forms, etc.

Ge0rG, see CAKHUCzxMJNt+oYc=+q=Pa7AYd5311oNE4s_zirUwNhykXNhvUg@mail.gmail.com

pubsub#public looks like a breaking change to me.

Would anyone else like to vote?

Not at this stage, I think we need OtherDiscussion first.

Ge0rG, not if it is exposed with a disco#info-able feature on the service, which it doesn’t seem to do atm.

yes, on-list

on-list then

OK. Moving on.

b) https://github.com/xsf/xeps/pull/834

XEP-0410: treat remote-server-{not-found,timeout} like timeout #834

I’m +1 on this.

+1 on that one

(SURPRISE!)

As this is only a client behavior recommendation, I don't consider this a breaking change and thus I'm also +1 with my Council hat on

This seems sensible. I'm going to +1 on this.

Kev, What do you think about this one?

this is also based on a real-world issue, https://github.com/horazont/aioxmpp/issues/312

I'm here and pondering.

I should probably +1 it.

Kev, Feel free to on-list if you need more pondering.

While being concerned that it illustrates the brittleness of all this sort of thing.

I think it is a breaking change, but I don't see how bumping anything would improve interop over not bumping.

Kev, Yes, all this stuff is a nightmare of heuristics that's a workaround for issues with MUC.

Kev: the breakage doesn't affect anything but how a client treats incoming errors.

there is no interop issue, because there’s nothing interoperating at that point of the "protocol", methinks?

Ge0rG: Yes. I mean that a client compliant to 1.0.1 wouldn't be compliant to 1.1 - but as I say, I don't think bumping anything would be beneficial to anyone.

define "compliant"

"does what the spec says".

Also, there is no negociation here, so no bumping is required anywhere?

interop issues require that one party is relying on behaviour of another party, right?

Although I think Kev means "conformant", really, since "compliance" is usually associated with some kind of testing.

I don’t think that anyone can be relying on that client behaviour recommendation either way.

jonas’, The client is relying on those errors meaning what we think they mean in this case.

Kev, Voting or on-list?

How long would we like to spend arguing over my choice of words in approving this not being the choice of words people would have liked me to use in approving this?

I wasn’t seeing a definite approval from you :)

+1

just a "should probably", which is neither here nor there

Kev: until you utter one of (-1, +1, on-list)

thanks

:-)

I did utter +1, FWIW.

Awesome.

Kev, You said you probably should. I didn't take that as a vote, sorry.

c) https://xmpp.org/extensions/inbox/auth-tokens.html

on-list

ProtoXEP: https://xmpp.org/extensions/inbox/auth-tokens.html

on-list

I mean, ProtoXEP: XEP-xxxx: Authorization Tokens

On list too.

dwd: you can LMC ;)

*could’ve

This is the thing that happened while I was on holiday and the thread looked scary, right? :)

Ge0rG, [I'm never quite happy with doing LMC in meetings for anything beyond simple typos because of the record]

Kev, That'd be it.

I'll on-list this. I suspect this'll involve more thinking than I'd like.

(Unless Dave helpfully vetoes first)

Kev: you can't simply reuse somebody else's -1, you need to provide your own arguments.

In general, I'm vociferously against trying to define authentication pathways in the XSF. I do not believe we have the expertise, and I think it's a area where we should defer to the IETF (XMPP and/or Kitten Working Groups).

Ge0rG: Sure you can, you can just say "Make Dave happy" as the remediation.

Hence, -1. In addition, I think large amounts of this duplicate work in XEP-0399 - I appreciate there are differences, but I think it'd be better to work on '399 than introduce something entirely new but heavily overlapping.

is it also overlapping with XEP-0397: Instant Stream Resumption?

without voting officially (just for the record): I think that Dave is mostly right, but I’d like to take a look at '399 in this context myself before voting

Ge0rG, You can -1 a proposed XEP because it's my wife's birthday, if you like.

Ge0rG: Somewhat related, because of tokens.

Ge0rG, To some extent, yes. I noted that in my mail to the list, but mostly in relation to the HT-* SASL mech,

dwd: In my opinion, the XSF, and the Council especially, is already in a sufficiently sad state, even without involving your wife.

that reads mean

Anyone else want to vote?

hasn’t everyone said "on-list" or "-1"?

Sorry.

It was probably a bad comparison.

everyone has

I'm going to on-list. I'll be of the same opinion as Dave on both counts, but still want to re-read it all first.

But I'm default to -1, because that's what I'll ultimately say.

OK, thanks.

5) Outstanding Votes

I think none of us have any, now? Although I've a holding -1 on Jonas's MUC thing, so I ought to get to AOB quickly...

6) Next Meeting

+1w wfm

Same.

+1W WFM

There's an MLS Interim WG meeting next week I'm attending (I'll report back). You're welcome to carry on without me.

dwd, can you prepare an agenda?

jonas’, Maybe. Meeting's on tuesday as well, but I'll try.

7) AOB

dwd: re that MLS meeting; EU and German regulators are looking for suggestions on how to standardize interop between silo IM providers, including E2EE. I'd love to know whether MLS can be the vehicle for that, on a time frame of maybe two years

We seem to have a number of small additions to MUC and PubSub in particular which are, more or less, additions to a info form describing the node/room/etc.

dwd, I think the first step we need to take is to bring our Registries in order. Much of what has been happening lately is covered by the registries, but we don’t have anyone maintaining them (I’m not even sure that there’s a build process and how it works and I’m scared of looking) ✏

Can we handle these via the Registrar, or small XEPs?

dwd: first step would be to collect all the different additions that didn't make it to the Registrar, and to update all the registries

This feels like a registry thing to me.

Do we have someone who's acting as the XMPP Registrar?

it is a registry thing, but the registry is broken for all practical matters.

see above

It's the Editor, but we don't really have process.

Ah, quite. So no.

Do we flag this to Board and get them to find a volunteer?

this is in dire need of fixing

I don’t think we’ll find one

what I’d need is a hackathon together with iteam to figure out what the current state is and how to fix it.

jonas’: The issue is largely technical isn't it?

probably

OK, so we have two problems:

1) A broken registry system, and

I mean, the process as far as the XSF's concerned is that it's the Editor doing this.

But the Editor doesn't have the ability to do it.

2) Nobody to act as Registrar.

So, solutions:

(I’d also like to mention that I have a deadline on 15:30 UTC)

dwd: 3) a technical foundation probably not sufficiently automated for the task at hand, and maybe also an insufficient number of registry categories

Ge0rG, I consider (3) as a part of (1)

jonas’, Noted. I need to keep this one short myself.

so from my side (Editor hat), I could work with the following:

How about I send a summary of the status to the members list and we see if we can find some volunteers to help get the ball rolling?

(I’m also going to have to leave about now, to move closer to the Stockholm XMPP Sprint.) ✏

I set up a date with iteam where we work closely (low-latency, e.g. IM) on fixing this. that’ll involve looking into the current build system and how it’s wired to the web server and how we can get this running.

I volunteer, but I need help from iteam.

I can probably help, as long as MattJ doesn't mind me interfering in his iteam :)

jonas’, That sounds great if you can find the time.

dwd, it *does* look more promising at the moment

OK, this sounds like a good thing to try first.

And even better, needs no further action from Council or me. :-)

Anything else anyone needs to raise here?

I have a number of large AOBs that I'm still carrying around from Meeting to Meeting

I've had a headache for about 4 days. I'm happy to not spend more time on this.

a.k.a. NO

OK. In that case:

8) Ite, Meeting Est

Thanks all.

Thanks Dave. Thanks all

thanks

Also, Ge0rG - I'm dashing off now, but could you drop me an email with your AOB things? Say a paragraph on each. I'm wondering if any might be addressed if we tried an open meeting, separate from Council.

dwd: I'm sure I wrote that in the AOB part of one of our last Meetings. Maybe two months ago.

Ge0rG, You probably did, but I lack an issue tracker for these kinds of things.

ah, it was 2019-09-04 according to the minutes mail 1. discuss what to list in CS-2020 "Future Development" 2. message errors, still. 3. probably something that's not relevant any more?

dwd: https://logs.xmpp.org/council/2019-09-04#2019-09-04-e4670d04e03033cc

I think the Attach-To AOB got obsoleted by Message Fastening.

And the CS-2020 things were discussed in the linked meeting.

At least a little bit.