XMPP Council - 2019-12-11

I’ll probably be able to attend via mobile since the party only starts at 16:30Z, not at 15:30Z as I originally thought

(but don’t want to chair using mobile to spare you all some time)

hi

Time?

16:01

Afternoon

1) Roll Call

Night (from the looks of it)

Good morning everyone!

I think jonas’ pinged that he wanted me here, but I'm only semi paying attention (while looking at Fastening etc.).

.

here but mobile

daniel, ?

i'm here

OK.

2) Agenda Bashing

Anyone got anything not in the agenda?

If not...

Fastening in MAM, depending on other discussions.

3) Items for Voting

£a) Resurrection of Reactions

Oh, capital number, there.

I am attempting to zombify it At This Moment.

Or the Fastening element, at least.

Thanks.

I'm hoping to at least have replied to and triaged feedback by the end of the afternoon.

I remain convinced that Reactions are better done in the scope of something like Fastening, FWIW.

If the auhors of Reactions and Fastening can try to work this out then I'm not blocking.

We did a similar thing with the Message Forwarding container XEP after publication of Carbons IIRC, so I don't see why you can't do something similar here during expermiental.

I would personally be happy to accept Reactions as-is if we could gain agreement that we'd solve the fastening issues as a priority. My concern is that with other Experimental XEPs of the same nature, such agreements have been ignored and the original authors have simply dug into their position having obtained any kind of concession.

Zash: and even years later, clients had the <forwarded> <message> hierarchy wrong.

Not having a XEP number isn't stopping anyone from implementing.

Zash, True, but it does prevent people working on it within XSF IPR policies.

Do we have the Reactions authors present?

> Zash, True, but it does prevent people working on it within XSF IPR policies why is it a worthy goal to prevent that?

I think there's a whole load of prior art to show that accepting something for expediency and expecting it to change significantly doesn't lead to it changing, and we end up in a Bad Place. Just looking at Fastening, I had every intention to immediately address feedback, and it's still taken me months because I was on holiday and missed the feedback.

daniel, It isn't.

That's the main drawback, I think.

assuming that reactions in it's current form will see adoption (not by me or Conversations fwiw) isn’t it better to have the ipr with the xsf?

and/or a referable number

daniel: I think the answer to that is a definite 'maybe'.

daniel, Yes. The probl;em is that previous cases have seen authors essentially entrench their positions after being accepted.

It /not/ having a number is a clear message that it's not yet endorsed. Despite the banners on Experimental XEPs, it's clear that as soon as it's got a number a good proportion of people believe it's been endorsed.

doesn’t the endorsing step come with 'draft'?

Should, yes.

Does, not really.

i'd be totally with you if that argument were raised on moving to draft

Our protocol evolution step names are also broken, yes.

Ge0rG, can we unbreak them?

Sadly, the argument then becomes "It's Experimental, it's widely deployed because everyone ignored that it was Experimental, it should be made Draft despite it being clearly unsuitable" as does happen.

(And if Mr. Chair would like me to go back to the peanut gallery at some point, I shall do so)

by making experimental 'everything goes' and instead move things to draft that belong to draft

daniel: only by pouring massive amounts of time into it

I'm actually coming around to (flo?'s) suggestion of a pre-experimental stage, where it doesn't get a number, or anything like that, but at least goes under IPR.

Which I hate in almost every way, other than that it might actually work.

Kev, that should be experimental

that is what experimental is for

daniel: Would that we lived in a world where 'should' counted for anything :)

daniel: Carbons are essentially expired, and still so widely used that we don't dare breaking them.

i mean we can introduce the ietf draft thing…

but then a lot of the other stages don’t make sense

OK, I think we're not making progress.

My view remains (although a minority) that we should work as much as we can to get Reactions to the stage that it's 'ready' and avoid the issue. I realise the blame for stalling Fastening lies with me.

Kev: More like the IETF model?

Zash: No number until ready? Yes, essentially.

Depending which model you mean :)

I see Kev pouring out email to the list, so unless that results in no further movement I'm going to honour the previous Council's decision (and I really hope we can get this all sorted).

dwd: Chair on.

I suggest Council apply pressure to me if I miss something again.

I care about this a lot.

We should be discussing the best way to do Fastening instead of meta-discussing process? ;)

Kev, Thanks.

4) Outstanding Votes

... are all about Reactions/Fastening.

5) Date of Next

Same time next week work for us all?

I missed last, and I'll on-list everything Fastening/Reactions'y to the latest date possible

> We should be discussing the best way to do Fastening instead of meta-discussing process? 😉 at some point we need to have that meta discussion

There is nothing on my calendar in +1W

maybe not now

+1w works for me

6) AOB

daniel: that meta-discussion has been happening in this MUC since Reactions was first proposed

(I agree with daniel that a metadiscussion being scheduled at some point is sane, even if I don't have a horse in that race now)

Can I have a quick AOB on Fastening/MAM, please?

I would note - and here seems as good a time as any - that a discussion on process is a thing that ought to happen on the list, and it's a Board thing to approve anyway.

Damn, AFK 60 seconds.

And since Kev wants to talk about Fastening/MAM...

Sorry, bad point for a doorbell.

So, two things about Fastening/MAM.

The other thing to consider would be some form of Inbox. ESL's is a reasonable model to start, and will similarly need to understand concepts of fastening and other ancillary messages.

1) I agree that we need that story told. There's been some suggestion that Fastening isn't usable until MAM3 has also been specified. I'm wondering how strongly people hold that view, if at all.

it might be Board's to approve but current and past councils certainly have a lot of valuable insights here

Kev, i need to be convinced that fastening will actually work with MAM and that we don’t have to rewrite it later

2) We came up with a rough story at the Summit, which is similar to Evgeny's that was recently posted. Get the messages independently or with metadata, including possibly sumarries of metadata. Are people still ok with that, or do they have more input before I try to spec something?

if that convincing happens via protocol or by other means is open

Kev, (1) I disagree with that view. I agree it urgently needs solving, but without fastening it's useless.

3) (of 2) There's also the inbox story. I'd like to punt that one for the moment, even though I want it.

Kev, (2) I'd greatly appreciate it if we threw some ever-more-concrete ideas around on the mailing list. I have a horse in this race.

Kev, (3) I also have a horse in the Inbox race, too.

I'm hoping to get Fastening 'done' and then move onto MAM2/3/4

And *hoping* that someone else then sorts Inbox using the same mechanism.

One problem with Inbox is that it needs an understanding of message receipts, so we need consensus on whether this means Message Receipts, Chat Markers, or Something New.

There are many problems to be solved with inbox. Several of them come with fastening and enhanced archiving.

Some are additional. This is why I'd like to put it off, and ideally someone else do it :)

I hope it's the solutions, not the problems, that come.

dwd: also Chat States play into that, which we wanted to move from message to presence semantics

Ge0rG, Good point.

A herd of unshaved yaks.

I'll commit to resurrecting Inbox talks.

We already rely on ESL's design.

what's ESL's design?

ESL's design?

Since we're coming up on the half hour, does anyone have anything else?

not from my side

nothing else here

Ge0rG, https://mongooseim.readthedocs.io/en/latest/modules/mod_inbox/

Ge0rG, The documentation isn't, I find, very clear - but the fundamental shape of it works.

OK, if there's nothing else, I'll close the meeting, but as usual people are welcome to continue chatting.

7) Ite, Meeting Est

Thank you all.

Thanks. And jonas's ping to join because something relevant was discussed was useful, I think.

Indeed - it was a good idea to explicitly request people join. A plan worth repeating.

(Dave says, smugly, having been a proponent for years) ✏

> at some point we need to have that meta discussion As a board member I'm happy to have that discussion (you need board anyway to change all that..)