XMPP Council - 2020-10-28

1) Roll Call

Here

here

dwd sent apologies

do we get a daniel?

If I dissapear then my laptop probably died.

Yes I'm here

neat

2) Agenda Bashing

anything?

I haven't managed to do any of the nice tasks I planned, like segmenting 0401

assuming no

3) Editor’s Update - Welcomed Martin Dosch as editor

4) Items for voting None.

5) Pending Votes

Ge0rG, do you want to vote on MR!25, the User tune thing today?

(you have time until next week I think)

jonas’: I haven't managed to catch up on that, sorry.

also, pretty please vote, otherwise I’ll have to look up exactly how our bylaws regulate this awful edge case :P

with either +1 or -1, don’t vote 0, that’s not helpful ;-)

🤔

but ok, moving on then

6) Date of Next

+1w wfm, without caveats (that I know of) from my side for a change

Yes that should work for me as well

+1w wfm

good enough, I suppose

7) AOB

7a) Election Season

yay!

I note that out of current council, only daniel and me have put up an application so far.

Out of curiosity, where do the other members stand? do you intend to reapply and haven’t gotten around yet? still contemplating? hard no?

Does anyone want me to continue?

Mostly just busy with other stuff or too exhausted to do anything.

Zash, I think you do regularly add valuable bits to the discussions.

also, with the current lineup, we have 0 server developers.

but if you don’t feel comfortable with doing it, I wouldn’t want to pressure you into anything.

I'd appreciate a reminder (when I'm at home with access to all my credentials)

I’ll try to arrange for that.

Ge0rG, any word on that matter?

jonas’: I'd like to continue, even though I have had less time this year than last one.

okay, I see, thank you

I suppose I need to fill out my application before it's too late

I’d also say that you add value to the discussions.

yes, you do :)

The thing eating all my time should end Soon:tm: too, hope to have more time then.

but maybe a last-second application will encourage newcomers to candidate

(like, early next year)

Zash, I wish you all the best for that

any other AOB?

I got nothing.

I'd like to add a <delay> element into the non-normative example of MUC subject delivery

Ge0rG, there is no delay element? :-O

jonas’: no

it's probably straight-forward, but one could argue that it belongs into 0203 instead

MUC never ceases to amaze me

And servers don't usually add that

Ge0rG, seen anything in the wild doing this? I think I have

Last I checked

daniel, they don’t? ✏

jonas’: I was as shocked as you when I realized it isn't there

Ge0rG, it most certainly belongs in '45

...when I wanted to tell the Bifröst devs that it's a good practice.

No. I once wanted to place the subject where it belongs in history

And that didn't work

daniel: prosody will send a delay

Does it?

Mhhh maybe that's a recent thing?

daniel, placing the subject in the place where it belongs in the history doesn’t really work in all cases (only approximating it if the subject is older than the oldest bit of history retrieved via classic history)

I last checked a few years ago

Should subject go in MAM?

jonas’: yes. But having a delay tag would at least allow you do try this with some considerations

Zash: subject changes should. The interesting question is whether they should expire together with regular messages

speaking of MAM, it recommends to store 'groupchat' messages into user archives.

Don't we need this for mix anyway?

It should probably handwave something about support for it.

daniel: no, and I'm not going to stop my opposition to that until somebody works out how to resync after any kind of s2s outage

Heck you could save everything, PEP notifications even.

leave pep. out of my MAM!

:(

so I’d be strongly in favour of specifying that a delay element SHOULD be included

> so I’d be strongly in favour of specifying that a delay element SHOULD be included +1

I’d be ok with doing that outside of the example even.

jonas’: that's a normative change!

> I’d be ok with doing that outside of the example even. +1

clients will see whether the <delay/> is there or not

Ge0rG, let me finish :)

and clients which don’t expect <delay/> are doomed anyway, because it can be added by anyone

+1 to this whole notion

jonas’: somebody is going to demand a feature var for that.

and if we then also add a note that you cannot rely on <delay/> being there because it didn’t exist in MUC < version X.YZ, it’s ok.

also +1 in case we are Formally Voting

Ge0rG, then we add one and make them happy

we’re not formally voting, we have nothing to vote on ;)

someone should prepare a text, which I may do after this meeting

yeah right.

jonas’: that'd be splendid, as I lacked the time to do it since I discovered this strange omission

will do, I have the file open already

any other AOB?

None here

None

alright

8) Ite Meeting Est

thanks everyone

Thanks jonas’

thanks jonas’, thanks theTedd

Thanks jonas’

Thanks Tedd!

FTR: https://gitlab.com/xsf/xeps/-/merge_requests/29 https://xsf.gitlab.io/-/xeps/-/jobs/817295433/artifacts/rendered-changes/xep-0045.html#enter-subject

ah, right. subject @from is the user, delay @from is the MUC because manipulation

yes

jonas’: 👍

While we are at it, we should change XEP-0118 to use the new integer-or-max field type for the `rating` element.

Shouldn't rating be in the 0..1 range?

maybe, but then we'd need a float-or-max type

why max?

because your favorite song should have the max rating

[💩️..❤️]