XEP-0392 implementation: colorize nicknames

[JohnXLivingston]

This PR implements XEP-0392 (Consistent Color Generation) for message author nicknames, and for MUC occupant list.

This XEP compliance is tracked here: #1349

This PR does not implement the default avatar color (but it should be easy to add it).

I added a configuration settings to enable this feature (colorize_username). By default i set it to false, but this can be changed if you think it is worth enabling it be default.

Here are some screenshot (the ConverseJS theme is not the default one on my project, but it is close enough to have a good idea of the result):

Note: the XEP is currently in "last call for comment" state, ending the 2024-03-25

[jcbrand]

Thanks @JohnXLivingston, this is great, although if it was up to me, I'd only make default avatars coloured, and not the nicknames as well.

Personally I find the coloured nicknames quite garish. Perhaps the feature could be extended to allow either nicknames or avatars or both to be coloured.

That said, I could see someone defending colouring the nicknames as a security feature (i.e. making it more difficult to impersonate someone).

[jcbrand]

To keep the build small and avoid loading unwanted code (e.g. if colorize_nicknames is false), I think we should see if this can be loaded dynamically.

See for example here:

converse.js/src/headless/plugins/emoji/index.js

Line 80 in d4dfc37

const module = await import(/*webpackChunkName: "emojis" */ './emoji.json');

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import

Hopefully it just works and Webpack should know what to do (i.e. create a separate file for Hsluv in ./dist).

[JohnXLivingston]

oh, great! Will fix. I just have to check if making the colorize function async is possible.

[JohnXLivingston]

Hsluv unminified is less that 12k, i think that it does not worth the overload of an additional http request.

[JohnXLivingston]

Thanks @JohnXLivingston, this is great, although if it was up to me, I'd only make default avatars coloured, and not the nicknames as well.

In my project, i generate random avatars for user that don't have avatars. So i don't need colored avatars. (but that is just my case, and as i said, it will be easy to re-use the colorize function to apply to default avatar SVG).

Personally I find the coloured nicknames quite garish. Perhaps the feature could be extended to allow either nicknames or avatars or both to be coloured.

I also found it quite garish, but i got good feedbacks on Mastodon.

We could add another settings for avatars (colorize_default_avatar?), or change the settings to colorize that could get multiple values: none, default_avatar, username, both.
What do you prefer?
The second solution seems elegant, but will not work if we want to add a third object to colorize (i don't know if this will be the case one day).

That said, I could see someone defending colouring the nicknames as a security feature (i.e. making it more difficult to impersonate someone).

Yes, and i think it will be usefull in my use case.

[jcbrand]

@JohnXLivingston I've rebased this PR to get the tests green.