voter default avatars are not stable on changes to the default avatar set

[homsar]

Ideally we might want to be able to add more options for the default avatar without affecting existing users' avatars. Currently this isn't possible (unless the hash of the uid happens to be less than the length of the list of avatars and new avatars are added at the end).

[colons]

this is a fair description of a problem, but im really struggling to imagine how it'd be possible and not horrible to resolve it

how can you have a deterministic hash that, over time, gains more output possibilities? even if we did this by, i dunno, having a cutoff for account creation that changes which hash we use, is it not mean to older accounts to not let them get a stab at one of the new ones?

[homsar]

how can you have a deterministic hash that, over time, gains more output possibilities?

You don't—the hash remains the same, but the value you get when you turn it to an integer and modulo it with the length of a list changes with the length of the list.

Edit: I've just realised I think I mis-parsed your sentence and hadn't spotted how the issue could occur rather than thought it wouldn't be possible to resolve.

even if we did this by, i dunno, having a cutoff for account creation that changes which hash we use, is it not mean to older accounts to not let them get a stab at one of the new ones?

I think you'd need to move the decision point on what image is used. One possible flow would be:

• At account creation time, the filename/url of the image is computed from the account hash
  • This could also be done randomly, now it doesn't necessarily need to be deterministically reproducible
• This could either
  • be set as the current image
  • This would mean it wouldn't be guaranteed recoverable if the user replaces it later, but that I think would match most other sites with custom avatars)
  • be a separate field
  • This would mean it could be fallen back to when a user deletes their custom avatar.
  • There could be a button to allow the user to re-roll their avatar.
    • If we kept to using hashes rather than random assignments, then this could only be made visible if the filename from the hash differed from the one in the db

This approach wouldn't be stable if we wanted to completely replace the default icon set, or its naming convention. An approach that would be more stable against this would be to treat the default avatar more like a regular user icon, i.e. making a copy of it in the same directory that user uploaded avatars and avatar taken from Twitter go.

[colons]

i'm closing this until we have plans to change the default avatar set, at which point we can implement a migration to retain pre-change ones. i don't want to have machinery in place to handle a situation that we currently have no intention of ever encountering, and are entirely in control of