XMPP Council - 2018-12-12

yellow vest revolutionary council : 🏦 🗼

join the revolution : giletsjaunes@muc.jeproteste.info 😡 🏃‍♀️ 👩‍👩‍👧‍👦 ✊ 🧡

Aw man did they raise xsf membership tax

theheck?

> Aw man did they raise xsf membership tax 🤣

Also, that avatar had a green shirt.

Is it that time of the week again?

it is!

well, in 8 minutes

And this time I’m here! Sorry again for last week.

Link Mauve: you better have some beverages with you this time

I have tea besides me, like always.

that’s too british for you

I think?

Spent too long on that island?

I had rooibos in my thermos last Saturday. ^^

In addition to a bottle of water, pretty much mandatory.

I bet that thermos is classified as weaponry.

because hard and such

Damn, if I can’t import British customs anymore… Down with the Queen^Wpresident!

you May have some problems.

oh my god.

'tis time.

'tis time.

And we seem at first glance to not have a chair.

Does the XSF have a furniture budget?

Afternoon.

woo

Sorry, just dashed back from an external meeting across the city.

Kev: your magic worked!

So:

1) Roll Call:

✏

XEP-0245

I is still here, naturally.

Full House!

2) Items for a vote:

(not sure if dwd is waiting for suggestions or searching in his documents)

(we did have a ProtoXEP submission at least)

a) Proposed XMPP Extension: Simple Buttons Inbox

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

(Searching and fighting with a MacBook. Awful things)

soo... I’m not happy with the things quality editor wise

Tempting to veto this until the examples are funnier.

jonas’, How so?

e.g. the "OPTIONAL." thing which is left over below the Glossary heading

section 9 is questionable too

and such

but I’m not here with my editor’s hat

Do we have other comparable XEPs in place?

Ge0rG, in terms of functionality or in terms of editorial quality?

We have accepted very raw XEPs in the past, if that's the question.

in terms of functionality.

We've had a number of early Experimental XEPs in similar condition over the years, I think.

Often mine. Although I'm not sure I've gone quite this far.

Ge0rG, we do have 0050, it’s mentioned already.

Ge0rG, not that I know. the closest is data forms and ad-hoc, but they don’t do quite the same thing.

I wonder if embedding a data form into a message would make sense instead.

They do so dangerously close to the same thing that a new mechanism seems wrong to me.

There's precedent for dataforms in messages in eg 0045

Kev, which?

(xep4 in messages)

indeed, kind of

I did a draft of that but it was ugly and horrifying and let's not go that way

Do we have buttons in dataforms?

I kind of fear data-forms indeed.

I appreciate forms don't quite do buttons yet, but extending them for that and i18n seems more appropriate at first glance than a new mechanism that we'll later need to extend for other form things.

dwd, no, but they could be handled with a list-single

dwd: not really

dwd, we have list-single, which is close enough.

aren't actions akin to buttons?

It already is represented by buttons in some clients when there are few choices.

Ge0rG: those are fixed at next/prev/cancel/complete

Well, maybe - but with ad-hoc we did actions, as Ge0rG implies, not in dataforms.

Ge0rG, they’re a Ad-Hoc thing, not a Data Forms thing

dataforms in message: https://xmpp.org/extensions/xep-0045.html#example-79

vanilla Ad-Hoc does not allow passing the context of the conversation in which this is happening

which this ProtoXEP does

and which any solution which wants to have this needs to

jonas’: I don't see context in this protoXEP

Ge0rG, @from

you can distinguish whether a reply from a user comes via a MUC or not

Ge0rG, There's context of conversation, not of message.

although that would probably work via MUC IQs, but maybe let’s not go there either

having context of the message is also a possibility with the protoxep by making the values unique

Combine with <thread> or whatever?

(e.g. append the @id of the message)

So two questions:

If two people send a <button/> in two following messages with the same @value, you have no way of knowing which one was referenced.

i) Do we think that having buttons in chat messages is OK?

Link Mauve, that’s true for a MUC.

ii) Is this method so broken we should abandon it?

i) yes, I do think that.

+1 to (i), not sure about (ii)

I do think that we should have that in fact, because there are many good and reasonable use-cases for this. Memberbot being one of them.

jonas’, for direct chats too, if your contact sends you the same set of buttons twice.

i) I think some use case involving something like this is valid (not quite answering the question)

Link Mauve, that’s your contact’s fault.

dwd, i) definitely.

jonas’, memberbot gets around the lack by using xmpp URIs to click on, which is pretty ikky.

dwd, I agree.

ii) It doesn't seem to be actively broken, but that's not the only reason to consider rejecting, I think.

maybe a client should only render the buttons in the last incoming message?

Ge0rG, Or grey them out when clicked.

do we wanrt to open the can of worms what the "last message" is again? :)

I'd like a generic <in-reply-to id=.../> plz

Zash, SHIM?

ii) I’ve needed way more than “just a set of buttons” a few times, for instance this very poll you’re making could do with a two questions text-single form.

I'm of the opinion that this is the Wrong Way, in the absense of further persuasion.

So, not sure it’s that broken, but it looks very much not usable for more than a very narrow set of usecases.

I just can't quite decide whether I should veto or not.

OK, so can I have some votes please:

regarding (ii): - I think those types of features are only useful for bots. - I think this proposal is something to play with. - I also definitely want more extensive features than this.

On-list.

I think I’m with Kev, but it’s tricky.

I think I'm +0 on this.

On-list as well, for similar reasons

formal question: can I say -1 now and decide to change it to +0 or +1 later on, until everyone has voted or the vote expires?

I'm concerned that people will jump on this, implement the simple stuff, and then immediately start extending with other form fields, and we'll rebuild xep4.

jonas’, We have, historically, allowed changes to votes until the last vote comes in, yes.

Kev, very valid concern. ✏

jonas’: I see nothing wrong with 'on-list, -1 if I don't do so'.

ok.

On list.

jonas’, Also, what Kev says.

on-list, -1 if I don’t do that.

(But if you do end up with -1, you're obliged to provide reasons)

jonas’, Though please do vote even if it's to confirm a veto, since otherwise you're delaying the end of the vote.

ok

also, good point Kev.

so changing to pure on-list now, because I can’t give a clear reason for -1 on the spot

You don't have to on the spot, on standards@ is appropriate.

Kev, if I say "-1 if I don’t go on-list", I kinda have to though :)

would this protoxep be sufficient for the "interact with a bot" use case?

Out of curiosity, of those on-list, are any of you potentially going to vote +1, or is this a choice between -1 and ±0?

Ge0rG, not for the use-cases I have in mind.

This is a choice between -1 and -0.

dwd, there is a slim chance of +1

there is a moderate chance of +1

I ask because unless we can find three +1's, there's very little point in continuing.

my issue with data forms is still that they don’t have a i18n story, and while others seem to think that you can always discover the right language, I don’t think that’s true.

I like the simplicity of the proposal, and it might be a good self-contained things not bothered by dataforms

so on this ground alone, I thnik that this proposal has a material advantage over plain data forms.

jonas’, I'm afraid that i18n in more a theory than a practise anyway.

dwd, I know of implementations which send i18n’d error messages, and implementations which can deal with that to some extent.

jonas’: I think we're faced with two options - one is to 'fix' xep4 in whatever way, the other is to invent an entirely new xep4. Given xep4's ubiquity, I'm far more inclined to fix that (until it's shown it can't be fixed).

Kev, I agree.

although I think that XEP-0004 in itself does too many things already.

(I don’t like the mix of forms and reports under the same element, it makes implementations weird and validation more complex than necessary.)

Kev, The other alternative is a sort of mutation of XEP-0050 for chat.

dwd: Essentially extending xep4, I think, so I'd put that under the same heading.

'submit' type form field?

Like <input type=submit> in html?

just a list-single with a specific var would do, no?

Anyway, you're all on-list, so let's move on.

Although what to, I'm not so sure - do we have anything else to vote on?

https://xmpp.org/extensions/inbox/cs-2019.html ?

did previous council close the votes on #716, #715? sorry, I don’t have that in my mental cache at the moment and they’re still open on github

oh, yeah, and that

Yes, just getting to that.

(for future reference: https://github.com/xsf/xeps/pull/716 https://github.com/xsf/xeps/pull/715 )

b) Proposed XMPP Extension: XMPP Compliance Suites 2019

https://xmpp.org/extensions/inbox/cs-2019.html

+1, but I’d like a discussion on why the CS are on the Standards Track and not Informational. It doesn’t make sense to me, semantically, except that XEP-0001 specifically lists CS to be on Standards Track.

+1, even though there are a few new XEPs missing from it which would be useful in 2019, but that can be fixed.

I'm +1 on this.

+1 for moving to experimental

I only caught this just before Council, so I need to on-list.

Sorry.

jonas’: what's the delta to CS'18?

jonas’, Adding a delta to the document would be handy, actually.

(I think it would make sense to mention new / removed XEPs in the Revision History)

Ge0rG, that would make sense if it was the same document

It would anyway, I think.

one sec for the "diff"

Not here necessarily, in the XEP itself.

jonas’: IMHO, it would make sense to keep the whole history of CS in the newest one.

As per my email from last meeting, I’d like to make a lot more noise about compliance suites, calling it XMPP 2019 and doing a lot of marketing around this, pointing fingers to Pidgin and other abandonned clients.

Ge0rG, that’s awful

Link Mauve, maybe sync up with Tedd Sterr on this

yaxim is abandoned by that definition 😢

Ge0rG, ok, the diff is unreadable even for me, so I’d like to do that in a quiet minute

Link Mauve, It's something to be pushed up to the Board,m actually.

Ge0rG, the goal is to stop with the complaint that XMPP is bad because Pidgin is bad.

dwd, indeed.

jonas’: at the minimum I'd like to see what changed since the last CS in the revision history

Ge0rG, can do, but not right now

Link Mauve: I know, but as long as Pidgin is advertised by the XSF, this is moot (https://xmpp.org/software/clients.html) ✏

Is "XMPP is bad because Pidgin is bad" solvable by redefining "XMPP"? I suspect we need to crowd-fund maintanence and development of Pidgin to fix that. :| ✏

bump the stream header version

Ge0rG, no, we can change things even if we don’t fix all of them at once.

XMPP2 for president!

Ge0rG, so you’re -1 until the revision history is fixed?

jonas’: YES! Kill the jabber:client & jabber:server namespaces and unify! :D

oh no, you gave your +1 already :)

jonas’: I'm +1

Zash, sounds like a plan!

And the announce effect is already something to aim for, for “compliance suites” or whichever new name we’d find.

(I like Rust’s “editions”.)

dwd, I think everyone gave a vote or on-list’d?

Link Mauve: we can only change things if all of us are heading in the same direction.

I would very much like to see a logical diff from the previous suite, but that won't be influencing my vote (on-list).

Folks, what the Board chooses to do with the website and the compliance suites once we finish them is out of scope for this meeting.

(FWIW, I’d also like input from the xmpp-based social network crowd; they could probably use their own section in the CS)

regarding contents, I think that 0184 belongs to IM Core

I’d like cs-2019 not to supersede cs-2018 until it is set active, but other than that +1.

Link Mauve, I think that's automatically the case.

Ge0rG, can you put this on-list or somewhere less ephemeral than this room, please?

dwd, it currently is set to supersede it, even though it’ll be experimental for a while.

But that’s editor’s domain.

Link Mauve, Yes, but it's an intent until it's Active, I believe.

it will never be Active

because it’s Standards Track

it can only become Draft and Final (on the positive side of things) ✏

ANything else?

(To vote on?)

the PRs I mentioned above

jonas’, I'll check the status of those PRs later. I cannot recall their status either.

ok

fine with me

3) AOB

just a quick note that we have had a XEP-0001 modification

IIRC we voted on both PRs.

jonas’, the last council said they didn’t have any pending vote.

we can now move Proposed back to Experimental

and also that we have a bunch of stuff stuck in Last Call

so that would be something to look on for the next meeting

I thought everything got voted on last Council.

KevI think so too.

ok, then it’s probably my (editor’s) own oversight

At least, everything I knew needed to be.

For reference, those are the open LCs: XEP-0357 (Push Notifications), LC ends: 2018-11-03; https://xmpp.org/extensions/xep-0357.html XEP-0359 (Unique and Stable Stanza IDs), LC ends: 2018-11-03; https://xmpp.org/extensions/xep-0359.html XEP-0280 (Message Carbons), LC ends: 2018-02-22; https://xmpp.org/extensions/xep-0280.html XEP-0363 (HTTP File Upload), LC ends: 2018-06-18; https://xmpp.org/extensions/xep-0363.html

since they’re open, I’ll re-start them due to council switch as editor soon-ish

just so that you get an idea already.

At least 357 and 359 aren't open, we definitely finished those last Council.

(after double-checking that they havent been voted on already)

jonas’, I believe that XEP-0363 is awaiting edits due to feedback, but I might be wrong.

I'm pretty sure we also -1ed Carbons because of XMPP-NG

hm

ok, I’ll shut up now and do my due diligence as editor. sorry for the noise. :)

Any Other AOB?

not from me

4) Next Meeting

+1w WFM

Same XMPP Time, Same XMPP Channel?

WFM.

That's 2018-12-19 16:00 UTC.

I will try to be here. I'll be in another meeting at the same time.

So preemptive tentative apologies.

I'll be (finally!) back at home.

Kev, would another time suit you better?

Not a lot.

I'll be on a train most probably.

It's only next week and last week it's an issue.

Unless, due to strike, I'll be on a car. Which will make typing much more challenging.

I can do any day of the week except friday and weekend next week at that time, FWIW

Let's stick with the same time and hope Kev/Georg can make it. We hit Christmas after that anyway.

Yup, at which point we can do the meeting at 35c3. :D

(not for me)

5) Ite, Meeting Est.

Thanks all.

Thanks all.

thanks all

Thanks!

Thanks. :)

Oh, I'd also like to advance XEP-0410.

Ge0rG, shouldn’t you do that on standards@?

probably yes

you wanna have a Call For Experience issued?

I think I do. We have working implementations in poezio and in yaxim, and the server optimization in ejabberd and prosody