How to properly create another fallback service providing 'nicer' avatars

Hi,

Because I don't like any of the default avatars for either Gravatar or Libravatar, I'm trying to get go-libravatar to return an error and/or empty string and/or something that I can check for 'avatar not available' — so that I can use go-unicornify instead.

Unfortunately, this seems not to be that easy. Although there are certain pre-defined constants (e.g. "mm" for the Mystery Man, and so forth for all the usual default Gravatar images) and a comment saying that these are used as the defaultURL (or defURL) when everything else fails, there seems no way to choose any of those options anywhere. In particular, the first such option is exactly what I want: HTTP404 = "404", which ought to return 404 when no avatar was found for such a user.

I cannot find an option to 'set' this defaultURL; it's an unexported field which has no access method. Maybe it's implicit in some weird way, but the truth is that go-libravatar will always return an avatar, even if it's the default one:

For my use case, though, there is a workaround that sort of 'fixes' the issue for now, which is basically to use for the fallback server unicornify.pictures (a 3rd-party service) instead of leaving the default at seccdn.libravatar.org, i.e. using a service as opposed to local generation:

avt.SetSecureFallbackHost("unicornify.pictures")

This works because the underlying technology behind unicornify.pictures uses basically the same URI structure as Gravatar and/or Libravatar; if the attempt to contact the 'main' server fails (because there is nothing stored at the 'main' (cdn.libravatar.org) server, then it falls back to the secondary server; any avatar providers using roughly the same API/URI structure will therefore work.

The problem, for me, is that this means that I would have to do one of two things:

Either depend on another 3rd-party service (besides Libravatar itself) which might be up or down; does not generate exactly what I want (the quality of unicornify.pictures is inferior to what is generated by go-unicornify); and if the Libravatar main host is down/slow, then, instead of falling back to another Libravatar backup server, it will return an unicorn — which might surprise an end-user that has a Gravatar. Theoretically this could be avoided by doing a local cache of avatars (it will also mean less traffic is requested to third parties).
Or, alternatively, build a full-blown federated service of my own, which generates unicorns locally; this is, indeed, possibly the way I'll go (since I use Gin, it might even make more sense that way) — because checking for a federated avatar takes precedence to calling the Libravatar service, so I won't need to rely on them being up.

Note that this is not really an 'issue'. As said, there are workarounds to accomplish what I wish. However, maybe there is a simpler way to accomplish the same thing without having to 'reinvent the wheel' — namely, the ability to access defURL and set it to HTTP404, for instance, thus allowing me to check if I've received the string 404 or a valid URI for an avatar, and proceed accordingly.

Thank you so much for the work put into this library!