XSF Discussion - 2019-10-15

Zash: treat them like chat messages?

aliex@exploit.im hi ✏

ah, my favorite domain. It ranks high in my spamlist.

pep., jonas’: please merge https://github.com/xsf/xeps/pull/841

k

rendered version for quality control: https://op-co.de/tmp/xep-0423.html

(it's got a gimmick for you, pep.)

hmm is there a revision block somewhere?

pep.: unfortunately, the revision block is not suitable for CS purposes.

pep.: feel free to rip off "Changes since 2019" into the rev block though

What does that mean

pep.: you can't have the "Changes since 2019" in a single place of the revision block

because it has a section for each minor version

so pre-Last-Call and post-Last-Call go into separate blocks there

sure

Are we talking about the same thing

pep.: I don't know?

pep.: what you probably wanted to hear instead of my rant is: no, I didn't add a revision block

And yeah that would probably look like your §1.1, since 0.1 is more or less similar to 412 right?

pep.: yes, 0.1 was an identical copy

plus "future changes", which is noted there, of course

Ok let's see..

pep., so you’re going to take care of that?

please let me see the diff before hitting the button

Ge0rG, as mentioned, no revision block is not an option

jonas’: I know. This is why I added §1.1

jonas’: I was just hoping that an Editor would add the rev block so that I don't mess up anything

jonas’, yeah doing for it now. Ge0rG I have as many chance as you of messing it up :)

going*

pep.: but I don't have that Editor hat, so now I can sleep calmly at night ;)

hm. Chat Markers were just suggested for addition.

Wasn't that meant to get the overlap with receipts and chat states removed?

we also wanted to reword chat states as presence.

Ge0rG, so.. what does that mean for editors

pep.: nothing so far.

Can you even do that wih a Final Standard?

pep.: please go on with your work

ok

pep.: I'll put that into the Last Call bucket.

Zash: sure, given a new XEP number

FYI, there's been a call for the Decentralized Internet & Privacy devroom at FOSDEM. Discuss over at summit@muc.xmpp.org.

whats the deal with the published XEPs by pep?

the are published but the link leads to the old version

lovetox, what isn’t?

ah, pep. sent the emails too early

oh

CI

Wait for the foreverbuild!

Ok I'll wait for the CI next time

CI isn’t the thing you need to wait for

lovetox, you're too quick for me

docker hub is broken, too

throws 500s at me

pep., you need to wait for https://cloud.docker.com/u/xmppxsf/repository/docker/xmppxsf/xeps/builds to finish

the page may not load at the moment, docker cloud/hub seems to be broken

I don't have access to that apparently (I get redirected to the main page)

Mmmmm Cloud

pep., that happened to me too, it’s the brokenness right now

you should have access

ok

pep., maybe send an email in reply to the CS-2020 notification

so that people don’t get confused

why how long does this build take?

i mean its 20 minutes already

lo[..]oong

lovetox, about 1h

lovetox, possibly longer if dokcer cloud is currently broken

so a note about that seems sensible to have

Here

Looks like our hoster has gone Serverless, eh?

It is the modern thing to do, right?

Is there any other good reason to do anything

Depends, do you support Nihilism over XMPP?

> lskdjf: also I'm curious what your actual problem with 0392 is, besides of it being out-of-scope of the XSF powers. Ge0rG, your question was a day ago, but anyways, now I have the time to answer. It's ok to write down a common way of generating colors, even if maybe not in the standarts track. The specification has it's flaws, but they can be improved, there was a mail on the ML about that. My main problem really is that you want to write 0392 into the compliance suites. Some days ago I complained that I couldn't do slack/github style avatars anymore. You said: "nothing prevents your smart pattern avatar generator from applying the same color as other clients do". But that's wrong, the XEP doesn't allow that. It says: Generate a color, fill a shape with it and render the first character of the name onto it. Thus, if I want to generate an avatar, I'm not allowed to have patterns, I'm not allowed to put two letters onto the avatar. Both are common approaches. If the XEP is in the compliance suites, I have to choose between having a UI that might better fit my application or being an Advanced IM client. You basically hinter potential UI improvements. Also, some environments strongly suggest to use a specific color palette. E.g. GNOME does and Android previously did, too. Or maybe my design department simply evaluated in user studies that this specific green tone fits best into my application. The XEP only allows me to use a specific palette if my device doesn't support otherwise, not if I want/should do so because of other constaints. Thus, I can choose between following the GNOME suggestions and being an advanced XMPP IM client. XMPP is a protocol and the compliance suites should define features. Not a set of user interface rules. We can have things like easy xmpp for that.

s/easy xmpp/modern xmpp

lskdjf, > Generate a color, fill a shape with it and render the first character of the name onto it. Okay, I did not intend this to be a *requirement*

It was meant as a non-normative inspiration

yeah, i agree, user interface stuff should be strictly separate from XEPs

only thing you get with putting this stuff into XEPs is, it gets simply ignored

jonas’, sorry, but hard to read "auto-generating an avatar SHOULD happen as follows" as an inspiration, inspirations SHOULD use MAY 😉

that’s true

not even a MAY

RFC 2119 language about UI things is weird

it should be in a different section without any keywords

just "may"

or not at all in the XEP

(because 8174)

why does a XEP have to make UI suggestions

lovetox, it doesn’t *have* to

we should find another venue for that

lskdjf, I see your points, and I think there is some merit to them

And as pep. touched on, Council isn't made to review UI/UX things.

lovetox, as I just wrote "It makes a lot of sense to give hints how things could/should be displayed, especially when it has security implications"

> only thing you get with putting this stuff into XEPs is, it gets simply ignored well it's hard to ignore the compliance suites if you want to be an advanced client. You'd have to either do what the XEP says or be downgraded to a basic client just because you want to display two letters in your generated avatars.

Technically it's only a SHOULD. :-°

(I know.)

yeah basically everything in there is a SHOULD. So I can ignore the XEP and still be compliant?

lskdjf: we really need to move this to standards. I'm currently not focused enough to give an appropriate response.

My reading of 0392 was to provide a consistent hue value for the visual element associated with a given user, not more and not less.

consistent *through UI

Ge0rG, pep brought it to standarts already and you basically replied with "I disagree, I would like to challenge Counil" ... So I fail to see the advantage of going to standards.

lskdjf: you can provide your arguments to council. But in fact I much more appreciate your specific feedback on 0392, and I'm sure it will be incorporated to improve it

> My reading of 0392 was to provide a consistent hue value for the visual element associated with a given user, not more and not less. that already is problematic. Refer to what I wrote about reasons to use e.g. different color palettes. A body that standartizes a protocol does not have the task to mandate UI.

> But in fact I much more appreciate your specific feedback on 0392, and I'm sure it will be incorporated to improve it I can only repeat: My proplem is that 0392 is in the compliance suites, not 0392 itself. And feedback on 0392 was already given on the ML yesterday.

lskdjf: you just gave additional feedback that wasn't on the list

lskdjf: and as I said, I can't provide adequate feedback right now

hm but still weird that this is a XEP

as it has really nothing to do with the protocol

not even remotely

its only purpose is to shape UI

weird that this was accepted

i dont think there is another XEP like that

lovetox, `/me` is close

and '393 to some extent

depending on how you look at it

but yes...

I’m not sure what a better place for this would be tho

in these XEPs there is at least something sent over the wire ^^

i just think we need a place where we put stuff like that

true

the modernxmpp project would be a start for example

lovetox, it's not supposed to be a Standards Track XEP tbh, 392

I don’t think that existed back then

As I think someone said at last Summit, we can set up a process for this if people want to, like an UX track with a UX review council or a SIG or something.

I don't know about 0245, " /me" is "wire" format, but most of the rest is UI

Zash, sure that'd be more appropriate

jonas’, this is not meant as a criticism of you writing the XEP, its just an observation from todays viewpoint :)

lovetox, as was pointed out on the ML, it's indeed not intended to specify anything but _wire protocol_ in the standarts track, according to XEP-0001.

so yeah, technically this XEP shouldn't exist in it's current form

XEP-0245 is Informational at least

there are actually many XEPs that hin at UI stuff

or even mandate it

like larma just wrote on the list, even the avatar xep which has a very early number, mandates how a client should resize avatars

https://logs.xmpp.org/council/2017-09-20?p=h#2017-09-20-e90eb46fa7027b61

17:24:33 Link Mauve "SamWhited, also, why are the compliance suites standards tracks, instead of informational?"

Hah

because they are supposed to, for some reason: https://xmpp.org/extensions/xep-0001.html#types-Standards-Track

wire protocols and protocol suites are allowed on standards track

That's clear, yeah.

Hasn't anyone remarked the color XEP being in Standards Track before? Can't find anything in my email archives and there wasn't much discussion at that council meeting.

Yeah no I guess it wasn't on purpose and nobody noticed

2 years ago!