api!: Contact::get_color(): Preserve address-based color hue for SELF

[iequidoo]

No description provided.

[link2xt]

I have created a topic on the forum for discussion https://support.delta.chat/t/setting-the-color-of-own-nickname/4068

So, introduce Config::Selfcolor for that, we can add a UI later. Users can set it meanwhile using deltachat-repl, it's not supposed to be a frequent operation anyway.

It does not make sense to introduce options only in the core that are not planned in the UIs. Most users cannot use deltachat-repl, so any such option is essentially a developer-only option.

Looking at #7127 (comment) I am also not sure if setting a self-color locally is what is the user requested. I guess it is a request to copy Telegram feature and users expect that the color they choose is visible for other users, not only for themselves. And if we send the color to others, we need to either limit the colors to predefined set or have a function similar to Twitch "Readable colors" to enforce that the text is readable.

[iequidoo]

I does not make sense to introduce options only in the core that are not planned in the UIs. Most users cannot use deltachat-repl, so any such option is essentially a developer-only option.

Ok, then this PR doesn't make sense w/o a migration preserving the old address-based self-color. Even if we don't send this color to others, it may make sense because there will be probably less complains (and i guess some users were creating their current profiles until they get the color they like).

I guess it is a request to copy Telegram feature and users expect that the color they choose is visible for other users

It's an interesting topic, but probably indeed better to be discussed at https://support.delta.chat/t/setting-the-color-of-own-nickname/4068.

EDIT: It will be difficult to preserve the old address-based color accurately because the old code generating colors is already dropped, but we can preserve the color angle (hue).

[iequidoo]

Added a migration, but overall the PR has questionable value (mainly because the color is only preserved locally), so feel free to close it. Maybe the useful part of this is that Contact::get_color() becomes async like Chat::get_color(), i.e. the API looks more uniform.

[r10s]

i agree in the questionable value, and would close this PR as well. currently, there are no plans for introducing smth in the ui

let's focus more on calls, multi-transport steps, bugfixes

[iequidoo]

i agree in the questionable value, and would close this PR as well. currently, there are no plans for introducing smth in the ui

This PR isn't about introducing an UI to change the self-color. It just preserves the old address-based color so that users don't complain that the color changes because now it's calculated from the key fingerprint. But the problems here are:

• The color is only preserved locally, others will see the new color anyway.
• It's not preserved accurately, only the hue (angle) is preserved.

[r10s]

we had one color change before some years ago, i do not expect much backlash here, and even if, it does not outweight effort etc