rendered version for quality control: https://op-co.de/tmp/xep-0423.html
Ge0rG
(it's got a gimmick for you, pep.)
Steve Killehas joined
pep.
hmm is there a revision block somewhere?
Ge0rG
pep.: unfortunately, the revision block is not suitable for CS purposes.
Ge0rG
pep.: feel free to rip off "Changes since 2019" into the rev block though
pep.
What does that mean
Ge0rG
pep.: you can't have the "Changes since 2019" in a single place of the revision block
Ge0rG
because it has a section for each minor version
Ge0rG
so pre-Last-Call and post-Last-Call go into separate blocks there
pep.
sure
pep.
Are we talking about the same thing
Ge0rG
pep.: I don't know?
Ge0rG
pep.: what you probably wanted to hear instead of my rant is: no, I didn't add a revision block
Wojtekhas left
Wojtekhas joined
pep.
And yeah that would probably look like your §1.1, since 0.1 is more or less similar to 412 right?
Ge0rG
pep.: yes, 0.1 was an identical copy
Ge0rG
plus "future changes", which is noted there, of course
UsLhas left
pep.
Ok let's see..
jonas’
pep., so you’re going to take care of that?
jonas’
please let me see the diff before hitting the button
jonas’
Ge0rG, as mentioned, no revision block is not an option
Ge0rG
jonas’: I know. This is why I added §1.1
j.rhas left
Ge0rG
jonas’: I was just hoping that an Editor would add the rev block so that I don't mess up anything
UsLhas joined
pep.
jonas’, yeah doing for it now. Ge0rG I have as many chance as you of messing it up :)
pep.
going*
Ge0rG
pep.: but I don't have that Editor hat, so now I can sleep calmly at night ;)
pdurbinhas joined
murabitohas left
j.rhas joined
murabitohas joined
!XSF_Martinhas left
!XSF_Martinhas joined
pdurbinhas left
j.rhas left
Nekithas left
Nekithas joined
stpeterhas joined
adiaholichas left
Ge0rG
hm. Chat Markers were just suggested for addition.
Zash
Wasn't that meant to get the overlap with receipts and chat states removed?
Chobbeshas left
Ge0rG
we also wanted to reword chat states as presence.
pep.
Ge0rG, so.. what does that mean for editors
Ge0rG
pep.: nothing so far.
Zash
Can you even do that wih a Final Standard?
Ge0rG
pep.: please go on with your work
pep.
ok
Ge0rG
pep.: I'll put that into the Last Call bucket.
Ge0rG
Zash: sure, given a new XEP number
matlaghas left
matlaghas joined
j.rhas joined
Chobbeshas joined
LNJhas left
j.rhas left
stpeterhas left
chronosx88has joined
j.rhas joined
adiaholichas joined
chronosx88has left
chronosx88has joined
stpeterhas joined
adiaholichas left
adiaholichas joined
adiaholichas left
stpeterhas left
adiaholichas joined
eevvoorhas left
pdurbinhas joined
Chobbeshas left
pdurbinhas left
niemandhas joined
ralphm
FYI, there's been a call for the Decentralized Internet & Privacy devroom at FOSDEM. Discuss over at summit@muc.xmpp.org.
adiaholichas left
ajhas left
Shellhas joined
j.rhas left
Chobbeshas joined
jubalhhas left
debaclehas joined
ralphmhas left
ralphmhas joined
lovetoxhas joined
lovetox
whats the deal with the published XEPs by pep?
lovetox
the are published but the link leads to the old version
jonas’
lovetox, what isn’t?
jonas’
ah, pep. sent the emails too early
pep.
oh
pep.
CI
Zash
Wait for the foreverbuild!
pep.
Ok I'll wait for the CI next time
jonas’
CI isn’t the thing you need to wait for
pep.
lovetox, you're too quick for me
jonas’
docker hub is broken, too
j.rhas joined
jonas’
throws 500s at me
jonas’
pep., you need to wait for https://cloud.docker.com/u/xmppxsf/repository/docker/xmppxsf/xeps/builds to finish
jonas’
the page may not load at the moment, docker cloud/hub seems to be broken
pep.
I don't have access to that apparently (I get redirected to the main page)
Zash
Mmmmm Cloud
jonas’
pep., that happened to me too, it’s the brokenness right now
jonas’
you should have access
pep.
ok
jonas’
pep., maybe send an email in reply to the CS-2020 notification
jonas’
so that people don’t get confused
joerghas left
lovetox
why how long does this build take?
lovetox
i mean its 20 minutes already
pep.
lo[..]oong
jonas’
lovetox, about 1h
jonas’
lovetox, possibly longer if dokcer cloud is currently broken
jonas’
so a note about that seems sensible to have
pep.
Here
Ge0rG
Looks like our hoster has gone Serverless, eh?
!XSF_Martinhas left
Zash
It is the modern thing to do, right?
pep.
Is there any other good reason to do anything
!XSF_Martinhas joined
Zash
Depends, do you support Nihilism over XMPP?
adiaholichas joined
mukt2has joined
adiaholichas left
lskdjf
> 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.
mukt2has left
!XSF_Martinhas left
lskdjf
s/easy xmpp/modern xmpp
Dele (Mobile)has left
jonas’
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*
jonas’
It was meant as a non-normative inspiration
jubalhhas joined
jubalhhas left
!XSF_Martinhas joined
jubalhhas joined
lovetox
yeah, i agree, user interface stuff should be strictly separate from XEPs
lovetox
only thing you get with putting this stuff into XEPs is, it gets simply ignored
larma
jonas’, sorry, but hard to read "auto-generating an avatar SHOULD happen as follows" as an inspiration, inspirations SHOULD use MAY 😉
jonas’
that’s true
lovetox
not even a MAY
Zash
RFC 2119 language about UI things is weird
lovetox
it should be in a different section without any keywords
pep.
just "may"
lovetox
or not at all in the XEP
pep.
(because 8174)
lovetox
why does a XEP have to make UI suggestions
jonas’
lovetox, it doesn’t *have* to
lovetox
we should find another venue for that
jonas’
lskdjf, I see your points, and I think there is some merit to them
Zash
And as pep. touched on, Council isn't made to review UI/UX things.
larma
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"
lskdjf
> 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.
pep.
Technically it's only a SHOULD. :-°
pep.
(I know.)
lskdjf
yeah basically everything in there is a SHOULD. So I can ignore the XEP and still be compliant?
Ge0rG
lskdjf: we really need to move this to standards. I'm currently not focused enough to give an appropriate response.
Ge0rG
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.
pep.
consistent *through UI
lskdjf
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.
LNJhas joined
ralphmhas left
ralphmhas joined
Ge0rG
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
lskdjf
> 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.
Nekithas left
lskdjf
> 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.
Ge0rG
lskdjf: you just gave additional feedback that wasn't on the list
Ge0rG
lskdjf: and as I said, I can't provide adequate feedback right now
Wojtekhas left
lovetox
hm but still weird that this is a XEP
lovetox
as it has really nothing to do with the protocol
lovetox
not even remotely
lovetox
its only purpose is to shape UI
lovetox
weird that this was accepted
lovetox
i dont think there is another XEP like that
jonas’
lovetox, `/me` is close
jonas’
and '393 to some extent
jonas’
depending on how you look at it
jonas’
but yes...
jonas’
I’m not sure what a better place for this would be tho
lovetox
in these XEPs there is at least something sent over the wire ^^
lovetox
i just think we need a place where we put stuff like that
jonas’
true
lovetox
the modernxmpp project would be a start for example
pep.
lovetox, it's not supposed to be a Standards Track XEP tbh, 392
jonas’
I don’t think that existed back then
stpeterhas joined
Zash
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.
pep.
I don't know about 0245, " /me" is "wire" format, but most of the rest is UI
pep.
Zash, sure that'd be more appropriate
lovetox
jonas’, this is not meant as a criticism of you writing the XEP, its just an observation from todays viewpoint :)
Wojtekhas joined
lskdjf
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.
lskdjf
so yeah, technically this XEP shouldn't exist in it's current form
Zash
XEP-0245 is Informational at least
lovetox
there are actually many XEPs that hin at UI stuff
lovetox
or even mandate it
lovetox
like larma just wrote on the list, even the avatar xep which has a very early number, mandates how a client should resize avatars
17:24:33
Link Mauve "SamWhited, also, why are the compliance suites standards tracks, instead of informational?"
Zash
Hah
larma
because they are supposed to, for some reason: https://xmpp.org/extensions/xep-0001.html#types-Standards-Track
larma
wire protocols and protocol suites are allowed on standards track
archas joined
stpeterhas left
Zash
That's clear, yeah.
pdurbinhas joined
Zash
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.
pep.
Yeah no I guess it wasn't on purpose and nobody noticed