Colors provide a valuable visual cue to recognize shapes. Recognition of colors works much faster than recognition of text. Together with the length and overall shape of a piece of text (such as a nickname), a color provides a decent amount of entropy to distinguish a reasonable amount of entities, without having to actually read the text.
Clients have been using randomly or deterministically chosen colors for users in multi-user situations for a long time already. However, since there has been no standard for how this is implemented, the experience differs across platforms. The goal of this XEP is to provide a uniform, platform-independent, stateless and easy-to-implement way to map arbitrary bytestrings to colors.
To allow cross-client use, it is important that the color scheme can be adapted to different environments. This specification provides means to adapt colors to different background colors as well as Color Vision Deficiencies.
In no way is the system presented in this specification a replacement for names. It only serves as an additional visual aid.
The color generation mechanism should provide the following features:
To generate a color from a string of text, the following algorithms are applied in order:
The algorithms in this document use the HSLuv [1]⎄ color space. It provides consistent brightness (for a given luminosity) across its entire definition space. There is also widespread library support.
Input: An identifier, encoded as octets of UTF-8 (RFC 3269 [2]).
Output: Hue angle.
Note: The goal of this algorithm is to convert arbitrary text into a scalar value which can then be used to calculate a color.
Input: Hue angle.
Output: Hue angle.
Note: This algorithm will re-map the angle to map it away from ranges which can not be distinguished by people with the respective Color Vision Deficiencies.
Note: Some floating-point modulo implementations will return negative outputs for negative inputs. This algorithm assumes that your implementation returns non-negative outputs for all inputs.
Add 90 to the angle, take it modulo 180 and subtract 90. Take the result modulo 360 to ensure that it's in the range from 0 to 360.
Note: the same effect can be achieved by forcing the two most-significant bits of the angle to be equal to the second-most-significant bit before converting to a float in Angle generation. This avoids having to perform a floating-point modulo operation.
Take the angle modulo 180.
Note: the same effect can be achieved by setting the most-significant bit to zero before conversion to floating point in Angle generation. This avoids having to perform a floating-point modulo operation.
Use the HSLuv operation hsluvToRgb to convert the Hue angle to a color. The saturation and lightness are to be defined by the implementation (see also the Contrast Ratio considerations).
Input: A set of RGB colors (each component from 0 to 1).
Output: A mapping from angles (integer, from 0 to 360) to RGB colors.
Note: when the algorithm finishes, the mapping maps angles (rounded to two decimal places) to the R, G, B triples which come closest to the desired color and lightness.
Implementations are free to choose a representation for palette colors different from R, G, B triplets. The exact representation does not matter, as long as it can be converted to a Hue angle accordingly.
Input: (a) A mapping which maps angles to R, G, B triplets and (b) a color to map to the closest palette color as angle alpha.
Output: A palette color as R, G, B triplet.
Note: See Conversion of an RGB color palette to a Hue palette on how to convert an R, G, B triplet to an angle.
D = min((alpha - beta) % 360, (beta - alpha) % 360)
Implementations are free to choose a representation for palette colors different from R, G, B triplets. The exact representation does not matter, as long as it can be converted to a Hue angle accordingly.
Implementations should be aware of Gamma correction and apply it as needed.
When processing JIDs as text input, implementations MUST prepare the JID as it would for comparing it to another JID with a case-sensitive comparison function.
As outlined above, implementations SHOULD offer the Red/Green-Blindness and Blue-Blindness corrections as defined in the Corrections for Color Vision Deficiencies section. Users SHOULD be allowed to choose between:
The last option is useful for users with monochromatic view or who find colors distracting.
Some sources on the internet indicate that people with Color Vision Deficiencies may profit from having larger areas of color to be able to recognize them. This should be taken into consideration when selecting font weights and line widths for colored parts.
Implementations should adapt the lightness value according to the background on which the color is rendered.
This specification extracts a bit more information from an entity and shows it alongside the existing information to the user. As the algorithm is likely to produce different colors for look-alikes (see Best Practices to Prevent JID Mimicking (XEP-0165) [4] for examples) in JIDs, it may add additional protection against attacks based on those.
Due to the limited set of distinguishable colors and only extracting 16 bits of the hash function output, possible Color Vision Deficiencies and/or use of palettes, entities MUST NOT rely on colors being unique in any context.
This section provides an overview of design considerations made while writing this specification. It shows alternatives which have been considered, and eventually rejected.
The versions up to 0.5 of this document used a variant of the YCbCr color space (namely BT.601 [5]) along with a custom algorithm to convert from angles to CbCr and from there to RGB. The HSLuv color space provides extremely consistent apparent brightness of the colors which cannot be achieved with simple application of YCbCr. In addition, HSLuv has widespread library support.
The HSV and HSL color spaces fail to provide uniform luminosity with fixed value/lightness and saturation parameters. Adapting those parameters for uniform luminosity across the hue range would have complicated the algorithm with litte to no gain.
Given a fixed-size and finite palette of colors, it would be possible to ensure that, until the number of entities to color exceeds the number of colors, no color collisions happen.
There are issues with this approach when the set of entities is dynamic. In such cases, it is possible that an entity changes its associated color (for example by re-joining a colored group chat), which defeats the original purpose.
In addition, more state needs to be taken into account, increasing the complexity of choosing a color.
This specification needs to collapse an arbitrarily long string into just a few bits (the angle in the CbCr plane). To do so, SHA-1 (RFC 3174 [3]) is used.
CRC32 and Adler32 have been considered as faster alternatives. Downsides of these functions:
SHA-1 is widely available. From a security point of view, the exact choice of hash function does not matter here, since it is truncated to 16 bits. At this length, any cryptographic hash function is weak.
The palette-mapping algorithm operates on angles only and disregards the lightness value except if the angles match. This has the downside that the brightness is not equal over the range of the palette mapped colors.
The alternative would be to require the lightness to be close to the target lightness. This has several issues:
For the sake of having more colors available, the given algorithm was chosen which prefers many colors with hue conformance over fewer colors with hue and lightness conformance.
This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [6].
This document requires no interaction with the XMPP Registrar [7].
Thanks to Klaus Herberth, Daniel Gultsch, Georg Lukas, Tobias Markmann, Christian Schudt, and Marcus Waldvogel for their input and feedback on this document.
This section holds test vectors for the different configurations. The test vectors are provided as Comma Separated Values. Strings are enclosed by single quotes ('). The first line contains a header. Each row contains, in that order, the original text, the text encoded as UTF-8 as hexadecimal octets, the angle in degrees, the calculated hue in degrees (differs from angle only for CVD-corrected rows), and the Red, Green, and Blue values.
text,hextext,angle,hue,r,g,b 'Romeo','526f6d656f',327.255249,327.255249,0.865,0.000,0.686 'juliet@capulet.lit','6a756c69657440636170756c65742e6c6974',209.410400,209.410400,0.000,0.515,0.573 '😺','f09f98ba',331.199341,331.199341,0.872,0.000,0.659 'council','636f756e63696c',359.994507,359.994507,0.918,0.000,0.394 'Board','426f617264',171.430664,171.430664,0.000,0.527,0.457
text,hextext,angle,hue,r,g,b 'Romeo','526f6d656f',327.255249,327.255249,0.865,0.000,0.686 'juliet@capulet.lit','6a756c69657440636170756c65742e6c6974',209.410400,29.410400,0.742,0.359,0.000 '😺','f09f98ba',331.199341,331.199341,0.872,0.000,0.659 'council','636f756e63696c',359.994507,359.994507,0.918,0.000,0.394 'Board','426f617264',171.430664,351.430664,0.904,0.000,0.494
text,hextext,angle,hue,r,g,b 'Romeo','526f6d656f',327.255249,147.255249,0.000,0.535,0.350 'juliet@capulet.lit','6a756c69657440636170756c65742e6c6974',209.410400,29.410400,0.742,0.359,0.000 '😺','f09f98ba',331.199341,151.199341,0.000,0.533,0.373 'council','636f756e63696c',359.994507,179.994507,0.000,0.524,0.485 'Board','426f617264',171.430664,171.430664,0.000,0.527,0.457
The used palette can be generated by sampling the RGB cube evenly with six samples on each axis (resulting in 210 colors (grayscales are excluded)). The resulting palette is commonly known as the palette of so-called "Web Safe" colors.
text,hextext,hue,best_hue,r,g,b 'Romeo','526f6d656f',327.255249,327,1.000,0.000,0.800 'juliet@capulet.lit','6a756c69657440636170756c65742e6c6974',209.410400,226,0.000,0.800,1.000 '😺','f09f98ba',331.199341,331,1.000,0.400,0.800 'council','636f756e63696c',359.994507,359,0.800,0.200,0.400 'Board','426f617264',171.430664,161,0.000,1.000,0.800
text,hextext,hue,best_hue,r,g,b 'Romeo','526f6d656f',327.255249,327,1.000,0.000,0.800 'juliet@capulet.lit','6a756c69657440636170756c65742e6c6974',29.410400,30,1.000,0.600,0.400 '😺','f09f98ba',331.199341,331,1.000,0.400,0.800 'council','636f756e63696c',359.994507,359,0.800,0.200,0.400 'Board','426f617264',351.430664,353,0.400,0.000,0.200
text,hextext,hue,best_hue,r,g,b 'Romeo','526f6d656f',147.255249,147,0.400,0.800,0.600 'juliet@capulet.lit','6a756c69657440636170756c65742e6c6974',29.410400,30,1.000,0.600,0.400 '😺','f09f98ba',151.199341,153,0.200,0.800,0.600 'council','636f756e63696c',179.994507,192,0.000,0.800,0.800 'Board','426f617264',171.430664,161,0.000,1.000,0.800
This document in other formats: XML PDF
This XMPP Extension Protocol is copyright © 1999 – 2020 by the XMPP Standards Foundation (XSF).
Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.
## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##
In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.
This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <https://xmpp.org/about/xsf/ipr-policy> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).
The HTML representation (you are looking at) is maintained by the XSF. It is based on the YAML CSS Framework, which is licensed under the terms of the CC-BY-SA 2.0 license.
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.
Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.
Errata can be sent to <editor@xmpp.org>.
The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".
1. HSLuv <http://www.hsluv.org/>.
2. RFC 3269: UTF-8, a transformation format of ISO 10646 <http://tools.ietf.org/html/rfc3269>.
3. RFC 3174: US Secure Hash Algorithm 1 (SHA1) <http://tools.ietf.org/html/rfc3174>.
4. XEP-0165: Best Practices to Prevent JID Mimicking <https://xmpp.org/extensions/xep-0165.html>.
5. BT.601: Studio encoding parameters of digital television for standard 4:3 and wide screen 16:9 aspect ratios <https://www.itu.int/rec/R-REC-BT.601-7-201103-I/en>
6. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.
7. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <https://xmpp.org/registrar/>.
Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/
Remove anything except the Hue generation from the specification. The other parts were user interface suggestions which are out of scope for the XSF standards process.
Fix CVD rules: they were incorrect in the last update.
Update test vectors after CVD fix.
Add note about floating-point modulo operator implementation interoperability.
Switch from custom YCbCr-based algorithm to HSLuv.
Prioritize bare JIDs over nicknames.
Write down normalization rules.
Fix a typo. (thanks zinid)
Use different formulas for Color Vision Deficiency correction, as suggested by Marcus Waldvogel.
Update test vectors.
Clarify generation of the angle.
Prioritize nicknames over bare JIDs.
Add rationale for new palette mapping algorithm introduced in 0.3.
Fix wording in angle generation section which did still use CRC32. Rework palette mapping after with implementation experience.
Move to SHA-1 as mixing function; Properly reference BT.601 and include constants in text; Prefer bare JID over roster name when selecting the hash function input; Editing.
Accepted as Experimental by Council.
First draft.
END