I don't think this specification specifically needs to be defined in the XMPP protocol stack, but I do think it's nice to have a recommended method for doing this. If there are other already-standardized ways of doing this, I would prefer that we adopt one of those instead of doing our own. I don't actually know if there are any though, and am happy for it to be standardized here as well if there aren't. I have only implemented an older version of this specification which I intend to continue using and it solves the problem well enough. I am not qualified to know whether it addresses the accessibility requirements, but as far as I can tell it does. I have no reason to believe that the current, more up-to-date version does a worse job at this, so I suspect it still solves all the problems and meets all the requirements. I have implemented an older version, but do not plan on implementing the current version. If we are going to standardize this we should be using existing standard color spaces that are widely implemented. In the latest version a color space that was defined by an individual and is not otherwise widely used has been adopted, which I feel isn't the right way to go about any standards development. I am sure critics will counter with "but it's so easy to implement, and the author has libraries in various languages", but never the less it is my belief that we should stick to widely used and widely vetted color spaces from other standards bodies, and not just whatever trendy new thing one or two people on hacker news have created this week. We are just making more work for ourselves by going this route. I should not have to vet a color space and a library that an individual made, and I am likely not qualified to do so. As a standards body we should re-use other standards bodies work unless there is a very good reason not to, and I don't believe there is one here. We should go back to a color space that is already used in the industry, or at least hold off advancing this XEP until we're sure the colors space that has been picked is actually being widely adopted itself. It's worth mentioning that any sort of color hash like this will be somewhat limited and that the human eye can only distinguish between so many colors, so it shouldn't be used to do things where the user would have to discern uniqueness. ie. if the user has two contacts that both hash to the same color (or close to the same color), they could become confused about who is speaking and who they're writing to if this isn't paired with other visual indicators that differentiate the contacts. Yes, it's easy enough to follow along with. —Sam On 3/10/24 10:24, Daniel Gultsch wrote: -- Sam Whited sam(a)samwhited.com

XEP-0392 (Consistent Color Generation) has just been moved to stable by Council. The Editor will act on that later today. However council strongly believes that the feedback provided by Stephen Paul Weber should be addressed with the following two action items: - make HSLuv a SHOULD, explain that other HSL could be used - state that implementations SHOULD use constant S and L for specific usecases/themes for uniformity Council believes that this can happen after the move to stable. (But we would be very disappointed if it doesn’t happen :-) ) cheers Daniel