Mismatched default avatar colours

[ara4n]

It's rather unintuitive that the colour of the room avatar doesn't match the user's avatar:

[rubo77]

can this be fixed easily?

maybe use an md5 hash on the comlete username and always create the colour from that?

[t3chguy]

This should also include matching the colour with the username colour in timeline

[waclaw66]

Another related problem is that avatar is not correcly depictured within browser notifications. There is shown only the solid color fill. I would suggest to use pre-rendered png avatar as another services do. That would solve both problems.

[waclaw66]

@t3chguy Do you have better solution?

[t3chguy]

I'm simply not a fan of the default avatars apps normally use, a colour and initial is much better for instant recognition than a random silhouette

[waclaw66]

I'm not talking about random silhouette, I'm in favour of current appearance too. But html representation as img and span doesn't work for notifications as I mentioned. In case of pre-rendered png (color+initial) you don't need to care about platforms (web, notification, android...).

[t3chguy]

So you want to pre-render every possible colour+letter permutation? Given that Displaynames are unicode that is a very large set of images.

[t3chguy]

Plus given that users are in control of the font their Element uses, the pre-rendered images would not be able to make use of system fonts and be fixed at just one font.

[waclaw66]

I just want to fix web notifications, that's it. If the way how other services (like Google) do that (pre-rendered png) is not feasible, then please propose better solution.

[t3chguy]

Well services like google are centralised and not end-to-end-encrypted, and don't allow you to change the font. They can just have a single copy of all pre-rendered avatars. Here you would need each Element instance to host a copy of those 100,000 * Number of Colours PNG files and you still have issues.

This is completely off-topic for this issue. This issue is about the default avatar colour generated for rooms being based on a hash of the Room ID but the one for Users is on the User ID so for DMs with a default avatar those can drift apart.

[waclaw66]

No, that's not what I say. Yes, notification image bug is offtopic. But my suggestion would fix it too. You don't need to have thousands pre-rendered images. You just pre-render the default avatar for each user on homeserver (when user is created or name changed) and save it in the same way as normal avatar picture, that's it. This is a common technique for default avatars.

[t3chguy]

Sure, you could do that. But the avatar colours are themable by the client. Like right now you could load up an Element theme and have different default avatar colours: https://github.com/aaronraimist/element-themes - this is important for branding and accessibility (colour-blindness and whatnot)

Docs: https://github.com/vector-im/element-web/blob/develop/docs/theming.md#custom-themes avatar-background-colors

Edit: I guess the point re branding is moot if it is at least configurable on the HS

[t3chguy]

Nothing to stop a Matrix homeserver doing this auto-generation, but it'd need to be specced with some way to signal to the client that their avatar is a generated one otherwise their client would continuously show a Remove button next to their avatar. Your proposal should probably go on the matrix-doc repo.

[waclaw66]

I wasn't aware of local default avatar theming (same theme for default avatars from another homeservers). This is the only obstacle for my solution. Remove button is not a problem, you can add column "custom_avatar" to the db and show/hide remove button according that. I think it's time to stop the discussion, thanks for explanation. I will create new issue regarding notification image bug.

[t3chguy]

Remove button is not a problem, you can add column "custom_avatar" to the db and show/hide remove button according that.

I'm talking about using the existing spec, there's either an avatar or there isn't one, if the server is generating a default then there always would be one so there would need to be a spec extension, not merely client/server work.