XMPP Council - 2017-11-08

I’d like to add "Revisit BMH in the context of Styling" on the Councils agenda for today, but I don’t want to abuse my editor powers to do so, so I’ll just drop this here.

when (and by whom) was this vetod upon? I can't find the minutes for that

Link Mauve

2017-10-18

and SamWhited

but I don’t see rationales

Does that mean it was actually accepted?

No, -1 is a veto

I'm trying to figure out if a rationale is required :)

I'd be surprised if not.

It is required that anyone vetoing provides a rationale, but a rationale isn't required to veto :)

I believe.

I am confused, Kev.

I can barely parse that sentence. I blame the coffee.

Me neither. And I've got enough coffee to rule out that source of confusion.

The word "veto" isn't in XEP 1

"object" it says

Ge0rG: unfortunately in English it's caffeine

"confusion" can also result if you remove a substring of "coffee/? infusion" ✏

> If objections are raised by the Approving Body on the Standards list or in its meeting, the XEP author is encouraged to address the feedback of the Council and to submit a revised version of the proposal and/or confer with the XMPP Extensions Editor or objecting Approving Body member(s) regarding how to proceed.

s/coffeine/coffee

:)

Sigh.

caffeine?

yes please

LMC with regex fail

Coffee contains caffeine. Kaffee beinhalted Koffein (funny mirroring there)

indeed

Kev, can you clarify your statement?

Anyone vetoing a protoXEP needs to provide a rationale, but that doesn't mean that failing to do so magically accepts the XEP.

Kev, that makes more sense, thanks.

So SamWhited is currently in violation of XEP-0001...

(so is Link Mauve, I think, at least on the list record I can’t easily find a rationale)

Damn, so I've violated 0001 as well.

jonasw: <Link Mauve> I’ve already read it yesterday evening, and I’m very much -1 on it due to the concept of waiving any format support, forcing implementations to support multiple formats and making it impossible for a message to carry more than one (think MUC for example).

Ge0rG, that’s not on-list unfortunately, but good to have

jonasw: it's in the logs.

Hi, it’s time.

I'm here

Ping Tobias, SamWhited, dwd.

pong

Link Mauve, you want to run the meeting?

I can do that yeah. :)

oops, I am still confused and thought it was in an hour. I also am here though.

Pang?

go ahead :)

So 1) roll call.

Everyone’s here.

here

2) any minute taker?

I'm available

\o/

great, thanks

Tobias: grooming Link Mauve for command I see!

SamWhited, :)

3) Styling it seems.

So, we have two proposals.

Which is great!

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

And also, which is great?

And https://xmpp.org/extensions/inbox/markup.html

trello just mentions one of them

Oh?

jonasw sent the second one yesterday, maybe we forgot to add it.

This is the next meeting for both, so we should properly consider them now.

It has had a proper announce email anyway.

Link Mauve, but we probably want to vote on each individually, not?

With these proposals, I’m finally happy with deprecating XHTML-IM, it seems jonasw took into account every criticism I’ve seen on the mailing list in all threads that have been talking about it recently.

Tobias, sure, but we will vote on them next week.

ah..ok

Link Mauve, I don't follow - vote on what next week?

Don't we normally vote in the first meeting after a submission (or on list, of course)?

(IIRC we have two weeks to vote on accepting a ProtoXEP, I can start the vote right away if you prefer.)

Link Mauve, Two weeks to vote, starting at the next meeting.

This being the next meeting.

Ok.

So let’s start.

4) Vote on styling.html

+1.

+1

On list.

+1, naturally

+1

Perfect.

5) Vote on markup.html

+1

SamWhited, You say naturally but XEP authors have voted against their own XEPs in Council before, you know.

on list, haven't read that one yet

+1

dwd: I'd love to hear the story there

On list.

I'm +1 on this too. I don't think I want both, ultimately, and would prefer the other, but I'm not going to die on this hill if I can avoid it.

The other one has seen a lot of criticism, before and after the proposal (it basically ignored most of the arguments against this approach), this one has only the downside of OTR and such not playing well with it; arguably OTR already has its own styling mechanism (it carries HTML).

yeah. I think we shouldn't let restrict us by ancient OTR

Link Mauve, It is possible to take notice of arguments without agreeing with them, you know.

Alternative take: most of the critisism was addressed and the responses were ignored, but maybe this isn't the time and the place to be throwing statements like that around.

dwd, of course, but it ignored all of the arguments against Markdown not to name it.

Anyway, let’s move on.

6) 0146 obsoletion.

This has happened since last week, so I just archived the card.

Sorry for the delay on that

Link Mauve, No, I'm not comfortable moving on when you're accusing others of *ignoring* arguments raised.

Sorry, 5) again.

Link Mauve, That's a very different accusation then asserting that the author has chosen not to agree with, or address, the arguments in the spec.

dwd, Link Mauve: this is the second time something like this has been brought up recently. I certainly don't think I ignored the arguments, just disagree and addressed why I disagreed, but since obviously multiple people feel that I ignored them I can try to address it on the list again if you want.

dwd, I think if arguments are heard, they should be in a rationale in the XEP, which Styling may or may not have done.

dwd, reading both the XEP, the mailing list, and xsf@, I haven’t seen most arguments addressed.

However, it would be more helpful if I had a list of specific things that you feel were ignored and then I'd be happy to address them (either in the XEP or on list)

(I added a sectino "Design Considerations" to my XEP-0392, which I think is a good way to do that)

I think both XEPs should contain a strong rationale about why they are designed that way.

SamWhited, I can make such a list, I’ll add that to my TODO list.

There were already somewhat-summaries on the mailing list, I’ll use these.

jonasw: I think addressing every on-list discussion in a Rationale section's a jolly bad idea, FWIW.

Link Mauve, FWIW, I do not wish to set any kind of precedence that every argument raised against a XEP has to be documented in the XEP.

Yes, this would be horrendous.

Else I want every XEP to document that the protocol isn't pink enough :)

Link Mauve, And having raised this argument, but those rules you'd have to document it in every XEP.

sure, but if arguments are brought up multiple times and are well reasoned, I don’t see why not.

I’m fine if people say my arguments aren’t well reasoned, I’d like to know why though :-)

message styling actually addressed a lot of critisms. for example we agreed on leaving the keywords in. get rid of the disco feature and so on

dwd, indeed, that sounds like a bad idea, but it would be useful to have a short list of alternative approaches and why they weren’t taken.

daniel, oh? Did it change since I last read it? I remember it letting the receiving client do whatever it wanted with the rendering.

I made promises to change it, I didn't want to merge until it was accepted

Link Mauve, the ProtoXEP wasn’t updated, but people agreed to change it

Which is the right thing to do, incidentally.

(unless of course one of those changes is blocking acceptance)

Ok.

We shouldn't be mandating rendering :)

Which confirms my “on list” vote for 4). :)

FWIW, I would recommend that if one of these two XEPs are temporarily blocked, both should be :)

Because they seem to be a pair of competing proposals that should be considered together.

Sounds fair, they both are as of now.

Kev, I personally am not seeing it that way (anymore).

(Although this is counter to my desire to get stuff published ASAP so it's under XSFness, so ... yeah)

jonasw: You might be in the minority :)

I think both can serve a very useful but distinct purpose each. And I think that we need BMH back.

but I guess that discussion has to wait until next week if not everyone has caught up on the list yet

I proposed to add reconsidering BMH to the agenda for today, not sure if that was seen?

so wait just to be clear and that we don't end up dead locking here. Link Mauve you want SamWhited to make those changes before you +1?

I would be totally happy with revisiting my vote on BMH with compelling arguments, fyi.

because if SamWhited waites until this is approved this will dead lock

If already-promised changes are the only thing blocking, I think just taking it on Sam's word that he'll update would be fair. Personally.

daniel, no, I haven’t fully caught up with the mailing list, I’m only based on my first reading of his XEP.

Of course I wouldn’t block anything due to changes not having been pushed yet.

Just to be clear concerning the minutes, BMH was a previously proposed protoXEP that wasn't accepted right?

jcbrand, yes

Yes.

tx

Yes, Flow’s one, about annotating which markup the body is formatted with.

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

Can we hold off on revisiting that one until next week since it just got brought up?

I haven't had a chance to think about how that would interact with either of the new proposals

sounds sensible

(I think, having been rejected, that it would need resubmitting for IPR purposes).

Of course, your ProtoXEP changes how it could interact with the ecosystem.

(That’s a detail, I’m sure Flow would be happy to do so. :))

SamWhited, to be clear, I’d argue that Styling should get a BMH hint-namespace-thing

fwiw i don't think we need bmh for the opt-in approach to message styling that jonasw proposed

I haven’t read that part yet, so I’ll abstain for now.

I agree with daniel, but I see merit in the general idea of BMH, following the argument Flow gave when proposing it

but moving this to next week until everybody has had time to consider all the XEPs seems very reasonable to me (not that I’d have any say in that)

I think what we actually need is an opt-out, but I need to have time to reply sensibly, and this is team appraisals week.

I think I agree with what Kev said, but I'm not 100% sure yet about the idea of hints in the styling xep.

yeah maybe opt-out is more sensible

I think what you want is <this-was-pasted/> for lots of thinsg.

i can live with both though

And that applies both to styling and to emoticons.

Kev, Auto-```?

Kev, oh yes, sounds great.

I still think we shouldn’t impose this on clients which don’t want that.

jonasw, That would be *terrible*.

Is this something people feel they need to make decisions on voting right now? If not, can we discuss specific details after the meeting? I want to make sure we get to everything before I need to leave for standup

It still breaks existing simple clients, such as bots.

Usually when people disagree with me it's because they're clearly idiots, but I think in this discussion there are reasonable arguments on multiple sides.

Kev: I disagree.

(sorry, couldn't resist)

SamWhited, we can discuss on list/in xsf@.

SamWhited: That would be one of the other cases.

:p

So, 7) AOB?

Link Mauve, You don't want to obsolete '146 anymore?

dwd, it’s obsolete already.

6) was super quick. :)

Oh, misread.

No AOB from me then.

next meeting?

8) Date of next.

+1W?

WFM

wfm

WFM2. How many more meetings do we have? Two?

Two yes.

Thanks everyone!

Btw, thanks dwd for sending chat states, it really helps to know who is going to speak next.

I wish every other council member would do the same.

thanks Link Mauve for running the meeting, thanks jcbrand for the minutes

Link Mauve, my client doesn't support that

Whew, we survived the styling meeting :) thanks all!

SamWhited: Are you *sure*?

Link Mauve, Well, here's the thing. Gajim sends them, but doesn't render them.

Tobias, I know, you should push for that then, it’s extremely useful during a meeting.

so far, I'm still waiting for the xmpp fork of 2017 due to styling

Link Mauve: No-one's going to push back on it.

Mcabber doesn't support anything… but it does do Vim style keybindings, which is really all I want in a client.

moparisthebest, You'll *never* be able to read messages again.

I've been saying I'd like this for ages, we've just not done it yet.

dwd, ah yeah, I provided the patch to send them, I don’t know if any other contributor wants to display them yet.

Kev, maybe I could contribute that then. :)

Kev, Our new client does, but I'm not using it yet (it's a little simplistic). Probably good enough for MUC meetings, though.

As of today I’m now unemployed, I should have more time to fix the world!

Link Mauve: If you want to send in a patch for send/render CSI in MUCs, it would be gratefully received (subject to normal patch things).

(Of course.)

Link Mauve: Unemployed, or Funemployed?

(where’s the difference?)

SamWhited, heh, doing things for myself, with myself as the drive, and myself as the client. :)

Nice, I'm jealous

dwd, hmm gajim colored your whole message to me red and bolded the whole thing, hence, I have no idea what your intention was

i should write a gajim plugin that always randomizes the color in the xhtml variant of the message

daniel: randomizes the color of each letter in the message.

/load rainbow

its called syntax highlighting

nouns red, verbs blue, adjectives green and so on

daniel, looking forward to a piece of software which gets this right!

jonasw, Stanford released some OSS code to do that in Java a while back.

An extension to replace all messages with the results of <messagebody> | cowsay | lolcat

aww, lolcat doesn’t install

__ _ / / (_) | _| | (_) | \_\

Hey, just like Yaxim and Conversations display single emoji bigger, poezio could do so with figlet!

figlet fails at utf8.

I know. :(

https://i.imgur.com/mhEqyAK.png

I can see that working well for all messages in Gajim.

SamWhited, | figlet!

cowsay and figlet don't play well together

they do

also, that’s kindof the point

not on my machine; maybe there are options

it looks weird for sure, but it produces sensible output

ah ok, it breaks with long messages

Link Mauve: take the Google NoTo Emoji font and render its SVG into the flickering avatar square

Would anyone be against me making a few slight changes to the styling XEP that don't actually affect anything before it actually gets published? I figured I might as well go ahead and commit some simple editorial changes (typos, definitions, etc.) that I was going to make assuming its accepted (since they're already done, I was only holding off on the larger changes because I didn't want to waste time if it didn't get accepted)

SamWhited, editorial changes etc. seem fine to me

yah, me too, I just want to make sure the people voting don't have any objection

SamWhited: Was it accepted?

Kev: one remaining vote on list

If it's not accepted, there's no issue updating the protoXEP. If it's accepted, you don't need Council approval to make changes to an Experimental XEP of which you're the author.

good point, I guess I could make them anyways.

So while *technically* you should publish the version that was approved, I don't think it's going to hurt much.

FWIW, I’ve been holding back editorial changes etc. until after approval too

Yeah just update it

I haven't heard a single person argue it should be kept as-is so

I ended up pushing some of the simple non-editorial changes too: https://github.com/xsf/xeps/pull/537

Still more to do, but that was all the simple stuff that didn't require a lot of work or that I already had done, plus I tried to clear up a few things.