#1 Randomly generated avatars resemble swastikas

Closed
opened 7 months ago by andy5995 · 18 comments

This avatar was randomly generated when I created an organization yesterday.

This avatar was randomly generated when I created an organization yesterday.
hw commented 7 months ago
Owner

This is the second time we have been notified about something like this from the generator (after some thousand random avatars).

Of course this is very discomforting, even if happening only at very low frequency. We started the avatar project https://codeberg.org/codeberg/avatars which is a port of https://avatars.dicebear.com/ from typescript to go.

If anybody has time for UI integration into gitea, this might make a nice project. All contributions welcome!

This is the second time we have been notified about something like this from the generator (after some thousand random avatars). Of course this is very discomforting, even if happening only at very low frequency. We started the avatar project https://codeberg.org/codeberg/avatars which is a port of https://avatars.dicebear.com/ from typescript to go. If anybody has time for UI integration into gitea, this might make a nice project. All contributions welcome!
Owner

In a first step we could just wire that up and replace the current generator, all users would then have a random avater which is styled like the one @hw is using.

In a second step one could allow users to regenerate their image or enter a hash themselves.

In a first step we could just wire that up and replace the current generator, all users would then have a random avater which is styled like the one @hw is using. In a second step one could allow users to regenerate their image or enter a hash themselves.

Can't you make the go app servable, and then set the config option GRAVATAR_SOURCE, like described in the gitea config?

GRAVATAR_SOURCE: gravatar: Can be gravatar, duoshuo or anything like http://cn.gravatar.com/avatar/.

Not familiar with go, so not sure what's needed here.

Can't you make the go app servable, and then set the config option GRAVATAR_SOURCE, like described in the gitea config? GRAVATAR_SOURCE: gravatar: Can be gravatar, duoshuo or anything like http://cn.gravatar.com/avatar/. Not familiar with go, so not sure what's needed here.
hw commented 7 months ago
Owner

It's probably less effort to integrate avatars in gitea?

It's probably less effort to integrate avatars in gitea?
hw commented 2 months ago
Owner
See https://codeberg.org/Codeberg/Community/issues/394
davidak commented 1 month ago

I also noticed that. After collecting many examples i came across over the time, i created an upstream issue: https://github.com/go-gitea/gitea/issues/14799

I also noticed that. After collecting many examples i came across over the time, i created an upstream issue: https://github.com/go-gitea/gitea/issues/14799
6543 commented 1 month ago
Collaborator

this lib now should be easy to integrate ... we just have to make gitea-avata-generator settable by gitea and make use of this lib.

this shouldn't be to hard to do, I just dont have time for this, but happy to help :D

this lib now should be easy to integrate ... we just have to make gitea-avata-generator settable by gitea and make use of this lib. this shouldn't be to hard to do, I just dont have time for this, but happy to help :D
6543 commented 1 month ago
Collaborator

I think this issue is unrelated to this lib and we should ship converstaion to Codeberg/Community#394

closing this for now - if I missed something, just ask for reopen :)

I think this issue is unrelated to **this** lib and we should ship converstaion to https://codeberg.org/Codeberg/Community/issues/394 closing this for now - if I missed something, just ask for reopen :)
6543 closed this issue 1 month ago
CL-Jeremy commented 1 day ago

First of all, I came to report here because the upstream issue is locked and my work is unrelated to Codeberg/Community#394.

Not sure if my attempt in the past few days were worth it, but I talked to the developer of the library currently used in Gitea (in Chinese though – the whole lib is commented in Chinese, and I'm taking the responsibility to maintain my fork) about the viability to modify/tweak the library for as a drop-in replacement in the current code base of Gitea.

What I'm aiming at, for the time being, is to keep the algorithm largely as is (as @zeripath summarized in upstream https://github.com/go-gitea/gitea/issues/14799#issuecomment-786107766, while not following his advice to change the order of generation), but try to work on the blocks to make sure it is visually complex, including as few rectangular elements as possible, and make the center take up more space to dilute the effect of the rotating edges (inspired by this blog post – it seems WordPress dealt with the issue in this way). The goal is to have this also be the local replacement of Gravatar et al. for use in e. g. Codeberg.

The result is, both of us have made some changes to the existing code. The upstream developer gave me some advice in making it more like the design of Gravatar identicon (original design from WordPress), while he also took a look into the code himself and made a few tweaks to the previous implementation from 6 years ago, refactored it, and added a few new image building blocks that I happen to like and have chosen to include in my fork. Now my code is API compatibile with the upstream's latest version, meaning that merging upstream changes are easy, while new modifications could be done at the side of Gitea (or, if I may, under my maintenance at your request, should issues emerge from my modification, such as if there are still unwelcomed icons getting generated).

To demonstrate my work, here is a batch of test data produced by running go test on my forked repo:

make-0 make-1 make-2 make-3 make-4 make-5 make-6 make-7 make-8 make-9 make-10 make-11 make-12 make-13 make-14 make-15 make-16 make-17 make-18 make-19

draw-0 draw-1 draw-2 draw-3 draw-4 draw-5 draw-6 draw-7 draw-8 draw-9 draw-10 draw-11 draw-12 draw-13 draw-14 draw-15 draw-16 draw-17 draw-18 draw-19

identicon-0 identicon-1 identicon-2 identicon-3 identicon-4 identicon-5 identicon-6 identicon-7 identicon-8 identicon-9 identicon-10 identicon-11 identicon-12 identicon-13 identicon-14 identicon-15 identicon-16 identicon-17 identicon-18 identicon-19

rand-0 rand-1 rand-2 rand-3 rand-4 rand-5 rand-6 rand-7 rand-8 rand-9 rand-10 rand-11 rand-12 rand-13 rand-14 rand-15 rand-16 rand-17 rand-18 rand-19

First of all, I came to report here because the upstream issue is locked and my work is unrelated to Codeberg/Community#394. Not sure if my attempt in the past few days were worth it, but I talked to the developer of the library currently used in Gitea (in Chinese though – the whole lib is commented in Chinese, and I'm taking the responsibility to maintain my fork) about the viability to modify/tweak the library for as a drop-in replacement in the current code base of Gitea. What I'm aiming at, for the time being, is to keep the algorithm largely as is (as [@zeripath](https://github.com/zeripath) summarized in upstream https://github.com/go-gitea/gitea/issues/14799#issuecomment-786107766, while *not* following his advice to change the order of generation), but try to work on the blocks to make sure it is visually complex, including as few rectangular elements as possible, and make the center take up more space to dilute the effect of the rotating edges (inspired by [this blog post](https://datenschmutz.net/das-unabsichtliche-hakenkreuz-zufalls-wiederbetaetigung-per-identicon/) – it seems WordPress dealt with the issue in this way). The goal is to have this also be the local replacement of Gravatar et al. for use in e. g. Codeberg. The result is, both of us have made some changes to the existing code. The upstream developer gave me some advice in making it more like the design of Gravatar identicon (original design from WordPress), while he also took a look into the code himself and made a few tweaks to the previous implementation from 6 years ago, refactored it, and added a few new image building blocks that I happen to like and have chosen to include in my fork. Now my code is API compatibile with the upstream's latest version, meaning that merging upstream changes are easy, while new modifications could be done at the side of Gitea (or, if I may, under my maintenance at your request, should issues emerge from my modification, such as if there are still unwelcomed icons getting generated). To demonstrate my work, here is a batch of test data produced by running `go test` on [my forked repo](https://codeberg.org/CL-Jeremy/identicon): ![make-0](/CL-Jeremy/identicon/raw/branch/testdata/testdata/make-0.png) ![make-1](/CL-Jeremy/identicon/raw/branch/testdata/testdata/make-1.png) ![make-2](/CL-Jeremy/identicon/raw/branch/testdata/testdata/make-2.png) ![make-3](/CL-Jeremy/identicon/raw/branch/testdata/testdata/make-3.png) ![make-4](/CL-Jeremy/identicon/raw/branch/testdata/testdata/make-4.png) ![make-5](/CL-Jeremy/identicon/raw/branch/testdata/testdata/make-5.png) ![make-6](/CL-Jeremy/identicon/raw/branch/testdata/testdata/make-6.png) ![make-7](/CL-Jeremy/identicon/raw/branch/testdata/testdata/make-7.png) ![make-8](/CL-Jeremy/identicon/raw/branch/testdata/testdata/make-8.png) ![make-9](/CL-Jeremy/identicon/raw/branch/testdata/testdata/make-9.png) ![make-10](/CL-Jeremy/identicon/raw/branch/testdata/testdata/make-10.png) ![make-11](/CL-Jeremy/identicon/raw/branch/testdata/testdata/make-11.png) ![make-12](/CL-Jeremy/identicon/raw/branch/testdata/testdata/make-12.png) ![make-13](/CL-Jeremy/identicon/raw/branch/testdata/testdata/make-13.png) ![make-14](/CL-Jeremy/identicon/raw/branch/testdata/testdata/make-14.png) ![make-15](/CL-Jeremy/identicon/raw/branch/testdata/testdata/make-15.png) ![make-16](/CL-Jeremy/identicon/raw/branch/testdata/testdata/make-16.png) ![make-17](/CL-Jeremy/identicon/raw/branch/testdata/testdata/make-17.png) ![make-18](/CL-Jeremy/identicon/raw/branch/testdata/testdata/make-18.png) ![make-19](/CL-Jeremy/identicon/raw/branch/testdata/testdata/make-19.png) ![draw-0](/CL-Jeremy/identicon/raw/branch/testdata/testdata/draw-0.png) ![draw-1](/CL-Jeremy/identicon/raw/branch/testdata/testdata/draw-1.png) ![draw-2](/CL-Jeremy/identicon/raw/branch/testdata/testdata/draw-2.png) ![draw-3](/CL-Jeremy/identicon/raw/branch/testdata/testdata/draw-3.png) ![draw-4](/CL-Jeremy/identicon/raw/branch/testdata/testdata/draw-4.png) ![draw-5](/CL-Jeremy/identicon/raw/branch/testdata/testdata/draw-5.png) ![draw-6](/CL-Jeremy/identicon/raw/branch/testdata/testdata/draw-6.png) ![draw-7](/CL-Jeremy/identicon/raw/branch/testdata/testdata/draw-7.png) ![draw-8](/CL-Jeremy/identicon/raw/branch/testdata/testdata/draw-8.png) ![draw-9](/CL-Jeremy/identicon/raw/branch/testdata/testdata/draw-9.png) ![draw-10](/CL-Jeremy/identicon/raw/branch/testdata/testdata/draw-10.png) ![draw-11](/CL-Jeremy/identicon/raw/branch/testdata/testdata/draw-11.png) ![draw-12](/CL-Jeremy/identicon/raw/branch/testdata/testdata/draw-12.png) ![draw-13](/CL-Jeremy/identicon/raw/branch/testdata/testdata/draw-13.png) ![draw-14](/CL-Jeremy/identicon/raw/branch/testdata/testdata/draw-14.png) ![draw-15](/CL-Jeremy/identicon/raw/branch/testdata/testdata/draw-15.png) ![draw-16](/CL-Jeremy/identicon/raw/branch/testdata/testdata/draw-16.png) ![draw-17](/CL-Jeremy/identicon/raw/branch/testdata/testdata/draw-17.png) ![draw-18](/CL-Jeremy/identicon/raw/branch/testdata/testdata/draw-18.png) ![draw-19](/CL-Jeremy/identicon/raw/branch/testdata/testdata/draw-19.png) ![identicon-0](/CL-Jeremy/identicon/raw/branch/testdata/testdata/identicon-0.png) ![identicon-1](/CL-Jeremy/identicon/raw/branch/testdata/testdata/identicon-1.png) ![identicon-2](/CL-Jeremy/identicon/raw/branch/testdata/testdata/identicon-2.png) ![identicon-3](/CL-Jeremy/identicon/raw/branch/testdata/testdata/identicon-3.png) ![identicon-4](/CL-Jeremy/identicon/raw/branch/testdata/testdata/identicon-4.png) ![identicon-5](/CL-Jeremy/identicon/raw/branch/testdata/testdata/identicon-5.png) ![identicon-6](/CL-Jeremy/identicon/raw/branch/testdata/testdata/identicon-6.png) ![identicon-7](/CL-Jeremy/identicon/raw/branch/testdata/testdata/identicon-7.png) ![identicon-8](/CL-Jeremy/identicon/raw/branch/testdata/testdata/identicon-8.png) ![identicon-9](/CL-Jeremy/identicon/raw/branch/testdata/testdata/identicon-9.png) ![identicon-10](/CL-Jeremy/identicon/raw/branch/testdata/testdata/identicon-10.png) ![identicon-11](/CL-Jeremy/identicon/raw/branch/testdata/testdata/identicon-11.png) ![identicon-12](/CL-Jeremy/identicon/raw/branch/testdata/testdata/identicon-12.png) ![identicon-13](/CL-Jeremy/identicon/raw/branch/testdata/testdata/identicon-13.png) ![identicon-14](/CL-Jeremy/identicon/raw/branch/testdata/testdata/identicon-14.png) ![identicon-15](/CL-Jeremy/identicon/raw/branch/testdata/testdata/identicon-15.png) ![identicon-16](/CL-Jeremy/identicon/raw/branch/testdata/testdata/identicon-16.png) ![identicon-17](/CL-Jeremy/identicon/raw/branch/testdata/testdata/identicon-17.png) ![identicon-18](/CL-Jeremy/identicon/raw/branch/testdata/testdata/identicon-18.png) ![identicon-19](/CL-Jeremy/identicon/raw/branch/testdata/testdata/identicon-19.png) ![rand-0](/CL-Jeremy/identicon/raw/branch/testdata/testdata/rand-0.png) ![rand-1](/CL-Jeremy/identicon/raw/branch/testdata/testdata/rand-1.png) ![rand-2](/CL-Jeremy/identicon/raw/branch/testdata/testdata/rand-2.png) ![rand-3](/CL-Jeremy/identicon/raw/branch/testdata/testdata/rand-3.png) ![rand-4](/CL-Jeremy/identicon/raw/branch/testdata/testdata/rand-4.png) ![rand-5](/CL-Jeremy/identicon/raw/branch/testdata/testdata/rand-5.png) ![rand-6](/CL-Jeremy/identicon/raw/branch/testdata/testdata/rand-6.png) ![rand-7](/CL-Jeremy/identicon/raw/branch/testdata/testdata/rand-7.png) ![rand-8](/CL-Jeremy/identicon/raw/branch/testdata/testdata/rand-8.png) ![rand-9](/CL-Jeremy/identicon/raw/branch/testdata/testdata/rand-9.png) ![rand-10](/CL-Jeremy/identicon/raw/branch/testdata/testdata/rand-10.png) ![rand-11](/CL-Jeremy/identicon/raw/branch/testdata/testdata/rand-11.png) ![rand-12](/CL-Jeremy/identicon/raw/branch/testdata/testdata/rand-12.png) ![rand-13](/CL-Jeremy/identicon/raw/branch/testdata/testdata/rand-13.png) ![rand-14](/CL-Jeremy/identicon/raw/branch/testdata/testdata/rand-14.png) ![rand-15](/CL-Jeremy/identicon/raw/branch/testdata/testdata/rand-15.png) ![rand-16](/CL-Jeremy/identicon/raw/branch/testdata/testdata/rand-16.png) ![rand-17](/CL-Jeremy/identicon/raw/branch/testdata/testdata/rand-17.png) ![rand-18](/CL-Jeremy/identicon/raw/branch/testdata/testdata/rand-18.png) ![rand-19](/CL-Jeremy/identicon/raw/branch/testdata/testdata/rand-19.png)
fnetX commented 1 day ago

AFAICT upstream discussed an option to easily switch avatar generators and therefore a diversity of options would probably be desirable, so thank you for your work here.

An idea for Codeberg might be a middleware that randomly chooses a generator. If icons are from one generator, they are usually quite similar (no matter if dicebears or this thingy). I would find it quite funny if we had the additional diversity of many default generators.

By the way, I was also looking forward to other generators because the current one creates some graphical issues (I noticed there are sometimes random spaces between parts of the image, but not really regularly but only on the right side for example or some gapps on one side are larger etc) - did you notice this as well or did you make such improvements (may be by coincidence)?

Examples:



AFAICT upstream discussed an option to easily switch avatar generators and therefore a diversity of options would probably be desirable, so thank you for your work here. An idea for Codeberg might be a middleware that randomly chooses a generator. If icons are from one generator, they are usually quite similar (no matter if dicebears or this thingy). I would find it quite funny if we had the additional diversity of many default generators. By the way, I was also looking forward to other generators because the current one creates some graphical issues (I noticed there are sometimes random spaces between parts of the image, but not really regularly but only on the right side for example or some gapps on one side are larger etc) - did you notice this as well or did you make such improvements (may be by coincidence)? Examples: ![](https://codeberg.org/avatars/afba997185586d1ad0cbbcb8cef99cfc) ![](https://codeberg.org/avatars/bf083f32a1b5f376c41a0c4b4014cb7c) ![](https://codeberg.org/avatars/45815c9f6363de7f99d92970ee28899f) ![](https://codeberg.org/avatars/8a5b73a0ac28d9b3135e8a023026e499)
CL-Jeremy commented 1 day ago

did you notice this as well or did you make such improvements (may be by coincidence)?

Yes, I did. The aforementioned discussion (here: https://github.com/issue9/identicon/issues/6, unfortunately in Chinese) is actually titled "Wish to have an option to remove borders" (as in surrounding each block). The most significant improvement by the author was to use integer values instead of floating point, as there isn't dithering or interpolation involved anyway. Another was to allow points on the borders of each polygon to be included while drawing (previously only those truely inside the borders were drawn in forground color). After those changes (plus my own change to remove the intentional borders around sqares), this has become a non-issue.

You can refer to the individual commits in my repo regarding this. Upstream is kept at 3x3, so a remainder is still kept as a gap on the right (still a big improvement as there won't be rounding errors anymore). I chose to use 4x4 to eliminate that problem as well.

> did you notice this as well or did you make such improvements (may be by coincidence)? Yes, I did. The aforementioned discussion (here: https://github.com/issue9/identicon/issues/6, unfortunately in Chinese) is actually titled "Wish to have an option to remove borders" (as in surrounding each block). The most significant improvement by the author was to use integer values instead of floating point, as there isn't dithering or interpolation involved anyway. Another was to allow points on the borders of each polygon to be included while drawing (previously only those truely inside the borders were drawn in forground color). After those changes (plus my own change to remove the intentional borders around sqares), this has become a non-issue. You can refer to the individual commits in my repo regarding this. Upstream is kept at 3x3, so a remainder is still kept as a gap on the right (still a big improvement as there won't be rounding errors anymore). I chose to use 4x4 to eliminate that problem as well.
CL-Jeremy commented 1 day ago

I would find it quite funny if we had the additional diversity of many default generators.

Gitea does support many generators out of the box, most importantly the Libravatar service (free and open-source, now sponsored by the Fedora project). They are all disabled in Codeberg, presumably for maximum freedom (Gravatar is non-free), reliability (Gravatar is inaccessible from Mainland China, the once suggested Chinese alternative has been shut down, and Libravatar was once to be shut down as well) and simply for being standalone. I believe my fork as a drop-in replacement of the existing library could at least be a fall-back solution for its simplicity (Note that both Libravatar and Gravatar support multiple fall-back algorithms when the input hash has no custom avatar associated with it).

> I would find it quite funny if we had the additional diversity of many default generators. Gitea does support many generators out of the box, most importantly the [Libravatar service](https://www.libravatar.org/) (free and open-source, now sponsored by the Fedora project). They are all disabled in Codeberg, presumably for maximum freedom (Gravatar is non-free), reliability (Gravatar is inaccessible from Mainland China, the once suggested Chinese alternative has been shut down, and Libravatar was once to be shut down as well) and simply for being standalone. I believe my fork as a drop-in replacement of the existing library could at least be a fall-back solution for its simplicity (Note that both Libravatar and Gravatar support multiple fall-back algorithms when the input hash has no custom avatar associated with it).
fnetX commented 1 day ago

I was talking about having multiple integrated generators at the same time, not about enabling more 3rd party services.

This way, the default / fallback avatars would have a lot more diversity and you could remember users better because they don't just have different colours or some slightly different patterns, but there are users that look completely different by default.

I was talking about having multiple integrated generators at the same time, not about enabling more 3rd party services. This way, the default / fallback avatars would have a lot more diversity and you could remember users better because they don't just have different colours or some slightly different patterns, but there are users that look completely different by default.
CL-Jeremy commented 1 day ago

Of course, that's also what upstream (notably @6543) is planning for, though some have expressed concerns on the potential controversy of DiceBear avatars in the upstream issue, which I totally understand.

Anyway, I crafted three avatars by hand just now. They don't happen to raise your concern, do they?

0 1 2

Of course, that's also what upstream (notably @6543) is planning for, though some have expressed concerns on the potential controversy of DiceBear avatars in the upstream issue, which I totally understand. Anyway, I crafted three avatars by hand just now. They don't happen to raise your concern, do they? ![0](/attachments/02faa24d-75a0-447f-bf35-dbb17a0e5020) ![1](/attachments/da0ed3d3-0191-42a7-a897-fcab51ae7df5) ![2](/attachments/9ae5268d-c05f-440e-aba4-23319479eebf)
davidak commented 22 hours ago

@CL-Jeremy i think they are still problematic and can easily be recognized as swastica shape.

@CL-Jeremy i think they are still problematic and can easily be recognized as swastica shape.
6543 commented 1 hour ago
Collaborator

well I'm happy if somebody would pick upstream issue up ...

working on other things atm

well I'm happy if somebody would pick upstream issue up ... working on other things atm
hw commented 59 minutes ago
Owner

@CL-Jeremy : have you seen the work on alternative avatar generators for 1.14? Would it make sense to join contributions to avoid diverging efforts?

@CL-Jeremy : have you seen the work on alternative avatar generators for 1.14? Would it make sense to join contributions to avoid diverging efforts?

@CL-Jeremy : have you seen the work on alternative avatar generators for 1.14? Would it make sense to join contributions to avoid diverging efforts?

I sure have. I mean, isn't this repo a candidate for that 😆. I just don't want to give up on the original library so soon. I like the geometric design a lot since it came out a decade ago and personally don't want to deprecate it.

Also, I'm just saying this, but I'm relatively new to coding Go. My previous contributions to Gitea focused specifically on frontend and I haven't got much understanding of Gitea's architechture to integrate things (I suppose it won't be hard, and other contributors at upstream just haven't really gone though the decision process on how it should be done). I've worked on the said library to partly to practise as it's relatively straightforward to me.

> @CL-Jeremy : have you seen the work on alternative avatar generators for 1.14? Would it make sense to join contributions to avoid diverging efforts? I sure have. I mean, isn't this repo a candidate for that 😆. I just don't want to give up on the original library so soon. I like the geometric design a lot since it came out a decade ago and personally don't want to deprecate it. Also, I'm just saying this, but I'm relatively new to coding Go. My previous contributions to Gitea focused specifically on frontend and I haven't got much understanding of Gitea's architechture to integrate things (I suppose it won't be hard, and other contributors at upstream just haven't really gone though the decision process on how it should be done). I've worked on the said library to partly to practise as it's relatively straightforward to me.
Sign in to join this conversation.
No Label
No Milestone
No Assignees
8 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.