@libravatar are you aware of WKD? Just in case, it's a standard for putting cryptographic keys on personal servers behind a URL that can be computed based on the identifier. So knowing just the identifier "email@example.com", you can easily download bob's key from his server on domain.tld
No need for a centralized service.
Do you happen to know if there's a similar thing for avatars? If you have a personal server, you can easily store an image there
The main problem there is currently that most software, built for gravatar, will just replace it with the backup CDN infrastructure for libravatar and ignore the federated part. And of course in the browser the discovery of SRV records is rather limited, but not impossible.
@libravatar reading the API documentation, I think libravatar's federated approach is not entirely what I was looking for.
It's great considering the alternative!
But every request still needs to be processed by a libravatar server, right? So the end-user must set DNS records and host a server implementation, correct?
@libravatar WKD on the other hand is just a simple file hosted on a server, accessible by a predictable URL. No need to install a WKD server or set any DNS records.
This is an attempt to lower barriers of entry. Do you happen to know if there's any work in this direction?
I built a pure-nginx based implementation a while ago: https://git.shivering-isles.com/shivering-isles/libravatar-nginx
It obviously lacks some features but nothing critical. Should be enough for most federated hosters.
There had been an earlier libravatar issue and at that moment, I had to put it on hold because of (poor) code design choices I had made 😐
With the Keyoxide 3.0.0 rewrite, this is now feasible. We must give key holders the choice of avatar provider. But I wouldn't mind setting defaults that favor decentralized options!
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!