XMPP Council - 2019-09-04

It is not a Dutch expression either, but we've been quite present on the edges of the anglosphere.

So it's similar to the jokes that were made around XEP-0420

It's time, isn't it?

Yes, indeed.

1) Roll Call

It is, but I've not noticed an agenda.

Yes, sorry - I'm on the road so I've struggled with that this week.

jonas’ ?

jonas’ was here just two minutes ago

the jabberfr linkmauve dropped out just five minus before the meeting.

I’m here

OK.

we have a ProtoXEP

2) Agenda Bashing

I find no fault in the published agenda.

So we have CS-2020 as a ProtoXEP. I don't know of any other requests for the agenda.

there’s one [needs council] we haven’t voted on I think

this one: https://github.com/xsf/xeps/pull/812

Ah, yes.

OK:

3) Items for a Vote:

a) Adopt https://xmpp.org/extensions/inbox/cs-2020.html (XMPP Compliance Suites 2020)

+1 obviously. Also I'd like to AOB that a bit

On-list.

+1, I think we can discuss all content details in Experimental stage for this one.

I'm afraid I need some time to look at this, so on-list.

(I can't imagine why I'd do anything but +1)

AOB noted.

b) https://github.com/xsf/xeps/pull/812 (Bump bytes datatype from unsignedShort to unsignedInteger)

on-list

I'm +1 on this. It's just rectifying an error in the XML schema.

Note that vanitasvitae posted about this on the list as well.

Default to +1 unless I think of a reason it's daft later.

yeah, +1

OK.

I poked lm

(via sms)

4) Outstanding Votes

But apparently it's over already.

not quite yet

IIRC, Ge0rG has some outstanding, as does Link. I think the rest of us have voted lodged.

I mailed in my votes yesternight

Ge0rG, Oh, sorry.

At least I think now that I'm synced.

In that case, I think XEP-0353's vote is done, so we're just pending on XEP-0300.

I change my vote on XEP-0353 advancement to -1

I think the Last Call has provided valuable feedback and that needs to be considered before moving to Draft.

jonas’, Noted, thanks.

5) Next Meeting

+1W?

wfm

6) AOB

+1W WFM

Ge0rG, hit it.

I have two AOBs regarding CS-2020, one regarding Message Errors and one regarding Attach-To-Reactions.

OK.

I'll start with CS-2020a: introductory text. The text in XEP-0412 is awful at informing developers that this is *THE* XEP to use as a guidance on what to implement first

I'd like to change the intro in CS-2020 and to make "compliance" a remote second in it.

+1

(https://github.com/siacs/Conversations/issues/3530 as an exemple of how it's not being advertized correctly)

Isn't this a third AOB item? But anyway, I'm fine with whatever you like.

dwd, I was confused for a second, too, but I think there are four AOBs in total, two for CS, one for Message Errors and one for Attach-to-Message

what jonas’ said

Ah. Ge0rG, master of the AOB.

We still have 8mins left

No wait, my clock is off.

But yes, I'm absolutely fine with some different introductory text.

Great.

AOB CS-2020b: https://xmpp.org/extensions/inbox/cs-2020.html#future - I've added that section because we need something like it, but the content I've put there is very very rough.

Please throw XEP numbers at me

Ideally, that text would have broad agreement from the community, mind.

dwd: I'm sure we can gain that via a Last Call.

In an ideal world the community would agree with us.

Ge0rG, XEP-0500

Ge0rG, But what if Royal Assent is withheld?

Equally, technical direction is one of the few things Council has purview over.

Sorry, wrong politics.

So by our process the most important thing is that Council agrees to a statement of technical direction.

Kev, That's true enough. Also, "Ideally".

Ge0rG, WRT "Future Development", I suspect that could cause a lot of discussion, and potentially few conclusions.

dwd, Ge0rG, I tend to agree

I think "future development" is more like a wiki page

dwd: Maybe that. Or it will get ignored, like most other topics.

Ge0rG, I mean, your call. But I think it might be the cause of much stress for little benefit.

I think a little tweaking would make it fine.

I'm not going to die on that hill. If there are issues, I can axe that section

If it simply said "These are the areas that Council believe ..."

Then if we agree between ourselves, it's non-contentious.

Or if it suggested these were areas under development rather than a forecast of the future.

I very very much think we should have that section, because we need to stop using the compliance suites as a form of wishful thinking, which we often seem to.

Kev, Yes, I can accept that.

mmm

I tend to agree with the sentiment, Kev, but I don’t think the CS are the right place for that. Maybe they are, though, because it makes it very clear immediately what they are for (by having a dedicated Future section)

Kev: so you say we need to move the wishful thoughts into that section?

so, no strong opinion either way from my side

Ge0rG: Yeah.

Ge0rG, If you're up for the pain, keep the section and we'll see what we can do with it. But I won't blame you if you find it more painful than you can be bothered with.

The world that we wish it to be, rather than what it currently is, can sit in that section.

I think there is value in having a section that contains XEPs that a (client) implementor should closely watch, or even implement under the premise that they will change.

Ge0rG, +1 to that sentiment, too

Ge0rG, There's both aspirational stuff and development stuff that could be there.

+1 to the sentiment

But you're running out of time for Errors and Reactions.

dwd: so we need sub-sections

Ge0rG: Or maybe a summary of why it's there.

Yes.

Anything along those lines would work for me.

Well, well.

The other AOBs won't fit into the remaining 3 minutes.

They rather deserve a Council Meeting of their own. Each of them.

Please comment on the "Persisting Message Errors (XEP-0280, XEP-0313, XEP-0160)" thread on standards@!

We need to rethink archives so drastically it's painful.

What about starting to rethink message delivery, and then fixing archives on the way?

That works.

Oh wait, we started that two years ago.

Well, errors I basically agree with. I should say so on the mailing list.

If I haven't.

dwd: you haven't

Reactions-and-attaching-and-stuff, I'm a little concerned that unless someone comes up with a proposal there, we risk rejecting every XEP in the space out of hand, which seems less than useful.

Assuming that was the other AOB.

dwd: it was indeed.

yeah

Ralph and I were working on stuff that I hope leads to a proposal.

dwd: we had a very productive discussion the other day on xsf@, and I've tried to summarize it in a gist.

I tried to get hold of the authors of Reactions and didn’t get a reply

I should just dump it onto standards, I suppose.

jonas’, I believe that one of them joined the XSF, which is positive.

Ge0rG was in the discussion too, actually. I wrote up some gists, Ralph is writing those up in a more consumable form.

Ge0rG, Please.

Three kinds of "References" in XMPP: * Thread (in-reply-to); largely off-scope for our discussion * References of things mentioned in the payload/body of a message (0372) - nicknames, URLs, old messages by means of xmpp: URI, etc. - multiple Reference elements are allowed - Can be used inside Attach-To to add References to a previous message - Can be sent by anyone - is irrelevant to MAM 2.0 * Attach-To for content that only makes sense in the context of another message - Usable for Reactions, Edits (former LMC), Retraction, Image / website previews, Receipts(?), Read Markers(?) - A message can be attached at-most to one other message (nobody could think of a case where it would be needed, Ge0rG still objects) - allows grouping / special handling by MAM 2.0, e.g. for thin clients - generally, the attached payload SHOULD be inside of the <attach-to> element (e.g. reactions) - for E2EE and legacy Last Message Correction, an <attach-to> without a payload implies that the sibling elements need to be reviewed - Some kinds of Attach-To can only be sent by the original author or a privileged entity (bot/admin in MUCs) - Attach-To messages SHOULD NOT be nested, i.e. attach-to another Attach-To message

Kev: what form is ralphm writing them in?

He's got a draft blog post about it.

Kev, can’t you make that proposal right away and get early feedback from the community?

ah; I’d prefer a ProtoXEP tbh

I am somewhat concerned with rejecting a XEP for not using another XEP that doesn't exist.

I think a description of the concept is more useful than a protoXEP at this point.

dwd, yes

Kev, a ProtoXEP could be a description of the concept

it doesn’t have to be standards track, mind

(even though I’d prefer that)

It seems that it is not the fault of the authors, and nothing they can possibly do can remedy it.

Ok. I got ahead of my schedule today.

So I can write something tomorrow, interruptions allowing.

dwd, well, they *could* come up with a solution ;)

but meh

dwd: Other than have said "Yes Kev, go ahead and make your suggestion"

Kev, I’m saying that because I know what happens to draft blog posts

I mean, I did offer to 'fix' it.

Kev: it seems that you were the only one who interpreted your response as an actual offer to 'fix' it ;)

Am I updating Sam's spec, or writing a new mostly duplicate one for attaching, or rolling it into References?

Ge0rG, no, I also interpreted it that way actually

Kev, we need to do a breaking change to the protocol in any case

so I’d say go with a separate document for now, see what happens. It also prevents issues with getting Sam on board.

Yes, but I would like Council to give me guidance here because I don't want a fight about having done the wrong thing.

I disagree with jonas’ here. Don't make a copy of Attach-To

I can still git mv inbox/kevs-thing.xml xep-0367.xml

I don’t have a strong opinion towards a separate document.

Can somebody summon Sam?

hardly

but MattJ is a co-author

Would I be right in assuming there is no desire to have all this described in a single document (references)?

Kev: right.

Kev, references needs fixing first

Kev, I honestly don't care.

I made proposals on-list about that a year ago or so

Kev: from our last discussion, we figured out three use cases. They should have three documents

jonas’: There's two halves - one is references, the other is attaching.

The other half is MAM, of course.

(Or three halves, if you include threads, which I think we decided to punt for now)

We're 10 minutes over, so unless anyone's got anything else pressing, I'm going to call it a day.

I would like a concrete agreement on my approach.

Update References for the one half, new protoXEP for the other (which can later overwrite attachment if people agree)?

TBH, with the ideas around redoing attach-to and to put the payload inside of the attach-to element, maybe forking it into a new document is the better way forward

Kev, ok, I don’t have a strong opinion on whether you do a new document for attaching or not, but I strongly don’t think that References is the right place for this. ✏

Just give me a +1 on my approach, please people, and we can go home :)

Kev, pragmatically, I’d say prepare an update to Message Attaching

if we find it should be a separate XEP, that’s a trivial thing to do

I would rather not deal with the admin of removing an author if Sam doesn't believe it should be used for this, but if that's the will of Council I'll go that way.

Just between the three of you agree something, please.

Kev, in that case we can still fork into a new XEP.

My preference is fork for now, as I said.

But I will do either.

do whatever you like (except merging into References) from my side

the rest is just editor dutywork which I’m happy to do

Kev, Least contentious is write a new XEP.

my main point is, get a proposal out there

Kev, Since it's much easier to merge into an existing one later if we choose that.

And Ge0rG already said fork, so I think that's agreement. Thanks.

Message Attaching 2

I will see what I can get done tomorrow.

I don't like forking.

"... (This time it’s going to stick around)"

Ge0rG, please.

jonas’, He's suggesting a new XEP, not a fork. That's fine.

XEP numbers are cheap, right?

Aaah, sorry! I was moving to the Berlin XMPP Meetup just during council meeting! >_<

they are

linkmauve, Well, I think I'm finally going to close this meeting, so perfect timing...

Thanks all.

X_1) Ite, Meeting Est

thanks dwd for chairing, thanks Kev for taking a stab on the attaching thing, thanks everyone for everything

thanks jonas’ for the encouraging words

https://github.com/Kev/xeps/blob/fasten/inbox/fasten.xml That's ludicrously simple, but I think it works as a first indication of how the marking that a payload applies to an earlier message would look.

There are several details of the (primarily) ralphm / Ge0rG / Kev discussion that still need reflecting there, and References also needs work, I realise.

Kev, FYI https://mail.jabber.org/pipermail/standards/2018-March/034559.html

let’s move this to xsf@?

Ge0rG: [moved over to xsf@] ✏

jonas’: Thanks. I'll try to incorporate that when I get to references.