XMPP Council - 2019-09-11

There is no agenda yet, so I'd like to bring up for vote: - https://github.com/xsf/xeps/pull/820 - https://github.com/xsf/xeps/pull/822

also, ProtoXEPs

I even started typing an agenda mail, but then I wasn't able to resist the urge to call it "Twin Towers Edition" and thus I quickly deleted the draft

You should have written it. I only just noticed it's Wednesday.

time is tricky

dwd: it would've been biased.

dwd: the time. It is.

Here, we are.

.

Yes indeed.

1) Roll Call.

Hi, I’m here!

Presumably that's a full house then.

Just on time I see. ^^'

2) Agenda Bashing

Given I didn't notice it was Wednesday, I've not managed one at all, sorry.

We've certainly got fastening on it.

I see one announced ProtoXEP, and one merged but not yet announced, is that right?

Plus the two github PRs above.

seems realistic

the merged one isn’t built yet, thus not announced

OK, sounds good. So three things.

3) Items for a vote.

a) Proposed XMPP Extension: Message Fastening

https://xmpp.org/extensions/inbox/fasten.html

This is clearly duplication of existing work.

The author should collaborate with the authors of Attaching.

it *is* duplicating existing work, and I find the remarks on the mailing list on lack of examples on how this helps with magic MAM relevant

There *is* merit in requiring to re-think magic MAM in this context, but maybe Council will be confident enough in this wire format to bear whatever magic MAM will require?

What is the actual distinction between this and XEP-0367?

dwd: Council decided last week that they'd rather a new protoXEP was submitted/accepted than 367 updated. As you'll remember.

something about the <external/> stuff doesn’t sit right with me either, and I’d like to see a practical motivation for it

During our discussion of whether it should be a new XEP, or an update to 367

(FWIW, I’m not strictly arguing for rejecting this because of dup)

Kev, Sure. But what is the difference between this as '367 beyond "it's in a different document"? ✏

the lack of fastenings to fastenings seems like an unnecessary restriction to me

dwd: Mostly the external stuff, the replacing, and the removing that I need to push once it's accepted.

I haven’t had the time to read this protoxep entirely yet, I just skimmed through it, but indeed that sounds like it would restrict future usecases we don’t know about yet.

As I've said before, it would fit well into 367 as long as we're happy to update 367 with it.

Such as for instance a fictional external approval for an edit.

Link Mauve: Yes, deliberately. Better, in this case, to restrict now and loosen later, than to end up with confusion where we didn't specify the use cases that we didn't anticipate properly.

so maybe the question for Council should be: 1) bury 0367, accept Fastening 2) Merge Fastening into 0367 3) Have both in parallel

Kev, we’ve had that in the past with 0308, where devs mostly ignored the “last” message restriction, and instead allowed to correct any without further negociation.

I mean, I'm basically fine with the document in isolation. But my impression was that XEP-0367 was unsuited to, for example, reactions. But fastening seems essentially similar to '367, so I'm wondering what fastening gains us that '367 does not.

But fair enough.

dwd: This started because we were told that Sam (as author) did not want 367 used for reactions.

dwd: 0367 is well suitable for reactions, give or take some minor business ruls

dwd, the only thing which made '367 "unsuitable" was that folks had the strong opinion that reactions are not attachments

The initial plan was to just update 367

Then last week I asked for a clear direction from Council as to whether to update 367 or publish something new because I did not want discussions about what the right thing to do was *after* I did the work. We concluded 'publish a new XEP'. Here we are.

We can, of course, go with Sam's offer of adding me as an author of 367 and having at it that way. I'll just be really annoyed by Council's policy flip.

Kev, I think there was an expectation that your proposal would go further beyond what '367 has

but I may be wrong

I'd be fully okay with burying 0367 and removing Fastening to New Attaching with a new number

Well, I'm for publishing it, but clearly both '367 and this cannot go on to Draft.

I was just expecting something significantly different from Attaching, I suppose.

FTR, I do *not* think 367 is fundamentally unsuited for this, or that fastening is revolutionarily different to 367. I was Just Following Orders.

Kev, I think that's somewhat unfair, given that you did insist on having orders to follow.

But let's vote on this:

Anyone want to vote?

Someone, anyone?

uh, I was expecting you’d spell something out ;)

I’m +1 on this

we can develop this further in Experimental

dwd: in case we do want to merge Fastening into 0367, wouldn't assigning a new number block us from that?

But yeah, let's make some progress. +1

Ge0rG: I believe if we wanted to C-A, C-C, ->367, C-V, we could.

Ge0rG, we can (have Kev) retract Fastening at any time

Although if that's our intention, we could probably just -1 this now and do it immediately.

jonas’: with Kev following orders, I agree

Kev, if we want to have only one, and the three 0367 authors are fine with that, it would better be.

for the protocol, I don't have a strong opinion on that, so we shoud do whatever is good to stabilize fastachments.

I'm +1, just to get progress.

Link Mauve: Technically, the 367 authors don't need to be, but yeah.

Kev, for an experimental one?

Indeed. It's the XSF's, Council get to do what they want, pretty much.

It doesn't belong to the Authors.

Link Mauve, we can always remove them as authors :)

I don’t mind having a new number and retracting the 0367 afterwards, or merging it into 0367, so I’m +1 on this too; numbers are cheap.

Right.

I'm +0 :)

Indeed, XEPs belong to the XSF, but only once adopted and given a number.

so everybody voted now?

I believe so - 4*(+1) +0

Yes, 4*+1, 1*+0

\o/

OK, moving on.

congratulations Kev

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

That's just adding an example of something that should be rejected.

+1

+1

Which looks good to me. +1

+1

I wasn't sure about the Shakesperean English.

+1 too.

Maybe one of the Brexiters can spellcheck that.

Unanimous +1's.

\o/

> Merge made by the 'recursive' strategy.

> [master 0fbb008] Accept inbox/fasten.xml as XEP-0422

Should we have a new CSS class for examples with a red background, to be certain no one will blindly copy this example?

Link Mauve, https://github.com/xsf/xeps/issues/821

c) https://github.com/xsf/xeps/pull/820/commits/8024555dd59926f092ee9ddb713e4d537888771c

jonas’, perfect.

Link Mauve, AIUI, this needs amendments to XEP-0001, so a bit of overhead there

That's adding XEP-0333 to carbonization and removing the error note.

Why remove the error note?

dwd, because errors are important to receive on multiple clients.

Also, why are we voting on this? It's Experimental.

dwd: also because it was only a note, and I don't want server authors to use that note as an excuse not to implement it

dwd: I'm not the author

Should we make Ge0rG the author?

s/the/an/?

I believe that it's impractical to implement for non-trivially-sized deployments, which is why the note is there, and this would need a namespace bump.

why did we vote on the previous PR? ;)

dwd: I wouldn't veto such a motion

jonas’, Because I didn't think of this then.

jonas’: Because it's easier than working out the process and potentially arguing.

Ge0rG, congrats, you successfully social engineered council and the editor ;) ✏

Council voting on changes avoids needing to think about whether a PR without an author's agreement should be merged.

jonas’: only to skip asking the vanished authors

I’m not opposed to making Ge0rG an author of '280 FTR

Anyway, I'm fine with moving the note, but as Kev says, this is tricky to implement so I'm not overwhelmingly in favour of removing the note entirely.

Kev: I don't believe it's actually impractical to implement, especially not in the context of persisting message errors, which I still am waiting for feedback on

But it *does* need a namespace bump for adding 333

(Not for carbons itself, for the I Support These Rules feature)

Kev: do you honestly believe that?

Instead of a namespace bump, couldn’t we add a feature to implementations which support that?

I'm not aware of any implementation that advertises that

Ge0rG: M-Link trunk certainly does.

Bumping Carbons would be the worst atm.

Kev: I can imagine changing the text into "it contains payload elements typically used in IM (e.g. &xep0184;, &xep0085;, &xep0333;)"

Since we re-implemented carbons with those rules (without the message tracking) :)

Yes, needs a namespace bump. And if your argument is that it doesn't because nothing [released] advertises the feature, that means a namespace bump is irrelevant.

Kev: I can't imagine how anybody would assume that 0184 and 0085 are an exclusive list of all IM-related payloads.

But in that case, we can't have a feature that says exactly what rules are implemented, and we're back to "Here's the intent, interpret it in your own way".

I tend to agree with Kev

while we’re bumping, how about CC-ing all error messages instead of just removing that note? ✏

Okay, in that case I retract the PR until somebody comes up with a conclusive list of all IM-related payloads.

jonas’: I think that *would* be feasible server-side. I wonder what the effect on clients would be.

jonas’: CC-ing MUC(PM) errors will wreak havoc.

Ge0rG: Only if clients weren't prepared for it, though.

again, there is no conlcusive list of possible causes of errors.

errors can happen

What if we had <include-errors/> and then a client needs to cope with errors that it didn't trigger?

Ge0rG, if your client breaks because it receives a random type=error stanza, you need to reconsider your design decisions anyways

Error correlation is going to be easier client-side than server-side, I suspect.

jonas’: Define 'break'. Swift will tell the user that something has gone wrong.

OK - we seem to have moved into developing a new design, please take that elsewhere.

Kev, if your client interrupts the users flow for unsolicited type=error stanzas, you may also need to re-evaluate design decisions

dwd, right, ack

4) Outstanding Votes.

(jonas’: They're not unsolicited - with current routing rules, if the client (with a random resource) receives an error, it's one it triggered.)

Kev: it _might_ receive error carbons.

Link Mauve, You have two outstanding, could you vote please?

5) Next Meeting

I don’t have access to my emails (my server is down…), could you remind me which ones please? :x

Link Mauve, Advance to Draft: XEP-0300 (Use of Cryptographic Hash Functions in XMPP) - https://xmpp.org/extensions/xep-0300.html Advance to Draft: XEP-0353 (Jingle Message Initiation) - https://xmpp.org/extensions/xep-0353.html

Thanks.

Same time next week?

I’ll shortly do so from my other email account.

I will endeavour to get an Agenda sorted this time.

dwd, +1w wfm

Same.

6) AOB

I won't be here next week, FWIW.

Given we're 7 minutes over, I'm really hoping nobody has AOB.

I still have the same AOBs as the last three times.

Sorry, dwd

Ge0rG, Yeah. I know.

Kev, dwd: did you vote on https://xmpp.org/extensions/inbox/cs-2020.html yet?

I'll try to ensure that with an Agenda and a bit of planning, we allocate more time for these next week.

Oh, I thought I had but I had not. There's also others expiring today.

I don't think I have anything expiring today. I do have stuff expiring next week.

Yes, they expire next week, sorry. I'm a mess today.

Proposed XMPP Extension: XMPP Compliance Suites 2020 - https://xmpp.org/extensions/inbox/cs-2020.html Dave: [on-list] (need time to look at this) Georg: +1 (obviously) Jonas: +1 (we can discuss details in Experimental) Kev: [on-list] Link: [pending] PR #812 - XEP-0084: Bump bytes datatype from unsignedShort to unsignedInteger - https://github.com/xsf/xeps/pull/812 Dave: +1 (just rectifies an error in the XML schema) Georg: [on-list] Jonas: +1 Kev: [on-list] (default to +1, unless I think of a reason later) Link: [pending]

I'll vote +1 on cs-2020. Nothing we can't fix in Experimental, let's get the ball rolling on it.

Anyway, let's call it a day now. See most of you next week.

I’m also +1 on both.

I'm +0. I don't see anything particularly wrong with it, other than that I want to break the cycle of yearly compliance suites.

7) Ite, Meeting Est.

Kev, did you have the meeting about it yet?

No.

Ok. :(

There is a Council re-election soon, and I'm very sure it will mess up our ability to Last-Call a XEP.

And I want 2020 to be finished before 2019 ends.

I also want to make it a lot more marketing-oriented.

sonny, ↑

Link Mauve: feel free to PR'ovide better text

Ge0rG, it’s not necessarily better text, but more like make noise around it, or rename it from Compliance Suite 2020 to something like XMPP 2020 with logos and a testsuite and other not-really-realistic things for the end of 2019 yet.

Link Mauve, does that include tweeting about it every 5 minutes?

Link Mauve: all those goals are worthy.

Ge0rG, any chance you can drop a vote on #812 right now?

I’m working on a bunch of merges and yours is the last missing

daniel, I hope not.

i think the name doesn’t really matter. but making it more widely know is certainly a good thing

not just for marketing but also simply to give developers a helping hand

Yes.

but we've also done an ok job with that before

i can still be improved obviously. but it's not that we were totally terrible about that

reminder about the blog post where someone ranted about activitypub and how bad it is and said that activity pub needed something like the compliance suite that xmpp has

and that was someone from outside the xmpp community

Was it Stéphane Bortzmeyer?

Link Mauve and I talked about it today, something like turning complicance suite as an annual XMPP version release, much like the ECMAScript standard

He’s a very well-known protocols guy.

jonas’ [17:47]: > Ge0rG, any chance you can drop a vote on #812 right now? +1

don't recal. no it was an activity pub person i think

Ok.

just saying all that because sometimes with all the internal criticism we fail to see what we actually did right

Indeed. :)

for clarity I really like the work around complicance suites, just thinking about an evolution

sonny, as Ge0rG said, PR’oviding better text or doing things around it would be super cool. :)

👍

http://0x0.st/zJkT.txt