Ge0rGflow: do you have a suggested wording for the MIX reference(s)=
Ge0rGflow: before you answered my mail, I made it look like this: https://op-co.de/tmp/xep-0423.html#future
lskdjfRegarding the Compliance Suite: It lists "Private XML Storage", but what for, actually? I mean, private xml storage is no end in itself. bookmark storage previously used it, but the current version of the XEP doesn't, so what does XEP-0049 even do in there?
Ge0rGlskdjf: it's still used for bookmarks by some clients, because transition and backward compatibility are hard
jonas’also because pep bookmarks (except bookmarks2) don’t give a real benefit
jonas’and there was massive lack of server support for private and persistent pep until a year ago or so
Ge0rGand the compatibility transition requirements of Bookmarks2 are abysmal
Ge0rGlooks at prosody 0.10 with a sad face
lskdjfit's actually used by pretty much all clients ^^ perhaps make it clear that this is really just about bookmarks backwards compatibility, then? Maybe by putting it into the same row as "Advanced Group Chat"?
pep.Ge0rG, you might want to reference https://xmpp.org/extensions/attic/xep-0048-1.0.html then instead?
ZashPrivate XML storage was widely used for client settings back in the day, but I don't know if anything still does that
Ge0rG"I don't know if" is not a good rationale to move it, or is it?
pep.Do you need stronger opinions?
lskdjfZash, you mean for storing it's own settings? that would have nothing to do with compliance, then.
Zashlskdjf, storing settings on the server
Ge0rGan advanced server needs to support it, no matter what a client does with it
MattJGe0rG, maybe a nice parallel to "Future development" would be to document what stuff we are trying to deprecate also
Ge0rGMattJ: indeed, but I'm not sure how to style that, also -ETIME
lskdjfGe0rG, also you didn't remove vcard-temp (at least from the core client) yet. A few days ago I got the impression you were on board with doing that. Did someting change?
Ge0rGlskdjf: I have no clue on how relevant vcard-temp still is
pep.vcard4 is Proposed, and has been for some months now :(
pep.(At least it's better than most other XEPs in the CS)
KevI think vcard-temp is still very relevant.
MattJvcard-temp is implemented by every server and just about every client
Ge0rGKev: is it core-relevant or advanced-relevant?
KevCore, I think.
MattJand vcard4 is implemented by one server, and possibly nothing else
Ge0rGbecause avatars became advanced somehow. I hope nobody noticed.
KevYou would struggle to implement an interoperable client/server without it.
KevAnd avatars need it, which are certainly core.
pep.Does that mean it needs to be Client core/advanced?
Ge0rGKev: as I said, User Avatars are advanced ;)
lskdjfConversations doesn't have vcard-temp and it's (one of) the most popular clients. So not having vcard-temp can't be too bad.
lskdjf> And avatars need it, which are certainly core.
Kev: well clients can implement vcard avatars without displaying/parsing other vcard-temp information.
lskdjfAnd for the record I also think avatars should stay in Core Client.
Ge0rGI'm slowly losing track of all the things. Maybe this is due to the other things I need to work on in parallel, plus the timeline being tomorrow
Ge0rGlskdjf: why are avatars more important than 0392?
lskdjf"more important" is IMHO a wrong way to compare those two things. Mandating UI in the compliance suite is simply a very bad idea and not the task or competence of the council. It's not part of the protocol, it's UI/UX design. avatars on the other hand are part of the protocol and it doesn't matter how or where you display them.
Ge0rG...or if you display them at all
MattJI somewhat disagree with this analysis
Ge0rGif I don't display avatars, do I need to support them at the protocol level?
pep.I agree with lskdjf here fwiw
Ge0rGluckily, I'm not wearing my Council hat here, but my XEP author hat ;)
KevI think Ge0rG's question is valid. Since 392 covers a fallback for avatars, it doesn't seem unreasonable to argue the case for it if you argue for avatars.
pep.lskdjf, in any case, that should probably be expressed on the ML
KevI'm not sure I agree with it, but I think the argument is sane.
Ge0rGKev: it's not a fallback, because you often need to display both the name and the image, but other than that, yeah.
Ge0rGlskdjf: yes, please write it to the ML.
KevGe0rG: The bit about fallback avatars is a fallback for avatars :)
Ge0rGKev: a fallback for fallback avatar fallback?
Ge0rGCan we agree on moving vcard-temp into "User Avatar Compatibility" or are there other use cases for it?
KevGe0rG: I think there's one argument that, irrespective of the optimal thing, it might be least contentious, if you want things through smoothly on a short timescale, to put comments in the future direction section, and not change too much that's likely to bikeshed.
ZashClients tend to use vcard-temp + xep-0153 for avatars?
KevI think vcard-temp is core, because of the avatar requirement.
lskdjf> if I don't display avatars, do I need to support them at the protocol level?
Ge0rG orcourse not. but then you're not compliant. the difference is: "User Avatars" mandates that you should _have_ a feature. Somewhere, somehow. If I have to cascade through 3 menues to get there, that's client choice. But "User Name Coloring" tells the clients _how_ to do a UI feature. That's a difference.
KevI think vcard-temp is advanced for all other use. It's not obsolete because vcard4 "isn't used".
Ge0rGKev: as I said, Avatars got demoted to Advanced by a strange mishap.
KevUsing this year as an opportunity to rectify that seems sane :)
Ge0rGI have no idea why heated debates always happen in the last days before the new CS XEP is getting proposed.
Ge0rGWe literally had a year to figure all that out.
moparisthebestthat's the first time people look at them :)
KevBecause everything happens last-minute when dealing with busy people.
Ge0rGI'm also slowly starting to feel why previous editors of the CS vanished.
Ge0rGlskdjf: I'm not sure whether we read the same version of 0392.
Ge0rG> Implementations may colorize the participants of a conversation with an individual color to make them easier to distinguish.
> In such cases, the color SHOULD be generated as described in the Generating a color section.
Ge0rG> Implementations SHOULD allow the user to turn off any colorization completely.
Ge0rGlskdjf: also I'm curious what your actual problem with 0392 is, besides of it being out-of-scope of the XSF powers.
Ge0rGlskdjf: that said, I really don't see the principal difference to avatars. I'd even argue that avatars are worse than 0392, because their transmission consumes additional network capacity
larmaGeOrG, I think the main issue is that quiet some XEPs on the list are on CS for the first time and many probably did not expect them to end up there given that they are still in their early days.
I am currently writing a lengthy mail for the ML explaining why I think the color generation is flawed and imposes accessibility issues if used as suggested (which is rarely done, fortunately).
Ge0rGlarma: I think the main goal of CS is to provide a useful selection of what to implement, to authors. I've done a review of the existing XEPs and considered some more for addition.
Ge0rGlarma: jonas’ and I will be very interested to hear about the accessibility issues of 0392, and I hope we can improve that.
larmaAs far as I know, there are actually very few existing clients implementing the 3.2 usecase of 0392, where lack of contrast is a significant issue (it doesn't really matter for avatars, because avatars don't matter)
DanielFwiw I feel some general uneasiness about trying to put in a lot of new xeps last minute
Ge0rGlarma: lack of contrast between the colored nickname and the background / theme of the client, or between different names?
larmafirst, second wouldn't be an accessibility issue
jonas’larma, for background contrast, there is https://xmpp.org/extensions/xep-0392.html#impl-bgcolor
jonas’larma, for background contrast, there is https://xmpp.org/extensions/xep-0392.html#impl-bgcolor
jonas’we can adapt the factors in https://xmpp.org/extensions/xep-0392.html#algorithm-bg if they’re not good enough for accesibility
jonas’also please note that all implementations must have an OFF switch for text colorisation for accessibility reason
jonas’also please note that all implementations must have an OFF switch for text colorisation for accessibility reasons
jonas’also please note that all implementations SHOULD have an OFF switch for text colorisation for accessibility reasons
pep.Daniel, yeah.. lots of friction in a short period of time, not good.
pep.We need to add some time to allow for dissipation
Ge0rGif only we didn't have Council election in a month, followed by re-org, followed by Christmas.
Ge0rGit will be impossible to finish this in 2019 if we don't vote on advancing before the reeleection.
Ge0rGI'm not sure when I volunteered to do CS-2020, but I'm sure it was early this year.
Ge0rGso everybody had enough time to propose changes.
DanielThe fact that nobody suggested changes could be seen as being fine with the status quo
KevOr that no-one's particularly enthusiastic about the suites.
Ge0rGOr that no-one's particularly enthusiastic about XMPP.
KevI'm more enthusiastic about XMPP than I am about the suites.
DanielIt seems to be causing some friction now. So apparently people do care about the CS
KevI didn't mention caring, I mentioned enthusiasm ;)
KevI think we'd be better off not publishing them (in their Compliance Suite form, at least), but if we have to publish them I don't think we should get them wrong.
Ge0rGKev: I think we tried very hard to have a phone conference type of thing happen to discuss alternative ways to do CS
DanielI think compliance suites are a good thing. But I'd be careful about them becoming a simple _include all_
Ge0rGSorry, I got to run now. I really hope I'm going to read your specific feedback on list, tomorrow.
Steve Killehas left
Steve Killehas joined
marc_Ge0rG: you're not attending at the Munich Meet up, right?
larmajonas’, yes I have read the XEP and the background color correction algorithm presented there is pretty bad
jonas’larma, suggestions welcome
ZashHow is it bad?
Ge0rGAnd regarding the last minute changes, I'm very sorry. I didn't factor in the time for the Last Call, also was very busy the last weeks (and still am). I really hoped to have this ready sooner
moparisthebestre 392, it's not perfect, but I haven't seen perfect yet, at least it's specified, it's better than whatever dino is using for instance
moparisthebestI'm in an IRC chat using biboumi with about 40 people, dino has about 4 different colors total shared across everyone, conversations uses 392 and at least has about 10 different colors instead
moparisthebest(I'm a little colorblind so that's how it looks for me, I haven't actually sampled RGB colors lately)
moparisthebestit's pretty hard to get it right, when jonas’ was playing with the algorithm, if he applied it to one set of usernames it'd look perfect, but then applied to another set, really bad, no idea
Ge0rGDaniel, pep. and me look almost identical in here. Well, that's life
larmaGe0rG, can you remove XEP-0223 from the list? It is Informational, there is nothing clients or servers need to do to implement it, so you are always compliant...
Ge0rGlarma: isn't it useful to know for implementing bookmarks?
pep.Isn't it required by bookmarks then?
pep.> It is RECOMMENDED to use Publish-Subscribe (XEP-0060)  for data storage, specifically through the use of personal data nodes hosted at the user's virtual publish-subscribe service as described in Best Practices for Persistent Storage of Private Data via Publish-Subscribe (XEP-0223)  and illustrated in the following sections.
ZashThere's no XEP for "Full blown PubSub on your own JID", XEP-0163 specifies a minimum subset.
pep.and it's again mentioned in the security considerations
ZashXEP-0222 and 0223 talk about fancy things you can do with a slightly bigger subset
ZashDoes '163 actually specify a protocol? Should it too be Informational?
ZashOr should 22 be Standards Track?
Zash0060 is where everything is defined anyways, but you can't implement all of that
pep.You can, no? But it's probably not required for most use-cases
ZashAll of '60? No that's impossible. First you have to implement half of it, which is a huge task. Then you have to implement half of the remaining part, also a huge task. Then half of the remaining, still a huge task.
larmaWell I was thinking it makes more sense to require bookmarks 2 support if we require bookmarks 2 support. It doesn't add any value (at least for client developers) to know they should implement XEP-0223, because there is nothing in XEP-0223 that can be implemented.
Zashlarma: You could not do '222 or 223 with Prosody prior to version 0.10.
ZashSo there was *something* that was implemented.
pep.because #persist_items ?
Zashand access models
larmaZash, Yeah, for servers it might make sense, for clients it doesn't
larmaon the other hand bookmarks 2 is nothing a server needs to handle if they do XEP-0223
Zashlarma: There is still a step between the absolute baseline defined by '163 up to what 222/223 describes
ZashLike, dealing with publish-options
larmaI agree, but still it's servers implementing 223, clients implement bookmarks 2 which relies on servers implementing the 0060 subset outlined in 0223
ZashSo, my point is, pointing to '223 in the compliance suite is a short-hand for pointing to specific features in 0060
larmawhat I mean is, we want servers to implement 163/223, but if a client only has a function to fetch bookmarks 2, that's fine, it doesn't need to be able to do anything generic for 163/223
ZashI think you want publish-options with access model = whitelist
Ge0rGlarma: there is also this thing about Bookmarks 2 not requiring backward compatibility.
pep.Ge0rG, yeah that should be added, and I think it is in the submitted PR
pep.(that JC just reviewed btw)
Ge0rGAnd even then, we can't demand bookmarks 2 right now, because inertia.
ZashUnder Futures maybe, but it seems way too early for a compliance suite spot
Ge0rGIt's been just a few hours since I was told not to add controversial specifications at the last minute.
Ge0rGZash: it's in Future already 😉
ZashCan you re-post the link please?
flowGe0rG, FWIW, I do really like your proposed compliance suites. Even though I don't see the point in mentioning all the single MIX XEPs, as it appears to create a lot of noise for no benefit. But besides that, it comes close to the "map of the xep jungle", which provides guidance about the current state and the probable future of XMPP, that I always asked for :)
lovetoxjust for info, there are still open issues with bookmarks 2
- 0060 needs changes
- bookmarks2 XEP needs many additions
- servers dont implement the requirements needed to use the XEP correctly
pep.https://github.com/xsf/xeps/pull/835 ^, as mentioned in the other channel
pep.Also for 0060: https://github.com/xsf/xeps/pull/840
lovetoxand for server issue: https://github.com/processone/ejabberd/issues/3044
lovetoxand of course we need conversion mods :)
lovetoxso long road i would say
Ge0rGflow: have you checked the updated MIX list?
pep.Well 402 can be used standalone once this is pushed
pep.So it would make sense in some setups already
pep.Maybe not for the "open network" (whatever that would be called)
flowGe0rG, when did you update it? You understood that I am arguing that there shouldn't be a MIX list at all but just a single reference to xep369?
Ge0rGflow: around the time you wrote your response. I just wondered whether this new approach is better. People need some way to discover the other MIX parts
ZashGe0rG, minor thing but why is the web section before the im section?
Ge0rGZash: it was that way before
ZashAnd should MLS be mentioned among the E2EE things?