XMPP Council - 2019-11-06

Ge0rG: Given your mail earlier, is it no longer your intention to try to get CS2020 through this Council?

Kev: answering that question with either yes or no would end up ambiguous.

Kev: I don't have my mail in front of me, but my intention was to vote on Draft today, and have Social added during Draft

Ah, I see.

Not sure what kind of wording mishap happened to make you think I changed my plan

Your words were right, I just didn't understand them (because the thought of pushing it to Draft while there were pending changes didn't process)

Sorry for stalling your pipeline

.

Is it one of those days?

Always.

no, only with a probability of roughly 14%

Do we have a Dave?

It is one of those days.

We have a Dave.

I think Dave's too busy in xsf@ trying to find Boris-inspired ways to avoid democracy :)

Ah, there we go.

1) Roll Call

Present.

me too

Assuming Ge0rG and Link Mauve are still here, full house.

Yes.

2) Agenda Bashing

XEP-0243 to Draft, and that's it, right?

I have two points for the Agenda, related to CS-2020

AOB or voting things?

a) shall XEP-0392 Consistent Color Generation be demoted from "Advanced IM Client" into "Future Development"? b) Can we advance XEP-0423 to Draft, given the changes that I promise to have pushed some time tomorrow.

OK, given these, let's discuss these first and *then* vote if we're to do so.

3) Georg's Things.

3a) Yes.

I have no strong opinion on (a)

a) shall XEP-0392 Consistent Color Generation be demoted from "Advanced IM Client" into "Future Development"?

do whatever works

Yes please.

I was heavily criticized for adding it to the mandatory list of the Compliance Suite, because Council is not competent at guiding UX, and because it's not ready yet and for other reasons.

so just remove it since that seems to be what the (loud part of the) community wants?

I don't think I have an opinion here. But given the Wailing and Gnashing Of Teeth, I'm thinking punting it out of the compliance per-se would be the path of least contention.

I’d say remove it, it can always get integrated back later once it’s clear it works properly for everyone.

indeed, but I have no fear of contention.

My opinion isn't /that/ strong, but I don't think it belongs there, at the moment.

XEP-245 is also clearly guiding the UI design, and nobody objected _that_ (except for its ugly wire format)

Personally I think there are UX issues in much if not all of what we do, but I would rather than CS matched some kind of community concensus anyway.

I think that's vague agreement on 3a, then?

(ftr, I need to leave at 16:30Z sharp)

jonas’, Ack.

I think we have rough consensus on 3a), yes.

well, then. https://github.com/xsf/xeps/pull/851/commits/8182e2e38b25bda0a1febe7dc1019c9b0bf2a630

b) Can we advance XEP-0423 to Draft, given the changes that I promise to have pushed some time tomorrow.

I'd be happy to advance to Draft once my feedback's addressed.

The promised changes are in #851, except for an update to the "Changes since 2019", which I'll fix after consensus is reached

This one is more problematc for me. My gut feeling is "no", modulo some very persuasive arguments I've not thought of.

I've not had a chance to check the rendered copy for differences from what I reviewed yet.

Kev: your feedback was adressed on-list as well as in #851

> Ge0rG> XEP-245 is also clearly guiding the UI design, and nobody objected _that_ (except for its ugly wire format) I wanted to.. :-°

dwd: if we make it a formal vote starting today, we can manage to make a decision right before Council falls apart

But it's so much used everywhere..

When does Council cease to exist?

I have a bad gut feeling about the pre-vote process-wise too

dwd, the election meeting is on nov 21st

so the last council meeting will be on nov 20th

#851 also adds 156 (probably ok), 520 in future (probably ok), and adds 77, which I don't think is ok, as well as the Push thing being weird (because at least Android nor iPhone guarantee long-lasting background connections, AFAIU).

i.e. 2 weeks from now

Ge0rG, Can you get everything merged by tomorrow?

dwd: please ask Editor.

can we have an irregular council meeting tomorrow?

Ge0rG, if it’s finished by tonight, I can arrange that

(tonight ~= 18:00Z)

dwd: I'll take all Council feedback that I can get and update the PR

jonas’: ack

jonas’, That's what i was thinking. Nothig says our meetings have to be every week (indeed, they weren't until recently).

Kev: does "I don't think is ok" translate into a -1?

Where 'recently' is probably longer than they weren't ;)

I can join any time tomorrow except 10:45Z -- 11:45Z (lunch \o/) if I know when

Kev, More than likely, these days.

Ge0rG: Including 77 feels wrong to me.

I can join any time tomorrow.

Kev: why?

AGM is at 1900Z?

I think IBR is very right to include

Kev, 77 feels right to me, maybe excluding account registration.

dwd, yes

But allowing users to change their password is a must imo.

Because it pretty much presupposes that these things are Internet.

Ge0rG> dwd: please ask Editor. I can also help

And supporting account registration (in a software) also seems like a must.

Kev: this is about implementation support, not about having it enabled by default

Link Mauve: I think for just about all non-Internet (and a good chunk of Internet) cases this isn't true.

Mandating support for registration does not mean it has to be enabled on every deployment

Kev, note that software and deployment are separate things and disabling either registration and/or password change due to restrictions is valid

Kev, supporting account registration on the client side is very reasonable IMO, especially since there have been efforts of building onto the data forms flow of '77 for invitations and such

Guys, stop a sec - if we hold a meeting tomorrow at, say 1600Z, can we all make it and do we think we can have CS-2020 ready for a vote by then?

I understand the distinction between deployment and implementation, but I think requiring stuff that's only interesting for (some) Internet deployments isn't right here.

("invitations" = links with tokens which allow registration to a deployment)

Kev: do you actually have a server or client software that can't be configured to do IBR?

Ge0rG: Several :)

Kev: do those care about being "Core IM"?

dwd, I can be there at 17:00 CET tomorrow.

can we agree on having this only "Advanced"?

"Care" isn't the right word, probably, but I think the other stuff in the compliance suite that they don't do they reasonably could, wherease IBR just isn't appropriate.

Kev, Ge0rG, jonas’, Link Mauve - Can we agree a meeting tomorrow at 1600Z, and if so, can we have CS-2020 merged and published ready for a vote by then?

jonas’: it doesn't make much sense to me, but yes

dwd, yes, works for me

dwd: +1

+1.

I *think* I can do 1600 tomorrow.

(dwd, sorry, I wasn’t ignoring you, I was polling my calendar)

But I think thrashing this out now is worthwhile.

Else we'll get to the meeting tomorrow and vote on something not ready to pass.

OK, in that case I move to adjourn the formal Council meeting until tomorrow. But feel free to use the remaining time now to thrash things out.

yes, having it done by tomorrow's meeting implies that we make all the decisions now

That is, I think we should go into tomorrow with the approval being a formality.

dwd, I think that’s a very good move

Ge0rG, It does, and I agree with kev.

dwd: On the IBR point, or on the point that we should agree it now?

s/now/before the time of the meeting so it's a formality/

So, my view on '77 is that it's useful for password changing and IBR in various cases, but in a number of deployments it's undesirable if not impossible.

and deployments are free to disable features of the software

Kev, That we discuss things now so tomorrow is, as much as possible, a formality.

CS is for software, not deployments AFAIU

What jonas’ said. But I've been thinking about a "deployment" category-thing somewhere in it.

jonas’, It's also for expectations. Could a client find itself reliant on '77 and unable to function without?

Kev, which kind of software can’t change passwords (at all, not depending on e.g. having connected with specific SASL mechanisms), btw?

Link Mauve: Anything running against a corporate directory, probably.

dwd: I don't see such a dependency in 0077

Link Mauve, my prosody can’t change passwords because it doesn’t have th enecessary permissions on the ldap database

I also can't imagine a client that will only work if you use it to register a new account.

16:18:27 dwd> OK, in that case I move to adjourn the formal Council meeting until tomorrow. But feel free to use the remaining time now to thrash things out.

Right, but Prosody the software can, if it is configured against another type of database.

can we do this please?

you are drifting into deployments again

if I can catch a bus earlier that would be very useful

dwd: Close the meeting, sure.

jonas’, I thought it was already adjourned.

and I don’t think this discussion is helpful for me or vice versa

99) Ite, Meeting Est

And we were just continuing the discussion.

dwd, thanks :)

(But don't Ite)

date of next: 2019-11-07T16:00:00Z

jonas’, see you tomorrow. \o_

bye jonas’, I'll ping you and pep. with the finished PR

Ge0rG, thanks

Kev, dwd: jonas’ suggested demoting IBR into "Advanced IM", to which I can agree.

Now the question is: can you, too?

I think it's wrong there, too.

I think it's Basic with a note that says "Implem,entations cannot rely on XEP-0077 being deployed for either IBR or password changes as these may be undesirable or unavailable in a given deployment"

Because it's meaning "IM" is "public open registration chat service", basically, and I think you can legitimately have an "Advanced IM client/server" for all the other uses cases that aren't the "public open registration chat service"

I guess the goal of CS is relevant here, do we want to have a document to point newcomers who want to write XMPP software to, or do we want to have a document for certifying our existing software, or something else?

BRB.

And back.

Kev, WHat do you think of my note suggestion?

I could do both Basic and Advanced with a note saying "Only when intended for public open registration chat services" or something, similar to the weasel words for Push (with which I don't agree, but can live).

dwd: I don't like it being required for implementations.

I think there's wiggle room here if people really want it in - but wiggling is needed.

Or something like "If in-band password change is provided, it must be provided with 77, if not an alternative out of band mechanism for password change must be possible". I think the registration part shouldn't be there for either, though.

What would be the alternative place to put it in?

if the CS is mostly about discoveribility or steering people to the right xeps for problems that have multiple xep solutions; i don’t think that ibr is hard to discover

for those who need it

Do we need a new category "Public IM" just for IBR and 0157?

Ge0rG: We could also just have a section ...

I was thinking "Account Management" just for 77.

Kev: what's a section in CS terms?

Or a section of "Other specifications of note", like the Future Dev one?

dwd: Perfect.

Account Management should include a lot more than just 77, but that’s all we have atm.

Things like MAM messages lifetime configuration, cleaning uploaded files up, etc.

Link Mauve: write the XEPs, and get them into CS-2021

Ad-hoc?

Ge0rG, yes.

Zash, yes.

Ge0rG, current MAM already includes that, future MAM won’t anymore.

I would suggest either "Other specs of note" as Dave said, or a new suite just for 77.

dwd: can we have a more formal name for it? "Further relevant specifications"?

Suggested Reading, eg for the Mobile power consumption one?

I see a certain value in a new category "Public IM"

There are other things that might belong there, like spam handling.

Ge0rG, "If You Like These Suites, You'll Love:"

(Not this year)

Another future category, but that’ll be 2021 at least, would be audio/video.

“Jingle Category”

dwd: I'm not sure I'll get _that_ through tomorrow's council

I'd prefer a "Public IM" category over a section, because it's better structured that way. Also would include 0191

Ge0rG, "Further Specifications" section in each Suite. Good place to put '77, '286, and so on.

I note that you can do 'Public IM' fine without 77 too, but I'm much less militant about that.

Ge0rG, Would work for '392, as well. Stuff we can't or shouldn't mandate, but might be useful.

dwd: I have a bit of a fear that it will end up in a huge list of meaningless and unweighted bullet points

I like the "Further Specifications" (or "Further Specifications Of Note") idea per suite best, but can go along with the new suite.

In that case I need to weigh on which XEPs belong into "Further" and which ones belong into "Future"

Okay, I will create new "Further Specifications of Note" bullet lists in the relevant Compliance Categories. Next?

I don't see anything else raised by Council folks.

66 goes in there, I think, and that addresses my other bit of feedback.

Oh, there we go.

66 together with SIMS?

0333 as well, I suppose.

SIMS is very much future atm.

I would avoid adding anything more than we've already been through.

It feels like we've got something we can live with. Further tweaking is inviting calamity.

So it’s safe to ignore it for this year.

IMNRHO

Kev: do you consider the current state of #851 as "we've been through it"?

and I'll move IBR, 66, SIMS, 0392 into the "Further Specifications Of Note" sub-section and be done with it?

I mean, if the new stuff gets moved into the new 'Futher Specs' bit, it looks ok to me, I think.

Oh, yes, 392 in Further Specs is better than Future, good call.

I think there was one extra thing added with 77? Let me check.

Oh, 157. I think that's better in Futher Specs, but don't feel as strongly as 77.

Kev: 157 hangs on 77 ✏

Does it?

Ah, it's in there only as 'recommended for public servers' anyway.

Is CS meant to be a deployment thing now, not just an implementation thing?

Kev, As a private entity it might still be good to know which part of another private entity I should reach directly, if the information is available

Kev: https://op-co.de/tmp/xep-0423.html#im

Zash: shush!

Zash, apparently..

Implementations are always intended for deployment. If your implementation isn't for deployment in a public server (in the sense here) the implementation doesn't need to support it.

What about what I just said?

It would still be a private deployment

federating

Ge0rG: I've just read the "Further Specifications of Note" thing under #im, and that looks good.

Thanks for sticking with this.

Kev: I've renamed it to "Further specifications of note, which are not required for compliance:" for maximum explicity

pep.: I didn't say 157 needed to be public only, I just said that in the diff it was public only, which is at least as restrictive as I felt was needed.

Ge0rG: Thanks.

I'm still not sure why you'd want to get Core/Advanced IM compliance for a private deployment anyway, but oh well

FWIW, annoying as this probably is, I think having these sections makes the CS much better than trying to shoe-horn things into compliance, or be ignored completely, so it's a net win, even if at an unfortunate time.

pep.: People still have to write the implementations that people then select for private deployments.

Well they you define your specset and be done with it?

And you call it PrivateCompliance(tm)

If you can always just define the features you want, and check if implementations support them, and don't need guidance from the XSF, the Compliance Suites have no value.

could you please stop that meta discussion? It's making my head spin

Kev: also just moved 0286 into a similar space under https://op-co.de/tmp/xep-0423.html#mobile

Ge0rG: Unless I've missed something, we're good now, and we should stop this.

Ge0rG: I think that's an improvement too, thanks.

Kev: thanks very much for the heated debate, I also consider this as an improvement over before, even for 77

pep.: I think that "'The Internet is the only network we have to think about', or 'all services are public services'" are mindsets the XSF falls into quite often, and it's very harmful. ✏

I think the question is pretty clear, who is the target of CSs, and why would a private company want to comply to it. If they deem they don't need avatars they just don't do avatars

It sounds like you're assuming that anyone with a private deployment wrote it themselves, or had it custom-produced for them.

Kev: that sounds like a strong parallel to the CA/BF and other entities equalling "Internet" with "Web", and causing much more collateral damage than we ever could

Kev, sure. I'm not promoting free software dev slavery for profit-driven companies

And I think I'm done with this discussion.

Who said anything about free software, or profit-driven companies?

but I still think that supporting IBR in an implementation is a net win for that implementation, even if it's targeted at Enterprisey Enterpises.

I think having a map for the jungle of xeps is very valuable to all kind of implementations. The map should just properly mark paths as such if they are only valuable for some demographics

daniel: I agree (and I think Ge0rG's changes just now make this much better).

It not just about getting the 'compliancy stamp'

Yes. I see the compliance suites as more useful for advice to implementors about what people choosing software might need, than about a sticker.

It's why, in a future year, I'd like to see them not called Compliance Suites, but something that better reflects they're Implementation Advice.

Then I don't understand why you fight so hard against IBR. These two last messages make me wonder

If you don't want the stamp anyway

Because I think it's bad advice to say it's needed in the general case (plus, as long as the compliance suites advertise themselves as compliance suites, they'll be treated as such).

> It's why, in a future year, I'd like to see them not called Compliance Suites, but something that better reflects they're Implementation Advice. I think I agree with that. The compliance suites have certainly evolved into what can be understood as implementation advice.

wherever there are green checks people will see green checks. Call it however you want ("Compliance Suites" or "Implementation Advice")

That being said. Stickers are also nice

Blindly chasing green check marks is probably not something we want to encourage

Says the person who developed the compliance tester

Kev, I’m thinking about drafting a blog post emphasising “XMPP 2020”, with the compliance suite being its technical specification, but also to encourage implementations to get the stamp.

My feeling with much of the 0392 backlash was that it came from people blindly following green checkmars.

I don’t know if that aligns with your views.

Ge0rG, did it?

I disagree with Kev regarding the value of a CS-2020 stamp, so feel free to put my name on that blog post ;)

Link Mauve: ^

:D

A little bit of marketing won’t hurt us. ^^

I’ll let you all review it of course.

pep.: along the lines of "we can't implement 0392 while following the Whatever Usability Guides so now you make us lose Advanced IM!"

pep., jonas’: https://github.com/xsf/xeps/pull/851 is ready to merge now

k

pep.: good luck doing the version block!

🙈🙉🙊

But I suppose you can derive it from https://github.com/xsf/xeps/pull/851/commits/b378edaa069b2d4df2fa5c0b88bf0c927dd585ff

But yeah I think we were successful in creating a compliance suite that nobody implements

Ge0rG, you know generally we just add the "Needs version block" label and let people do?

I'd prefer if you did it, you know best what goes in there :x

ok if it's "just" that I can have a look

daniel: in light of that statement, I now see why you didn't follow up to our recent discussion re Compliance Checker vs Compliance Suite, and how the latter can learn from the former

pep.: I always struggle with what version to put in there, and fear that Editor Tooling will mess around with it. Sorry

Update the minor, it's not an editorial change

editorial is patch, and major is process

(I mean.. experimental, draft, final)

I'm also very much new to that anyway :P

pep.: see, you can train your editor skills now! ;)

How lucky am I!

I'll try to do it next time, but I still haven't fully recovered and already spent more on 0423 today than my time budget permitted.

k, I started already

Ge0rG, you forgot to add 333 and 420 in the changelog since 2019

pep.: you just made me shiver a little bit, but I intentionally left out "Future Development" from "Changes since 2019"

I see. I'm wondering if I should add that in the changelog. But I see now I've copied your block last time and it wasn't in it..

Ge0rG, pushed. Let's wait for CI now..

pep., just build locally with docker

I don't have a good enough uplink

it takes ages

building?

or pushing?

worry about your downlink

pushing

right

is it on master already?

yeah it's master

I’m building it

thanks

this 1 MiB/s uplink must be good for something.

> Microsoft is at capacity with at least some of its Azure VMs in the East US2 region, users are reporting. Microsoft acknowledges it is placing restrictions on additional quota on some customers there: https://t.co/8cCaKvJJh1 Stop using the cloud already! It's overloaded! https://twitter.com/maryjofoley/status/1190015959140057089

The cloud isn't a big truck!

Yes it is!

https://upload.yax.im/upload/lfkVjwUG0FDz6k4b/awssnowmobile.0.jpeg

Oh snap

pep., push’d

Thanks, I sent the email