user configurable display name colors

[HarHarLinks]

Suggestion This suggestion already exists as a feature request by @compu42 to element at vector-im/element-meta#841. Since it requires an MSC, I will summarize here. This feature should be considered optional.

There are a couple reasons for supporting this feature, including:

• self expression and customization make a user feel at home
• visual identification ("grepping") thanks to a wider variety of colors
• de-clashing colors in DMs and small groups
• recognizeability beyond the matrix ecosystem
• it is a common feature in other chat clients/systems and a common request

Implementation ideas and details:

• Clients should offer the theme's predefined colors via a palette. This sets the value to a color name, which another client/theme may interpret differently, but it suggests that a value red should resemble a vaguely reddish tone in context of the theme. Advanced values like css color codes or a similar basic format may be allowed.
• Spec should mention that clients should offer the ability to override/disable this optional feature (completely, or arbitrary sublevels), for accessibility and other reasons. vector-im/element-web#13102
  • In the end, clientside UX of a colorblind user supersedes me wanting to tell them my color.
• In case the user has no avatar, the fallback should use the same color
• The feature should integrate with global, space, and room profiles. Essentially at every level you could change your display name and avatar, you can now also change your color the same way.
• The feature should integrate with badges or their evolution-to-come in spaces (roles?, ...)
  • For example, admins of discord "servers" often manage user's colors as a side effect of their role and permission level, thus being able to manage other user's color within the space they administer. The rules on how to apply this can probably follow the badges.

Counter-arguments

• Most colours people will choose will not play well with themes
  • Clients would offer a palette of theme-defined colors as they exist today
  • Clients should offer to disable this optional feature and instead autogenerate or different mechanism. E.g. correct the colors to something more fitting, e.g. choose closest theme-defined color instead.
  • It may be considered a feature by some to e.g. have an invisible name. If a client's UI is so bad that this is 100% unrecognizable, then the client has bigger problems.
• This also begins to feature creep, what if someone wants an animated rainbow name?
  • Colored names already are a thing. This is a reasonable and clear limit which fulfills common expectations.

[amytimed]

I think this should be implemented and would greatly benefit Matrix

[HarHarLinks]

For reference, in the last couple versions (at time of writing) of Element Android https://github.com/vector-im/element-android/pull/2614, it is possible to "Override nick color" of all users including yourself on a per-room basis by entering a CSS style #ABCDEF hex color value. There is a PR that mirrors the same function in the react-sdk (i.e. Element Web/Desktop): https://github.com/matrix-org/matrix-react-sdk/pull/5626

[k8ieone]

What's required to turn this into an MCS PR? This feature is totally a must-have!

[TheRedXD]

Alright, why in the world is this still an open issue and nobody has taken care of it?

In my humble opinion, the colors should be role-based or at least be changeable by the user itself, but I would prefer for them to be role-based. Upon creating a role, a user could assign it a color, so that you do not need to click on the profile to see what role this user has. It would simply be color-coded!

This implementation would give the colors an actual purpose rather than just be a randomly assigned color that you can't really change.

I'd like to see this added and in my opinion, this would greatly benefit the matrix.org experience!

[epicEaston197]

I am appalled that this has not been implemented yet. is there any good reason why this has not been implemented yet? and it seems like it's such a simple feature Like it's just epicEaston197

[KitsuneRal]

What's required to turn this into an MCS PR? This feature is totally a must-have!

The process is published here: https://spec.matrix.org/latest/proposals - anybody caring about the feature beyond leaving a "why is this not implemented" comment is welcome to write a Markdown document and submit it along the lines of that process.

[sublimeclemency]

i am looking forward to this feature!

[unknown-user-9246102101]

Order of application of potential colors are important.

1. Default - Current rules applied, hash theme dependent
2. User supplied self colorization IF set. Can minimize user intentionally bad colors or theme inapplicable by having preset hex codes in alongside a color picker and an extra click to custom at end of listing.
3. Room Admin of a particular Group/Role IF enabled to override user supplied to use particular colorpicker OR default hash.
4. Room Admin of a particular User which overrides all previous to use specific or default.
5. Accessibility settings to apply to a Role and then User.

[fevers]

What's required to turn this into an MCS PR? This feature is totally a must-have!

The process is published here: https://spec.matrix.org/latest/proposals - anybody caring about the feature beyond leaving a "why is this not implemented" comment is welcome to write a Markdown document and submit it along the lines of that process.

This was originally submitted as a proposal, and was subsequently transformed into a pull request for unknown reasons. I can't speak for anyone else here, but personally I don't understand why you would expect me to believe that wouldn't happen again, even if I did go to the trouble of figuring out how to follow the abstruse and unwieldy proposal process.

[morguldir]

This was originally submitted as a proposal, and was subsequently transformed into a pull request for unknown reasons. I can't speak for anyone else here, but personally I don't understand why you would expect me to believe that wouldn't happen again, even if I did go to the trouble of figuring out how to follow the abstruse and unwieldy proposal process.

If you’re referring to the repo move, both issues like this one, changes to the spec, and proposals used to live in the same repository. They changed that, and now the original repo is just for proposals, while the spec and things that aren’t a full proposal yet live here