-
Ge0rG
Zash: treat them like chat messages?
-
aliex@exploit.im
aliex@exploit.im✎ -
aliex@exploit.im
aliex@exploit.im hi ✏
-
Guus
ah, my favorite domain. It ranks high in my spamlist.
-
Ge0rG
pep., jonas’: please merge https://github.com/xsf/xeps/pull/841
-
pep.
k
-
Ge0rG
rendered version for quality control: https://op-co.de/tmp/xep-0423.html
-
Ge0rG
(it's got a gimmick for you, pep.)
-
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
-
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
-
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
-
Ge0rG
jonas’: I was just hoping that an Editor would add the rev block so that I don't mess up anything
-
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 ;)
-
Ge0rG
hm. Chat Markers were just suggested for addition.
-
Zash
Wasn't that meant to get the overlap with receipts and chat states removed?
-
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
-
ralphm
FYI, there's been a call for the Decentralized Internet & Privacy devroom at FOSDEM. Discuss over at summit@muc.xmpp.org.
-
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
-
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
-
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?
-
Zash
It is the modern thing to do, right?
-
pep.
Is there any other good reason to do anything
-
Zash
Depends, do you support Nihilism over XMPP?
-
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.
-
lskdjf
s/easy xmpp/modern xmpp
-
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
-
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.
-
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.
-
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
-
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
-
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 :)
-
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
-
Zash
https://logs.xmpp.org/council/2017-09-20?p=h#2017-09-20-e90eb46fa7027b61
-
Zash
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
-
Zash
That's clear, yeah.
-
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
-
Zash
2 years ago!